Issues here with 2.6.14-r2, wpa_supplicant 0.3.9-r1 and madwifi-driver-0.1_pre20050420-r1. If I emerge wpa_supplicant 0.4.5 then I get "ioctl [SIOCSIWPMKSA]: Operation not supported" error. 0.3.9-r1 just times out with the 2.6.14 kernel, dmesg shows ath0 (WE): Driver using old /proc/net/wireless support, please fix driver!. I have rolled the kernel back to 2.6.13-r5 and everything works again... Reproducible: Always Steps to Reproduce: 1. 2. 3.
(In reply to comment #0) > Issues here with 2.6.14-r2, wpa_supplicant 0.3.9-r1 and > madwifi-driver-0.1_pre20050420-r1. If I emerge wpa_supplicant 0.4.5 then I get > "ioctl [SIOCSIWPMKSA]: Operation not supported" error. 0.3.9-r1 just times out > with the 2.6.14 kernel, dmesg shows ath0 (WE): Driver using old > /proc/net/wireless support, please fix driver!. > > I have rolled the kernel back to 2.6.13-r5 and everything works again... > > Reproducible: Always > Steps to Reproduce: > 1. > 2. > 3. Some other general comments: a. Seems to effect not just mad-wifi but other wifi cards as well - the simply refuse to associate. b. Often, ifconfig ath0 up; iwlist ath0 scan - and then setting the card to the access point will get partial working results - ie the driver is not completely dead. c. in my case - wiping out anything that configures the card (clearing /etc/conf.d/wireless) also allowed the mad-wifi card to properly associate. Interaction between Mad-wifi, Kernel, Coldplug card detection and configuration... ????
I can confirm 2.6.14 breaks the current stable madwifi driver. It is because they changed to version 19 of wireless extensions. http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6582c164f2b3b6e58d1f13c1c031b19ee691eb14
(In reply to comment #0) Same problem here, and same comments... # emerge info Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.14-gentoo-r2 i686) ================================================================= System uname: 2.6.14-gentoo-r2 i686 Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo" LANG="en_GB.UTF-8" LC_ALL="en_GB.UTF-8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X acpi alsa avi bindist cdr crypt cups dts dvd dvdread encode esd exif f77 foomaticdb fortran gif gnome gphoto2 gpm gtk gtk2 java jpeg lcms mmx mp3 mpeg ncurses nls nsplugin nvidia ogg oggvorbis opengl oss pam pdflib perl png ppds python radius readline samba sdl spell sse ssl tcpd tiff truetype unicode vorbis wifi win32codecs wmf xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS
(In reply to comment #2) > I can confirm 2.6.14 breaks the current stable madwifi driver. It is because they > changed to version 19 of wireless extensions. > > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6582c164f2b3b6e58d1f13c1c031b19ee691eb14 The new 20051111 driver works with kernel 2.6.14 using both hostapd (D-link PCI) as the AP and wpa_supplicant client (laptop, airlink pcmcia). The new driver also has the patches I requested in a bug report on the current 20050420 driver so the Windows XP client (Trendnet TI 802.11g chipset) also works fine with no patching required. WPA-PSK used.
(In reply to comment #4) > (In reply to comment #2) > > I can confirm 2.6.14 breaks the current stable madwifi driver. It is because they > > changed to version 19 of wireless extensions. > > > > > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6582c164f2b3b6e58d1f13c1c031b19ee691eb14 > > The new 20051111 driver works with kernel 2.6.14 using both hostapd (D-link PCI) as > the AP and wpa_supplicant client (laptop, airlink pcmcia). The new driver also has the > patches I requested in a bug report on the current 20050420 driver so the Windows XP > client (Trendnet TI 802.11g chipset) also works fine with no patching required. > WPA-PSK used. Well, I partly take that back. -2.6.14+latest madwifi works fine on laptop with Airlink PCMCIA (used for hostapd+win xp wpa desktop client and wpa_supplicant to AP). -The desktop another story. Using kernel 2.6.14+latest madwifi-driver/madwifi-tools (including 20051111 and 20051124 from portage overly), PCI D-Link G520 and Trendnet PCI lock up the machine (hard reboot required) on creating the ath0 device in either sta or ap mode.
(In reply to comment #0) > Issues here with 2.6.14-r2, wpa_supplicant 0.3.9-r1 and > madwifi-driver-0.1_pre20050420-r1. If I emerge wpa_supplicant 0.4.5 then I get > "ioctl [SIOCSIWPMKSA]: Operation not supported" error. 0.3.9-r1 just times out > with the 2.6.14 kernel, dmesg shows ath0 (WE): Driver using old > /proc/net/wireless support, please fix driver!. > > I have rolled the kernel back to 2.6.13-r5 and everything works again... > > Reproducible: Always > Steps to Reproduce: > 1. > 2. > 3. I get same behaviour with an IBM T42 laptop: same system and WPA-supplicant and ipw2200 driver. -- Peter V.
I'm also having trouble using gentoo-sources-2.6.14-r4 with wpa_supplicant. I was able to use the drivers included with the kernel to establish a connection with an access point using WEP. However, if I tried to use wpa_supplicant to connect to this same AP, I get the following error: wpa_supplicant -B -D ipw -c /etc/wpa_supplicant.other.conf -i eth1 ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported Failed to set encryption. ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported Failed to set encryption. ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported Failed to set encryption. ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported Failed to set encryption. ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported Thinking that there was some incompatability issue with ipw2100-1.1.0 (this is what is included in the kernel), I installed net-wireless/ipw2100-1.1.3 as well as net-wireless/ieee80211. Again, I was able to get the driver to establish a connection with an AP using WEP (I used iwconfig to configure the key, etc). Once I bring wpa_supplicant into the picture, I also get the same error message posted above. I went as far as to install CVS versions of ieee80211, ipw2100 and wpa_supplicant with no luck. This leads me to think that there is some issue with wireless extensions in the kernel but I'm not 100% sure. I also found the following patches which looked interesting: http://ipw2100.sourceforge.net/patches/ipw2100-1.1.1-wep_fix.patch http://ipw2100.sourceforge.net/patches/ipw2100-1.1.0-wpa_supplicant-0.4.x.patch I tried the second patch with no luck. Let me know if there is some additional information that I can post. Shiva
(In reply to comment #7) > wpa_supplicant -B -D ipw -c /etc/wpa_supplicant.other.conf -i eth1 That is totally unrelated to this bug report. Please stop posting comments on random bug reports that look vaguely like something you might think is an issue. Thanks. (Your issue should be fixed by using -D wext instead of -D ipw)
> That is totally unrelated to this bug report. Please stop posting comments on > random bug reports that look vaguely like something you might think is an issue. > Thanks. (Your issue should be fixed by using -D wext instead of -D ipw) I think this may be the same bug. Nonetheless I'll investigate further and open a new bug if necessary. I tried you suggestion with no luck. I also get the same "eth1 (WE) : Driver using old /proc/net/wireless support, please fix driver !" message mentioned in comment #1. Thanks.
Created attachment 74669 [details] Documentation relative to Comment #6 bz2 archive containing: boot error message dmesg .config for Gentoo 2.14.4 module versions wpa_supplicant.conf net
Hi guys, this bugentry looks like it also applies to me. When I use ndiswrapper (any version) + wpa_supplicant 0.3.9 + 2.6.14-gentoo-r4 wpa_supplicant has trouble recognizing the wpa key So I upgraded to wpa_supplicant 0.4.7 and the problem is gone. So there must be a bug in older wpa_supplicant versions that only occur in combination with some drivers under 2.6.14 @All Everyone having trouble with their card, please try the latest wpa_supplicant
(In reply to comment #11) > Hi guys, this bugentry looks like it also applies to me. > > When I use ndiswrapper (any version) + wpa_supplicant 0.3.9 + 2.6.14-gentoo-r4 > > wpa_supplicant has trouble recognizing the wpa key > > So I upgraded to wpa_supplicant 0.4.7 and the problem is gone. > > So there must be a bug in older wpa_supplicant versions that only occur in > combination with some drivers under 2.6.14 > > @All > > Everyone having trouble with their card, please try the latest wpa_supplicant Using wpa 0.4.7 did no solve my problem (#6). I also tried ieee80211-1.1.6, ipw2200-1.0.8, ipw2200-firmware-2.4, wpa_supplicant-0.4.7 straight from their home pages and got the same result. wpa_supplicant complains about encryption and gives the error messages previously communicated. (iwconfig works OK, as does WPA2 in XP on the dual boot laptop).) What is the procedure for getting the problem solved? It prevents WPA authentication on Gentoo on an IBM T42 laptop, which is a kind of security problem.
What exactly is the problem with wpa_supplicant, do you have the output of wpa_supplicant if you start wpa_supplicant from konsole and use -dd option for verbosity
Ah I just looked at the bootmesg you supplied, looks like the ioctl commands wpa_supplicant tries to send don't work. So the driver doesn't implement those ioctls correct, since there were some changes. I'm using ndiswrapper which has been updated to work with 2.6.14
This is not a discussion forum for random wpa_supplicant related issues. Please use forums.gentoo.org instead.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > I can confirm 2.6.14 breaks the current stable madwifi driver. It is because they > > > changed to version 19 of wireless extensions. > > > > > > > > > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6582c164f2b3b6e58d1f13c1c031b19ee691eb14 > > > > The new 20051111 driver works with kernel 2.6.14 using both hostapd (D-link PCI) as > > the AP and wpa_supplicant client (laptop, airlink pcmcia). The new driver also has > the > > patches I requested in a bug report on the current 20050420 driver so the Windows > XP > > client (Trendnet TI 802.11g chipset) also works fine with no patching required. > > WPA-PSK used. > > Well, I partly take that back. > > -2.6.14+latest madwifi works fine on laptop with Airlink PCMCIA (used for hostapd+win > xp wpa desktop client and wpa_supplicant to AP). > > -The desktop another story. Using kernel 2.6.14+latest madwifi-driver/madwifi-tools > (including 20051111 and 20051124 from portage overly), PCI D-Link G520 and > Trendnet PCI lock up the machine (hard reboot required) on creating the ath0 device in > either sta or ap mode. Just wanted to give a status update... Over the last couple months I've been watching the madwifi developement and changesets closely. I update my ebuilds (based on Mr. Andersen's) accordingly and have been pushing new versions of madwifi-ng onto the laptop regularly. madwifi-ng+wpa_supplicant-0.4.7 has worked on the laptop with no problems under heavy usage. During this time, the AP has worked great in the following configuration: Atheros PCI+madwifi-old 20050420+hostapd-0.3.9 using WPA-PSK. As stated previously the AP rejected the madwifi-ng driver (complete lockup on creation of ath0) so I've been forced to continue to use hardened-sources-2.6.11+old madwifi driver. A WinXP client has also been using the AP w/o issue. Over the last couple days there has been some lockup fixes to the madwifi-ng driver. Last night (20060115) I upgraded the laptop from r1392 to r1399 (their release names seem to be a day ahead of me) to test it and make sure no issues were introduced. It worked as before without issue, so tonight I gave the madwifi-ng another shot on the AP. Success! I used hardened-sources-2.6.14+madwifi-ng-r1399-20060116+hostapd-0.4.7, no lockups and it has performed flawlessly in initial testing. I've transfered over 2GB of mixed traffic types in each direction so far between it and the laptop. The WinXP client has also connected and is communicating without issue. The new driver performs much better as speeds have increased across the board. If any issues arise (such as stuck beacon type issues, etc.) I will post back here. If you don't hear from me then all is well.
Fixed in net-wireless/madwifi-driver-0.1401.20060117.
