2

I'm working on replicating some research wherein users were profiled based on the SSIDs they asked for when sending out 802.11 probe requests. I only captured probe requests, so information from clients rather than APs.

Each probe request contains the sender's MAC address, as well as the SSID they're looking for. I gathered about 200,000 probes from around the city where I live, and over 70% of the probes I gathered had a MAC address that wasn't listed in the IEEE OUI database.

About half of those MAC addresses had the self-assigned bit set, which I would expect for iOS8 devices sending probe requests, but I don't think I would expect that proportion of devices to be iPhones, given their market share relative to Android.

The statistics I have from that data set are 9% Apple, 36% invalid OUI without the self-assigned bit set, 34% invalid with the self-assigned bit set, and 20% valid vendors other than Apple.

Plausibly, the 43% of users either self-assigned or specifically Apple could be iOS users, taking into account the number of unique MAC addresses being higher if a new one is being randomly generated for each probe request.

However, I'm still not sure why there would be such a large proportion of invalid OUIs.

I can't find any sources on widespread adoption of randomised MAC addresses in any OS; someone suggested that several "small name" vendors might be generating invalid/random MACs to prevent having to buy their own OUI, but I wouldn't have thought they would be such a high proportion.

So, in conclusion: 70% of MAC addresses sampled had an invalid OUI when sending probe requests, and only around half of those had the "self-assigned" bit set, hence leaving about half who are invalid for no reason I can find; does anyone know why this might be?

  • What makes you think they are invalid? Can you provide some examples? – YLearn Jun 7 '15 at 3:24
  • Hey, sorry -- I realised the problem was that my OUI database was incomplete. I was using a third party Python library that claimed to use the IEEE database, but I discovered that the majority of the MACs I found that were "other/invalid" were actually just ones that weren't in the database I was using. I ended up parsing the Wireshark database and that found all but maybe twenty of the MACs, which was a much more reasonable finding. Thank you for being the prompting factor in me finding this bug with the database, though. I would've totally missed this otherwise. – Andrew Jun 8 '15 at 2:04
  • Glad you found your answer, but please post it as such and accept it when you can.. SE fully encourages people to provide answers to their own questions when they find them. – YLearn Jun 8 '15 at 2:48
  • 1
    @Andrew, it's best if you rollback your edit to the question and post it as an answer. – Ryan Foley Jun 8 '15 at 4:51
  • Ah sorry, I'll do that now :) – Andrew Jun 9 '15 at 3:45
4

It turns out the database I was working with was incomplete. I was using "python-netaddr" on Ubuntu 14.04, and this was significantly smaller than the Wireshark combined IEEE+misc database. After I fixed this, all but a very few MACs had valid vendors, which is the result I was expecting.

0

Some devices use MAC Randomization technique in Probe Request.

They use a fake MAC address to send Probe Request. I found my HTC One A9 use this technique when performing WPS connection. It's MAC is 80:01:84:xx:xx:xx, however, when probing for WPS, using Wireshark I could only see many Google OUI devices probing to my router.

Apple already adopted MAC address randomization, in version 8 of iOS Link here . Please check this link also.

This could be a reason why you found so many devices with invalid OUI.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.