Wireshark-users: Re: [Wireshark-users] Question regarding oversized frames

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 5 Sep 2006 17:29:16 -0700

On Sep 5, 2006, at 3:56 PM, Grant Mills wrote:

On 9/5/06, Grant Mills <gmills@xxxxxxxx> wrote:

I'm trying to view some packets generated by a SmartBits.

I generate a 1514 byte frame on the Smart Bits.  This goes out and
ethereal displays it.  The device on the other end, loops it back
(Swaps Src & Dest MAC & IP Addrs.)  The SmartBits capture tools
receives and displays the frame.  Wireshark does not display the

packet. There is one slight modification to frame. Due to a hardware

limitation on the DUT, the return frame is now 1516 bytes (not

including CRC.) We're forced to use 4 byte alignment on our transmit.

Gak. Did whoever makes the hardware that imposes that requirement hire one of the designers of the DEC Tulip Ethernet chips, or something such as that?

(Those chips had to start receiving Ethernet packets on a 4-byte boundary in memory. Unfortunately, given that an Ethernet header is 14 bytes long, that means that the Ethernet payload is *not* aligned on a 4-byte boundary in a received packets, which was probably only a minor performance hit in the x86-based machines we made at Network Appliance, but a *real* pain in the Alpha-based machines.

Yes, Alpha. The chips made by, err, umm, the same company that made the Tulip Ethernet chip.

But I digress.)

While I was able to determine that 0.10.7 does indeed display the
frames, I also determined that the problem does not exist there.

As I expected.

I installed 0.10.7 with a different version of winpcap and did not see
the oversized frames.  My journey just took a dive into either
winpcap, the driver or the NIC hardware.

I'm continuing to investigate, but would like a shove in the right direction.

My guess would be it's the driver or the NIC hardware. The only way I can think of for testing this involve using the same NDIS code path that WinPcap uses or using some commercial network analyzer that uses a different NDIS code path (unlikely, if it uses NDIS) or doesn't use NDIS at all (which, unfortunately, probably means it also uses a different driver).