Bug 487445
| Summary: | wpa-supplicant fails with TKIP ciphers on 2.6.29 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rubio <_rubio_> | ||||||
| Component: | kernel | Assignee: | John W. Linville <linville> | ||||||
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | rawhide | CC: | kernel-maint, quintela, redhat, _rubio_ | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-03-02 17:52:39 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 333264 [details]
debug wpa supplicant log for failure under 2.6.29
Created attachment 333265 [details]
debug wpa supplicant log for success under 2.6.27
I appreciate the thoroughness of your bug report. It does draw some suspicion on the movement of code to lib80211, although I am equally suspicious of the patch that adapts the partially closed-source wl driver. Unfortnately, I cannot support problems with the wl driver. I have to close this bug. TKIP problems in lib80211 ought to reveal themselves with ipw2100, ipw2200, and hostap users. If any such user discovers this problem, please reopen this bug. Hi everybody, I too have to thank you Rubio for your efforts in describing this situation. Although I'm on Debian, I ran into the same situation. So as you already compared the modules, I simply ran insmod lib80211_crypt_tkip.ko insmod lib802100_crypt_ccmp.ko (I suppose modprobe'ing them works as well), and afterwards modprobe'd wl. After this I got a working connection instantly. So the problem seems to be a missing dependency between lib80211.ko and lib802100_crypt*. Perhaps you, Mr. Linville, can forward this issue to the correct person (supposedly kernel developer?) I'm just a mere user and do really not know who could be responsible for fixing this. Thanks everybody! Joost ifdown wlan0 rmmod wl modprobe lib80211_crypt_ccmp modprobe lib80211_crypt_tkip modprobe wl ifup wlan0 works for me. Bye, Joost Joost, thanks for providing the missing link to understand this problem with the (mostly) closed-source Broadcom driver. Fortunately for those using that driver, the problem is fixable within the open-source parts of it.
As you indicated, the problem should disappear if one manually loads the lib80211_crypt_tkip module. Judging from the sources, the lib80211_crypt_ccmp module should be unnecessary even when using CCMP. (I guess they are using hardware encryption for CCMP?)
The issue is that the old ieee80211 crypto API required the crypto algorithms to be loaded before they are used. The ieee80211 component took care of this for the ipw2100 and ipw2200 drivers. The hostap driver (which only uses the crypto API of the ieee80211 component) requests the appropriate modules on its own, as apparently does (or did) the wl driver.
The upstream kernel has reorganized the code, and in the process the old ieee80211 component has been split-up into different pieces. The old crypto API is now part of the new lib80211 component and its modules have been renamed appropriately. Unfortunately, the wl driver seems not to have "gotten the memo".
The driver is calling 'request_module("ieee80211_crypto_tkip")', which no longer exists. As of kernel version 2.6.28, the module's new name is "lib80211_crypto_tkip". Perhaps you, Mr. Joost, can forward this information to whomever is maintaining the wl driver sources on your behalf?
I've opened a bug for this over at rpmfusion.org https://bugzilla.rpmfusion.org/show_bug.cgi?id=466 Please continue discussion there. I hope to have a new build later today. Chris |
Description of problem: Hardware: Dell Latitude D630 Wireless: Dell Wireless 1500 Draft 802.11n WLAN Mini-card i.e. Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03) Under kernels 2.6.29-0.66.rc3.fc11.i586 (11-Alpha) and 2.6.29-0.148.rc6.fc11.i586, on either kernel using rpmfusion's broadcom-wl-5.10.27.14-1.fc11.noarch and matching akmod-wl, wireless in general works fine but attempts to connect to WPA-PSK or WPA-EAP access points using TKIP cipher fail (CCMP works just fine). Behavior is the same for wpa-supplicant versions 0.6.4-3.fc11.i386 (11-Alpha), -0.6.7-3.fc11.i386, and -0.6.4-2.fc10.i386. Downgrading kernel and kernel-devel to 2.6.27.19-170.2.35.fc10.i586 (from updates/testing/10), and thus akmod'ing a matching kmod-wl into existence, with all other components left unchanged, results in a working connection. With a working setup under 2.6.27, loaded modules are: "wl", "ieee80211_crypt", and "ieee80211_crypt_tkip" With a non-working setup under 2.6.29, loaded modules are: "wl" and "lib80211" There is a "lib80211_crypt_tkip" in the 2.6.29 modules but it is never loaded. I'm not sure if the change from ieee80211* to lib80211* between 2.6.28 and 2.6.29 is relevant but it certainly seems to be a likely suspect. The broadcom-wl rpm includes, and uses, a "broadcom-sta-5.10.27.14-kernel-2.6.29.patch" patch to accommodate the 2.6.29 networking changes, including the shift from ieee80211 to lib80211. I am unaware of the origin of this patch, and unqualified to tell if it is correct, but the interface changes appear to be straightforward and the patch appears to be largely mechanical. I would thus expect the driver to interface with the 80211 modules more or less equivalently, and am therefore suspicious at the failure of lib80211_crypt_tkip to load, particularly given the failure of TKIP cipher connections to function. Since I have no other wireless card to test with, I cannot tell if this is limited to this "wl" driver or if all lib80211-based TKIP is affected. Version-Release number of selected component (if applicable): kernel 2.6.29-0.66.rc3.fc11.i586 kernel 2.6.29-0.148.rc6.fc11.i586 and probably any other 2.6.29 How reproducible: Always Steps to Reproduce: 1. Under Fedora 11 Alpha, with a very recent broadcom wireless adapter, use NM or wpa_supplicant.conf to configure a connection to a WPA-PSK or WPA-EAP access point using TKIP cipher. 2. Try to connect. It will never succeed. 3. Using the same NM or wpa_supplicant config, try connecting under a 2.6.27 kernel. Success! Actual results: wpa_supplicant fails to establish GROUP_HANDSHAKE, times out, and blacklists AP. Log messages (with a lot of noise elided) are roughly as follows: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE WPA: RX message 3 of 4-Way Handshake from 00:0c:e6:8e:88:02 (ver=1) WPA: Sending EAPOL-Key 4/4 WPA: Installing PTK to the driver. State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE EAPOL: startWhen --> 0 Added BSSID 00:0c:e6:8e:88:02 into blacklist CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys State: GROUP_HANDSHAKE -> DISCONNECTED Expected results: Connection to be established successfully, as happens on 2.6.27. Log messages (with a lot of noise elided) roughly as follows: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE WPA: RX message 3 of 4-Way Handshake from 00:0c:e6:b6:89:02 (ver=1) WPA: Sending EAPOL-Key 4/4 WPA: Installing PTK to the driver. State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE RX EAPOL from 00:0c:e6:b6:89:02 EAPOL: Ignoring WPA EAPOL-Key frame in EAPOL state machines IEEE 802.1X RX: version=1 type=3 length=127 WPA: RX message 1 of Group Key Handshake from 00:0c:e6:b6:89:02 (ver=1) State: GROUP_HANDSHAKE -> GROUP_HANDSHAKE WPA: Group Key - hexdump(len=32): [REMOVED] WPA: Installing GTK to the driver (keyidx=1 tx=0 len=32). WPA: Sending EAPOL-Key 2/2 WPA: Key negotiation completed with 00:0c:e6:b6:89:02 [PTK=TKIP GTK=TKIP] Cancelling authentication timeout State: GROUP_HANDSHAKE -> COMPLETED CTRL-EVENT-CONNECTED - Connection to 00:0c:e6:b6:89:02 completed (auth) [id=0 id_str=] Additional info: