On Thu, 2006-06-08 at 10:17 -0400, Dan Williams wrote:
> My initial thought was that it violated spec, but I decided to do some > checking. It appears that SSID<->BSSID mappings are a gray area of the > spec, and that there are products that do multiple SSID on a single > BSSID. The catch is that you can only have one SSID be a broadcast SSID > in this scheme, the rest _must_ be hidden. That right there is a nice, > fat, bright red warning flag, as are notes about "the downside is less > client compatibility..." Furthermore, broadcast traffic is somewhat > undefined in this scenario, and other information leakage between SSIDs > is also possible because they are sharing the same BSSID. This is ludicrous. The spec actually mentions hidden networks? And a spec actually says "the downside is less client compatibility"? How does broadcast traffic work? If a network is hidden but shares the MAC of a non-hidden network, how on Earth is anything supposed to ever differentiate it? I have a multiple-SSID-in-single-box AP, but it gives different BSSID's to each network. Seems easy enough. > So here's a thought (started out as two different options, but this one > is clearly better): So, you are really arguing here for two points, right? The first is that we should change the merge-AP-into-existing-list code in NetworkManagerAPList.c to not just coalesce AP X and Y if their BSSID matches, but also check if their security (or some other attribute) matches? Isn't the main point of the coalescing code detecting changes in a given AP? Where you add X to the scan list and X is really Y, which is already in the list? In other words, why have the merging code at all for BSSIDs? Just keep the merge code for ESSIDs. The BSSID -> ESSID mapping happens elsewhere, so we should be able to ditch the merging code and still do the mapping (which I agree we 100% want to do) bit. The second point you offer is moving from ESSID to UID-based object paths. I'm not against this -- not having to escape the network names would prove nice -- but this will prove a bit of work. And the UID will probably end up containing an escaped ESSID. ;-) But its probably worth it, because we DO have a problem (ignoring this absurdity) with different networks sharing an ESSID. We probably need to face the facts that the only proper identifier for an AP is its unique (ESSID,BSSID) pair. Not one or the other, but both. This is a problem, though, because we also have a concept of "network" which is really a set of one or more AP's, and thus we have a list of BSSIDs... We mix these paradigms at times. We store networks, but you connect to AP's. Etc. In short, I have words for whoever wrote the wireless spec. Robert Love _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list