http://defect.opensolaris.org/bz/show_bug.cgi?id=11297


amaguire <alan.maguire at sun.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ACCEPTED
                 CC|                            |alan.maguire at sun.com


--- Comment #2 from amaguire <alan.maguire at sun.com> 2009-09-15 09:10:30 UTC 
---
(In reply to comment #1)
> Some additional data: the same problem exists when adding new entries to the
> known wlan list.  If an entry is explicitly added (as opposed to being added 
> by
> nwamd upon connection), the nwam service must be restarted in order for nwam 
> to
> start using that wlan.

that's very strange. Did you wait for a rescan? I would have expected that on
rescan, nwamd_find_known_wlan() would have picked up the new WLAN, since it
walks the known WLAN list directly (rather than the cached version of it in
nwamd).

To an extent, the known WLAN handling is broken in nwamd since we maintain and
refresh an object list of known WLANs but don't use it really - when we read
scan results and check for known WLANs we call the libnwam API functions
directly rather than utilize the in-nwamd cached object list.

So in a sense, I'd expect the known WLAN handling to work "better" than the
objects in the sense that we can't get out of sync with the backend config
since we refer to it rather than a cached view of it.

We should probably do the following (though I'm not convinced these will
address the problems you're seeing) to improve known WLAN handling:

- remove the known WLAN object list from nwamd
- maintain the init/fini event handling, since these are the only events we
care about for known WLANs. On init, we should add a function that, if we're
not currently connected, checks the last scan results for the wlan added. If
it's found, initiate a connect (checking if we're connected prevents flurries
of connect/add to known WLAN/connect). On fini, we should add a function that,
if we're currently connected, and the WLAN connected is the one removed,
triggers a disconnect.

What do you think?

-- 
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

Reply via email to