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

[Dan Williams <dcbw redhat com>]

On Thu, 2006-06-08 at 10:57 -0400, Robert Love wrote: 
> 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?

No, the spec mentions nothing about this possibility AFAICS, but random
comments and other documents I've found via Google describe how to do it
and the particular limitations of doing it.  It seems to be a
manufacturer driven thing where they simply decided to charge into areas
that weren't fully spec-ed out by the 802.11 spec and make up their own
interpretation.

> I have a multiple-SSID-in-single-box AP, but it gives different BSSID's
> to each network.  Seems easy enough.

Yeah, same for some of our test equipment at the office.  It provides up
to 64 BSSIDs and won't let you do more than one SSID on a single BSSID.

> > 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?

Yes.

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

Yes, that code would go away because most of it would be rewritten.

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

We'd probably want to roll that code into the merging code, since in
Jens' situation we would normally coalesce 'foo' to 'bar' because they
share the same BSSID and 'foo' is hidden.  (Well, 'foo' just wouldn't
show up in the scan list really, so we'd have to pull 'foo' out of GConf
and merge it into the scan list artificially).  But the point here is
that we can't seem to rely on the merge logic the way it is now.

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

Yes, the UI will obviously have to escape bits of the ESSID, and we'll
have do lookups to find ESSIDs in our networks list rather than just
constructing the object path itself.  But I think that's somewhat
cleaner in the long run than having to jump through hoops to stuff
random character sets through dbus and GConf.

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

Correct; even if we use (ESSID, BSSID) pairs, we still need the concept
of a "network", which is exactly what the ESSID was supposed to provide.
We're still going to combine APs to form "networks", but the combination
process should take into account more than just ESSID; it should also
account for mode (adhoc/infra) and encryption settings.  We have
somewhat of an M:N mapping here, but I think it's quite doable and not
too messy.

In the end, we're not going to be perfect, but I assert that is OK.
We're making a trade-off between ease of advanced configuration and easy
of daily use.  Everyone makes that tradeoff, and we're no different.
Where we make the difference is how far to either side we go.  And
obviously I'm on the record for more easy-of-daily-use.  If somebody
relies daily on an access point that has the same security type and
ESSID as another, but not the same WEP key, that's just dumb.  We're not
going to work around everyone, or we'd get nothing done and have a
horrible UI to prove it :)

Dan