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 > Wireshark-users@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-users >
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. Thanks. -- Grant Mills [EMAIL PROTECTED] _______________________________________________ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
