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).
