Unknown mac address in BLE
brupala Posted messages 111153 Registration date Status Member Last intervention -
Hello, I am detecting around MAC addresses whose manufacturer is unknown in official databases. For example: 4A:A2:26:3C:A2:73.
Depending on the surroundings, I detect several of them. What MAC addresses could be unidentifiable regarding the manufacturer? One is fine, but I'm detecting dozens and dozens depending on where I am. The more people there are, the more I detect? And they are always BLE protocols. To detect them, you need to be in developer mode on Android and enable the "Show unnamed Bluetooth devices" option.
What devices are not required to have a recognized manufacturer that would have become trendy?
4 answers
-
Hello,
actually, it's not any manufacturer, these are ephemeral and random MAC addresses that change all the time, they are often used in BLE to anonymize mobile devices just like there are more and more in Wi-Fi as well.
We recognize these addresses by the fact that they have the U/L bit set to 1 which indicates a local and not universal definition of the address.
To identify them, the first octet ends with 2, 6, A, or E, in your example, it's A (4A).
And there you go, there it is ....
But damn, those line breaks are annoying!! -
Thank you for your reply.
But I didn't quite understand how to identify them? What do you mean by the first octet? If it's the first two characters, that doesn't add up, I find some that don't end with 2, 6, A, E and that are not in the IEEE database.
Well, in my example, I have the first bit as 1. Does that mean it's a local address? Am I correct?
Example: 43:25:66:AB:A6:6B
One more question: do smartphones continuously emit these MAC addresses in BLE or only when they are in pairing mode or in a specific communication?
-
-
OK,
I don't really master BLE addresses; I have some readings and some measurements like you, but not more than that. Since I'm rarely in very populated areas, it's hard to have significant statistics.
To continue from what I explained to you regarding the U/L bit, there is also its neighboring bit, the first (or last, but that's another debate) which makes the first byte even or odd (in a binary sense), because saying that B is the odd value of A is a bit tricky.
Still, the last bit of the first byte of the MAC (I/G bit, see link above) is supposed to indicate a multicast MAC address (all machines on the network) or a unicast (a single recipient).
In Ethernet or Wi-Fi networks or others (TR ...), this is applied, so all addresses with an odd first byte are supposed to be broadcasted, intended for everyone on the network or nearly so.
In any case, a MAC with the I/G bit set to 1, therefore global, can only exist as a destination, never as a source MAC; otherwise, it doesn't make sense.
MAC addresses where the first byte is odd (x1, x3, x5, x7, x9, xB, xD, xF) are therefore reserved for multicast destinations.
I still haven't found any documentation on this subject, but it seems that certain BLE functionalities bypass this rule and create random addresses that resemble multicast.
This shouldn't exist in a normal world, unless MAC addresses in BLE are not managed at all, since they throw in whatever:
random addresses allow the I/G bit to be set to 1, while private random addresses only allow the U/L bit to be set to 1; then there are normal addresses with both bits 0, it's complicated.
To help with understanding (or not), it should be clarified that the "little endian" notation corresponds to the bit transmission order in Ethernet and similar, while the traditional byte notation is the reverse (big endian).
https://networkengineering.stackexchange.com/questions/24269/network-byte-order
And there you go ....
But misery, how annoying interline spacing is!!



