| Summary: | madwifi-driver-0.1_pre20050809.ebuild kills wifi cards | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chris Bainbridge (RETIRED) <chrb> |
| Component: | New packages | Assignee: | Mobile Herd (OBSOLETE) <mobile+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | chewi, falco, langthang, pupeno, rhill, uberlord, xmit |
| Priority: | High | Keywords: | InVCS |
| Version: | 2005.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 110791 | ||
|
Description
Chris Bainbridge (RETIRED)
2005-08-11 04:32:01 UTC
This happens only with wpa-supplicant? Can you please try to increase or decrease the version by renaming? unmergeing files from /lib/modules does not work because it's in kind of a confprotect, you need to remove them manually before upgrading/downgrading madwifi. Oh, and you can go to the madwifi mailinglist and beg them to do a release, because a cvs snapshot often works only partially :( I need wpa_supplicant to authenticate to the AP, so I can't test anything else. unmerged, rm /lib/modules/2.6.12/net/* and emerged pre20050809. Crash. unmerged, rm /lib/modules/2.6.12/net/* and emerged pre20050420. Crash. Again with the February snapshot. Same crash. The 20050809 release must've done something that is affecting operation of the previous releases, because they were working. Either the releases rely on something common that has been modified, like the kernel sources, or the hardware has been broken. Argh. Have you tried a cold restart? Can you please report it to the madwifi mailing list? Did you reset the card by replugging or rebooting after downgrading? I rebooted in between each test. I just tried a cold boot and got the same crash. I'm going to check out a new cvs tree, and if that fails I'll try the mailing list. I just investigated a bit further and found out that the compiled modules differ between just "make; make install" and how the ebuild does it. Also the ebuild installs ath_rate_amrr.ko and ath_rate_onoe.ko which is not installed by a normal "make". Can you please try a manual (i.e. without ebuild) make and try to remove these two modules from an ebuild-make? I have it working again. This is what I did: rm -rf /lib/modules/ rebuild and re-install kernel bzimage and modules_install emerge madwifi-driver-0.1_20050420 remove all modules from /etc/modules.autoload.d/kernel-2.6 that the ebuild tells you to add, replace with just 'ath_pci' (maybe not necessary, but cleaner) modules-update reboot it should now work. 20050809 snapshot (built from ebuild) and todays cvs (built from source) give the same errors: /sbin/wpa_supplicant -dd -Dmadwifi -c/etc/wpa_supplicant.conf -iath0 ioctl[SIOCSIWPMKSA]: Operation not supported ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long ioctl[SIOCSIWENCODEEXT]: Operation not supported ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long .... repeats I have a feeling something wasn't updated before and it was that ioctl with the long argument list that was crashing the kernel. If run from net.ath0 start it will timeout (probably what the forum poster was seeing). I'd recommend masking this snapshot as it seems broken. may be bump wpa_supplicant to the current madwifi version? I used the snapshot dated 07-26-05 without any problem and I don't see much different with 08-09 snapshot. I'll try the new snapshot as soon as I get home and report back. Ah, I didn't realise wpa_supplicant builds with the cvs snapshot of madwifi! I changed the snapshot version in the wpa_supplicant ebuild and suddenly it works - I have the madwifi-20050809 with wpa_supplicant-0.4.3.. there are errors about unsupported ioctls but it does work. Can someone fix the wpa_supplicant ebuild then? Thanks. I'll take care of wpa_supplicant. Perhaps it would be best for wpa_supplicant to use headers from the installed version of the madwifi drivers? A note could be added the the madwifi-drivers package to remind people that they may need to recompile wpa_supplicant. Either that or the madwifi/wpa_supplicant versions should be forced to match by adding madwifi as a DEPEND of wpa_supplicant. Just a quick note to say that I cannot get this snap (20050809) to work with wpa_supplicant for love nor money. It gets as far as GROUP_HANDSHAKE and then bails. Running with -dd shows no debug information - just ioctl warnings. Reverting to the prior snapshot worked. Note to ebuild devs. For some reason I have to remove /lib/modules/<KERNEL-VERSION> before emerging madwifi-driver and then wpa_supplicant otherwise reverting fails. Well, the emerge works, but the end product does not. Removing the installed modules and then emerging always works - but not with this new snap. (In reply to comment #13) > Just a quick note to say that I cannot get this snap (20050809) to work with > wpa_supplicant for love nor money. It gets as far as GROUP_HANDSHAKE and then > bails. Running with -dd shows no debug information - just ioctl warnings. > > Reverting to the prior snapshot worked. > Well, same thing. I use a dlink DWL-G650 with WPA-PSK TKIP (so with wlan_tkip.ko) in the beginning, i couldn't have my card working at all, even i came back to madwifi-driver-20050420. (like Chris) In fact, i don't know why, as for today, modprobe doesn't load the good modules (it loads ath_rate_sample whereas i need ath_rate_onoe), then modprobe segfaults and causes a kernel Oops. Indeed : if i load the modules manually with insmod, and if i load ath_rate_sample in place of ath_rate_onoe, i have a segfault and kernel Oops when insmoding ath_pci too. This happens with both madwifi-driver-20050420 madwifi-driver-20050809. Then i came back to madwifi-driver-20050420 and i load ath_rate_onoe manually : this is the only way my card work. insmod wlan.ko insmod wlan_tkip.ko insmod ath_hal.ko insmod ath_rate_onoe.ko insmod ath_pci.ko madwifi-driver-20050809 does NOT work for me, wpa_supplicant timeouts. In some certain configuration (e.g. without re-emerging wpa_supplicant), i have this message : Aug 12 23:24:44 ganesh kernel: [17179753.284000] pci: Bound Device 0000:02:00.0 to Driver ath_pci Aug 12 23:24:46 ganesh kernel: [17179755.576000] no rates yet! mode 0 Aug 12 23:24:46 ganesh kernel: [17179755.764000] no rates yet! mode 0 Aug 12 23:24:46 ganesh kernel: [17179755.844000] no rates yet! mode 0 Aug 12 23:24:46 ganesh kernel: [17179755.848000] no rates yet! mode 0 (...) maybe it could help :/ in this case, "rmmod ath_pci" always leads to a segfault and a kernel Oops. Note that, again, you *must* re-emerging wpa_supplicant after each change of madwifi-driver (except if you use quickpkg) : without this, i can't connect to my access point, and rmmod may lead to a segfault and a kernel Oops. i used : madwifi-driver-0.1_pre20050420 + wpa_supplicant-0.4.3 (old ebuild) madwifi-driver-0.1_pre20050420 + wpa_supplicant-0.4.3-r1 and madwifi-driver-0.1_pre20050809 + wpa_supplicant-0.4.3-r1 finally, i've had to put this line in my /etc/portage/package.mask : >net-wireless/madwifi-driver-0.1_pre20050420 I would like to lower the severity of this bug from "critical" to "major" because it does NOT kill any wifi-card, and "critical" is rather.... for very important issues good luck ! :) Downgrading to major .. when I put critical I had no working wifi and no downgrading, I was imagining a LG cdrom scenario.. ;-) I too have had to downgrade to 20050420. The new 20050809 release with fixed wpa_supplicant build works fine with some access points, but not with others. There's no debugging or errors output.. wpa_supplicant appears to connect to the AP ok, but dhcpcd can't get an IP address. But it only happens with some APs. Weird. The downgraded version doesnt work because the new ebuild leaves /lib/modules/2.6.12/net/ath_rate_sample.ko around. So: rm /lib/modules/2.6.12/net/ath_rate_sample.ko modules-update Should be sufficient to get the downgraded version working again. i was very suprised to see the update of this package in portage. i've been following the madwifi devel list and can tell you that the current cvs is nowhere close to stable. i have the same problem as comment #13 and #14. 0000:02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) no debug info. =/ Well, I can kinda workround this problem by putting the new version in package.mask globally. Do you have any better idea? As it stands the madwifi snapshot is unstable and afaik they are not planning to go for stability :( So perhaps we should add net-wireless/madwifi-driver-0.1_pre20050809 to the global package mask? genstef, what do you think? Added to package.mask. You can version-bump the ebuild yourself if you like and please send any of your bugreports to the madwifi mailing list. I will resolve this as UPSTREAM, because we wait for upstream to produce a more stable driver. Thanks to all who have commented here. *** Bug 102842 has been marked as a duplicate of this bug. *** Loading the kernel modules md5 and aes_i586 before loading ath_pci solved the issue for me. wpa_supplicant-0.4.6 fixes this bug for me. (In reply to comment #23) > wpa_supplicant-0.4.6 fixes this bug for me. So you're saying that net-wireless/madwifi-driver-0.1_pre20050809-r1 and net-wireless/wpa_supplicant-0.4.6 works for you regardless of the load order mentioned i comment #22? If so, we should unmask net-wireless/madwifi-driver-0.1_pre20050809-r1 and add a note to the ebuild that it requires >=net-wireless/wpa_supplicant-0.4.6 for WPA support. correct. i load the ath_hal, wlan, and ath_pci modules in that order. i have md5 built into the kernel but not CONFIG_CRYPTO_AES_586. my AP is set up using WPA-PSK if that helps. I would also want to add that this madwifi snapshot makes samba not to work correctly with windows XP machines (connections reseted). I've compiled a new CVS snapshot on my own and now i don't have this behaviour. I'm using 2.6.14 and wpa_supplicant-0.4.6. > So you're saying that net-wireless/madwifi-driver-0.1_pre20050809-r1 and
> net-wireless/wpa_supplicant-0.4.6 works for you regardless of the load order
> mentioned i comment #22?
>
> If so, we should unmask net-wireless/madwifi-driver-0.1_pre20050809-r1 and add a
> note to the ebuild that it requires >=net-wireless/wpa_supplicant-0.4.6 for WPA
> support.
Please don't - I still can't get this madwifi snap to work using WPA/PSK at all.
I've tried the removing the above mention kernel enc modules, compiled into
kernel, not used at all, altered the madwifi module insert order, etc.
looks like i spoke too soon. i have no troubles connecting to my AP the first time, but after that if take the connection down i can't bring it back up unless i do a full reboot. it associates and handshakes with the router but then just times out. moving back to the previous madwifi-driver and wpa_supplicant fixes it. =/ Madwifi changed the API in there newest SVN. I had a lot of work to get my madwifi-card running again. All avaible ebuilds doesn't work with the newer kernels. Here What I have done: Download latest svn from madwifi Download latest cvs from hostap/wpa_supplicant 1) Compiled and intalled madwifi (Madwifi sources required later, so don't delete them) 2) COmpiled and install wpa_supplicant (enable madwifi sources in defconfig at the wpa_supplicant source) 3) create an ath interface with: wlanconfig ath create wlandev wifi0 wlanmode sta 4)running wpa_supplicant on the new interface 5) ifconfig ath0 up (I done an simple) dhcpcd ath0 No all I need is to automate these steps and an ebuild... Steffen: there is an ebuild for the madwifi-part .. it is package.masked currently due to configuration changes. For WPA there is an ebuild proposed in http://bugs.gentoo.org/show_bug.cgi?id=112420 but it has not made it into gentoo cvs yet Fixed in net-wireless/madwifi-driver-0.1401.20060117. |