Re: Tutorial: Query the Apple database with Python for your access point BSSID

Char Jackson wrote:
> A BSSID is typically based on the interface's MAC address. Each MAC
> address is assumed, by many people, to be globally unique, but they
> don't have to be.* It helps greatly if a MAC address is unique within
> its local network segment, but a duplicate MAC appearing somewhere else
> shouldn't cause any problems. By extension, a duplicate BSSID appearing
> somewhere else shouldn't cause any problems that I can think of.
> 
> So my question is, would it help Arlen's quest for privacy if he were to
> choose a MAC, and thus a BSSID, that already exists somewhere else and
> is already present in the database? When someone does a query on that
> BSSID, would they get the first result, or all results? I wonder if
> Arlen has checked for duplicate BSSID entries in his favorite database.
> 
> *Many years ago, where I worked we trialed a piece of software that
> intentionally used the same IP address and MAC address on every server
> in the pool. That violates everything we're taught about network
> addressing, but it didn't cause any problems. It simply moved certain
> tasks farther up the network stack. We ended up buying and deploying
> that software into our production network.

Hi Char Jackson,

Happy New Year!

You are one of the people on this newsgroup who know more about routers
than anyone I personally know, including me, although Jeff Lieberman and
Paul and a few others would know as much or almost as much as you do.

So I welcome your question as I am wondering the same things myself!

In the context of OpenWrt running on consumer-grade hardware, it is
important to distinguish between what the configuration layer *allows*
you to request and what the underlying wireless chipset and driver will
actually honor. While OpenWrt exposes 'option macaddr' for wireless
interfaces, the ability to override the BSSID (which is simply the MAC
address of the AP's radio interface) is entirely dependent on the
capabilities of the Wi-Fi hardware and its corresponding mac80211 or
vendor-specific driver.

Most consumer routers use Broadcom, Qualcomm Atheros, or Mediatek
chipsets whose Wi-Fi MAC addresses are stored in OTP/EEPROM and are
treated as immutable by the firmware. Even when OpenWrt writes an
override into /etc/config/wireless, the driver frequently rejects the
requested MAC because the hardware enforces the burned-in address or
derives multiple interface MACs from a fixed base. As a result, the
BSSID remains tied to the factory-programmed value regardless of user
configuration. This is why many OpenWrt users observe that attempts to
spoof the BSSID simply do not take effect on real consumer hardware.

Only a subset of chipsets, typically those using fully mac80211-based
drivers with permissive MAC handling, will accept a user-specified
address for the AP interface. Even then, the override must satisfy the
802.11 requirement for a unicast, locally administered MAC (i.e., the
second-least-significant bit of the first octet must be set, and the
least-significant bit must be clear). If the address fails these
constraints, the driver will silently normalize or reject it.

Because of these hardware and driver limitations, the idea of selecting
an arbitrary BSSID to "collide" with an existing entry in a Wi-Fi
positioning database is largely theoretical for typical OpenWrt
deployments. Even on hardware that does permit MAC spoofing, WPS systems
such as Apple's treat the BSSID as a unique key and will simply update
the single stored location rather than maintaining multiple entries. As
a consequence, spoofing an existing BSSID does not provide meaningful
privacy benefits and, in practice, is simply not achievable on most
consumer routers, even when they are running the latest OpenWrt firmware.