http://defect.opensolaris.org/bz/show_bug.cgi?id=9798
amaguire <alan.maguire at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |9919
--- Comment #1 from amaguire <alan.maguire at sun.com> 2009-07-08 07:05:57 ---
(In reply to comment #0)
> at present, for a phase 0(.5) key to be upgraded to phase 1, it needs to match
> both ESSID and BSSID of the network being connected to. In phase 1, we store
> keys as ESSID-only, so the upgrade process involves reading in the key and
> changing it to the ESSID-only form. However we could probably do a bit better
> by matching any key that matches the ESSID prefix rather than looking for the
> exact ESSID/BSSID match.
The difficulty here is it's sometimes the case that the WiFi key gets updated -
then we're presented with a phase 0(.5) state which contains multiple
essid/bssid pairs, perhaps with a different key (if bssid X hasn't been
connected to since the key was changed).
Since we don't have a good key validation test at present, I'm beginning to
wonder if we should try and update the key in cases where we don't get an exact
essid-bssid match. The problem is that if we pick up an old key, we can't weed
it out as invalid since the connection will appear to succeed. In such cases,
we're better off prompting the user for a new key than consuming a (possibly
invalid) old one. The key will only need to be prompted for once also.
So we could push for a bit more intelligence in handling old wifi keys on
upgrade, but the more I think about it, the more I prefer tying this to having
a valid WLAN connection self-test.
--
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.
