Invisile router manufacturer for TP-Link TL-MR3420 v5.1

[olekstomek]

Here there is no BSSID (6aff7b) for TP-Link TL-MR3420 v5.1 and this device is not recognized: https://github.com/VREMSoftwareDevelopment/WiFiAnalyzer/blob/d710b47a80c0e9d11e88be45fd0e41cf5052bf4a/app/src/main/res/raw/data.txt#L16520 Is there a public database with updated values for devices? Because this is just an example and I had the same problem once before on a device other than mine. More details here.

[Spudz76]

When the MAC has been randomly generated, there is no way to tell. You can lie about any device by simply modifying the first three octets in a MAC. It is not a secure or reliable way to "know for sure" and is simply looked up in the database of three-octet-prefix-to-manufacturer. Every device can have its MAC overridden quite easily. This is mostly why relying on a authorized-MAC-access-list for wifi security is not really security, only a slight extra hurdle -- sniffing your network would reveal some authorized MACs, then intruder simply switch their MAC to that and wait for the real device to go away (or flood it off).

Some devices just don't have a way to get the factory MAC (stored in some undocumented place, or obfuscated, etc) so they generate a random one at firstboot, and store it in the network or wireless configs so it persists for the lifetime of that config (until next no-keep-config reflash, or factory default reset). These devices are somewhat more rare than ones where we can find the factory MAC somewhere in flash (uboot config partitions or otherwise).

I like to change my MAC so my Linksys looks like a regular Intel network card, then it "looks" like just another computer rather than obviously my router device. Throws off anyone looking to collect clues about my network, such as wigle warriors (I used to be one). If my router just advertised "hey I'm obviously the router since I'm the only Linksys device" that would be sort of a security leak, "they" would know where to attack...

[Spudz76]

Also the BSSID is simply the Basic Service Set ID which is a fancy name for the MAC address of the wifi network, which is then looked up the same as any other MAC address, but can also be changed so it doesn't really mean anything authoritative (only a "neat clue", maybe).

[olekstomek]

Very interesting point of view and analysis, thank you!

Some devices just don't have a way to get the factory MAC

I found picture from seller (it's bad quality) and I will check MAC address on this device, but I see on picture for my device 68:ff:7b, so second character is different :O and this value (68FF7B) exist in WiFiAnalyzer/app/src/main/res/raw/data.txt. Also exist here:

68:FF:7B Tp-LinkT Tp-Link Technologies Co.,Ltd.

[kurahaupo]

BSID numbering is just one use for unique equipment identifiers (MAC addresses), the same numbering pool used for Ethernet & Bluetooth devices; not really surprising when you consider that WiFi was originally designed as an "Ethernet Extender" protocol.

Half of the possible numbers are "private use", meaning there is no issuing authority, analogous to RFC1918 IPv4 addresses. These are marked by having the "private bit" set to 1 (bit 6, corresponding to 02:00:00:00:00:00).

"Randomized MACs" are supposed to have the private bit set, and you should also set this bit of you are assigning BSIDs or MACs by hand.

The other half of the possible numbers (with the 6th bit set to 0) are from a register maintained by the IEEE, who delegate OUI prefixes (usually 24 bits) to manufacturers. https://standards-oui.ieee.org/ is the ultimate authoritative answer but it's intended for human reading, not machine parsing,

The good news is there are many sites that periodically take this and make it available for searching; just search for "Ethernet OUI lookup" or "Ethernet MAC lookup".

Obviously there's no point looking up a private OUI prefix to get the device manufacturer; you should check the private bit before wasting time doing lookup.

The point of having a central register is to give certainty that no two devices will share an address, so that a device with such an address can skip "collision detection" and assume it's immediately good to go; this is especially important for infrastructure like core routers.

Unfortunately most hardware that supports programmable MACs or BSIDs won't prevent you from loading one with someone else's registered OUI, so it's still possible for a human to mess things up.

The private bit is inverted when constructing a MAC-based IPv6 address, so that "nice" IPv6 addresses with lots of zeroes can't conflict with addresses constructed from registered MACs.

registered	private
x0:xx:xx:xx:xx:xx	x2:xx:xx:xx:xx:xx
x1:xx:xx:xx:xx:xx	x3:xx:xx:xx:xx:xx
x4:xx:xx:xx:xx:xx	x6:xx:xx:xx:xx:xx
x5:xx:xx:xx:xx:xx	x7:xx:xx:xx:xx:xx
x8:xx:xx:xx:xx:xx	xa:xx:xx:xx:xx:xx
x9:xx:xx:xx:xx:xx	xb:xx:xx:xx:xx:xx
xc:xx:xx:xx:xx:xx	xe:xx:xx:xx:xx:xx
xd:xx:xx:xx:xx:xx	xf:xx:xx:xx:xx:xx

[kurahaupo]

6a:ff:7b:1a:96:4e is simply the router's allocated OUI with the private bit flipped. This is lazy but sadly not unusual in consumer-grade products.

(A router obviously need multiple OUIs (for multiple interfaces), but in the case of a consumer grade WiFi access point, it can reduce this to "one for ethernet, one for wifi". The manufacturer only assigns one OUI per device, and gets two for the price of one by flipping the private bit.)