Horace Algier writes:
I purposely kept my earlier post at a fairly high level, mostly because
from your other posts I was left with the opinion that you weren't
handling the information you were presented with very well. I attempted
to provide some background for the discussion so that we could at least
agree on the meaning of various terms and the concepts that use those
terms.
While your reply was cordial, for the most part, you did with me as you
have done with others, namely rejected statements which are easily
verified as true.
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).
Again, here I was attepting to lay a background.
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.
And here you are trying to bore down to a lower level prematurely, IMHO.
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".
Yes, I'm afraid it is true. To reject it implies that you believe that
all cellphones do wifi. I have two on the shelf in this room that do
not do and never did do wifi.
As Jeff and I just discussed, if an Android or iOS cellphone acts as
an Access Point, then that cellphone will broadcast an SSID.
This is consistent with what I wrote above and what I wrote below. This
action has nothing to do with it being a cellphone but to do with it
acting at this point as a wifi device.
If that iOS or Android cellphone broadcasts an SSID, it also
broadcasts a BSSID, which is unique to that cellphone.
Not necessarily. The protocols allow the creation of a BSSID on the
fly. It only has to be unique within the (very short) range of the
radios in use.
In fact, it
broadcasts *two* BSSIDs, one for each radio (5Ghz and 2.4Ghz).
Actually, any wifi device acting as a BSS can identify itself as up to
32 BSSIDs and 1 or more SSIDs per radio. So, yes, a single radio can
simultaneously be using 32 different BSSIDs/MACs.
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.
As I said below, poorly configured has nothing to do with it when any
user level program running on the BSS or within the cellphone can access
the very same wifi information and pass it on to whomever it wishes.
Notice this allows such iOS or Android cellphones to be tracked!
Did I ever say anything to contradict this? I merely pointed out that
cellphone configuration, if done "properly" (whatever that means) won't
cure the problem when user level code running on the equipment can
accomplish the same thing. In fact, it might be through user level code
that it is being accomplished right now.
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.
While Google might honor the use of the suffix (for now) it doesn't mean
that anybody else will.
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*.
That "paragraph above" means absolutely nothing until one understands
that even in a "properly configured" phone user level code could be
gathering the same information (or more) and sending it to agents
unknown.
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
As stated above, poorly configured is not the problem, and Google might
not be the only recipient.
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
Get off this poorly configured fixation you have. A perfect config-
uration with any amount of user-level programs has potentially the same
nasty possibilities.
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).
Or maybe even "Angry Birds" does this too!
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.
Actually, you are partially correct. DECnet changes the leading four
octets (notice, the proper term is octets, not bytes; I was too casual
in the above paragraph) to "AA 00 04 00". The remaining 2 octets make
up the node within a DECnet network. How do I know this? I'm an
ex-DECie. (Actually, I'm still a DECie but they don't pay me anymore.)
If you want a reference on this a brief desctiption may be found at
https://en.wikipedia.org/wiki/DECnet which contains the following:
"The Ethernet implementation was unusual in that the software
changed the physical address of the Ethernet interface on the
network to AA-00-04-00-xx-yy where xx-yy reflected the DECnet
network address of the host. This allowed ARP-less LAN operation
because the LAN address could be deduced from the DECnet address."
I've avoided making any references to 802 so far here. And my DECnet
references mostly concern(ed) 802.3, 802.whatever all have the same
underpinnings. DEC was one of three companies that colaboratively
"invented" ethernet (at least the hardware specs, that is). The origin
of ethernet comes from the amateur radio two meter band protocols used
in Hawaii, which was called "Aloha Net".
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.
Without reference I can not comment on this, but what I'm talking about
for MAC has nothing to do with cloning.
The cloning is on a different MAC address, which is not the MAC
address of concern here.
Huh?
Too bad, becuase if it were easy to change the Access Point MAC
address, then I would change mine daily.
You might want to look into this then.
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.
That statement is most definately true. I can assure you that when a
VAX computer was moved from one location to another nobody went running
for a soldering iron.
If changing the MAC address (also called the hardware address) was so
difficult, why do you suppose the capability exist in ifconfig(8) to
change it?
Bruce .
--