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] http://www.wireshark.org/mailman/listinfo/wireshark-users
