driver_nl80211 broken again
johannes at sipsolutions.net
Thu Oct 1 04:46:26 EDT 2009
On Thu, 2009-10-01 at 01:13 +0300, Jouni Malinen wrote:
> > @@ -1302,8 +1302,10 @@ void wpa_supplicant_disassociate(struct wpa_supplicant *wpa_s,
> > wpa_drv_disassociate(wpa_s, wpa_s->bssid, reason_code);
> > + wpa_drv_deauthenticate(wpa_s, wpa_s->bssid, reason_code);
> To me, this looks broken. When wpa_supplicant requests a
> disassociastion, it is _only_ asking for disassociation, not
> deauthentication. cfg80211/mac80211 may not currently handle that, but
> as far as I can tell, it sounds like an issue there and not in
> wpa_supplicant. Johannes may disagree with this, though.
cfg80211/mac80211 _do_ handle that. If you ask for disassociation, it
stays authenticated, and later expects you to still remember that and
refuses authentication since you're already authenticated.
> I don't think either of those options would be acceptable for
> wpa_supplicant and the correct fix is to make cfg80211/mac80211 be able
> to handle authentication to a STA that is already authenticated. If
> that is not acceptable, this hack needs to be hidden in driver_nl80211.c
> instead of polluting core wpa_supplicant code which is supposed to be
> driver independent. In other words, make driver_nl80211.c deauth if auth
> fails and then try auth again. I don't really like that much, but if
> this needs to be worked around in wpa_supplicant, that is the most
> likely place where such a change could be considered.
I still don't see how it makes sense to authenticate while still being
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 801 bytes
Desc: This is a digitally signed message part
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20091001/e6f3462a/attachment.pgp
More information about the HostAP