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

Arlen,

Wishfull thinking much ? If he doesn't I will.

Which is pretty useless.

:-) You're just telling us exactly what you've done, so we can repeat it ourselves. In my country thats called "aiding and abedding" - which can easily land you into jail.

You already asked that.

If he doesn't I will. Also, *the* BSSID ? Just a single one ? What are you ? Poor ?

Thats a rather big "if", don't you think ? It certainly trashes your initial claim that you could track *everyone* (all over the world).

Tell that to all the poor city-dwellers who predominanty rent they places.

Who are, by the way, in close proximity and often stacked several layers ontop of each other. Which ofcourse makes a mockery of any claim that a certain location will al;ways point to a single home.

:-) You're "cooking the books" there.

Chances are - for multiple reasons as indicated in the above - he's not.

You're playing the "no true Scotsman" falacy there* : when you do not like a certain result you just discard it - leaving you with a meaningless, small subset, but all confirming what you wish to claim. Duh. Also, blergh.

• formatting link

Bottom line : you *might* be able to track someone when you are given a persons name. - if the stars align just right.

Regards, Rudy Wieser

Some random thoughts...

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.

Char,

I would say that!

Examples of 'puters who could not communicate over the LAN because either their ethernet-cards MAC was already present, or they had a hard-set IP that clashed are aplenty.

As long as it would not be a duplicate there, you would be correct. :-)

There are a few problems with your suggestion though : it only works for devices that do not move around, which would make Arlens statement that he can track anyone a bit of a joke.

If they hoever *do* move around (hello smartphones!) there is a rather good chance that they will, sometimes, enter a network segment where their BSSID is alread present - which could lead to a denial of service for one, or even all of the devices being copies of each other.

...

I think it did a bit more. Like negotiating which server would handle the request, and how to mark it that a certain ethernet packet was part of an ongoing conversation with a specific server.

iow, all those servers would need to /activily work together/ so they would not yell over each other and try to hijack each others conversations.

You know, it does sound odd : that sofware (that was bought) would need to add markers to make sure ongoing conversations would go to the server which first serviced it, in effect duplicating what the ethernet MAC and the puters IP are for ...

Regards, Rudy Wieser

Arlen,

As my thoughts went over to the "well off" city-dwellers who own the appartments they live in, I realized that they too often live stacked that way, sometimes in high-rises of 20 stories or more, with penthouses ontop.

Your Apple-database location data in such cases ? Useless.

Regards, Rudy Wieser

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

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.

Hi Char Jackson,

I appreciate your input because you're very knowledgeable in router setup.

I had left a note in the chimney on Christmas Eve for a consumer router with DD-WRT or OpenWRT firmware that allows me to change the AP BSSID.

Unfortunately, there is no consumer router brand or model that universally "allows BSSID changes" as far as I'm currently aware. Certainly that ability to change the BSSID of the access point exists in pro routers.

But what matters is not the router but the Wi-Fi chipset and the driver.

OpenWrt can only spoof a BSSID on hardware whose mac80211 driver permits overriding the interface MAC address. Most consumer routers do not permit this because the Wi-Fi MAC is stored in OTP/EEPROM and the driver enforces it.

The only consumer-grade devices that consistently allow BSSID spoofing are those using ath9k (Atheros 802.11n) or ath10k/ath11k (Qualcomm

However, even within the same product line, behavior varies.

Many ath10k-based consumer routers ship with board data that locks the MAC or derives multiple interface MACs from a fixed base, preventing spoofing. Mediatek MT76 devices sometimes allow MAC override on 2.4 GHz but not on

Therefore, the most accurate answer is that only certain Atheros-based consumer routers, typically older models using ath9k or early ath10k, permit true BSSID spoofing. No vendor guarantees this capability, and it must be verified per chipset and driver rather than per router model.

My next chance is my 86th birthday, where I'll ask for an older router that can change the BSSID in the outward-facing access point BSSID as no modern consumer router running OpenWrt or DD-WRT can reliably spoof the outward-facing BSSID.

As far as I'm aware, only certain legacy Atheros ath9k devices could do this, and they are no longer current hardware, unfortunately for me. :(

Drat.

We all agree the BSSID picked up by Apple/Google devices and then uploaded to the Apple/Google WPS databases is simply the MAC address of the wireless access point's radio interface as advertised in its beacon frames.

So to change the BSSID, we must change the MAC address of the AP interface.

While OpenWrt exposes: option macaddr 'AA:BB:CC:DD:EE:FF' it is ultimately the driver and hardware that decide whether to honor the override. Most modern Wi-Fi chipsets ignore it for AP mode.

Only older Atheros AR9xxx devices using the ath9k driver (circa 2008¡V2014) allowed true MAC override in AP mode, which indirectly changed the BSSID. These were fully mac80211-based radios with no firmware offload and no MAC locking. Examples include early TP-Link WR841N/WR1043ND units and some Ubiquiti M-series devices. These are now obsolete and unsuitable for modern Wi-Fi.

Modern chipsets behave very differently. Qualcomm ath10k/ath11k, Mediatek MT76 (MT7603/MT7612/MT7915/MT798x), and all Broadcom-chipset consumer radios store the Wi-Fi MAC in OTP/EEPROM and enforce it in firmware.

Even when OpenWrt accepts a user-specified MAC, the driver normalizes or rejects it, or regenerates interface MACs from a fixed base. As a result, the AP interface MAC cannot be changed, and the BSSID remains fixed.

From what I can determine, no modern consumer, prosumer, or WISP-grade router (including Ubiquiti, MikroTik, OpenWrt, DD-WRT, or anything based on Qualcomm, Mediatek, or Broadcom chipsets) can arbitrarily change the BSSID that appears in beacon frames.

As far as I can find out in google searches, unfortunately for me, and for anyone who cares about privacy, there is no mechanism in 802.11 to override the BSSID field independently because the BSSID is not a configurable parameter as the BSSID is always derived from the AP interface MAC address.

I wish it were that easy...

Yes, :) Unless of course if it's done intentionally, which should very rarely be the case.

When I was in college/university, someone in the computer lab intentionally enabled a DHCP server, knowing that there was already an active DHCP server. With over 300 workstations affected, we were all dismissed for the day while the lab team figured out what had happened.

I was thinking that the chance of that kind of collision would be exceedingly low, but statistics were never my strength.

We thought it was odd, as well, but in the end we implemented it and it worked, so there's that. That was more than 20 years ago, but I remember the servers having dual NICs, with one dedicated as sort of a mesh, where they disambiguated and de-duped everything, and the other interface being for the actual subscriber traffic. Looking back, perhaps it was overly complicated. I'm sure it has been replaced several times by now.

Arlen says the whole idea that I tossed out above is a non-starter, so thanks for the discussion. Happy New Year!

Hi Char Jackson,

Happy New Year to you too!

I agree the simplest solution is to change the outward-facing SSID BSSID. And I may have been wrong when I previously assumed no router allows it.

I've scoured the net trying to find a router that allows BSSID changing.

With FOSS firmware, the question morphs from which routers to which chipsets and drivers allow changing the access point BSSID at will.

OpenWrt/DD-WRT can request a custom MAC/BSSID, but the radio driver must honor it (i.e., option macaddr 'AA:BB:CC:DD:EE:FF').

Some sources claim these routers allow the BSSID override: 1. Netgear R7800 (Qualcomm Atheros IPQ8065 + ath10k radios) 2. TP-Link Archer C7 / A7 (Qualcomm ath9k/ath10k/ath11k) 3. Linksys EA8300 (Qualcomm IPQ4019) 4. Ubiquiti UniFi AC-Lite / AC-LR / AC-Pro (ath9k/ath10k) 5. GL.iNet ATX1800 (Wi-Fi 6, MediaTek MT7915) Using OpenWRT in this three-step procedure: STEP 1: Check BSSID iw dev wlan0 info STEP 2: Change BSSID uci set wireless.radio0.macaddr='02:11:22:33:44:55' uci commit wireless wifi reload STEP 3: Recheck BSSID iw dev wlan0 info

Changing the BSSID means overriding the MAC address of the virtual AP interface, but only certain chipsets & Wi-Fi drivers allow this: a. ath9k -> apparently always allows MAC override b. ath10k -> apparently allows MAC override c. ath11k -> apparently allows MAC override d. mt76 (MediaTek) -> sometimes allows it; MT7915 is one of the good ones e. Broadcom -> apparently never allows it f. Marvell -> apparently never allows it g. Realtek -> apparently unreliable or unsupported

So the list of potential routers that allow BSSID changes collapses to 'routers with Atheros or certain MediaTek chipsets that are sold today'.

Char,

That makes it likely that my (educated) guess that all servers would need to work together is what happened. :-)

Arlen says a lot of things, most of it - lets put it nicely - not thought thru.

And happy year to you - and everyone else here. :-)

Regards, Rudy Wieser

Char,

Mine neither, and that is why I saved a copy of the explanation to the "birthday paradox" : The chance that in a rather small group of people two would have the same birthday.

It turns out that that chance is above 50% for a group of just 23 people. Which is, to me, remarkable.

Ofcourse, the range of possible "birthdays" for BSSIDs is a "bit" (understatement)larger* (but would it be if we would have started with your idea ? I don't think so), but as the BSSID is moving around the "group" becomes much larger too.

• If we choose our BSSIDs ourselves, the actual range drops dramatically. Take passwords as an example. Most of us have to be forced not to use our own name or birthdate. :-)

Bottom line, those clashes would probably be much more likely than you think.

Regards, Rudy Wieser

Adding location information to DNS, DHCP, SNMP etc have been proposed. Go to:

and search for "location". You will find 165 RFC's involving location.

An early scheme is RFC 1712

The location data was limited to "level", which translates to floor number, and "room" which provides horizontal location data for a specific "level". Note that the data does not need to be derived from GPS data. Since it doesn't change (often), it could be entered into the database when the DNS record was created.

Among the later schemes is RFC 5870

Jeff,

...

proposed in 1994. Its now more than 36 years later (which is, for technology, a loooong time), and nothing like it has been implemented.

Maybe that is because there is no automated way to determine the "floor number". Especially for devices which task it is to do DNS, DHCP and so on - those do not even contain hardware to determine their own X/Y location.

I must say that that RFC does have a joke smell to it. You know, like the "I'm a teapot" HTTP status, the "evil bit" for ethernet packets and lets not forget "IP over avian carriers" (which, by the way /does/ work).

And although most/all smartphones do have a GPS, those are notoriously bad at determing elevation (which is not really a surprise, if you look at where the GPS satelites are located in relation to the GPS receiver).

Regards, Rudy Wieser

My apologies, its only 32 years ago.

Regards, Rudy Wieser

On Dec 23, 2025, Chris wrote (in article <10idp84$67nc$ snipped-for-privacy@dont-email.me):

Listen very carefully, I shall say this only once.

I'm 77 years old and am still proposing ideas which could easily be labeled as science fiction. I've also seen projects that were proposed, complete with detailed documentation, that didn't function until funding was found many years later. I suggest you not pass judgment on technology that you might consider old and instead concentrate on whether they might actually work. Also, if you wish to pass judgment on whether some technology is worth doing, there are seats in the various houses of government awaiting your political involvement.

Quoting myself: "Note that the data does not need to be derived from GPS data. Since it doesn't change (often), it could be entered into the database when the DNS record was created."

That means that in 1994, there was no requirement to identify the location of a router, server, computer, etc using GPS. Merely entering the location data the SNMP MIB (management information base) would be sufficient. Obviously, that won't work for moving objects, but GPS was not fully operational until 1995 and was not useable for indoor applications until High Sensitivity GPS arrived in about 1999

and Selective Availability was disabled in May 2000. If someone proposes a geographic network equipment location system prior to about

The RFC's I mentioned don't seem to be in the official book of April Fools RFC's.

That's true which is why sports GPS receivers often include a barometric altimeter:

"With proper calibration, the barometric altimeter of a Garmin watch or outdoor handheld will report elevation readings ranging from -2,000 to 30,000 feet with an accuracy of +/-10 feet at any given point." "Elevation calibrated by GPS is accurate to +/-400 feet at any given point with a strong GPS signal"

Happy New Year!

Every January 1st, I change the moniker on many of my accounts for privacy. Maria Sophia snipped-for-privacy@comprehension.com is what the moniker is now.

The rest of the headers are completely random from dictionary lookups (as my "newsreader" is actually a bunch of scripts using telnet & gVim).

I'm not "hiding from you". I change nothing but the headers. Hence, if you can't figure out who I am in less than about ten seconds based on what I write and how I write it and how I post excellent research often backed up by detailed annotated screenshots & photos, please don't exclaim a thousand posts from now that you finally eventually figured it out - as when you do that - it's absurd you think I'm "hiding" from you.

If you have no understanding of privacy, then save us all the trouble and just put me in your killfile because anyone saying that they "found me" is someone who has nothing to offer because if it's that difficult for anyone to figure out what is never hidden, then they have no right to exclaim they're a genius for finally figuring out what was never hidden from them.

Note that while the headers are dictionary lookups, I did take what Andy & Chris suggested into account by adding scripts to identify the fontset.

Jeff,

Two things about that :

Worse, privacy-concious people would leave it at its default on purpose (I certainly would).

And than there is the problem how a human would determine the floor number he's on. Besides all the houses/buildings that have a half-sunken/elevated "cellar" (where you have to go up half a flight of stairs to reach the front door) there are also houses where going up/down half a flight of stairs gets you to the next room.

You misunderstood : I did not say it was old, I indicated that it had a

As for "might actually work" ? It doesn't bring any benefits to the user, so most of them will simply not bother with it.

As I assume that the people who wrote that RFC where aware of the "if /everybody/ has to do it to make it work, than it won't work" saying I have to assume it was put up as a joke.

Which are also a problem : it relies on air pressure, which varies under the different weather types. /Way/ enough to make the measurement go up/down a number of floors. Its also a relative measurement, and needs to be calibrated before use.

Regards, Rudy Wieser