On Wed, 2006-06-07 at 18:53 -0400, Robert Love wrote: > Jens Lautenbacher wrote: > > > Please, reconsider the decision to not shown the trusted networks in an > > easily accessible list... this would help so much here :-) > > The old behavior (as of the last patch I posted) would not have solved > this, either. > > Are you saying you have two wireless networks, with two different > ESSID's, but sharing one BSSID? > > That violates the wireless spec, I am 99% sure. Who makes the access > point?
This is horrid. 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. I'd rather not actively aid & abet this practice by separating out every MAC, but that doesn't mean we can't try to make life easier for those people who's network admins make the WRONG decisions :) > The reason NM chokes on it is that we have logic to merge two AP > objects into one if they share the same BSSID. So here's a thought (started out as two different options, but this one is clearly better): Do finer-grained coalescing of access points. Still do limited BSSID->ESSID fill-in, but after that, start matching AP capabilities too. There's no way to distinguish between 40/64/104/128-bit WEP, but we can stuff the APs into categories like unencrypted, WEP, WPA1, WPA2. If the user has pre-configured settings for them, we can use those to further differentiate them. We must be careful to not do too-aggressive differentiation, but it's pretty clear that an AP that's unencrypted shouldn't be coalesced with an AP that's encrypted, even if they share the same SSID. The point is that we accommodate users who's networks suck, but don't make pointless distinctions for people who never are, or never will be, in that situation. Given Jens' situation, with a few others thrown in: a. SSID: foo, BSSID: xx:0a, hidden, WEP b. SSID: bar, BSSID: xx:0a, broadcast, unencrypted c. SSID: linksys, BSSID: xx:bf, broadcast, WPA1 d. SSID: linksys, BSSID: xx:ac, broadcast, WPA1 e. SSID: linksys, BSSID: xx:9f, broadcast, Ad-Hoc, WEP f. SSID: stupid, BSSID: xx:12, broadcast, WPA1 g. SSID: stupid, BSSID: xx:66, broadcast, WEP The NM applet would show the following list of logical networks: .----------------------------------. | O Wired Network | | | Wireless Networks | | | | O foo ========.... | | O bar E ==========.. | | O linksys E =====....... | | O linksys AE =........... | | O stupid (WEP) E =======..... | | O stupid (WPA1) E ========.... | |----------------------------------| | VPN Connections > | |----------------------------------| | Connect to Other Wireless... | | Create Wireless Network... | `----------------------------------' A few notes; first, you'll see that 'linksys' doesn't have its encryption type shown, because all access points in the area are homogeneous. There's no point to the extra information, except to know that the AP is encrypted, if you care. 'foo' and 'bar' are differentiated, because they have different SSIDs. This _does_ mean a bunch of extra logic in NM to make sure we don't do the hidden network BSSID->SSID matching too soon if more than two or more GConf entries share the the same BSSID. Since the 'last connected' timestamp is kept per-SSID, which I think is 100% correct, NM should only connect to 'bar' for Jens, and ignore 'foo'. For him, the latency for connection will be slightly higher, but that's the price he pays for working at a company that doesn't want to shell out for a better AP. Bad Jens :) If we differentiate APs this way, we can't keep using dbus object paths or GConf paths like we have until this point, ie keyed off SSID. After a long and futile struggle, I hereby capitulate to pragmatism. I propose to not use the SSID in the dbus object path, and not to use it in GConf paths either. I guess we'll just use some sort of UID instead. This also means we don't have to escape SSIDs for dbus or gconf, which proved to be a PITA. This should all be 0.7 material. Thoughts? I'd also like some bclark interaction input here, but we'll get that in a minute after we make sure I'm not smoking the heavy technical/situational crack at all. Dan _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list