On Wed, 14 Sep 2016 18:41:22 -0400, bruce wrote:
Oh, what the hell. I'll give it a try.
Thanks Bruce. I'm always nice if someone is sincerely trying to answer the
question, and, I do realize that most people don't even *understand* the
question.
In the following I tend to intersperse WAN and LAN as well as BSSID and
MAC. The basic underlying concepts work in both environments (with some
fudging).
All we care about, for *this* discussion, is the MAC address of the 5GHz
and 2.4GHz radios in the iOS or Android cellphones we are trying to track.
That MAC address is also called a BSSID.
Google also logs the SSID, the signal strength, and the GPS location, but
they are not of importance for *this* discussion.
Only the MAC address (aka BSSID) is important for *this* discussion.
SSID has nothing to do with cellphones. It has to do with wifi only.
The same is true for BSSID.
This is not true that "SSID has nothing to do with cellphones".
As Jeff and I just discussed, if an Android or iOS cellphone acts as an
Access Point, then that cellphone will broadcast an SSID.
If that iOS or Android cellphone broadcasts an SSID, it also broadcasts a
BSSID, which is unique to that cellphone. In fact, it broadcasts *two*
BSSIDs, one for each radio (5Ghz and 2.4Ghz).
It's *those* unique BSSIDs which are captured by poorly configured Android
devices and uploaded multiple times a day to the Google Public Database,
along with the GPS location of the poorly configured Android device and the
SSID and Signal Strength of the access point.
Notice this allows such iOS or Android cellphones to be tracked!
SSID is just a name. There could be thousands of wifi access points
around the world with the same SSID.
I agree. SSID is "just a name". If the name ends with "_nomac", Google
promises to *drop* that SSID from its' public database.
However, you must realize that the Google Public Database contains *more*
than the SSID! It contains the *unique* BSSID associated with that SSID,
and furthermore, it contains the Signal Strength of that access point at a
specific GPS location of the poorly configured Android device that is near
that access point.
Anyone who doesn't *understand* that paragraph above can't possibly
understand the topic of this thread - so it's critical that the paragraph
above be *understood*.
A wifi access point consists of one or more radios to create a WAN.
Each radio is a BSS with a BSSID, which is also known as a MAC. Each
network device/radio has (by design, but not always in fact) a unique
value for the MAC.
I agree. Specifically, if an iOS or ANdroid cellphone is acting as an
access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
a. The cellphone AP SSID
b. The cellphone AP BSSID
What you must understand to understand the question, is that poorly
configured Android devices will *send* to Google not only that information
above, but *more* information!
Poorly configured Android devices will send to Google:
a. Your cellphone AP SSID
b. Your cellphone AP BSSID (aka MAC address)
c. Your AP signal strength seen by the poorly configured Android cellphone
d. The GPS location of the poorly configured Android cellpone
A device wishing to connect to a wifi access point looks for a broadcast
wifi packet with a particular SSID in the data field of the packet. The
header to the packet contains the BSSID/MAC of the access point in
source field. To connect to the access point the device sends a packet
back to the sender of the broadcast by putting the access point's BSSID
in the destination field of the packet and its own MAC in the source
field. The rest of the connection protocol is left as an exercise for
the reader.
This part is understood that the BSSID of the 5Ghz and 2.4GHz radios in
both iOS and Android devices is sent in the clear in packets whenever those
cellphones connect to an access point.
But I'm not talking about that.
I'm only talking about when an iOS or Android cellphone has the following
four bits of information *sent* to the Google database by poorly configured
Android devices:
a. Your cellphone AP SSID
b. Your cellphone AP BSSID (aka MAC address)
c. Your AP signal strength seen by the poorly configured Android cellphone
d. The GPS location of the poorly configured Android cellpone
Now, with all that said, there is in theory nothing to stop any program
running as part of the wifi access point or within the connecting device
to query its own networking internals to grab its own MAC address or the
MAC address of devices it is communicating with and send that info out
onto the internet to some recipient along with info from its own GPS, if
available.
Yes. You are correct that there are *other* methods, other than the Google
Public Database, to obtain MAC addresses of devices.
For example, this web site from wardriving softwa
https://wigle.net/
But *this* question is complex enough for most people (almost nobody
understood the question) if I simply stick to the Google mechanism.
Lord knows how complex this question gets if I bring in the Wigle
wardriving mechanism (which even I don't understand).
So, while it is not part of the normal protocols to reveal that
information it is not inconceivable that some user level program could
be doing the nasty deed.
Yep. Wardrivign software.
Or anything from Marius Milner (e.g., netstumbler).
Furthermore, all of this is at best fleeting information because a
network device's MAC address is held in ROM on the device. The network
software in a device reads the ROM to get the MAC, but is in no way
required to use that address when constructing packets that will go out
the device. The device itself *DOES NOT* insert the address into the
outgoing packets. That is all handled by software. Therefore it is
trivial for the software to use whatever MAC address it wants for its
outgoing packets. This is in fact how DECnet used to work, the two high
order bytes of the MAC were changed to reflect the fact that a packet
was a DECnet packet.
This is not true.
Jeff Liebermann explained in the past why it would take an heroic effort to
clone the MAC address of the radio that is sending out the packets.
The cloning is on a different MAC address, which is not the MAC address of
concern here.
Too bad, becuase if it were easy to change the Access Point MAC address,
then I would change mine daily.
As was said before, just flip a few bits and you could suddenly appear
to be on the other side of the planet.
Not true.
You're confusing the easily cloned MAC address with the one that would take
desoldering to change.