Bug 433770
Summary: | mac80211 fails to initialise WEP | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Brad Walker <me> | ||||||||
Component: | kernel | Assignee: | John W. Linville <linville> | ||||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | low | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | rawhide | CC: | cebbert, davej, herbert, johannes | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2008-03-14 14:08:14 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: |
|
Description
Brad Walker
2008-02-21 12:28:32 UTC
Created attachment 295499 [details]
dmesg output
OK, what is happening with the "Failed to initialize wep" thing? I thought that this came down to enabling KMOD, but that is enabled in Fedora kernels. Any ideas? Clearly this is an upstream issue as well. No, no idea, but it has been reported upstream as well. If the reporter can attach the .config file of the failing kernel I can ping Herbert Xu about it again, he requested that but I couldn't provide it. Created attachment 295563 [details]
config-x86_64-generic from kernel-2.6.25-0.61.rc2.git4.fc9.src.rpm
Created attachment 295564 [details]
/boot/config-2.6.25-0.61.rc2.git4.fc9
kernel-2.6.25-0.64.rc2.git5.x86_64 seems to have fixed this problem. The device is enabled and NM shows scanned WLANs. The machine successfully connected to a WLAN. It's again having problems with the RFKILL switch like bug 432927. So which is the failing and which is the good config? Neither of the configs I attached has working wireless. The first one's a template or something while the second's the actual config of the failing kernel. The later kernel 2.6.25-0.64 works, but I didn't attach its config. It slightly differs: --- config-2.6.25-0.61.rc2.git4.fc9 2008-02-20 23:51:58.000000000 -0700 +++ config-2.6.25-0.64.rc2.git5.fc9 2008-02-21 14:26:11.000000000 -0700 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.25-0.61.rc2.git4.fc9 -# Thu Feb 21 01:42:54 2008 +# Linux kernel version: 2.6.25-0.64.rc2.git5.fc9 +# Thu Feb 21 16:17:28 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set @@ -1604,13 +1604,11 @@ CONFIG_ATH5K=m CONFIG_ATH5K_DEBUG=y CONFIG_IWL4965=m -CONFIG_IWL4965_QOS=y CONFIG_IWL4965_HT=y CONFIG_IWL4965_SPECTRUM_MEASUREMENT=y CONFIG_IWL4965_SENSITIVITY=y CONFIG_IWL4965_DEBUG=y CONFIG_IWL3945=m -CONFIG_IWL3945_QOS=y CONFIG_IWL3945_SPECTRUM_MEASUREMENT=y CONFIG_IWL3945_DEBUG=y CONFIG_HOSTAP=m Does this continue to be a problem with current rawhide kernels? http://koji.fedoraproject.org/koji/buildinfo?buildID=42641 John Linville, All kernels, including kernel-2.6.25-0.113.rc5.git2.fc9.x86_64, since kernel-2.6.25-0.64.rc2.git5.x86_64 haven't had this WEP problem. However at some release after kernel-2.6.25-0.64.rc2.git5.x86_64, NetworkManager can no longer connect the wireless interface to networks, even unencrypted ones. The current FC8 kernels do the same. I've been running kernel-2.6.23.13-105.fc8.x86_64 for working iwl4965. I test new kernels whenever they're done building on Koji. I believe kernel-2.6.25-0.64.rc2.git5.x86_64 solved this particular WEP issue. John Linville, Actually, I can connect to encrypted and unencrypted networks on the 2.4ghz band w/kernel-2.6.25-0.113.rc5.git2.fc9.x86_64. On the 5ghz band it'll connect to unencrypted networks but it won't authenticated WPA. Testing on a D-Link DGL-4500 dual-band router It sounds like this issue is resolved. You may want to open another bug for the NetworkManager-related problem you described. |