Re: [3/3] Do something with trusted networks



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]