Re: Tutorial: Query the Apple database with Python for your access point BSSID
Char Jackson <[email protected]> Wed, 31 Dec 2025 20:24:56 -0600
| Newsgroups | alt.comp.os.windows-10,alt.internet.wireless,alt.comp.microsoft.windows,alt.comp.os.windows-11 |
|---|---|
| Organization | Newshosting.com - Highest quality at a great price! www.newshosting.com |
| Message-ID | <[email protected]> |
On Wed, 31 Dec 2025 08:03:36 +0100, "R.Wieser" <[email protected]> wrote: >Char, > >> It helps greatly if a MAC address is unique within its local >> network segment, > >I would say that! Yes, :) Unless of course if it's done intentionally, which should very rarely be the case. >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. 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. >> but a duplicate MAC appearing somewhere else shouldn't cause >> any problems. > >As long as it would not be a duplicate there, you would be correct. :-) I was thinking that the chance of that kind of collision would be exceedingly low, but statistics were never my strength. >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. > >> *Many years ago, >... >> it didn't cause any problems. It simply moved certain >> tasks farther up the network stack > >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 ... 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!