Re: network profiles

[Dan Williams <dcbw redhat com>]

On Tue, 2004-12-14 at 12:05 -0500, Bill Moss wrote:
> I think NM is not working properly with ipw2200 because ip2200 does not 
> yet support scan quality; i.e. I have to keep entering ESSID and WEP key 
> using 'Other Wireless Networks'

Hmm, it _should_ work already...  When the results of a scan are
returned, NM attempts to match up non-broadcasting AP's MAC addresses
with their ESSIDs, which are pulled in from NetworkManagerInfo.  It then
uses that information to determine what the most recently accessed AP
was (i.e. the timestamp key in gconf).

I've successfully used this at work and at home, where neither of my
target networks (work has a few "cloud" or whatever with a couple APs
and the same ESSID) broadcast their ESSID.  I guess the next thing to do
would be to add some debugging statements to figure out what's going
wrong...

> IBM's Access Connections tool works equally well with broadcast and 
> hidden ESSID's and only requires the input of ESSID and WEP key. I go 
> back and forth from home (broadcast) to office (hidden) without problem. 
> In fact, for a long time I operated my home with the same ESSID as 
> campus. It was only after I started using NM, that I created a separate 
> ESSID for home. My guess is that IBM's Access Connections utility scans 
> for MAC's and compares to its database. If it finds a MAC in the 
> database for an AP inrange, it looks up the corresponding ESSID and WEP 
> key. Using ESSID as the primary key for the networks database does not 
> make sense to me. I have gconf set up with a network called Clemson. The 
> addresses key contains the list of campus MAC's. The ESSID is cuairnet 
> and there is a 128 bit hex WEP key. When an ipw2200 scan tells NM that 
> there is an AP in range with MAC XXX, I would expect NM to look in gconf 
> for that MAC. If it finds it, then NM can read the corresponding ESSID 
> and the key

As above, this _should_ happen automatically in NM already, at least I
specifically coded this behavior in.  Since its not working, something
must not be correct in the code, we need to debug more.  I need to think
of some good ways to figure this out.  Would you be able to accept a
patch and try that out, and to email back the output of NetworkManager
with that patch?

Dan