Wireshark-users: Re: [Wireshark-users] Question regarding oversized frames
From: Guy Harris <[email protected]>
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 <[email protected]> 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).