I think the length is correct. I forgot to tell, I disabled the LLC dissector. Before I did, it attempted to decode the first 4 bytes, but failed to to anything meaningfull: DSAP unknown, SSAP unknown.
I am going out of town today, will answer in full when I am back on monday next week. Thank you for the help! wbr, Aleksander Veksler Siterer Guy Harris <[EMAIL PROTECTED]>: > > On Sep 6, 2007, at 3:23 PM, Aleksander Veksler wrote: > >> Anyone have tips on how you loose a few bytes? I get 12 bytes >> between the Ethernet header and IP header. > > That's the "length field" version of the Ethernet header, not the > "type field" version, so those 12 bytes appear to be... > >> This means that wireshark does not recognize the IP header as, and I >> can't use any of the wireshark's advanced features. >> >> Anyone know how to get rid of those bytes, or perhaps what they are? > > ...4 bytes of mysterious crap followed by an 802.2 header for SNAP > followed by a SNAP header: > > 95 e5 5c 00 - 4 bytes of crap > aa - destination SAP of an 802.2 header > aa - source SAP of an 802.2 header; both of them being 0xaa means > it's a SNAP frame > 03 - control field of an 802.2 header, indicating it's a UI frame > 00 00 00 - OUI field of a SNAP header, indicating that this is > encapsulated Ethernet > 08 00 - protocol ID field of a SNAP header, which is an Ethertype for > encapsulated Ethernet; that's the Ethertype for IPv4 > > 802.11 packets use 802.2, so that's probably the 802.2 header plus > 802.2 payload (SNAP header and packet data) that the raw frame had. > >> * My card is Intel Pro/Wireless 3945ABG > > So is this on some flavor of Windows? The title bar looks Windowsish, > but some UN*X+11 window managers have Windowish title bars. However, > I'd expect UN*X 802.11 drivers to be better-behaved than this. > >> * The wireless switch is D-Link DIR-635 > > That probably doesn't matter. > >> * The problem only happens in promiscuous mode, and only to the >> packets not directed to my computer > > For Windows (at least prior to NT 6.0^H^H^H^H^H^HVista), the OS > networking stack has no understanding of 802.11, so the adapter and > driver turn received packets (or, at least, the ones with a SNAP > header) into fake Ethernet packets (with the "type field" version of > the Ethernet header, so they're not limited to 1500 bytes or less of > payload) and supply that to NDIS, so that's what WinPcap and thus > Wireshark sees. > > I suspect that the Intel adapter and its driver do that only for > packets intended for the host, not for packets that would have been > discarded if you hadn't been in promiscuous mode. It appears to do > other crap for promiscuously-received packets. > > We'd probably have to throw in a heuristic hack to try to recognize > those packets. I'm not sure why the 802.2 LLC dissector didn't do any > dissection of that packet; if you could send us a capture file > containing one of those packets (if you still have the capture > containing that frame, just save that frame into a capture file), we > could try to find some way of detecting those frames and dissecting > the payload as 802.2 starting after the 4 bytes of crap. > _______________________________________________ > Wireshark-users mailing list > Wireshark-users@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-users > _______________________________________________ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
