deauthentication and disassociation nl80211 commands

deauthentication and disassociation nl80211 commands

[Maxim Levitsky]

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

Re: deauthentication and disassociation nl80211 commands

[Maxim Levitsky]

On Mon, 2009-10-05 at 04:11 +0200, Maxim Levitsky wrote: 
> 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
> 

Nobody uses driver_nl80211 but me?

Best regards,
Maxim Levitsky

Re: deauthentication and disassociation nl80211 commands

[John Klehm]

On Fri, Oct 9, 2009 at 10:45 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>
> Nobody uses driver_nl80211 but me?
>

I do and I'm sure there are more people like me that get great use out
of the older working version.

Of course Id love to have an updated version but I understand that if
I don't have the time to write it then it makes it hard to complain :P

I (and others I'm sure) appreciate your efforts to document what needs
to be fixed Maxim.  No doubt useful to the person that finally takes a
crack at the nl80211 code.

Cheers,
--John Klehm

Re: deauthentication and disassociation nl80211 commands

[Holger Schurig]

> Nobody uses driver_nl80211 but me?

And me :-)     But still not in production.

Consider us two early-adaptors :-)

-- 
http://www.holgerschurig.de

Re: deauthentication and disassociation nl80211 commands

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Mon, 2009-10-05 at 04:11 +0200, Maxim Levitsky wrote:

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

Jouni just wanted to have what he felt was a workaround in
driver_nl80211.c rather than the core code.

> Or kernel should became smarter and do the work for wpa_supplicant. 

I still disagree. Why should the kernel deauthenticate when userspace
disassociated.

On the other hand, I think Jouni's argument is that you should be able
to authenticate (force an auth frame exchange) even while authenticated.
I don't really disagree with that all that much, but I'm not sure how to
cleanly fit it in. mac80211 would have to reset the auth state without
sending a deauth.

johannes

(NB: I'm off to Japan on Monday. Sorry I've been slow with email, but
had lots of stuff to do and then planning the next trip, I hope it'll
improve once I return on the 22nd -- well after the weekend then)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: deauthentication and disassociation nl80211 commands

[Jouni Malinen]

On Sat, Oct 10, 2009 at 06:24:26PM +0200, Johannes Berg wrote:
> On the other hand, I think Jouni's argument is that you should be able
> to authenticate (force an auth frame exchange) even while authenticated.
> I don't really disagree with that all that much, but I'm not sure how to
> cleanly fit it in. mac80211 would have to reset the auth state without
> sending a deauth.

Yes, this is exactly what I would like to see happening when using
mac80211. For now, I think we can work around the issue in
wpa_supplicant, but eventually, this change in mac80211 would allow the
code in wpa_supplicant to be cleaned up and the need for an extra
deauthentication frame could be removed.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: deauthentication and disassociation nl80211 commands

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Mon, 2009-10-12 at 09:55 +0300, Jouni Malinen wrote:
> On Sat, Oct 10, 2009 at 06:24:26PM +0200, Johannes Berg wrote:
> > On the other hand, I think Jouni's argument is that you should be able
> > to authenticate (force an auth frame exchange) even while authenticated.
> > I don't really disagree with that all that much, but I'm not sure how to
> > cleanly fit it in. mac80211 would have to reset the auth state without
> > sending a deauth.
> 
> Yes, this is exactly what I would like to see happening when using
> mac80211. For now, I think we can work around the issue in
> wpa_supplicant, but eventually, this change in mac80211 would allow the
> code in wpa_supplicant to be cleaned up and the need for an extra
> deauthentication frame could be removed.

This would require a change in cfg80211 too, since that keeps the BSS
list around and refuses this, mac80211 isn't necessarily involved.

However, we need to spec it out more clearly. For instance, we'd have to
not add a new work item and try for another authentication, but rather
use the old one. Right?

I'm happy to have such a change, but it needs to be clearly documented
what is expected of drivers that get an auth() call while already
authenticated with that AP. Especially since it's not just
send_auth_frame(), as we expect the driver to handle the entire
handshake for WEP SK auth.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: deauthentication and disassociation nl80211 commands

[Jouni Malinen]

On Mon, Oct 05, 2009 at 04:11:47AM +0200, Maxim Levitsky wrote:

> Today kernel explicitly requests the driver to perform both
> disassociation and deauthentication in that order.

I hope that deauthentication alone would be enough since that is
supposed to implicitly first take care of disassociation as far as the
IEEE 802.11 standard is concerned. It should also be noted that "kernel"
here is referring to mac80211; most other drivers/IEEE 802.11 stacks
do not have this type of restriction.

> However, currently wpa_supplicant assumes that once it called
> wpa_drv_disassociate it can again start the complete connect sequence
> from the authentication.

Actually, wpa_supplicant assume that it can authenticate again at any
point, i.e., even without first calling wpa_drv_disassociate.

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

Yes, wpa_supplicant tries to follow the operations as defined in IEEE
802.11 and does not unnecessarily deauthenticate. In addition, when
reassociating back to the same AP (e.g., to change some parameters),
there will be no deauthentication/disassociation at all.

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

There is no such assumption and the patch is not correct.

> Or kernel should became smarter and do the work for wpa_supplicant. 

No, it should not do that either. Rather, it should allow valid IEEE
802.11 operations to be performed (authentication while authenticated is
allowed)..

> If mac80211 is already authenticated to the AP that was requested, it
> should just return success.

No. It should start new authentication in that case.

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

That should be done regardless of the current authentication/association
state.

> When do you plan to switch officially the wpa_supplicant to
> driver_nl80211?

To whom is this "you" referring? wpa_supplicant does support both WEXT
and nl80211. It is up to the user (of wpa_supplicant; e.g., NM) to
decide which driver wrapper it wants to use.


As far as working out this issue is concerned, I committed a following
change to wpa_supplicant:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=6d6f4bb87f33278aed133875d0d561eb55d7ae59

I cannot day that I exactly like this due to the required extra code in
events.c, but the part in driver_nl80211.c shows how this type of
driver-specific cases should be handled in general. Anyway, I hope that
this can be eventually removed from wpa_supplicant.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: deauthentication and disassociation nl80211 commands

[Maxim Levitsky]

On Mon, 2009-10-12 at 09:52 +0300, Jouni Malinen wrote:
> On Mon, Oct 05, 2009 at 04:11:47AM +0200, Maxim Levitsky wrote:
> 
> > Today kernel explicitly requests the driver to perform both
> > disassociation and deauthentication in that order.
> 
> I hope that deauthentication alone would be enough since that is
> supposed to implicitly first take care of disassociation as far as the
> IEEE 802.11 standard is concerned. It should also be noted that "kernel"
> here is referring to mac80211; most other drivers/IEEE 802.11 stacks
> do not have this type of restriction.
> 
> > However, currently wpa_supplicant assumes that once it called
> > wpa_drv_disassociate it can again start the complete connect sequence
> > from the authentication.
> 
> Actually, wpa_supplicant assume that it can authenticate again at any
> point, i.e., even without first calling wpa_drv_disassociate.
> 
> > 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).
> 
> Yes, wpa_supplicant tries to follow the operations as defined in IEEE
> 802.11 and does not unnecessarily deauthenticate. In addition, when
> reassociating back to the same AP (e.g., to change some parameters),
> there will be no deauthentication/disassociation at all.
> 
> > 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.
> 
> There is no such assumption and the patch is not correct.

Thanks for explanation, then this is a kernel issue.


> 
> > Or kernel should became smarter and do the work for wpa_supplicant. 
> 
> No, it should not do that either. Rather, it should allow valid IEEE
> 802.11 operations to be performed (authentication while authenticated is
> allowed)..
> 
> > If mac80211 is already authenticated to the AP that was requested, it
> > should just return success.
> 
> No. It should start new authentication in that case.
> 
> > 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)
> 
> That should be done regardless of the current authentication/association
> state.
> 
> > When do you plan to switch officially the wpa_supplicant to
> > driver_nl80211?
> 
> To whom is this "you" referring? wpa_supplicant does support both WEXT
> and nl80211. It is up to the user (of wpa_supplicant; e.g., NM) to
> decide which driver wrapper it wants to use.

I mean, the general community, distributions, NM, ...

> 
> 
> As far as working out this issue is concerned, I committed a following
> change to wpa_supplicant:
> http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=6d6f4bb87f33278aed133875d0d561eb55d7ae59
> 
> I cannot day that I exactly like this due to the required extra code in
> events.c, but the part in driver_nl80211.c shows how this type of
> driver-specific cases should be handled in general. Anyway, I hope that
> this can be eventually removed from wpa_supplicant.
Me nether, now I am sure that this is kernel issue, and should be done
there.


Thanks a lot,
	Maxim Levitsky