lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061210031202.6rgqw4go8ck48kks@webmail.spamcop.net>
Date:	Sun, 10 Dec 2006 03:12:02 -0500
From:	Pavel Roskin <proski@....org>
To:	Paul Collins <paul@...ny.ondioline.org>
Cc:	"John W. Linville" <linville@...driver.com>, netdev@...r.kernel.org
Subject: Re: Please make CONFIG_CFG80211 harder to enable

Quoting Paul Collins <paul@...ny.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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ