12 bytes before the IP header

Hi Aleksander,

I have no idea at this point in time on what they are, but James Small
has a good procedure on how to "get rid of the extra bytes". Have a look
at his mail:

http://www.wireshark.org/lists/wireshark-users/200707/msg00191.html

Hope this helps, Cheers,
Sake

Aleksander Veksler

2007-09-07 08:54:36 UTC

Hello again, and thank you for the quick response!

This looks like a solution, yes. There seems to be no http traffic
over my network right now (except mine), but it looks like the
solution for the problem. I have seen the DLT_USER before, but I
thought the header_size was supposed to be the length of the
proprietary header.

BTW, it seems there is a bug in Windows version, the payload_header
gets overwritten by random data. It's 1800 in the capture I attached,
but sometimes it will be just random symbols, which seem to come from
the capture data. Looks like an array out of bounds somewhere.. It is
not a big problem, as it doesn't happen each time.

Thank you very much for the help, I'm going out of town now, but I'll
mail back if this works!

Aleksander

Post by Sake Blok
Hi Aleksander,

I have no idea at this point in time on what they are, but James Small
has a good procedure on how to "get rid of the extra bytes". Have a look
http://www.wireshark.org/lists/wireshark-users/200707/msg00191.html
Hope this helps, Cheers,
Sake
_______________________________________________
Wireshark-users mailing list
http://www.wireshark.org/mailman/listinfo/wireshark-users

Guy Harris

2007-09-07 02:05:18 UTC

Post by Aleksander Veksler
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...

Post by Aleksander Veksler
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.

Post by Aleksander Veksler
* 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.

Post by Aleksander Veksler
* The wireless switch is D-Link DIR-635

That probably doesn't matter.

Post by Aleksander Veksler
* 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.

Aleksander Veksler

2007-09-07 09:00:30 UTC

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

Post by Guy Harris

Post by Aleksander Veksler
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...

...4 bytes of mysterious crap followed by an 802.2 header for SNAP
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.

Post by Aleksander Veksler
* My card is Intel Pro/Wireless 3945ABG

Post by Aleksander Veksler
* The wireless switch is D-Link DIR-635

That probably doesn't matter.

Post by Aleksander Veksler
* 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
http://www.wireshark.org/mailman/listinfo/wireshark-users

Joerg Mayer

2007-09-07 07:44:17 UTC

Post by Aleksander Veksler
Anyone have tips on how you loose a few bytes? I get 12 bytes between
the Ethernet header and IP header. 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?
* My card is Intel Pro/Wireless 3945ABG
* The wireless switch is D-Link DIR-635
* The problem only happens in promiscuous mode, and only to the
packets not directed to my computer
* I attach picture of a window of a sample http packet
* Please help :)

Actually it looks like this packet might have a third mac at the beginning:
Is the length of 02 d7 really correct? Sending a packet would have
helped more than the image you sent and have been smaller.
After the third mac it looks to me that there is an ordinary LLC/SNAP
header.

Ciao
Joerg

--
Joerg Mayer <***@loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.

Aleksander Veksler

2007-09-07 09:03:17 UTC

Is the length of 02 d7 really correct? Sending a packet would have
helped more than the image you sent and have been smaller.
After the third mac it looks to me that there is an ordinary LLC/SNAP
header.

The LLC dissector attempted to dissect the first 4 bytes, right after
ethernet length. Again, I will have to send full data on Monday.

Thank you for the help!

Post by Joerg Mayer
Ciao
Joerg
--
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
_______________________________________________
Wireshark-users mailing list
http://www.wireshark.org/mailman/listinfo/wireshark-users

Aleksander Veksler

2007-09-19 23:23:27 UTC

Hello again guys,

Sorry for the delay. The procedure Sake Block recommended didn't work.
I first thought it was because there was a trailer, so I tried with
trailer sized 1,2,3 and four (see the packet to see why), but this
didn't work.

There seem to be a bug in DLT_USER configuration page, which make
random characters appear in the "payload" field (it seem to me the
characters are coming from the capture, but I am not sure. I attach a
screenshot, can make more if you need it.

I also attached a sample http packet. I found a packet with as much
clear text as possible, tell me if you need more. This particlular
packet was not classified as LLC, but many others were.

Thank you again for your help.

Aleksander

The LLC dissector attempted to dissect the first 4 bytes, right after
ethernet length. Again, I will have to send full data on Monday.
Thank you for the help!

_______________________________________________
Wireshark-users mailing list
http://www.wireshark.org/mailman/listinfo/wireshark-users

Small, James

2007-09-20 01:23:18 UTC

Aleksander,

If I save the pcap file you sent and follow this procedure:
bittwiste -I http_packet.cap -O http-new.cap -M 147

Open http-new.cap in Wireshark 0.99.6

Edit->Preferences->Protocols,DLT_USER,Edit...
Click on Edit...
Click New
Leave encap at default of User 0 (DLT=147)
payload_proto - ip
header_size - 26 (12 for Ethernet + 12 for extra stuff + 2 for next
protocol field)
header_proto - eth_withoutfcs
trailer_size - leave blank
trailer_proto - leave blank
Click OK
Click OK

Now, the IP part and "below" of the packet decode correctly in
Wireshark.

This doesn't work for you?

BTW - there does appear to be a bug in the DLT_User preferences where
you get gobbledygook - I should probably file a bug...

As to whether this should be automatically decoded I can't say - I would
have to defer to one of the developers.

--Jim

-----Original Message-----
Sent: Wednesday, September 19, 2007 7:23 PM
Subject: Re: [Wireshark-users] 12 bytes before the IP header
Hello again guys,
Sorry for the delay. The procedure Sake Block recommended didn't work.
I first thought it was because there was a trailer, so I tried with
trailer sized 1,2,3 and four (see the packet to see why), but this
didn't work.
There seem to be a bug in DLT_USER configuration page, which make
random characters appear in the "payload" field (it seem to me the
characters are coming from the capture, but I am not sure. I attach a
screenshot, can make more if you need it.
I also attached a sample http packet. I found a packet with as much
clear text as possible, tell me if you need more. This particlular
packet was not classified as LLC, but many others were.
Thank you again for your help.
Aleksander

Actually it looks like this packet might have a third mac at the
Is the length of 02 d7 really correct? Sending a packet would have
helped more than the image you sent and have been smaller.
After the third mac it looks to me that there is an ordinary LLC/SNAP
header.

The LLC dissector attempted to dissect the first 4 bytes, right after
ethernet length. Again, I will have to send full data on Monday.
Thank you for the help!

Post by Joerg Mayer
Ciao
Joerg
--
Joerg Mayer
We are stuck with technology when what we really want is just stuff

that

Post by Joerg Mayer
works. Some say that should read Microsoft instead of technology.
_______________________________________________
Wireshark-users mailing list
http://www.wireshark.org/mailman/listinfo/wireshark-users

_______________________________________________
Wireshark-users mailing list
http://www.wireshark.org/mailman/listinfo/wireshark-users

Aleksander Veksler

2007-09-23 15:03:07 UTC

Yes, this worked,thanks!

wbr

Post by Sake Blok
Aleksander,
bittwiste -I http_packet.cap -O http-new.cap -M 147
Open http-new.cap in Wireshark 0.99.6
Edit->Preferences->Protocols,DLT_USER,Edit...
Click on Edit...
Click New
Leave encap at default of User 0 (DLT=147)
payload_proto - ip
header_size - 26 (12 for Ethernet + 12 for extra stuff + 2 for next
protocol field)
header_proto - eth_withoutfcs
trailer_size - leave blank
trailer_proto - leave blank
Click OK
Click OK
Now, the IP part and "below" of the packet decode correctly in
Wireshark.
This doesn't work for you?
BTW - there does appear to be a bug in the DLT_User preferences where
you get gobbledygook - I should probably file a bug...
As to whether this should be automatically decoded I can't say - I would
have to defer to one of the developers.
--Jim

Post by Aleksander Veksler
Anyone have tips on how you loose a few bytes? I get 12 bytes

between

Post by Aleksander Veksler
the Ethernet header and IP header. This means that wireshark does

not

Post by Aleksander Veksler
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?

Post by Aleksander Veksler
* My card is Intel Pro/Wireless 3945ABG
* The wireless switch is D-Link DIR-635
* The problem only happens in promiscuous mode, and only to the
packets not directed to my computer
* I attach picture of a window of a sample http packet
* Please help :)

LLC/SNAP

Post by Joerg Mayer
header.

The LLC dissector attempted to dissect the first 4 bytes, right

after

Post by Aleksander Veksler
ethernet length. Again, I will have to send full data on Monday.
Thank you for the help!

Post by Joerg Mayer
Ciao
Joerg
--
Joerg Mayer
We are stuck with technology when what we really want is just stuff

that