From: Maxim Levitsky <maximlevitsky@gmail.com>
To: "hostap@lists.shmoo.com" <hostap@lists.shmoo.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: deauthentication and disassociation nl80211 commands
Date: Mon, 05 Oct 2009 04:11:47 +0200 [thread overview]
Message-ID: <1254708707.24430.68.camel@maxim-laptop> (raw)
Here I want to ask and summarize problems we found in thread
'driver_nl80211 broken again'
First of all it it known that lifetime of connection to access point is
typically:
authentication request/response
association request/response
EAPOL 4 way handshake (for WPA)
<session>
disassociation
deauthentication
Today kernel explicitly requests the driver to perform both
disassociation and deauthentication in that order.
It is also possible to do disassociation and then association, skipping
the authentication step.
However, currently wpa_supplicant assumes that once it called
wpa_drv_disassociate it can again start the complete connect sequence
from the authentication.
In fact I have carefully studied the code and found that calls to
wpa_supplicant_deauthenticate (which is the only user of
wpa_drv_deauthenticate) only happen at deinitialization of wireless
interface and when wpa_supplicant really has to do it, that is if there
is a failure (mic failure for example).
My hacky patch that was rejected on the grounds that it is not right to
introduce the driver dependent behavior might actually be the correct
solution. It just makes the wpa_supplicant_disassociate do both
disassociation and deauthentication, as was always assumed by the
wpa_supplicant core.
Or kernel should became smarter and do the work for wpa_supplicant.
In this case it should work like that:
If mac80211 is already authenticated to the AP that was requested, it
should just return success.
However currently (and I was told that this is feature, not a bug)
mac80211 would flatly refuse to do any scanning while it is in
authenticated but not associated state.
If it isn't authenticated to new AP then, new authentication should be
made.
(and old one can be kept, but removed after a timeout)
And the last question.
When do you plan to switch officially the wpa_supplicant to
driver_nl80211?
Currently it has this issue, and another issue that it (nl80211) reports
signal levels in another format that NetworkManager doesn't understand.
Other that that it is faster, and especially it allows me to bring
network up, when I press rfkill button within 4 seconds or less.
Best regards,
Maxim Levitsky
next reply other threads:[~2009-10-05 2:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-05 2:11 Maxim Levitsky [this message]
2009-10-10 3:45 ` deauthentication and disassociation nl80211 commands Maxim Levitsky
2009-10-10 16:04 ` John Klehm
2009-10-12 7:44 ` Holger Schurig
2009-10-10 16:24 ` Johannes Berg
2009-10-12 6:55 ` Jouni Malinen
2009-10-16 9:36 ` Johannes Berg
2009-10-12 6:52 ` Jouni Malinen
2009-10-15 11:45 ` Maxim Levitsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1254708707.24430.68.camel@maxim-laptop \
--to=maximlevitsky@gmail.com \
--cc=hostap@lists.shmoo.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox