http://defect.opensolaris.org/bz/show_bug.cgi?id=9077
amaguire <alan.maguire at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alan.maguire at sun.com
AssignedTo|nwam-dev at opensolaris.org |alan.maguire at sun.com
Status|NEW |ACCEPTED
--- Comment #2 from amaguire <alan.maguire at sun.com> 2009-05-22 07:00:43 ---
(In reply to comment #0)
> For some reason when I unplugged my cable, and nwamd did a scan for wireless
> networks, I got prompted (using nwamadm interact) for the wifi key for the
> dub04wlan network, and despite entering the key, I got re-prompted 3 times
> more.
I've seen this too, I'm working on it as part of the state
machine work - hopefully this problem will go away. I'll
be testing for it and I'll update this bug.
>
> One other interesting point is that prior to the BFU, I already had the
> correct
> key stored, with the bssid suffix as a secure object.
>
The "upgrade key" algorithm is pretty basic at the moment
and assumes that the old key's ESSID/BSSID pair matches
that of the WLAN you're trying to connect to. We could
enhance this algorithm to be more general (as would be
needed in sunwifi settings) and walk secure objects
looking for a match. The only problem with that is
that we may have to pick one of many keys (since the
user will have had to enter a key for each ESSID/BSSID
pair, there will be multiple secobjs). We could just
pick the first (or maybe the last, since it's likely
to be most recent), but I can't think of any other
heuristics to use here. I'll file a separate bug
for this I think, but probably won't get to
it until next week.
> Despite this, I still got prompted - possibly since it was for a different
> BSSID, but that still surprised me since I thought nwamd was meant to look for
> existing keys after an upgrade that used nwam-ESSID-BSSID, but with different
> BSSIDs.
>
> I'm attaching the nwamd log file for this.
>
> While doing this, in another terminal I was running dladm show-secobj, and a
> new secobj was created with the BSSID suffix after the first or second request
> for a key, later then after a subsequent request, the sec-obj was created
> without the BSSID suffix.
That's weird. A new ESSID/BSSID secobj shouldn't appear.
--
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.
