Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 306189 - net-wireless/broadcom-sta WPA TKIP connection and kernel options
Summary: net-wireless/broadcom-sta WPA TKIP connection and kernel options
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: M. B.
URL: http://forums.gentoo.org/viewtopic-t-...
Whiteboard:
Keywords:
: 311429 (view as bug list)
Depends on:
Blocks: 468388
  Show dependency tree
 
Reported: 2010-02-21 14:25 UTC by Nico Schlömer
Modified: 2013-05-03 09:57 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ebuild patch for broadcom-sta-5.100.82.112-r2 (broadcom-sta-5.100.82.112-r2.ebuild.patch,1.12 KB, text/plain)
2012-10-14 22:06 UTC, Thomas Zwaagstra
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Schlömer 2010-02-21 14:25:12 UTC
Hi,

so I was running into this issue when trying to connect to a WPA (TKIP) secured network with my Broadcom.

It didn't work for a couple of days here, and i cost me hours and hours to find out that apparently you need kernel support for TKIP. There's no check for that yet in the ebuild.

The module that is needed seems to be lib80211_crypt_tkip, at least after manually pulling it in the connection is established.
In the kernel I'm using, vanilla 2.6.32.8, there is no such option as TKIP to be found. If you explicitly search for it via '/' in `make menuconfig', it tells you that you likely need to pull in either of ipw2{1,2}00. Did that, module is build, fine.

Now, this situation seems a little bit weird to me in the sense that you have to build drivers for Intel cards to get your Broadcom connect to WPA.

What's your opinion about this?

Cheers,
Nico


PS: See also http://forums.gentoo.org/viewtopic-t-786480-start-0-postdays-0-postorder-asc-highlight-.html?sid=09fb73d26a773b66fbb2dc79d4329676

Reproducible: Always
Comment 1 Gilles Dartiguelongue gentoo-dev 2010-02-22 13:25:35 UTC
that would possibly explain why I cannot connect to any WPA protected network since the last time I made this work (kernel config changes). I'll try this out asap.
Comment 2 Gilles Dartiguelongue gentoo-dev 2010-02-22 21:44:45 UTC
I just enabled LIB80211_CRYPT_TKIP in my 2.6.32 configuration and this finally made my bcm4328 work again on linux. I didn't get it working since 2.6.28 so thanks very much for the tip.
For the record, I had this symbol enabled by selected HostAP support in kernel menuconfig since I couldn't find another knob for this.
Comment 3 Nico Schlömer 2010-02-24 23:45:57 UTC
Yeah well, the kernel says

Symbol: LIB80211_CRYPT_TKIP [=m]
  Selected by: LIBIPW [=n] && NETDEVICES [=y] && WLAN [=y] && PCI [=y] && WLAN_80211 [=y] && CFG80211 [=y] || HOSTAP [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_80211 [=y]

so enabling one of HOSTAP and LIBIPW should be fine.

Cheers,
Nico
Comment 4 Nuno Silva 2010-03-26 21:23:38 UTC
I'm able to - at least - confirm there's a problem with broadcom-sta and protected wireless networks. My card (BCM4312), which is using that driver, works with unprotected access points, failing to associate with TKIP WPA acesspoints (I don't know about other type of protected AP's - those are the ones I need to use).

There is also a message in the kernel log:
[    1.174100] lib80211: common routines for IEEE802.11 drivers
[    1.174103] lib80211_crypt: registered algorithm 'NULL'

Which, I suppose, is where (at least) TKIP should appear.

I hope I can report the results of some testing soon, but now I am still working on enabling TKIP on the kernel (there's another setting (s390) blocking it).

(Linux version: 2.6.31)
(broadcom-sta version: 5.60.48.36)
Comment 5 Thomas Zwaagstra 2010-03-28 20:35:25 UTC
*** Bug 311429 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Zwaagstra 2010-03-28 20:46:40 UTC
oddly, you CAN connect to and use a TKIP access point WITHOUT
lib80211_crypt_tkip, but only when using a static IP configuration

enabling lib80211_crypt_tkip (with HOSTAP) does the trick though.  Thanks
everyone 
Comment 7 Nuno Silva 2010-04-02 11:56:41 UTC
I've managed to enable TKIP on the kernel, and now it registers the TKIP algorithm and is able to connect to encrypted access points. (But I still had to play a bit with wpa_supplicant.conf, so I plan to test it with the non-TKIP kernel to double-check it is a kernel config issue...)

Although this fixes it, as there's no direct way to enable it using the kernel config UIs (at least here - 2.6.31) doing a check on its value migth be misleading, unless the error message explains a hack is needed (and how to do it).
Comment 8 William L. Thomson Jr. 2012-10-14 20:56:04 UTC
Not sure this bug is still relevant, seems a bit old and no comments in over 2 years. Bug can likely be closed.
Comment 9 Thomas Zwaagstra 2012-10-14 22:05:24 UTC
This bug still exists.  The workaround is to select unrelated kernel drivers which happen to enable LIB80211_CRYPT_TKIP.

Upstream could fix this by adding a config option for LIB80211_CRYPT_TKIP.

I think it's unlikely that upstream will give priority to a bug caused by an out-of-tree proprietary driver.

IMHO the resolution here is to update the ebuild to check for LIB80211_CRYPT_TKIP, and print a warning with the workaround (e.g. "Please enable hostap or ipw driver")

I'll attempt a patch for the ebuild....
Comment 10 Thomas Zwaagstra 2012-10-14 22:06:34 UTC
Created attachment 326564 [details]
ebuild patch for broadcom-sta-5.100.82.112-r2
Comment 11 Nuno Silva 2012-10-15 07:42:11 UTC
Having the ebuild check for it is, indeed, pretty good. Maybe also add some informational message to the ebuild so that, after the merge, one gets something like:

    Please make *sure* that your kernel has *LIB80211_CRYPT_TKIP*.

    This can only be selected by selecting other 
    wireless-related options, such as ... and ....

    Without this, you will *not* be able to connect to wireless 
    networks that use TKIP, although it will work with other APs,
    including open APs.

Just to make sure the ebuild clearly states why is this important and, more important, why will the card still work in some cases without this option.
Comment 12 Thomas Zwaagstra 2012-10-15 08:08:03 UTC
As the patch is now, the build fails if it doesn't find LIB80211_CRYPT_TKIP, and it prints a warning at the same time.  So it can't be ignored or missed.

However, some of the other warnings seem trivial and should probably be removed.  The ebuild warns about B43, SSB and MAC80211.  I personally have all 3 enabled with no side effects.

If the build fails because of LIB80211_CRYPT_TKIP, a user might be tempted to fix all 4 warnings, disabling B43, SSB and MAC80211 at the same time.  This seems like a bad outcome.  It's useful to have B43 and MAC80211 along side broadcom-sta.

Thoughts on this?  Should the extra warnings be removed?
Comment 13 Nuno Silva 2012-10-15 17:44:54 UTC
There is no reason to disable B43, it can be compiled, as far as it is not loaded at the same time as broadcom-sta.

As for the other two, I don't recall exactly what they are (I'm now using b43), but about TKIP, it is only required for TKIP APs. It makes sense to make a bold warning when the user does not have it enabled, OTOH I think it's bad if the package manager intentionally refuses to build something that will actually work, even if just partially.

Maybe a "tkip" USE-flag, enabled by default? Would go a bit against the idea of USE-flags, but it would effectively allow people to build broadcom-sta without TKIP in the kernel if they don't need TKIP support at all.
Comment 14 Gilles Dartiguelongue gentoo-dev 2012-10-21 11:54:25 UTC
You cannot stop user from building this package just because of a missing kernel option for reasons stated on gentoo-dev ml a thousand times.

A few of these reasons are:
  * machine with no kernel sources installed
  * buildbot not running target kernel

Just print the warning, users of kernel modules packages generally pay attention to such messages because rebooting without a working module is kinda annoying :).

As for B43 and SSB, there used to be a time when having these modules available and/or loaded would make wl stop working. B43 by taking over in load order (which is not a problem anymore afaik) and SSB by fiddling with the card which stops wl module from working at all. This might not be a problem anymore but I have not checked in a while.
Comment 15 Thomas Zwaagstra 2012-10-21 12:45:10 UTC
(In reply to comment #14)
> You cannot stop user from building this package just because of a missing
> kernel option for reasons stated on gentoo-dev ml a thousand times.
> 

I don't subscribe to the mailing list but I'll take your word for it

> A few of these reasons are:
>   * machine with no kernel sources installed
>   * buildbot not running target kernel
> 
> Just print the warning, users of kernel modules packages generally pay
> attention to such messages because rebooting without a working module is
> kinda annoying :).

If the kernel sources are not installed, the build fails regardless.  But I see what you're saying, so it can be changed to a warning.  I suppose not supporting TKIP is technically a valid configuration anyway (:

> 
> As for B43 and SSB, there used to be a time when having these modules
> available and/or loaded would make wl stop working. B43 by taking over in
> load order (which is not a problem anymore afaik) and SSB by fiddling with
> the card which stops wl module from working at all. This might not be a
> problem anymore but I have not checked in a while.

Having both of the modules available does not cause any problems, as long as one of the two (wl or b43/ssb) is blacklisted.  It's even possible to switch drivers without rebooting if you "remove" the pci device through the /sys interface, and then rescan the PCI bus.  A reboot would probably be best though.

When I get a chance I'll reword some of the warnings and make the tkip warning non-fatal.
Comment 16 M. B. 2013-05-03 00:00:17 UTC
Put a check into the newest ebuilds. They should hit upstream as soon as a dev commits them. Please refer to #438622 for further details.

Until then, get them from my overlay; tbc in layman.