I've noticed that the WiFi drivers no longer work. I'm using Gentoo and have tried both Gentoo's sources and I've downloaded the kernel from kernel.org with no luck. WiFi seems to have lost functionality with the start of the 3.8 kernel. The 3.9 kernel still has lost functionality. Network controller: Broadcom Corporation BCM4331 802.11a/b/g/n Also, not sure if aware or if it's not possible at the moment, but with the 3.7 kernel, I cannot search for 5GHz networks. Only works with 2.4GHz. When running through the kernel configuration (using "make menuconfig") I've noticed some options missing compared to the 3.7.10-r1 (latest 3.7 kernel being used)when setting up the wireless drivers.
Created attachment 101481 [details] Config file for the working kernel Configuration file for 3.7.10
Created attachment 101491 [details] Config file for the kernel that does not work Configuration file for 3.9.2
Still does not work for 3.9.2
Created attachment 101501 [details] Config file for the kernel that does not work Configuration file for 3.9.2
Created attachment 101511 [details] Config file for the kernel that does not work Configuration file for 3.9.2
I did have CONFIG_CFG80211_DEFAULT_PS turned on but it didn't work, I tried turning it off to see if that could have been causing my issue. Both tries did not work.
Downstream bug at https://bugs.gentoo.org/show_bug.cgi?id=466920
Created attachment 107046 [details] Full lspci output
I have a similar issue on my Lenovo S12. I'am using Gentoo Linux with b43-fwcutter-017", b43-firmware-5.100.138 and '03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)' (see attachment above for full lspci output). I bisected git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and got the following commit: 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 is the first bad commit commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Nov 23 14:23:30 2012 +0100
I have the same problem with my pcmcia card: 02:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) A bisect also returned the same commit for me. It doesn't seem to try to assosiate anymore to the AP anymore.
Does this problem happen on specific networks, or generally?
(In reply to Johannes Berg from comment #11) > Does this problem happen on specific networks, or generally? I've only tried this on my home network which uses channel 1 and WEP if this is relevant.
(In reply to Johannes Berg from comment #11) > Does this problem happen on specific networks, or generally? I have configured a wpa2-psk and a wpa2-enterprise network, but my driver doesn't even scan anymore, so the configuration doesn't matter at all.
I thought that for me iwlist scan still returned things, it's just that it doesn't seem to try to associate.
(In reply to Kurt Roeckx from comment #14) > I thought that for me iwlist scan still returned things, it's just that it > doesn't seem to try to associate. You are right. I thought so, because NetworkManager doesn't show the scanned networks, but 'iwlist scan' still scans.
Can you attach the "iw wlan0 scan -b -u" info (for the APs you'd like to connect to)?
(In reply to Johannes Berg from comment #16) > Can you attach the "iw wlan0 scan -b -u" info (for the APs you'd like to > connect to)? Best on a working kernel, or even better on both working/non-working actually
(In reply to Johannes Berg from comment #17) > (In reply to Johannes Berg from comment #16) > > Can you attach the "iw wlan0 scan -b -u" info (for the APs you'd like to > > connect to)? > > Best on a working kernel, or even better on both working/non-working actually What is the purpose of the -b option? I couldn't find it in my iw utilities. So I just attach 'iw wlan0 scan -u'.
Created attachment 107197 [details] iw wlan0 scan -u output iw wlan0 scan -u output of working and non working kernel
(In reply to Uwe Breidenbach from comment #19) > iw wlan0 scan -u output of working and non working kernel Well, they both have exactly the same output, and it all matches (channel 5 = 2432 MHz) so I really don't see how commit a024de28e44d04637de9bb0506189e2238c6ef2e could be causing a connectivity problem? Besides, mac80211 has always used the DS IE, but it doesn't even mismatch... I think your bisect was probably not quite right.
The bisect was right. But maybe it's not (directly) a kernel bug. I tried to connect via wpa_supplicant separately and I got a connection. But NetworkManager (version 0.9.6.4 and 0.9.8.2-r3), which uses wpa_supplicant, neither show any wireless networks nor connect to the configured ones. So why could the NetworkManager have a problem with this commit? Was there an API change? And why are only some b43 devices affected?
Have you tried reverting that commit? I don't know if it's possible, but I don't really see how that would have changed behaviour ... Are you using wireless extensions with wpa_supplicant by any chance? I'm grasping at straws though - as far as I checked the iw scan output was completely identical.
Can you debug the supplicant? See https://wiki.gnome.org/NetworkManager/Debugging#Debugging_wpa_supplicant_0.7_and_later
For me "iw wlan0 scan" doesn't produce any output on the broken version, but does work on the working version. iwlist wlan0 scan works on both I would also like to point out that we were with 2 that found the same commit id to be the first broken version.
I'm not using network manager or wpa_supplicant. I just use iwconfig to set the essid and the WEP key.
I've tracked similar problem and reported it in: http://lists.infradead.org/pipermail/b43-dev/2013-March/003003.html Then ZHAO fixed this problem in commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64e5acb09ca6b50c97299cff9ef51299470b29f2 I've tested it and confirmed the fix in: http://lists.infradead.org/pipermail/b43-dev/2014-January/003334.html Fix is preset in kernel 3.14 and all newer ones. It was also commited to many stable kernels: 3.2.56 3.4.79 3.10.29 3.12.10 3.13.2 Please try one of the kernels with the fix included.
*** Bug 60798 has been marked as a duplicate of this bug. ***