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.
