2

I captured 2.5 million packets over 3 hours using Wireshark in monitor mode, on a single channel on the 802.11ac 5GHz spectrum, channel 36.

I opened Statistics > Conversations in Wireshark, to see all MAC addresses that had been talking to each other over Wi-Fi. I have subsequently saved the list of "Conversations" as provided by Wireshark, as a Google Sheet, shared below for reference and analysis.

https://docs.google.com/spreadsheets/d/1RE72s7DYXDhRdMopXQ9zIqNkww6OhzUeZbLeQvYqpPc/edit?usp=sharing

Valid devices I have seen during "Devices Near Me" scans from Wi-Fi management apps on Android, are listed in the "Device_Validity" sheet. The same are colored green in the primary Conversation sheet. However only the first 1000 rows (out of 169,242) have been formatted in any manner at all, to keep performance reasonable.

Now to the issue: I'm seeing in the Wireshark logs, several mutated versions of the MAC addresses of my devices and my neighbours' devices.

By mutated, I mean that if 18:56:80:7e:0d:c9 is a valid MAC address, then I'm seeing the following variants in source/destination or transmitter/receiver addresses of observed packets in Wireshark:

  • 18:56:80:7e:0d:49 - where only the last 1 or 2 octets are changed. This could be valid, if the device has multiple network interfaces with slightly modified MAC addresses.

  • 19:56:80:7e:0d:c9 - where the first N octets are changed. This could happen when packets pass through range extenders. Though AFAIK usually 3 octets are changed, not just 1.

  • Seemingly random mutations of the original MAC address as below:

    18:56:80:7e:0d:a9
    18:56:80:7e:0d:29 - how many interfaces can one device have?
    18:56:80:7e:4d:76
    18:56:80:7e:6d:39
    18:56:80:7e:ad:05 - Are there so many additional devices from the same manufacturer nearby, that were somehow missed during the “Devices Near Me” scans I mentioned above? It’s possible, but unlikely
    00:56:80:7e:0d:c9 - Prefix changed twice, once to 19:56 and again to 00:56. How many range extenders are there? And again, only changing the first octet?
    02:56:80:7e:0d:c9 - Prefix changed again.
    02:56:80:7e:ad:2b - 3 octets changed over both ends.
    98:6f:80:7e:0d:05 - 3 octets changed over both ends.
    01:18:56:80:7e:0d - all octets shifted to the right, and padded with 01 at the left.
    4b:27:80:7e:0d:63 - another multiple substitution.
    18:56:80:7e:b9:c4 - and many many many more

I found the above 14 mutations by performing a simple search for the octet sub-string 80:7e in the Google Sheet, and looking at only 55 of the 7354 results it turned up. Many more mutations could be found yet, simply by searching for different octet sub-strings of valid MAC addresses, or by examining more of the search results.

Further, if you sort the provided Google Sheet by one of the "Unresolved Address" columns, and analyse the neighborhood of any valid MAC, you'll see that the addresses keep mutating until almost all of the octets are different.

And this is for just one device. Similar mutations are found for multiple devices, both belonging to myself and of my neighbour’s. One more set of examples follows:

5c:f9:38:a7:d9:32 - Original
d0:f9:38:a7:d9:32
32:f9:38:a7:d9:32
30:fa:38:a7:d9:32
fe:f9:38:a7:d9:32
5e:f9:38:a7:d9:5a
00:5c:f9:38:a7:d9 - shifted right and prefixed
f9:38:a7:d9:32:98 - shifted left and suffixed
59:f9:38:a7:d9:f2 - and a d9:b2
5c:f9:38:a7:71:2d - non-existent device
5c:f9:38:a7:41:45 - non-existent device
and many more

These are the patterns I cataloged for just two devices, out of the dozen+ devices within range of my monitor. For any of the devices in the Device_Validity tab of the sheet, these bit-shift/mask patterns are easily observed by searching for specific octet sub-strings in the Conversations tab.

Network traffic pattern:

These shifted or masked MAC addresses are not participating in beacon request/response, auth/deauth frames and so on, or other such places where you expect new devices or even "attacker" devices to keep popping up or disappearing. Instead, they typically send/receive one-off packets for random RTS/CTS, Block-Ack, Null Function and Beamforming (VHT/HE NDP announcement frames), suddenly in the middle of valid traffic. I repeat, only one-off frames, not entire conversations.

Eventually resulting in tens of thousands of one-off mutated MAC addresses, exchanging one-off packets, with valid devices, or with other mutated MAC addresses.

Given all the above evidence,

What is the most likely source of so many _mutated_ MAC addresses of valid devices

Note that we eventually end up with tens of thousands of MAC addresses in an area, mutated from only the dozen or so valid MAC addresses physically present in the wireless neighborhood. The number of devices was validated by the "Devices Near Me" scans mentioned previously (these scans look for both associated and unassociated devices in the vicinity).

Possible theories:

  1. High probability - Packet errors - that are for some reason not flagged as errors in Wireshark. Why do they even show up in Wireshark? Why are they not rejected by the network card / OS? (specifically, macOS 10.14.5 on a MacBook Air mid-2013)
  2. Low probability - Malicious actor - What could they possibly achieve by injecting beacon frames, RTS/CTS and such? Besides, seems like a high amount of effort to achieve…exactly what?
  3. What else?

1 Answer 1

2

These are errors. Your 802.11 WNIC in monitor mode is doing its best to receive and report every frame it can see on the channel you set it to, but because of the unreliability of the wireless medium, there will always be many packets it can see where the SNR is not strong enough for it to receive and decode every bit correctly.

They're not being rejected because you've put the WNIC in 802.11 monitor mode, and monitor mode is often used by 802.11 engineers to debug 802.11 problems, including packet error problems, so engineers like to be able to see the errors rather than have them automatically rejected by the WNIC.

They're not being flagged by Wireshark because, well, because dealing with FCS errors has always been a huge pain with NICs and sniffers (this goes way back to the early days of wired Ethernet, so it far predates 802.11). Some NICs have the ability to pass FCS-failing frames up to the host and some don't. Some NICs have the ability to include the FCS in the packets they pass up to the host, and some don't. There's never been a good way for the sniffer to automatically find out which kind of NIC it's dealing with, so it doesn't know whether to expect to see FCSes or bad frames or not.

So Wireshark, as I recall, defaults to the safe position of assuming frames do NOT have FCSes attached, so it doesn't do FCS validation checks, so it doesn't flag bad frames. Wireshark has several settings to let you control how it deals with FCSes.

See, for example:

Preferences > Protocols > 802.11 Radiotap  
Preferences > Protocols > IEEE 802.11  
Preferences > Protocols > Ethernet  
2
  • Excellent. Thank you. I definitely hadn't enabled FCS at the time of capturing the logs. Although I found the setting later during my investigations, I wasn't personally sure if the older data could or could not be explained away as being related. Thank you for clearing that up.
    – Somy Nona
    Jun 20, 2019 at 3:26
  • Confirmed: I set wlan.check_checksum and wlan.check_fcs to TRUE under WireShark > Preferences > Advanced (on Mac), and reran the analysis. Sure enough, all the packets with corrrupted MAC addresses I have checked so far, show FCS/CRC errors. I will keep checking other packets but so far it seems that this issue has been cleared up quite nicely.
    – Somy Nona
    Jun 20, 2019 at 4:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .