Bug 2038

Summary: kmod-wl fails to connect on channel 13 (Japan), other channels are fine
Product: Fedora Reporter: linux.ninja1
Component: wl-kmodAssignee: Chris Nolan <chris>
Status: RESOLVED WONTFIX    
Severity: normal CC: jarod, nicolas.vieville
Priority: P5    
Version: 16   
Hardware: i386   
OS: GNU/Linux   
namespace:

Description linux.ninja1 2011-11-19 12:15:44 CET
On a freshly installed Fedora 16 netbook, with the kmod-wl-5.100.82.112-1.fc16.1.i386 package from RPMfusion, the notebook can see the wireless AP with WPA2 protection running on channel 13, I can enter the WPA2 key but the wireless card can't connect to channel 13.

Putting the channel of the wireless access point to channel 11, everything works fine with the same hardware, access point or SSID.

Channel 13 is fully legal in Japan, so it feels like a bug.
Comment 1 NVieville 2011-11-30 22:50:18 CET
Hello,

Thanks for reporting this!

This problem seems to be an inner limitation of the driver provided by Broadcom. Depending on your wireless chipset model, you'll be able to list recognized channels with the next commands in a root console:

iwlist wlan0 f 

or 

iwlist eth1 f

If you look at this bug report for Debian GNU/Linux http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636119, this problem seems to be old, but explanations from Broadcom in the driver documentation about the channel limitation were present up to 5.10.91.9.3 version. From 5.60.48.36 version explanations were removed.

I reported this fact to Broadcom Linux Wireless support list (mailto:linux-wlan-client-support-list@broadcom.com), but no response for the moment.

Maybe other drivers could be tried to keep using channel 13, depending on your wireless chipset model (b43 or brcmsmac).

Hope you could still enjoy Fedora!


-- 
NVieville
Comment 2 linux.ninja1 2011-11-30 23:44:07 CET
Thanks for the update.

I checked iwlist wlan f
and the card does support channel 14 channels (01-14)
with frequencies from 2.412 Ghz to 2.484 Ghz
So this should suggest channel 13 would be supported on 2.472 Ghz

wireless card according to lspci
is a Broadcom BCM4313 802.11b/g/n wireless LAN controller (rev 01)

Meanwhile with the Fedora 16 kernel update 3.1.2-1 from Nov 22, the yum process un-installed the rpmfusion kmod-wl module as this kernel has native support for the wireless card.   But it has the same problem.  Channel 13 is visible, the SSID is visible, entering the WPA2 key does not associate the card with the AP
Comment 3 NVieville 2011-12-01 00:30:23 CET
(In reply to comment #2)
> Thanks for the update.
> 
> I checked iwlist wlan f
> and the card does support channel 14 channels (01-14)
> with frequencies from 2.412 Ghz to 2.484 Ghz
> So this should suggest channel 13 would be supported on 2.472 Ghz

While reading further, I saw that you explained that from Nov 22 kmod-wl was un-installed. Could you confirm that by running lsmod command in a root console, and see which of "wl" or "brcmsmac" module is loaded?

> wireless card according to lspci
> is a Broadcom BCM4313 802.11b/g/n wireless LAN controller (rev 01)

Mine, with the same wireless chipset, doesn't show more than 11 channels available with the Broadcom driver (kmod-wl). Maybe your 14 channels are seen because you probably use brcmsmac driver. 

> Meanwhile with the Fedora 16 kernel update 3.1.2-1 from Nov 22, the yum process
> un-installed the rpmfusion kmod-wl module as this kernel has native support for
> the wireless card.   But it has the same problem.  Channel 13 is visible, the
> SSID is visible, entering the WPA2 key does not associate the card with the AP

There seems to be http://download1.rpmfusion.org/nonfree/fedora/updates/16/x86_64/repoview/kmod-wl-3.1.2-1.fc16.x86_64.html for that kernel in the RPMFUsion repository. I personally use the akmod-wl package to avoid the kmod-wl being un-installed on every kernel update (http://download1.rpmfusion.org/nonfree/fedora/updates/16/x86_64/repoview/akmod-wl.html). If you use the kmod-wl driver from RPMFusion repository, how many channels are shown available by the "iwlist wlan f" command?

If you still use brcmsmac kernel driver, and still have problem using channel 13, it would be probably more accurate to fill a bug report on the kernel mailing list for this driver. But, if you want to use RPMFUsion kmod-wl driver, I'm afraid we have to wait a Broadcom response to my information request to know if and how channels beyond 11 are usable. 


-- 
NVieville
Comment 4 linux.ninja1 2011-12-06 00:31:34 CET
I had some trouble getting back to the same situation.
With the rpmfusion driver I never got more than :

iwlist wlan f met rpmfusion kmod:
eth0      11 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Current Channel:1

But If I do a fresh F16 install, reboot at the end, go through first boot and then do a yum update all and a reboot, I end up with  brcmsmac.and iwlist wlan 0 f
now also show
Channel 12 : 2.467 Ghz
Channel 13 : 2.472 Ghz

it sees my access point on Channel 13, asks for a WPA/WPA2 key, but still does not connect to it.   The rpmfusion driver/firmware does not want to see channel 12 and 13. Different sourcecode or a different binary firmware blobs ?

So my bug report should be adapted to say tha Channel 12/13 are not available with the rpmfusion driver.

And I need to open a different bugzilla at bugzilla.redhat.com for the driver that I got thanks to my new fedora 16 kernel upgrade ?
Comment 5 NVieville 2011-12-06 12:18:46 CET
(In reply to comment #4)

Thanks for this details.

> I had some trouble getting back to the same situation.
> With the rpmfusion driver I never got more than :
> 
> iwlist wlan f met rpmfusion kmod:
> eth0      11 channels in total; available frequencies :
>           Channel 01 : 2.412 GHz
>           Channel 02 : 2.417 GHz
>           Channel 03 : 2.422 GHz
>           Channel 04 : 2.427 GHz
>           Channel 05 : 2.432 GHz
>           Channel 06 : 2.437 GHz
>           Channel 07 : 2.442 GHz
>           Channel 08 : 2.447 GHz
>           Channel 09 : 2.452 GHz
>           Channel 10 : 2.457 GHz
>           Channel 11 : 2.462 GHz
>           Current Channel:1

Seems conform with Debian Broadcom driver bug report (see comment #1). At this moment Broadcom haven't responded to my information request on their mailing list, so I think we have to assume that it's the normal way for this driver to deal with channels.

> But If I do a fresh F16 install, reboot at the end, go through first boot and
> then do a yum update all and a reboot, I end up with  brcmsmac.and iwlist wlan
> 0 f
> now also show
> Channel 12 : 2.467 Ghz
> Channel 13 : 2.472 Ghz
> 
> it sees my access point on Channel 13, asks for a WPA/WPA2 key, but still does
> not connect to it.   The rpmfusion driver/firmware does not want to see channel
> 12 and 13. Different sourcecode or a different binary firmware blobs ?

As the wl-kmod provides pure binary parts from Broadcom, we cannot be purely sure of what's in it. So, maybe there are differences between the wl-kmod and brcmsmac drivers source code or firmware, but surely there are differences in the manner they deal with channels.

> So my bug report should be adapted to say that Channel 12/13 are not available
> with the rpmfusion driver.

Yes, this should be provided in the Broadcom documentation, that's why I filled an information request on their mailing list. 

> And I need to open a different bugzilla at bugzilla.redhat.com for the driver
> that I got thanks to my new fedora 16 kernel upgrade ?

Yes this should be done after verifying that it's not already done, for example with such a request :

https://bugzilla.redhat.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=Fedora&content=brcmsmac

Thanks for your comments.

Cordially,


-- 
NVieville
Comment 6 NVieville 2012-05-17 16:22:15 CEST
As last explanations already mentioned it, this bug seems to be unsolvable, so I tag it as RESOLVED:WONTFIX. Feel free to re-open it if needed, or if you have new information from Broadcom. For my part, my request about these issues get no response from Broadcom.

Cordially,


-- 
NVieville