Wireshark-users: Re: [Wireshark-users] 12 bytes before the IP header
From: Guy Harris <[email protected]>
Date: Thu, 6 Sep 2007 19:05:18 -0700
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.