Wireshark-users: Re: [Wireshark-users] Question regarding oversized frames
From: "Grant Mills" <[email protected]>
Date: Tue, 5 Sep 2006 19:57:07 -0700
On 9/5/06, Guy Harris <[email protected]> wrote:
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).
Wireshark-users mailing list
[email protected]

I'm pretty confident that it's in the driver.  Windows XP with WinPcap
(didn't note which version) couldn't capture the packets.  Under
Linux, everything worked fine.  At least I know I'm not going to get
tasked with attempting to fix the Windows Driver.


Grant Mills
[email protected]