Please make CONFIG_CFG80211 harder to enable

Please make CONFIG_CFG80211 harder to enable

[Pavel Roskin]

Hello!

Somebody please mark CONFIG_CFG80211 in wireless-dev.git as
experimental/broken/incomplete/whatever.  Not only doesn't it work, but
it also breaks Wireless Extensions if enabled, even if CONFIG_D80211 is
disabled.

Driver developers should know that if they enable CONFIG_CFG80211 they
won't be able to debug their drivers effectifely; they'll have to fix
cfg80211 first.

-- 
Regards,
Pavel Roskin

Re: Please make CONFIG_CFG80211 harder to enable

[John W. Linville]

On Sat, Dec 09, 2006 at 03:48:43AM -0500, Pavel Roskin wrote:
> Hello!
> 
> Somebody please mark CONFIG_CFG80211 in wireless-dev.git as
> experimental/broken/incomplete/whatever.  Not only doesn't it work, but
> it also breaks Wireless Extensions if enabled, even if CONFIG_D80211 is
> disabled.
> 
> Driver developers should know that if they enable CONFIG_CFG80211 they
> won't be able to debug their drivers effectifely; they'll have to fix
> cfg80211 first.

Perhaps you could be more specific?  I'm sending this to you from a
box booted on the current (~1 week old) wireless-dev kernel using a
WEXT-configured ipw2200 device.

What problems are you experiencing?  CFG80211 shouldn't interfere w/
WEXT if a driver doesn't support it.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Please make CONFIG_CFG80211 harder to enable

[Paul Collins]

"John W. Linville" <linville@tuxdriver.com> writes:

> On Sat, Dec 09, 2006 at 03:48:43AM -0500, Pavel Roskin wrote:
>> Hello!
>> 
>> Somebody please mark CONFIG_CFG80211 in wireless-dev.git as
>> experimental/broken/incomplete/whatever.  Not only doesn't it work, but
>> it also breaks Wireless Extensions if enabled, even if CONFIG_D80211 is
>> disabled.
>> 
>> Driver developers should know that if they enable CONFIG_CFG80211 they
>> won't be able to debug their drivers effectifely; they'll have to fix
>> cfg80211 first.
>
> Perhaps you could be more specific?  I'm sending this to you from a
> box booted on the current (~1 week old) wireless-dev kernel using a
> WEXT-configured ipw2200 device.
>
> What problems are you experiencing?  CFG80211 shouldn't interfere w/
> WEXT if a driver doesn't support it.

I think I hit this too when I started playing with wireless-dev a week
or so ago.  I had CFG80211 enabled and iwconfig reported "wireless
extensions not supported" with orinoco, bcm43xx and bcm43xx-d80211.

-- 
Paul Collins
Wellington, New Zealand

Dag vijandelijk luchtschip de huismeester is dood

Re: Please make CONFIG_CFG80211 harder to enable

[Pavel Roskin]

Quoting Paul Collins <paul@briny.ondioline.org>:

> >> Driver developers should know that if they enable CONFIG_CFG80211 they
> >> won't be able to debug their drivers effectifely; they'll have to fix
> >> cfg80211 first.
> >
> > Perhaps you could be more specific?  I'm sending this to you from a
> > box booted on the current (~1 week old) wireless-dev kernel using a
> > WEXT-configured ipw2200 device.
> >
> > What problems are you experiencing?  CFG80211 shouldn't interfere w/
> > WEXT if a driver doesn't support it.

Sorry, it looks like the evil setting is actually CONFIG_CFG80211_WEXT_COMPAT.
I should have checked it better.  Please look for the code around the
cfg80211_wext_ioctl call in dev_ioctl(), net/core/dev.c.

The logic now is to try the compatibility code first.  I think it's wrong, at
least for now.  I think the compatibility code should only be invoked if the
native WE support failed for the request.  Or maybe if the cfg80211 support is
present for the driver.

> I think I hit this too when I started playing with wireless-dev a week
> or so ago.  I had CFG80211 enabled and iwconfig reported "wireless
> extensions not supported" with orinoco, bcm43xx and bcm43xx-d80211.

Yes.  And I could trace "iwgetid -m ath0" to cfg80211_wx_get_mode() in
net/wireless/wext-compat.c, which returns -ENOSYS unconditionally.  ath0 is
from current MadWifi.

Both in-tree and outside drivers are affected (orinoco and hostap from the tree,
MadWifi outside the tree).  DadWifi also failed to respond to iwconfig, although
its author says that Wireless Tools should be used for now.

Both the latest beta of Wireless Tools and its alpha version with Netlink
support fail to work.  wpa_supplicant with the wext driver also fails.  But
MadWifi could associate (as evidenced by working dhclient) if there was a
strong open AP around.  Also, scanning using wlanconfig worked, which shows
that the ioctls to network interfaces are not generally hosed, just those used
by Wireless Extensions.

--
Regards,
Pavel Roskin

Re: Please make CONFIG_CFG80211 harder to enable

[Johannes Berg]

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

On Sun, 2006-12-10 at 03:12 -0500, Pavel Roskin wrote:

> Sorry, it looks like the evil setting is actually CONFIG_CFG80211_WEXT_COMPAT.
> I should have checked it better.  Please look for the code around the
> cfg80211_wext_ioctl call in dev_ioctl(), net/core/dev.c.
> 
> The logic now is to try the compatibility code first.  I think it's wrong, at
> least for now.  I think the compatibility code should only be invoked if the
> native WE support failed for the request.  Or maybe if the cfg80211 support is
> present for the driver.

No, it's correct. Re-read the code.

> Yes.  And I could trace "iwgetid -m ath0" to cfg80211_wx_get_mode() in
> net/wireless/wext-compat.c, which returns -ENOSYS unconditionally.  ath0 is
> from current MadWifi.

Now trace it further and notice that on -ENOSYS the original WE is
invoked.

johannes

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

Re: Please make CONFIG_CFG80211 harder to enable

[Michael Buesch]

On Sunday 10 December 2006 07:48, Paul Collins wrote:
> "John W. Linville" <linville@tuxdriver.com> writes:
> 
> > On Sat, Dec 09, 2006 at 03:48:43AM -0500, Pavel Roskin wrote:
> >> Hello!
> >> 
> >> Somebody please mark CONFIG_CFG80211 in wireless-dev.git as
> >> experimental/broken/incomplete/whatever.  Not only doesn't it work, but
> >> it also breaks Wireless Extensions if enabled, even if CONFIG_D80211 is
> >> disabled.
> >> 
> >> Driver developers should know that if they enable CONFIG_CFG80211 they
> >> won't be able to debug their drivers effectifely; they'll have to fix
> >> cfg80211 first.
> >
> > Perhaps you could be more specific?  I'm sending this to you from a
> > box booted on the current (~1 week old) wireless-dev kernel using a
> > WEXT-configured ipw2200 device.
> >
> > What problems are you experiencing?  CFG80211 shouldn't interfere w/
> > WEXT if a driver doesn't support it.
> 
> I think I hit this too when I started playing with wireless-dev a week
> or so ago.  I had CFG80211 enabled and iwconfig reported "wireless

Ehm, guys?
cfg80211 is not usable in its current form because there isn't
even a damn userspace tool to interact with nl80211.
So why don't you just disable the option for the time being? That's
not too hard, I guess, and it magically fixes _all_ of your problems.

Another optional possibility would be to _implement_ the cfg80211
in d80211 and the standalone drivers, so at least the compatibility
layer works.
Come on guys, get your hands dirty instead of talking bullshit about
development code.

-- 
Greetings Michael.

Re: Please make CONFIG_CFG80211 harder to enable

[Pavel Roskin]

Quoting Johannes Berg <johannes@sipsolutions.net>:

> On Sun, 2006-12-10 at 03:12 -0500, Pavel Roskin wrote:
>
> > Yes.  And I could trace "iwgetid -m ath0" to cfg80211_wx_get_mode() in
> > net/wireless/wext-compat.c, which returns -ENOSYS unconditionally.  ath0 is
> > from current MadWifi.
>
> Now trace it further and notice that on -ENOSYS the original WE is
> invoked.

Not quite.  cfg80211_wext_ioctl() returns -ENODEV (no idea why), but the code
only falls back to Wireless Extensions if the return code is -ENOSYS.  That
should be quite easy to fix.

--
Regards,
Pavel Roskin

[PATCH] fix cfg80211 WE compat code

[Johannes Berg]

When cfg80211's WE compat code is enabled and the cfg80211 module is
loaded (or built-in) WE calls on non-cfg80211 devices will return
-ENODEV because cfg80211 internally says -ENODEV for cfg80211 calls on
devices that don't have cfg80211 handlers.

This patch makes the cfg80211 core return -ENOSYS which is more
appropriate since the device exists but the configuration request can't
be fulfilled. This will then cause the fallback code to the original WE
to trigger.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
John, please apply this to wireless-dev if Pavel says it works (I think
it should).

On Sun, 2006-12-10 at 11:08 -0500, Pavel Roskin wrote:

> Not quite.  cfg80211_wext_ioctl() returns -ENODEV (no idea why), but the code
> only falls back to Wireless Extensions if the return code is -ENOSYS.  That
> should be quite easy to fix.

Ah, but you said -ENOSYS and I thought that somehow went to userspace
and was confused.

Yeah, the bug is actually hidden in cfg80211_wx_setup() and all that
calls.

This patch should fix it.

--- wireless-dev.orig/net/wireless/core.c	2006-12-10 17:15:43.442451537 +0100
+++ wireless-dev/net/wireless/core.c	2006-12-10 17:15:54.672451537 +0100
@@ -131,7 +131,7 @@ cfg80211_get_drv_from_ifindex(int ifinde
 	if (drv)
 		mutex_lock(&drv->mtx);
 	else
-		drv = ERR_PTR(-ENODEV);
+		drv = ERR_PTR(-ENOSYS);
 	dev_put(dev);
  out:
 	mutex_unlock(&cfg80211_drv_mutex);

Re: [PATCH] fix cfg80211 WE compat code

[Pavel Roskin]

On Sun, 2006-12-10 at 17:21 +0100, Johannes Berg wrote:
> John, please apply this to wireless-dev if Pavel says it works (I think
> it should).

Yes, it's working for me.  Please apply the patch.

Sorry for answering so late.

-- 
Regards,
Pavel Roskin

Re: [PATCH] fix cfg80211 WE compat code

[Pavel Roskin]

On Thu, 2006-12-21 at 21:53 -0500, Pavel Roskin wrote:
> On Sun, 2006-12-10 at 17:21 +0100, Johannes Berg wrote:
> > John, please apply this to wireless-dev if Pavel says it works (I think
> > it should).
> 
> Yes, it's working for me.  Please apply the patch.

Actually, iwpriv without arguments is still hosed.  In this case,
cfg80211_wext_ioctl() returns -EOPNOTSUPP.

I also noticed that cfg80211_wext_ioctl() sometimes returns 0 although
no drivers I'm using are cfg80211 capable.

It looks like we need a better solution.  I'll try to be more responsive
when it comes to testing.

-- 
Regards,
Pavel Roskin

Re: [PATCH] fix cfg80211 WE compat code

[Johannes Berg]

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

On Fri, 2006-12-22 at 00:30 -0500, Pavel Roskin wrote:

> Actually, iwpriv without arguments is still hosed.  In this case,
> cfg80211_wext_ioctl() returns -EOPNOTSUPP.

Ahrg, right, probably caused by me ripping out large chunks of code of
of the base function after copying it as the cfg80211 compat code...
I'll have to take a look.

> I also noticed that cfg80211_wext_ioctl() sometimes returns 0 although
> no drivers I'm using are cfg80211 capable.

Now that really shouldn't happen.

johannes

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