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

[Robert Love <rml novell com>]

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