nl80211 and wext interoperability

nl80211 and wext interoperability

[Johannes Berg]

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

Hi!

With the recent work I've done in cfg80211 for nl80211 and wext, we've
mostly removed wext code everywhere. The only thing missing right now is
the key support, and I think then we can declare cfg80211's wext compat
layer pretty much done in terms of what mac80211 had -- orinoco will
need the sensitivity (or AP density) thing but I'm not sure how we
should do that since it's a value that is hardware dependent -- we'll
need to have very good discovery code for the allowed values (unlike
wext where you can set 0..3 and don't know what that means). Anyway,
that wasn't the point of this email.

Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
-Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
"disconnect". When then the interface is brought UP again, the cfg80211
code assumes that you set configuration while it was DOWN, and tries to
recover that configuration. This means it will start scanning for the
network, which means -Dnl80211 gets -EBUSY for the scan and it all gets
very delayed. This also happens if you set an SSID with iwconfig before
using -Dnl80211.

Do we just ignore that issue? It's only added timeout and people using
purely nl80211 will never have a problem.

I'm all for ignoring wext issues, but I can also see people complain
about things like this. Not sure what mac80211 did, did it just ignore
settings while interfaces were down? I never really made sense of that
code.

johannes

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

Re: nl80211 and wext interoperability

[John W. Linville]

On Thu, Jul 09, 2009 at 01:43:17PM +0200, Johannes Berg wrote:

> Do we just ignore that issue? It's only added timeout and people using
> purely nl80211 will never have a problem.

In my opinion this is acceptable.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.
			¡Viva Honduras Libre!

Re: nl80211 and wext interoperability

[Pavel Roskin]

On Thu, 2009-07-09 at 13:43 +0200, Johannes Berg wrote:

> Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
> -Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
> "disconnect". When then the interface is brought UP again, the cfg80211
> code assumes that you set configuration while it was DOWN, and tries to
> recover that configuration. This means it will start scanning for the
> network, which means -Dnl80211 gets -EBUSY for the scan and it all gets
> very delayed. This also happens if you set an SSID with iwconfig before
> using -Dnl80211.

I'm seeing delay is I start wpa_supplicant with -Dwext on the current
wireless-testing.  I don't use -Dnl80211 on that system at all, as it
has stock Fedora 11 wpa_supplicant without nl80211 support.

I think using random data is a problem by itself.  Are we exposing
random pieces of kernel memory in probe requests?  That's bad.

> Do we just ignore that issue? It's only added timeout and people using
> purely nl80211 will never have a problem.
> 
> I'm all for ignoring wext issues, but I can also see people complain
> about things like this. Not sure what mac80211 did, did it just ignore
> settings while interfaces were down? I never really made sense of that
> code.

If your description is correct, I think the fix should be easy.

-- 
Regards,
Pavel Roskin

Re: nl80211 and wext interoperability

[Johannes Berg]

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

On Thu, 2009-07-09 at 13:13 -0400, Pavel Roskin wrote:

> I think using random data is a problem by itself.  Are we exposing
> random pieces of kernel memory in probe requests?  That's bad.

You misunderstood. wpa_supplicant _explicitly_ tells us it _wants_ to
use that 32-byte random SSID. It's just like it telling us it wants to
use the ssid "foobar" or "Pavel's House" or ... I don't see what we can
do, other than actually take it seriously and at least attempt to
connect to that network.

johannes

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

Re: nl80211 and wext interoperability

[Luis R. Rodriguez]

On Thu, Jul 9, 2009 at 4:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> Hi!
>
> With the recent work I've done in cfg80211 for nl80211 and wext, we've
> mostly removed wext code everywhere. The only thing missing right now is
> the key support, and I think then we can declare cfg80211's wext compat
> layer pretty much done in terms of what mac80211 had -- orinoco will
> need the sensitivity (or AP density) thing but I'm not sure how we
> should do that since it's a value that is hardware dependent -- we'll
> need to have very good discovery code for the allowed values (unlike
> wext where you can set 0..3 and don't know what that means). Anyway,
> that wasn't the point of this email.
>
> Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
> -Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
> "disconnect".

When do we disconnect like this? Upon initialization of wpa_supplicant
-Dwext -Dnl80211 ?

  Luis

Re: nl80211 and wext interoperability

[Johannes Berg]

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

On Thu, 2009-07-09 at 10:53 -0700, Luis R. Rodriguez wrote:
> On Thu, Jul 9, 2009 at 4:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> > Hi!
> >
> > With the recent work I've done in cfg80211 for nl80211 and wext, we've
> > mostly removed wext code everywhere. The only thing missing right now is
> > the key support, and I think then we can declare cfg80211's wext compat
> > layer pretty much done in terms of what mac80211 had -- orinoco will
> > need the sensitivity (or AP density) thing but I'm not sure how we
> > should do that since it's a value that is hardware dependent -- we'll
> > need to have very good discovery code for the allowed values (unlike
> > wext where you can set 0..3 and don't know what that means). Anyway,
> > that wasn't the point of this email.
> >
> > Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
> > -Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
> > "disconnect".
> 
> When do we disconnect like this? Upon initialization of wpa_supplicant
> -Dwext -Dnl80211 ?

When you shut down wpa_supplicant -Dwext it does that.

johannes

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

Re: nl80211 and wext interoperability

[Dan Williams]

On Thu, 2009-07-09 at 20:15 +0200, Johannes Berg wrote:
> On Thu, 2009-07-09 at 10:53 -0700, Luis R. Rodriguez wrote:
> > On Thu, Jul 9, 2009 at 4:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> > > Hi!
> > >
> > > With the recent work I've done in cfg80211 for nl80211 and wext, we've
> > > mostly removed wext code everywhere. The only thing missing right now is
> > > the key support, and I think then we can declare cfg80211's wext compat
> > > layer pretty much done in terms of what mac80211 had -- orinoco will
> > > need the sensitivity (or AP density) thing but I'm not sure how we
> > > should do that since it's a value that is hardware dependent -- we'll
> > > need to have very good discovery code for the allowed values (unlike
> > > wext where you can set 0..3 and don't know what that means). Anyway,
> > > that wasn't the point of this email.
> > >
> > > Currently, if you use wpa_supplicant -Dwext and -Dnl80211 mixed,
> > > -Dnl80211 gets confused because -Dwext will set a 32-byte random SSID to
> > > "disconnect".
> > 
> > When do we disconnect like this? Upon initialization of wpa_supplicant
> > -Dwext -Dnl80211 ?
> 
> When you shut down wpa_supplicant -Dwext it does that.

Mainly because there's no way to tell WEXT drivers to "stop whatever
you're doing and just be idle"...

The supplicant clears out the keys on TERM anyway, and in some cases
(iwlagn) the driver will keep trying to reassociate internally, and if
the keys aren't there, the AP will keep rejecting it, which just means
you're spamming the air and the AP continuously, and then when you
re-start the supplicant, you get a constant stream of WEXT disconnect
events because the AP keeps rejecting you, and the supplicant freaks
out.

So, forcing a random SSID/BSSID combo is the best way (with WEXT) to
tell the driver to just stop trying to associate to anything.

Dan

Re: nl80211 and wext interoperability

[Johannes Berg]

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

On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote:

> Mainly because there's no way to tell WEXT drivers to "stop whatever
> you're doing and just be idle"...
> 
> The supplicant clears out the keys on TERM anyway, and in some cases
> (iwlagn) the driver will keep trying to reassociate internally

Seems unlikely, ITYM ipw?

johannes

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

Re: nl80211 and wext interoperability

[Dan Williams]

On Thu, 2009-07-09 at 19:48 +0200, Johannes Berg wrote:
> On Thu, 2009-07-09 at 13:13 -0400, Pavel Roskin wrote:
> 
> > I think using random data is a problem by itself.  Are we exposing
> > random pieces of kernel memory in probe requests?  That's bad.
> 
> You misunderstood. wpa_supplicant _explicitly_ tells us it _wants_ to
> use that 32-byte random SSID. It's just like it telling us it wants to
> use the ssid "foobar" or "Pavel's House" or ... I don't see what we can
> do, other than actually take it seriously and at least attempt to
> connect to that network.

That was the idea, expect that this random BSSID/SSID combo will simply
fail to be found in a scan, and either the card driver will just keep
periodically scanning to find the AP until another request comes in, or
they will eventually just give up and idle.  What it was meant to do was
to stop the card from trying to keep re-associating to a previous AP now
that the supplicant has terminated.  See my just-posted mail a bit up in
this thread as to why.  WEXT sucks.

Dan

Re: nl80211 and wext interoperability

[Dan Williams]

On Mon, 2009-07-13 at 19:54 +0200, Johannes Berg wrote:
> On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote:
> 
> > Mainly because there's no way to tell WEXT drivers to "stop whatever
> > you're doing and just be idle"...
> > 
> > The supplicant clears out the keys on TERM anyway, and in some cases
> > (iwlagn) the driver will keep trying to reassociate internally
> 
> Seems unlikely, ITYM ipw?

Nope.  I saw this behavior with iwlagn (both 3945 and 4965) when I was
doing all that hidden stuff back in April with 2.6.27 kernels.  Might be
different in very recent kernels?

Dan

Re: nl80211 and wext interoperability

[Johannes Berg]

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

On Mon, 2009-07-13 at 15:10 -0400, Dan Williams wrote:
> On Mon, 2009-07-13 at 19:54 +0200, Johannes Berg wrote:
> > On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote:
> > 
> > > Mainly because there's no way to tell WEXT drivers to "stop whatever
> > > you're doing and just be idle"...
> > > 
> > > The supplicant clears out the keys on TERM anyway, and in some cases
> > > (iwlagn) the driver will keep trying to reassociate internally
> > 
> > Seems unlikely, ITYM ipw?
> 
> Nope.  I saw this behavior with iwlagn (both 3945 and 4965) when I was
> doing all that hidden stuff back in April with 2.6.27 kernels.  Might be
> different in very recent kernels?

That doesn't sound right, to the best of my knowledge the _driver_ has
no chance to try to associate, and mac80211 didn't.

johannes

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

Re: nl80211 and wext interoperability

[Dan Williams]

On Mon, 2009-07-13 at 21:14 +0200, Johannes Berg wrote:
> On Mon, 2009-07-13 at 15:10 -0400, Dan Williams wrote:
> > On Mon, 2009-07-13 at 19:54 +0200, Johannes Berg wrote:
> > > On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote:
> > > 
> > > > Mainly because there's no way to tell WEXT drivers to "stop whatever
> > > > you're doing and just be idle"...
> > > > 
> > > > The supplicant clears out the keys on TERM anyway, and in some cases
> > > > (iwlagn) the driver will keep trying to reassociate internally
> > > 
> > > Seems unlikely, ITYM ipw?
> > 
> > Nope.  I saw this behavior with iwlagn (both 3945 and 4965) when I was
> > doing all that hidden stuff back in April with 2.6.27 kernels.  Might be
> > different in very recent kernels?
> 
> That doesn't sound right, to the best of my knowledge the _driver_ has
> no chance to try to associate, and mac80211 didn't.

For some reason it did.  I can't figure out why it would keep doing so,
but the supplicant was dead, and the driver would try to reassociate
every time the AP kicked it off wtih "AP denied association (code=13)"
becuase the supplicant already cleared the keys and IEs but not the
SSID.

All because we can't tell WEXT to just stop doing anything and sit
there.

Dan