Toshiba TV29C90 problem; Image fades to black...

[Phil Hobbs]

On 04/07/2016 09:17 AM, Geo wrote:

On Wed, 6 Apr 2016 16:58:02 -0700 (PDT), Peter Easthope
petereasthope@gmail.com> wrote:

On Wednesday, April 24, 1996 at 12:00:00 AM UTC-7, Tim Warner wrote:
Does anyone know where I can find a replacement for a Lovato DPMC9
Relay/Contactor?
Thanks...
---Tim

eBay. If nothing appropriate is current, save a search.

... Peter E.

Current?? Ho ho ho... 2016-1996=10

Well, in base 20 arithmetic

Of course then the original post would be from the year 11786 AD.
Devilish up-to-date, to be sure.

Cheers

Phil Hobbs

 

[Geo]

On Thu, 7 Apr 2016 09:53:29 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

Well, in base 20 arithmetic

I use my toes too...

 

[Anai]

Hi T&E,

I am keen to protect Hitachi H8-3064F flash eprom content.
Would like to know if you have the procedure to protect H8 MCU and if so willing to share the knowledge?

Regards
Anai

 

Hi you don't know me but I saw your Fred on Google and I think I may have what you're looking for this is the video player machine Sears Roebuck made before betamax came out the model number is 5285200204

 

[Michael Black]

On Sun, 8 May 2016, tomjenrobinson@gmail.com wrote:

Hi you don't know me but I saw your Fred on Google and I think I may
have what you're looking for this is the video player machine Sears
Roebuck made before betamax came out the model number is 5285200204

The original post is 17 years ago.

You didn't notice the date, you didn't even read through the thread so you
never saw the idiot who posted in late 2013 saying they had such a
machine, or our replies then pointing out that the original poster wasn't
here in 2013.

There were over 30 posts in the thread back when this thread was topical,
you really think the guy didn't get what he needed/wanted back then?

The only thing worse than people who reply to old threads is people who
don't even read the full thread before replying late, to even try to see
if the problem was solved.

Michael

 

[Allodoxaphobia]

On Sun, 8 May 2016 21:08:27 -0400, Michael Black wrote:

On Sun, 8 May 2016, tomjenrobinson@gmail.com wrote:

Hi you don't know me but I saw your Fred on Google and I think I may
have what you're looking for this is the video player machine Sears
Roebuck made before betamax came out the model number is 5285200204

The original post is 17 years ago.

You didn't notice the date, you didn't even read through the thread so you
never saw the idiot who posted in late 2013 saying they had such a
machine, or our replies then pointing out that the original poster wasn't
here in 2013.

There were over 30 posts in the thread back when this thread was topical,
you really think the guy didn't get what he needed/wanted back then?

The only thing worse than people who reply to old threads is people who
don't even read the full thread before replying late, to even try to see
if the problem was solved.

Google Groopers -- bless their little hearts (and other little organs.)

 

I have a sony mch-c50 and I want to fix it. Where can I find someone who could fix it for me please?

 

Brian S., et al:


Mechanical optical players(CD, Laser Disc,
DVD, etc) were intentionally engineered to
give a relatively short life of functionality,
regardless of brand or price-point. The
manufacturers of these things knew, thirty
years ago, what was coming as far as
"downloading" or "streaming" are concerned.

So they skimped on the build-quality and
mechanical quality of CD players and such.
Sad it is the truth, because fidelity-wise I
will choose a CD or DVD player any day
over a streaming or cloud service to listen
to my music or watch my movies.

The price we pay for planned obselescence...

 

On Friday, May 20, 2016 at 11:43:49 PM UTC-5, abbaa...@gmail.com wrote:
> I have a sony mch-c50 and I want to fix it. Where can I find someone who could fix it for me please?

Umm, you realize this thread is old enough to drive a car, almost legally. It is 14 years old.

If you are having trouble with the CD reader you are looking at an incredible bitch just to clean the LASER to see if that works. If that doesn't work you need to replace it. They do go bad over the years. Don't put alot of money into it. First of all due to its age it probably only plays CD+G. There are new formats, MP3+G and NEO+G which are superseding that by leaps and bounds. What's more they are getting into Karaoke players that have harddrives, and I mean like terabyte harddrives. Never scratch another one. In fact you get online and update from a USB stick. The firmware in the units can generally handle up to 250,000 songs if you can gitem and fitem.

The ones with the internal harddrives usually have a model specific file structure to keep the software simple. However many with the USB jack can use an external harddrive formatted with FAT32, which almost everything can read. Well maybe fukin Windows 10 can't but that is not my fault.

I don't want to give a free plug, but a joint called Lightyear Music deals in this stuff. I work for them. I am kinda new to the karaoke business so I do not know if they are good or bad but they seem alright and seem to try to please the customers. They got cheap players that are totally backwards compatible but you need a TV with them. But then that looks better anyway. I didn't notice any mention of a video output on that Sony.

If you need the karaoke function you might consider one of those, or a refurb. The NEO-22 is about to drop in price because the 22 PRO is out, which adds bluetooth capability. Really, that shows how outdated that Sony is. If you went to buy karaoke disks for it your selection would be limited, like buying records for example.

I a not saying throw it out. not at all. If she likes the sound and does't use the karaoke then I think it would be easier to just find the audio wires from the CD section to the preamp/selector and wire a pair of RCA jacks on the back and plug a CD player in there.

The problem is they put the CD drive so low, all the stuff you have to take off just to CLEAN the lens is ridiculous. and there are pitfalls, you must be very careful. You miss disconnecting ONE ribbon cable and rip it as you pull out a board or assembly you are done. Throw it away.

The main board is on top and the heatsinks hanging off the back. Once you get all the shit disconnected from that then you have to remove the dual cassette mechanism which you'll be lucky to remember where all the wires go to that. Then I couldn't see, but you might not be able to remove the disk clamp which means disassembling the CD drive, just to get a Qtip in there.

And you got 20 square feet of parts laying around, though thet is not all that hard to deal with if you are ready for it.

And then you have to put it ALL THE WAY BACK TOGETHER to see if the cleaning helped or not.

I call these things frack systems for "fake rack" systems. I do ot recommend them to anyone, even if they have to hire someone to come in and connect separate components. I do not recommend they be repaired except for the most basic things like a cord or something.

If you have an AUX input just plug a CD or karaoke player in it, if not, try to fid the wire feeds the audio from the CD drive. That is my recommendation. And if you want to try doing it just for fun, I guarantee you it will not be fun.

 

Yours may not have the karaoke function.

If not, and all it plays is regular CDs don't bother. Just find the wires.

I just looked again and they do not all have that.

 

On Thursday, August 15, 2002 at 12:30:56 AM UTC-4, Stephen Jacobs wrote:

I have an Atari 5200 videogame system. The motherboard is dated (c)1982,
and a stamped label on the RF shield is dated 1983.

The system does not power up.

Surrounding many of the solder points on the underside of the
motherboard is some kind of residue that looks like some sort of brown
syrup-ish substance, a bit like old Coca-cola. Might be nothing.

The previous owner indicated that he received the system with the
incorrect power supply. He obtained the correct power supply, and never
got the machine to work.

I noticed 3 components, labelled C30, C32, & C33. These components look
like discs, mostly olive green, with shiny black coloring at the tops.

A) I'm guessing these are capacitors - am I right?
B) Are these components supposed to be all green, and is the black on
the top indicative that they've fried?
C) Is it reasonable to conclude that the wrong power supply was hooked
up, and it fried these capacitors? If so, could I probably get the
system working by replacing these capacitors?

Thanks for any help,
Steve

I am so sorry if I am sounding like a complete novice in this, but I AM ONE! Rather than learn about circuits, schematics, chips, soldering, troubleshooting, etc., does anyone know of any person or shop that troubleshoots and fixes these Atari 5200 (especially 4-port model) machines? I just had my first major fail at this tonight and it is quite disappointing and disheartening. I'm 64, unemployed, and disabled, and am quite willing to learn anything new, especially electronics, but perhaps I have bitten off more than I can chew with having about 13-15 4-port 5200s that don't work for one reason or another. I thought I could make one good console out of 2 bad ones, but it's not working out that way for me. The only option is to try to get them fixed. Some of you on this board make it sound so EASY..."just pop out this chip, swap it with this chip, if it works then you have found your culprit", etc. But for most of us here, this is total "greek to us". Can someone please point me and others with me in the right direction? I'd even be willing to pay to have these machines repaired (if within reason), it sounds like some of you could do it in under an hour for each console. I've almost mastered refurbishing the OEM CX-52 controllers with new parts....that's mostly just mechanical, replace the old, put in the new, put it back together carefully and hope it works! But please, someone come to my aid and reply to me. Do repair people/shops even exist for Atari 4-port consoles? Thanks so much for your kindness in even reading this far. - Ed Fernandez, South Amboy, NJ - June 22, 2016

 

[Allodoxaphobia]

On Wed, 22 Jun 2016 18:22:16 -0700 (PDT), ehf0528@gmail.com wrote:

On Thursday, August 15, 2002 at 12:30:56 AM UTC-4, Stephen Jacobs wrote:
I have an Atari 5200 videogame system. The motherboard is dated (c)1982,

<snip>

I am so sorry if I am sounding like a complete novice in this, but I
AM ONE!

....in several ways.

Why _the hell_ did you reply to a FOURTEEN-YEAR OLD posting instead
of starting a new one to request help for your problem(s)?

sheeesh!! google groopers!!

 

[Rheilly Phoull]

On 23/06/2016 10:30 AM, Allodoxaphobia wrote:

On Wed, 22 Jun 2016 18:22:16 -0700 (PDT), ehf0528@gmail.com wrote:
On Thursday, August 15, 2002 at 12:30:56 AM UTC-4, Stephen Jacobs wrote:
I have an Atari 5200 videogame system. The motherboard is dated (c)1982,

snip

I am so sorry if I am sounding like a complete novice in this, but I
AM ONE!

...in several ways.

Why _the hell_ did you reply to a FOURTEEN-YEAR OLD posting instead
of starting a new one to request help for your problem(s)?

sheeesh!! google groopers!!

Well disregarding other "helpful" comments
it would seem you havent googled "repair atari 5200" ??
Theres a heap of posts on that one !!

 

[Horace Algier]

On Wed, 14 Sep 2016 00:24:59 -0000 (UTC), William Unruh wrote:

If you know the MAC address of your equipment (e.g., automotive WiFi
beacons), and the MAC address of someone else's equipment, how can you look
up *where* your phone currently is?

You cannot. There is no necessary relationship between IP addresses and
location. Now often there is some rough correlation, but that is all you
can do.

I realize you're trying to help, so I will just try to be gentle at the
same time I'm trying to be blunt (you can do the same with me).

Nobody said anything about IP addresses.
And the *location* is inside of Google's database.

What I'm trying to understand is how the system works.
And then I'm trying to see if there is a *vulnerability* in the system.

I'm not a hacker (as a hacker would have far more technical acumen and a
hacker wouldn't be asking about a vulnerability on the net like this).

What I see is a *vulnerability* but you're *never* gonna see that
vulnerability if you keep talking about IP addresses!

I know that a public free easily accessible Google API maintains that
information, where if you know the MAC address of the person you're trying
to track, you can find out instantly if two MAC addresses are near each
other from anywhere in the world:
https://developers.google.com/maps/documentation/geolocation/intro

Nope.

I realize you're trying to help, but just saying "Nope" wastes *everyone's*
time, including yours and mine - but mostly other people have to read me
responding to you, which, if all you say is "Nope" means you don't have a
clue what you're talking about.

It's a *fact* that you can query Google's database to find the *location*
of a BSSID. Google implemented a (IMHO weak) "security" system by requiring
*two* BSSIDs.

It's this weak security that I'm searching for the vulnerability of.

It's a *fact* that you only need three things to get a GPS location out of
the Google database:
1. BSSID 1
2. BSSID 2 (added as a weak security feature!)
3. Signal Strength

Do you dispute *that* fact?

For the Google lookup, the only *mandatory* parameters are:
1. MAC ADDRESS #1
2. MAC ADDRESS #2
3. A fabricated signal-strength value

Except for fun, I would not rely on it.

That's not at all the point!
I am probing a perceived privacy vulnerability in the Google system.
I am doing this not to take advantage of that perceived vulnerability, but
to better *understand* that privacy vulnerability.

Specifically, with the facts known, "if" your cellphone does broadcast an
SSID, then your cellphone *can* be tracked.

Do you dispute that statement (which I have backed up in gory detail
already)?

Why or why not?

> As a trivial example, lets say I run a VPN from Vancouver to Italy.

*[Where is Jeff LIebermann when we need him?]*


What on earth does this question have to do with IP addresses?

I realize you're trying to help - but what you're doing is *jumping* to
conclusions that *nobody* else is talking about.

VPN has *nothing* whatsoever to do with this problem.
The entire Internet has (almost) nothing whatsoever to do with this
problem.

The *only* way the Internet is even involved is that your neighbor's
cellphone is *sending* your SSID & MAC & GPS location & Signal Strength
(etc) of your router *over* the Internet to Google.

So the IP address (and VPN) is completely irrelevant to this question.

My
IP will probably be an Italian one as far as the world is concerned. My
computer however is in Vancouver.

This question has absolutely nothing to do with IP addresses and VPNs.
Where did you get the idea that the question had *anything* to do with the
Internet?
I'm sorry if I'm being too blunt, but I'm focused on getting the answer to
a *simple* question.

Q: When does an Android cellphone broadcast an SSID?

NOTE: The SSID has nothing to do with the question but people get all hung
up if I ask the question this way:

Q: When does an Android cellphone broadcast a BSSID?

 

[Horace Algier]

On Wed, 14 Sep 2016 00:27:22 -0000 (UTC), William Unruh wrote:

So, my key question is *when* does a mobile device broadcast it's MAC
address (BSSID & SSID)?

Those have nothing to do with the MAC addresses. And the Mac address of
a device ( a wireless card-- that is what a MAC address is the address
of) can be changed at will

Thank you for trying to help answer the question, as I realize answering
such a deeply technical question involves risk - and we need to communicate
so that we don't waste time on completely meaningless tangents.

First off we have to agree on some terms, and which are meaningful for the
purpose of *this* thread:

- SSID: This is *not* very meaningful for the purpose of this thread!
The SSID is only meaningful in that you can "do things" with your SSID
which tell Google to do *other things*, e.g., you can append "_nomac" to
the end of the SSID and Google promises to *drop* your information from its
databases. But since SSIDs are not generally unique, the SSID is not the
focus of *this* discussion.

- BSSID: This *is* the focus of this discussion, where each router has
*multiple* BSSIDs (aka MAC addresses) and where the focus of this
discussion is *only* on the one unique MAC address that is transmitted in
companion with the SSID of an access point!

It's critical that you understand that your statement is patently incorrect
that the router MAC addresses that *Google* is collecting using your
neighbor's Android device are easily cloned.

The MAC addresses that Google is collecting using your neighbor's poorly
configured Android cellphone are *not* easily changed (you have one per
each radio, e.g., 2.4GHz and 5GHz, for example).

These radio access point MAC addresses are NOT easily cloned!
This has been covered in this newsgroup in detail in the past.

However, even if the router's MAC address could be cloned (it can't, at
least not without desoldering and other heroic actions), it *still* would
be collected by your neighbor's poorly configured Android device.

So, it doesn't matter that you can't clone the MAC address that Google is
collecting by using your neighbor's Android device to automatically send
that information to Google periodically during the day.

The fact is that all poorly configured Android devices are automatically
sending Google throughout the day *your* MAC address of your router.

NOTE: While I'm completely aware that turning off SSID broadcast is
possible (and that it's not useful for security), we are assuming for this
purpose that the SSID is broadcast by the router.

Does a mobile device broadcast its MAC address when acting as a hotspot,
for example?

No.

I realize you are trying to help - but I must be blunt, since this *is* the
critical question.

Since this *is* the critical question, a simple "No" is not enough,
especially since your previous statements in this post show that you
misunderstood completely the question and the situation.

I'm sorry if that sounds mean, but, a simple "No" is not believable under
those two circumstances.

The correct answer might still be "No", but you don't understand the
question yet, nor the technical situation, so a "No" all by itself doesn't
help.

My key question is *when* does an Android cellphone broadcast the MAC but
most people get all hung up about MAC addresses - so I'll dumb down the
question to ask "When does an Android cellphone broadcast an SSID?".

Q: Under what conditions does an Android cellphone broadcast an SSID?
NOTE: I don't care about the SSID - I care about the MAC - but people get
hung up about MAC addresses so I'll ask it in the simpler form.

 

[Andy Burns]

Horace Algier wrote:

> I'll dumb down the question

Doesn't matter if the hat says "Alice J", "Aardvarks" or "Horace",
people don't want to go over the same ground again ...

 

[Frank Slootweg]

Horace Algier <horatio@horatio.net>... oops I mean "Aardvarks"... oops I
mean "Paul M. Cook"... oops I mean "VPN User"... oops I mean "Joe
Clock"... oops I mean "Marob Katon" ... oops I mean "Chris Rangoon"...
wrote:

My key question is *when* does an Android cellphone broadcast the MAC but
most people get all hung up about MAC addresses - so I'll dumb down the
question to ask "When does an Android cellphone broadcast an SSID?".

Q: Under what conditions does an Android cellphone broadcast an SSID?
NOTE: I don't care about the SSID - I care about the MAC - but people get
hung up about MAC addresses so I'll ask it in the simpler form.

You don't ask a dumbed down question, but a dumb question and your
'question' isn't a question, but a false statement.

HTH.

 

[bruce]

This question has absolutely nothing to do with IP addresses and VPNs.
Where did you get the idea that the question had *anything* to do with the
Internet?
I'm sorry if I'm being too blunt, but I'm focused on getting the answer to
a *simple* question.

Q: When does an Android cellphone broadcast an SSID?

NOTE: The SSID has nothing to do with the question but people get all hung
up if I ask the question this way:

Q: When does an Android cellphone broadcast a BSSID?

Oh, what the hell. I'll give it a try.

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).

SSID has nothing to do with cellphones. It has to do with wifi only.
The same is true for BSSID.

SSID is just a name. There could be thousands of wifi access points
around the world with the same SSID.

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.

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.

Until things get handed over to (presumably) DHCP there is no way to
communicate other than the use of MAC addresses in the appropriate
fields of the LAN packets. Strictly speaking, even after an IP address
is assigned to the device, all communications on the LAN/WAN is still
through the use of BSSID/MAC. It is only after a packet is recieved by
the router that higher levels of network communications kick in and a
packet will be repackaged with the necessary outer packet to make its
way to the internet.

So, "Q: When does an Android cellphone broadcast an SSID?"

A: Keying on the use of the word "broadcast" and ignoring the use of the
word "cellphone" because it doesn't apply, only when it is acting as
its own access point/hot-spot for other devices. After all, an SSID
is only a name.

And, "Q: When does an Android cellphone broadcast a BSSID?"

A: Again, keying on the use of the word "broadcast" and ignoring the
word "cellphone" the answer is the same as for the previous question.
However, as mentioned earlier, the MAC/BSSID is used in every packet
that is sent back and forth with the access point, but is strictly
usable only within the geographic area that the radio signals reach,
which is pretty much limited to line of sight communications and for
which walls are only semi-transparent at those frequencies.

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.

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.

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.

As was said before, just flip a few bits and you could suddenly appear
to be on the other side of the planet.

Whew!

Now, what has been left out? Oh yes, the cellphone network. How data
is sent over the cellphone network is probably off topic for most of the
newsgroups listed above. Therefore, I suggest you redirect your
queries/confusions to more appropriate groups.

Bruce .

--

 

[Kerr Mudd-John]

On Wed, 14 Sep 2016 08:54:56 +0100, Frank Slootweg
<this@ddress.is.invalid> wrote:

Horace Algier <horatio@horatio.net>... oops I mean "Aardvarks"... oops I
mean "Paul M. Cook"... oops I mean "VPN User"... oops I mean "Joe
Clock"... oops I mean "Marob Katon" ... oops I mean "Chris Rangoon"...
wrote:
My key question is *when* does an Android cellphone broadcast the MAC
but
most people get all hung up about MAC addresses - so I'll dumb down the
question to ask "When does an Android cellphone broadcast an SSID?".

Q: Under what conditions does an Android cellphone broadcast an SSID?
NOTE: I don't care about the SSID - I care about the MAC - but people
get
hung up about MAC addresses so I'll ask it in the simpler form.

You don't ask a dumbed down question, but a dumb question and your
'question' isn't a question, but a false statement.

HTH.

It's a xposting troll.

--
Bah, and indeed, Humbug

 

[Horace Algier]

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 software:
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.