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

According to the wireshark wiki

capturing on WLAN's may capture only user data packets with "fake" Ethernet headers. In this case, you won't see any 802.11 management or control packets at all, and the 802.11 packet headers are "translated" by the network driver to "fake" Ethernet packet headers.

Can one detect that a packet has an 802.11 history? That is, that it was captured as 802.11 and then modified to contain a fake Ethernet instead? Or is the fake Ethernet is indistinguishable from a regular one?

asked 19 Jun '17, 01:52

Guy%20Kroizman's gravatar image

Guy Kroizman
81247
accept rate: 0%


I agree with @sindy that it is really not possible to positively identify these cases where we have 802.11-->EthII/802.3 conversion, but I wanted to share some things things that I have picked up over the years that may 'suggest' a wireless adapter collection. These are not deterministic - only some things I have found that tend to be different between wired and wireless world:

  1. Wireless typically has much more packet loss, so when looking at TCP flows, I typically see very little packet loss on wired side, but the same network I might see 10x (or more!) the amount of TCP retransmission or UDP loss. Packet loss happens for other reasons, but I have a feel for the level on my networks that I run, so I can guess based on the amount of loss. If your evaluation is unknown, this may not be the most useful technique.

  2. Delay on my wireless networks can be noticeable when comparing wireless to wired networks. If you have a baseline of what to expect on wired, you may detect a difference as the wireless could be a lot higher - in the 100s of ms or more (I have seen many seconds on poorly designed/busy wireless networks). This is most noticeable with powersave wireless clients that may sleep for one or more DTIM periods. Do some analysis with ping responses or something to see if you can detect differences. Smokeping is a nice tool for this comparison. The variance in response time is always higher for me as well when comparing wireless to wired response time delays - the distributions are very different.

  3. On Linux and MAC OS, I see the 4-way EAPOL keying process in the 'faked' capture (I should check to see if the data is decrypted...). For whatever reason, when capturing on the interface and not in monitor mode, these are passed up. I suspect the 802.1X process is done in user space so they have to be passed up (e.g. wpa_supplicant with Linux). Only helps if you see them in the trace, and I have never seen this with Windows, or if your WiFi network is unencrypted.

  4. capinfos tool with pcapng seems to give interface name in the output. If you know the interface name you would be able to tell. Otherwise, if you don't know, and you see 'wlan0' maybe you can guess what that you are in this situation. On my MAC, it says 'en0'. I have a MacBook Air, so en0 is wifi. I think if you have a MacBook Pro, the wired interface is en0 and wifi is en1 (I don't have a pro, but feel free to donate one and I will let you know for sure!) so that isn't a huge help unless you know the system that took the capture. But on Windows and Linux it can often be a little more descriptive.

My view is that if I see enough of these traits, I can guess how the capture was taken. Unfortunately I live in a world where deterministic answers are not always available and yet we have to solve the problem anyway. I am forced to guess sometimes to move forward in many situations, so techniques that allow us to reduce risk while still guessing are quite useful in the real word.

permanent link

answered 20 Jun '17, 16:56

Bob%20Jones's gravatar image

Bob Jones
1.0k2515
accept rate: 21%

edited 20 Jun '17, 16:56

I have a MacBook Air, so en0 is wifi. I think if you have a MacBook Pro, the wired interface is en0 and wifi is en1

If you have a MacBook Pro with a built-in Ethernet, that's the case. MacBook Pros haven't come with a built-in Ethernet for many years, however; mine doesn't have one, and the Wi-Fi is en0.

(20 Jun '17, 18:43) Guy Harris ♦♦

Mostly the second. The fake ethernet headers are there to completely replace the 802.11 headers, so you can only use the MAC address (which is inherited from the 802.11 header to the Ethernet one) to identify the interface of the device which has sent the packet. If it is an address of a WLAN interface, the packet came directly through WLAN; if it is an address of a wired interface, it hasn't. But if you e.g. have a wired bridge between two WLANs, you have to look at the position of that device too.

permanent link

answered 19 Jun '17, 13:26

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 19 Jun '17, 13:32

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×114
×87

question asked: 19 Jun '17, 01:52

question was seen: 1,026 times

last updated: 20 Jun '17, 18:43

p​o​w​e​r​e​d by O​S​Q​A