Bug 2562

Hello,

Thanks for reporting this issue.

In order to try to understand what is going wrong, could you please provide (by adding an attachment) the result of the command lines below typed in a root console (using sudo may be requested) just after you log in:

dmesg
cat /var/log/messages
lsmod
rpm -qa | grep -e broadcom -e kmod-wl -e kernel
lspci -vn | grep 14e4
rfkill list
dmidecode -t 1

For the last one (dmidecode) remove all personal information (serial number,
UUID, etc), just keep the necessary things that can identify your laptop
manufacturer, model, family, etc.

If the second command (lsmod) doesn't show any wl module loaded, could you
please also provide the output of this command line typed in a root console:

modprobe -v wl

and then after this command, provide again the output of dmesg in a root
console.

Could you also please verify that your configuration file in /etc/modprobe.d
folder and specially /etc/modprobe.d/broadcom-wl-blacklist.conf file use good
"blacklist" instruction according to your hardware configuration?

Thanks in advance for providing all this. 

Cordially,


-- 
NVieville

I have the same problem for my Dell Latitude E6410 laptop which comes with "Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller". After I upgrade the kernel to 3.6.x, it won't connect to the wireless network.
I have all the output files you asked in previous message uploaded.
One thing I want to mentioned is I noticed is when I'm in 3.5.x kernel, working, I have the following kernel modules loaded:
[root@arnoldw wl]# grep wl /tmp/lsmod.3.5.4 
wl                   2573484  0 
lib80211               13968  2 wl,lib80211_crypt_tkip
[root@arnoldw wl]# grep 802 /tmp/lsmod.3.5.4 
lib80211_crypt_tkip    17662  0 
lib80211               13968  2 wl,lib80211_crypt_tkip

However, in kernel 3.6.x, the followings are loaded.
[root@arnoldw wl]# grep wl /tmp/lsmod.3.6.3 
wl                   2600657  0 
cfg80211              196846  1 wl
lib80211               13968  2 wl,lib80211_crypt_tkip
[root@arnoldw wl]# grep 802 /tmp/lsmod.3.6.3 
lib80211_crypt_tkip    17662  0 
cfg80211              196846  1 wl
lib80211               13968  2 wl,lib80211_crypt_tkip
rfkill                 21384  4 cfg80211,bluetooth

Please let me know if you need anything else.
Thanks.

Created attachment 985 [details]
blacklist

Created attachment 986 [details]
dmesg

Created attachment 987 [details]
dmidecode

Created attachment 988 [details]
lsmod

Created attachment 989 [details]
lspci

Created attachment 990 [details]
messages

Created attachment 991 [details]
rfkill

Created attachment 992 [details]
rpm

(In reply to comment #2)
> I have the same problem for my Dell Latitude E6410 laptop which comes with
> "Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller". After I
> upgrade the kernel to 3.6.x, it won't connect to the wireless network.
> I have all the output files you asked in previous message uploaded.

Thanks for reporting this issue and for all the attached documents.
Nothing noticeable in your attached files.

> One thing I want to mentioned is I noticed is when I'm in 3.5.x kernel,
> working, I have the following kernel modules loaded:

Yes. CFG80211 was activated in last kmod-wl modules as this API will be the default one for the kernels to come. Old WEXT API will be dropped in the future, but I don't know when exactly. See https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=10bab00afed042c1a38ed5ffb135e2aea5ce1277 for more precision.

In order to find what's wrong, I propose to try 2 things.

First one easy to be done add a /etc/dracut.conf.d/20-wl.conf file and fill it with the one line below:

add_drivers+="lib80211 lib80211_crypt_tkip wl"

Then save your current kernel initramfs file (for example /boot/initramfs-3.6.3-1.fc17.x86_64.img renamed to boot/initramfs-3.6.3-1.fc17.x86_64.img.good) and rebuild the current kernel initramfs by using the command "dracut". For more complex usage of this command you can see http://people.redhat.com/harald/dracut.html#id489921 and http://people.redhat.com/harald/dracut.html#dracutconf5.

Then reboot. If your wireless device doesn't work correctly with this first attempt, then remove the /etc/dracut.conf.d/20-wl.conf file and restore the old initramfs file previously saved or rebuild the current kernel initramfs. Reboot.

Second one needs you to rebuild the wl-kmod packages. If you feel comfortable with this, you should get the last sources packages here:

http://download1.rpmfusion.org/nonfree/fedora/updates/17/SRPMS/wl-kmod-5.100.82.112-6.fc17.2.src.rpm

Set a building environment (see https://fedoraproject.org/wiki/How_to_create_an_RPM_package for this).

Then extract it in your ~/rpmbuild directory. All the files in ~/rpmbuild/SOURCES directory except wl-kmod.spec file in ~/rpmbuild/SPECS directory.

Edit ~/rpmbuild/SPECS/wl-kmod.spec file and modify the line in the %build section from:

 make -C ${kernel_version##*___} M=`pwd` modules

to

 make -C ${kernel_version##*___} M=`pwd` modules API=WEXT

Save the file and rebuild this package:

rpmbuild -ba ~/rpmbuild/SPECS/wl-kmod.spec

If all goes well then install the new built packages that can be found in ~/rpmbuild/RPMS sub-directories. You probably need to add to the yum command line the --nogpgcheck option.

yum localinstall --nogpgcheck /PATH_TO_YOUR_HOME_DIRECTORY/rpmbuild/RPMS/YOUR_ARCH/kmod-wl*.rpm /PATH_TO_YOUR_HOME_DIRECTORY/rpmbuild/RPMS/noarch/broadcom-wl*.rpm

Reboot and see if this is Ok.

If you don't feel comfortable with package building let me know, I'll try to build you a special package only for testing (let me know the kernel version and arch you intend to use for the test).

Please, in any case provide feedback about these two propositions.

Thanks in advance!

Cordially,


-- 
NVieville

Thanks for the response. I will try these two options later today.
Before I do that, I'd like to know a little bit more about them, particularly the first option. If I'm not mistaken, we're trying to load the "lib80211 lib80211_crypt_tkip wl" modules into the ramdisk. I'm not sure what difference will it make.
For the second option, I assume we're trying to use "WEXT" option instead of cfg80211. 
Thanks.

(In reply to comment #12)
> Thanks for the response. I will try these two options later today.

Ok! Delay is not a problem. Many thanks for accepting to try these.

> Before I do that, I'd like to know a little bit more about them, particularly
> the first option. If I'm not mistaken, we're trying to load the "lib80211
> lib80211_crypt_tkip wl" modules into the ramdisk. I'm not sure what difference
> will it make.

On certain platforms the Broadcom STA wireless driver cause a kernel panic at boot time (https://bugzilla.rpmfusion.org/show_bug.cgi?id=2526#c29) when loaded automatically, but accept to be loaded manually later. As a part of this driver is not open sources, and my skill in kernel details isn't so deep, I think it's worth trying. Maybe I'm wrong.

> For the second option, I assume we're trying to use "WEXT" option instead of
> cfg80211. 

Yes. 
This option has already given a good result for F-16 with a certain platform. But for the moment I can't say why. The device not working with CFG80211 on F-16 works for me on F-17 on a different platform (not the same laptop but the same device bcm4313)!?! Difficult to catch what's going wrong here.

Cordially,


-- 
NVieville

I tried out both options. 
1. For modified initrd ramdisk, that didn't make any difference. As far as I can tell, I believe those modules were added to the initrd image file.
(initramfs-3.6.3-1.fc17.x86_64.img is the modified one and initramfs-3.6.3-1.fc17.x86_64.img.original is the one comes from rpmfusion.)
[root@arnoldw boot]# lsinitrd initramfs-3.6.3-1.fc17.x86_64.img | grep wl
-rw-r--r--   1 root     root           81 Nov  3  2011 etc/modprobe.d/broadcom-wl-blacklist.conf
drwxr-xr-x   2 root     root            0 Nov  6 13:24 usr/lib/modules/3.6.3-1.fc17.x86_64/extra/wl
-rw-r--r--   1 root     root      3200720 Oct 23 09:18 usr/lib/modules/3.6.3-1.fc17.x86_64/extra/wl/wl.ko
[root@arnoldw boot]# lsinitrd initramfs-3.6.3-1.fc17.x86_64.img | grep 80211
-rwxr--r--   1 root     root       299664 Oct 22 09:06 usr/lib/modules/3.6.3-1.fc17.x86_64/kernel/net/wireless/cfg80211.ko
-rwxr--r--   1 root     root        11160 Oct 22 09:06 usr/lib/modules/3.6.3-1.fc17.x86_64/kernel/net/wireless/lib80211.ko
-rwxr--r--   1 root     root        17680 Oct 22 09:06 usr/lib/modules/3.6.3-1.fc17.x86_64/kernel/net/wireless/lib80211_crypt_tkip.ko

2. I also tried to rebuild the package. I expected to see two packages, broadcom-wl and kmod-wl. Instead, I saw the following:
Wrote: /home/awang/rpmbuild/RPMS/x86_64/kmod-wl-5.100.82.112-6.fc17.2.x86_64.rpm
Wrote: /home/awang/rpmbuild/RPMS/x86_64/kmod-wl-3.6.5-1.fc17.x86_64-5.100.82.112-6.fc17.2.x86_64.rpm

Can you double check and let me know whether this is correct? 
The complete build log is attached as well. I haven't modified the SPEC file for WEXT yet. 
Thanks.

Created attachment 995 [details]
build output

I went ahead enabled API=WEXT option and installed the new module. Surely it fixed the problem. 
Now, the challenge is we need figure out why the driver won't work with cfg80211 driver.
Thanks.

(In reply to comment #16)
> I went ahead enabled API=WEXT option and installed the new module. Surely it
> fixed the problem. 
> Now, the challenge is we need figure out why the driver won't work with
> cfg80211 driver.
> Thanks.

Sorry for late response. 
Many thanks for helping to identify a part of the problem. 
Yes the challenge is now to understand for example why with the same device (yours and mine - BCM4313 [14e4:4727]), the same arch (x86_64), the same drivers, but not the same laptop, and yours doesn't work and mine works perfectly in CFG80211 mode.

While reading again the logs you provided, I saw that the output of /var/log/messages was a little bit short. I can't find in it the beginning of the launch of NetworkManager for example. Please, is it possible to provide a new /var/log/messages output (beginning at the first second of the boot process with messages from kernel) in the failing configuration (eg. with CFG80211 drivers installed)?

Thanks again for the time you spent and the quality of your feedback.
Feel free to add any comment on this issue, if you find anything that can give a path to the solution.

Cordially,


-- 
NVieville

I have upload the messages output, hopefully it has the information you're looking for this time.
It contains messages for two separate boots. First one is with WEXT mode driver and the second one is for CFG80211 driver. I also upload two separate dmesg outputs. 
I will try to spend more time on this, unfortunately my skill on this low level driver stuff is limited. 
Feel free if you need me try anything. 
Thanks.

Created attachment 997 [details]
today's /var/log/messages

Created attachment 998 [details]
dmesg when WEXT driver is loaded.

Created attachment 999 [details]
dmesg when cfg80211 driver is loaded.

Hello Arnold,

Many thanks for your last message, the feedback you gave and the time you spent to try to identify the problem encountered.

In an attempt to fix this issue, I made some modifications on the broadcom-wl akmod-wl package, and I wonder if you could try to install the packages cited below. 
These packages are only for testing and validating (if all goes well) the solution before pushing modifications on official ones on RPMFusion.

In order to install, to use and to test them, you should remove all the previous packages installed. Be sure to be able to revert the situation before going on (wired connection or local copy of the working packages).

To begin, please download the testing packages (wget can help you):

http://dl.dropbox.com/u/25699833/rpmfusion/F-17/broadcom-wl/broadcom-wl-5.100.82.112-3.fc17.noarch.rpm
http://dl.dropbox.com/u/25699833/rpmfusion/F-17/wl-kmod/akmod-wl-5.100.82.112-7.fc17.x86_64.rpm

Then remove all existing broadcom-wl and kmod-wl packages by typing in a root console (including double quote and star character): 

yum remove "*kmod-wl*" "broadcom-wl*"

Maybe you should reboot, but I'm not sure it is mandatory.
Verify that no packages are still here (a blank line should be the output of the command below):

rpm -qa | grep -e kmod-wl -e broadcom-wl

Then install the fresh downloaded packages:

yum localinstall --nogpgcheck broadcom-wl-5.100.82.112-3.fc17.noarch.rpm akmod-wl-5.100.82.112-7.fc17.x86_64.rpm

Verify that only these two packages are installed:

rpm -qa | grep -e kmod-wl -e broadcom-wl

Then configure the newly installed packages to use WEXT API. Reading the /usr/share/doc/broadcom-wl-5.100.82.112/fedora.readme file should help, specially in section 1: "Choosing between WEXT or CFG80211 API".

As testing these new packages requires also testing the documentation provided, reading the fedora.readme file is a part of the test. So I don't provide detailed instructions to achieve this configuration intentionally, but only general procedure (in case the documentation file are not sufficient or clear enough, feel free to let me know - English is not my natural language so mistakes are possible):
- configure the correct file to choose the API that fit your needs,
- then 2 options:
  - reboot the last Fedora kernel to see if the akmod-wl module will be
    correctly rebuilt and loaded (preferred option in this test)
  or
  - force rebuilt of the akmod-wl module before rebooting the last Fedora 
    kernel (less accurate in this test).

- if previous step goes well, try to reboot older kernels to see if the
  akmod-wl module will be correctly rebuilt and loaded (wireless connection 
  operational),

- if previous step goes well, reboot last Fedora kernel, verify that your 
  wireless connection is Ok and try to update your packages:

  yum upgrade

  If you don't want to upgrade your system just hit "n" when prompted, but in 
  any case check that no kmod-wl* packages will be upgraded. The new packages 
  assume that you will exclusively use akmod-wl and broadcom-wl packages. 
  kmod-wl* packages are no longer needed in case you want to choose the API,
  and will break this if you install them, so the upgrade test is necessary.

Feedback about these tests is welcome. In case things goes wrong please provide all the information needed to try to understand what happened.

Any comment on this message are welcome.

Cordially,


-- 
NVieville

Sorry for the delayed response, I just had the chance to try these out.
the followings are what I did:
1. I installed the akmod-wl and kmod-wl in your download sites.
2. Modified the /etc/akmods/akmod-wl/api to enable the WEXT option, run "akmods --force ..." command.
3. Reboot the machine. 
4. The wireless didn't work.
5. I removed the kmod-wl package, re-run the "akmods --force..." command again.
6. reboot the machine.
7. The wireless worked this time. I verified that is is running in WEXT option.
8. I did a "yum updated". The Kernel was updated.
9. reboot the machine and wireless continued to work.
Let me know if you need me do more testing. 
Thanks.
BTW, I noticed that the Kernel build in Broadcom driver supports my WLAN card now. I probably won't use Broadcom driver in the future, as long as the Kernel one continues to work.

Hello,

New broadcom-wl, kmod-wl and akmod-wl packages were build in the official RPMFusion repository for F-17. They will be pushed and available in the next few days. They include the workaround tried since comment #22 to be built against WEXT API. 

To get them installed from the repository and replace those provided in this discussion, one should use "yum reinstall broadcom-wl akmod-wl" command in a root console. Then force akmod to rebuild the corresponding kernel packages. Otherwise, erase all the packages actually installed, and reinstall them from the official repository. Setting configuration file according to the API chosen is still needed for the first time this packages get installed. Once the configuration file correctly set, kernel updates should not need any action. Just reboot. 

Feel free to get any feedback you think useful about this.

Cordially,

I did the WEXT change as recommended above for my BCM4312, it worked in 3.6.7 on Fedora 17.

Sorry for the lack of activity on my part, I have been a little preoccupied with things outside of the Linux realm for a bit.

Thanks for everyone's help.

Hello,

As this bug seems to be resolved, I close it.

Feel free to re-open it if needed.

Cordially,


-- 
NVieville