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


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

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


--- Comment #2 from amaguire <alan.maguire at sun.com> 2009-08-25 13:00:46 UTC 
---
(In reply to comment #1)
> Created an attachment (id=2497) [details]
> Contents of nwamevent structure.
> 
> This appears to be happening because when we get the WLAN_NEED_KEY event from
> nwam the wlan_info contains invalid data, for example see the attachment for
> the complete structure, but the sub-set is here:
> 
> 
>         wlan_info           = {
>             name      = "iwh0"
>             connected = B_FALSE
>             num_wlans = 1U
>             wlans     = (
>             {
>                 essid           = "dub04wlan"
>                 bssid           = ""
>                 signal_strength = "H\017??????"
>                 security_mode   = 2U
>                 speed           = 169U
>                 channel         = 134509040U
>                 bsstype         = 4269387513U
>                 keyindex        = 0
>                 have_key        = B_FALSE
>                 selected        = B_FALSE
>                 connected       = B_FALSE
>             }
>         }

the issue here is that when we allocate the NEED_KEY event message in nwamd, we
don't bother filling in these fields. I think selected should be true here of
course, but I'm not sure we should fill in the rest if the user hasn't made a
specific BSSID selection, since it's possible different WLANs with the same
ESSID have different signal strengths, channels, bsstypes etc. Would it be
acceptable to just fill in the have_key/selected/connected fields here, or do
you need more? Thanks!

-- 
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.

Reply via email to