This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

802.11 packets converted to “fake” Ethernet packets

1
2

The Wi-Fi Wiki page ( http://wiki.wireshark.org/Wi-Fi ) says that sometimes the hardware/driver translates 802.11 headers into Ethernet headers.

Can someone please give me an example of such differences? Or maybe two packets - the proper 802.11 one, and how the translated Ethernet packet would look like? Wireshark screenshots would also be really helpful.

Thank you to anyone who replies, or even attempts to help.

asked 09 Jan '14, 10:56

DumaHandle's gravatar image

DumaHandle
21124
accept rate: 0%


One Answer:

1

The adapters/driver:

  • don't supply non-data (management and control) packets;
  • for data packets with SNAP headers with an OUI of 00:00:00, meaning that the protocol ID in the SNAP header is an Ethernet type, supply packets with a fake Ethernet header in which the source and destination addresses are the source and destination addresses from the 802.11 header, other fields of the 802.11 header are discarded, the type/length field is the protocol ID from the SNAP header, and the Ethernet header is immediately followed by the part of the payload that follows the LLC and SNAP headers (so that the LLC and SNAP headers aren't in the fake Ethernet packet);
  • for other data packets, supply packets with a fake Ethernet header in which the source and destination addresses are the source and destination addresses from the 802.11 header, other fields of the 802.11 header are discarded, the type/length field is the length of the payload following the 802.11 header, and the Ethernet header is immediately followed by the payload, including the LLC and SNAP headers.

answered 09 Jan '14, 15:48

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Hi Guy Harris,

First of all thank you very much for your explanation and your time. I've read your reply a number of times and researched on SNAP headers and OUI since my knowledge of networking is very limited. I believe I now understood your reply.

Basically what I've understood is that 802.11 packets are translated as Ethernet packets.

This is done by:

  • reading the source & destination from the header within the 802.11 packet

  • discarding some information from the header within the 802.11 packet

  • setting the packet type as Ethernet (0x0800)

  • Re-calculating the length by checking the size of the payload (the actual contents of the packet) which comes after the header

  • setting the header with the protocol ID for packets with SNAP headers with a MAC address starting with 00:00:00, and for other packets setting the header with the payload as well as the LLC and SNAP headers (not sure if I understood this last point)

Still, I am unable to identify what may seem odd about packets coming from 802.11 which have been translated to Ethernet. What should I look for to determine that in reality a packet has been sent through Wi-Fi, and not through Ethernet as the packet capture indicates?

Thanks again

(09 Jan '14, 18:25) DumaHandle

setting the packet type as Ethernet (0x0800)

No. The packet type is part of the Ethernet header, so "Ethernet" isn't really a value that makes sense. 0x0800 is the Ethernet type for IPv4, so if the 802.11 packet were an IPv4 packet, it would have, after the 802.11 header, an IEEE 802.2 LLC header, with a DSAP and SSAP of 0xAA and a control field of 0x03, followed by a SNAP header with an OUI of 00:00:00 and a protocol ID of 0x0800, followed by an IPv4 packet.

The 802.11 adapter/driver would convert that packet to a fake Ethernet packet by using the destination and source addresses from the 802.11 header, inserting a packet type of 0x0800, and then taking the rest of the packet following the LLC and SNAP headers - i.e., the IPv4 packet - and putting it after the packet type.

0x86DD is the Ethernet type for IPv6, so if the 802.11 packet were an IPv6 packet, it would have, after the 802.11 header, an IEEE 802.2 LLC header, with a DSAP and SSAP of 0xAA and a control field of 0x03, followed by a SNAP header with an OUI of 00:00:00 and a protocol ID of 0x86DD, followed by an IPv6 packet.

The 802.11 adapter/driver would convert that packet to a fake Ethernet packet by using the destination and source addresses from the 802.11 header, inserting a packet type of 0x86DD, and then taking the rest of the packet following the LLC and SNAP headers - i.e., the IPv6 packet - and putting it after the packet type.

Those two conversions are actually the same - the hardware/firmware/software that does the conversion doesn't know about IPv4 or IPv6, it just knows about LLC and SNAP headers, so the packet type it inserts is the protocol ID field from the SNAP header.

setting the header with the protocol ID for packets with SNAP headers with a MAC address starting with 00:00:00, and for other packets setting the header with the payload as well as the LLC and SNAP headers (not sure if I understood this last point)

No, it's not the OUI (Organizational Unit Identifier) in the MAC address, it's the OUI in the SNAP header; OUIs are used in places other than MAC addresses.

That's the same thing that I described above in this comment. If the OUI is not 00:00:00, it has to be done differently.

(09 Jan '14, 18:40) Guy Harris ♦♦

What should I look for to determine that in reality a packet has been sent through Wi-Fi, and not through Ethernet as the packet capture indicates?

There's not really much you can look for. The fake Ethernet packets don't have any "this is fake Ethernet" markers; about the only "odd" things you might see are a larger number of retransmissions than you'd see on Ethernet, possibly different transmission and reception rates (as Ethernet and 802.11 speeds are different), possibly different latencies (passing through an access point might take longer than passing through an Ethernet hub or switch), and possibly traffic of the sort that a Wi-Fi access point sends out (and that thus wouldn't be likely to appear on an Ethernet network).

(09 Jan '14, 18:45) Guy Harris ♦♦

Ah, that explains things better, and in fact makes more sense.

From my understanding, however, there doesn't seem to be a way to determine whether an Ethernet packet in a capture file has been sent over the wire, or has been sent over Wi-Fi (802.11) but has been translated to Ethernet (and therefore can be considered as "fake" Ethernet packets) - am I correct?

I am really grateful for your responses.

EDIT: Sorry, I hadn't read your reply before I posted this. I'll reply soon.

(09 Jan '14, 19:14) DumaHandle

Alright, I think I fully understand everything now.

Once again, thank you very much for your explanations and clarifications. I have marked your answer as the correct answer to my question.

Have a nice day :)

(09 Jan '14, 19:24) DumaHandle

there doesn't seem to be a way to determine whether an Ethernet packet in a capture file has been sent over the wire, or has been sent over Wi-Fi (802.11) but has been translated to Ethernet (and therefore can be considered as "fake" Ethernet packets) - am I correct?

There's no reliable way that applies in all cases. Some capture file formats might supply information about the type of adapter or adapters on which traffic was captured, such as the adapter name (from which you might be able to infer the adapter type, e.g. "eth0" vs. "wlan0" on Linux) or the adapter type, but not all do. As noted earlier, it might be possible to try to guess the type of network from network behavior, but that's not guaranteed to be possible or to yield a reliable answer.

(09 Jan '14, 20:09) Guy Harris ♦♦
showing 5 of 6 show 1 more comments