From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 Description of problem: I installed fedora 9 RC - I have not been able to connect to my home wireless network with WEP security on. I could connect with fedora 8 (and ubuntu 8.04) so I know there is nothing wrong with network (and I can connect when I disable WEP security) I am using 128 bit ascii passphase. I keep getting the "passphase required" popup message. When I click on "show passphrase" it is some random word that I never entered. So it appears as though network manager is not using the password I supplied. I am using BCM4306 - b43 Version-Release number of selected component (if applicable): 2.6.25.8 How reproducible: Always Steps to Reproduce: 1.Select the WEP security enabled network 2.Choose 40/124 bit ascii as wireless security 3.Enter 13 charecter password Actual Results: the wireless network icon spins at the right hand corner of the screen and after a couple of minutes, pops back the "passphrase required" dialog box Expected Results: It should have connected to wireless network Additional info: Used to work in fedora 8. WOrks fine in Ubutu 8.04. WOrks fine with WEP security disabled. Followed instruction on http://fedoramobile.org/fc-wireless/bcm43xx-yum-extras I have b43
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I am experiencing these identical symptoms.
Okay maybe the 3rd time is a charm. I went back one more time and entered my key using 40/128 WEP/ASCII ( and clicked on view key to be sure ). It connected.
I am still having the same problem. Is there any work around ?
I upgraded to most recent kernel and it now works !!
I am experiencing the same problem on my laptop. The kernel version I am using is kernel-2.6.25.6-55.fc9.i686. I played around a bit, and it actually appears to be multiple problems. First, there is no option to specify a 64 bit key. Traditionally I have used 64 a 64 bit key, because it gives me faster throughput, and it is still good enough to keep my non-technical neighbours from connecting to my network. But after failing to get my 64 bit key to work, I decided to try a 128 bit key. I notice that if I enter an ascii key, it is converted to hex decimal, which makes it impossible to check for typos or such, and this probably corrupts the key if it is re-saved again. After failing to connect with an ascii key, I tried using a hex key. But again no matter what I tried I could not connect. When I went back in to "show key" I found the hex key I entered was modified from an even to an odd number. So it looks like there is a single bit round-off error somewhere.
This is getting much worse. I just updated to: kernel-2.6.25.9-76.fc9.i686 and I was not able to connect to WIFI with WAP security either. I ended up reverting back to: kernel-2.6.25.6-55.fc9.i686 So I can get some work done. When I get a chance I will try various settings and figure out if there is are settings I can use with the updated kernel over WIFI. Bill
I am having a problem identical to Bill. The upgrade to the kernel has broken wireless. I am seeing many errors like the following in /var/log/messages: Jul 3 09:13:39 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 0 -> 2 Jul 3 09:13:43 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 2 -> 3 Jul 3 09:13:47 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 3 -> 4 Jul 3 09:13:49 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 4 -> 0 Jul 3 09:13:49 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 0 -> 2 Jul 3 09:13:53 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 2 -> 3 Jul 3 09:13:53 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 3 -> 4 Jul 3 09:13:53 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 4 -> 5 Jul 3 09:13:53 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 5 -> 6 Jul 3 09:13:53 E1103 NetworkManager: <info> (wlan0): supplicant connection state change: 6 -> 7 Rolling back to the previous kernel version fixes this bug, but that is obviously not ideal. The wireless network I am connecting to is a PEAP, Version 0, MSCHAPv2 using AD credentials. Works great with NetworkManager on kernel-2.6.25.6-55.fc9.x86_64, just not the kernel-2.6.25.6-76.fc9.x86_64 kernel version.
Hardware field should be updated, since I can confirm this is also an issue with the x86_64 OS.
me too. This started with a recent update install - running on 2.6.25.9-76.fc9.i686 with WPA/PSK (sorry, I have no more precise release to pinpoint) The connect fails, and the network manager dialog shows a 64 character hex password that I never entered when trying to reconnect.
I've been hit by this bug as well. Some information that I think might be pertanent off the top of my head. 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) iwl3945 170980 0 mac80211 222064 1 iwl3945 cfg80211 33936 2 iwl3945,mac80211 kernel-2.6.25.6-55.fc9.x86_64 kernel-2.6.25.9-76.fc9.x86_64 55 works, 76 does not. I'm on a wpa personal protected ap. I'm going to try to use wpa supplicant to get it working. I also can't connect to an open ap with 76, I've not tried with 55.
Are you in a location with multiple APs? If you do iwconfig wlan0, do you see a different essid configured? And if so, does manually setting the essid while NM is trying to connect fix the problem most of the time? (See bug 449754)
I've had similar issues for what must be a similar amount of time and have found that most of the time I'm needing to manually modprobe ieee80211_crypt_tkip, ieee80211_crypt_ccmp, and ieee80211_crypt_wep. I'm not seeing anything obvious that would be causing these to not load or to unload possibly around a suspend/resume...But (re)loading these drivers allows me to connect with fc9 and multiple types of wireless card to multiple types of networks.
I have been experiencing this issue since the late 2.6.26 kenrels in Fedora 9 all the way to the 2.6.27 kernels; then upgraded to Rawhide, and then all Rawhide kernels have showed the very same behavior,m which leads me to believe that the problem is not in the kernel as such, and may lie somwehere else? (WPASupplicant or NetworkManager as such?) I have also seen the key change when the connection fails. With the latest Rawhide updates, this still occurs in my hardware (Toshiba Satellite S215-57437 with a Realtek 8187B internal USB dongle in it. I've tried pretty much everything, even building a vanilla 2.6.27.7 kernel (had a really hard time trying to build NM and WPAsupplicant from source for some rason). I'll give F10 Live a try and if that fails... I guess I'll have to prescind of Fedora on this laptop for a while... as much as that sucks.
Is this still an issue with latest kernel updates? This problem is highly driver dependent and usually gets better with updated kernels. When the connection fails, the key you see is the WEP Hex key, which is what actually gets used even when you enter passphrases. All WEP ASCII keys or passphrases always get hashed to the hex key right before connection. It just happens that nm-applet doesn't store the ASCII key or passphrase, but stores just the hex key after hashing.
(In reply to comment #15) > When the connection fails, the key you see is the WEP Hex key, which is what > actually gets used even when you enter passphrases. All WEP ASCII keys or > passphrases always get hashed to the hex key right before connection. It just > happens that nm-applet doesn't store the ASCII key or passphrase, but stores > just the hex key after hashing. Does this include re-hashing of already HEX keys? From what I've been able to see in NM, it would seem as if it wouldn't properly recognize or set the type of key you are using, i.e, if you select a HEX key from the key types, enter the key and then see the key changed (seemingly always the "same changed key") that would actually make sense if NM is not discriminating between Hex and non-hex keys and re-hashes all of them despite the type selected in the drop-down menu, which means, is clearly a bug in NM rather than the wireless drivers.
(In reply to comment #16) > (In reply to comment #15) > > When the connection fails, the key you see is the WEP Hex key, which is what > > actually gets used even when you enter passphrases. All WEP ASCII keys or > > passphrases always get hashed to the hex key right before connection. It just > > happens that nm-applet doesn't store the ASCII key or passphrase, but stores > > just the hex key after hashing. > > Does this include re-hashing of already HEX keys? From what I've been able to > see in NM, it would seem as if it wouldn't properly recognize or set the type > of key you are using, i.e, if you select a HEX key from the key types, enter > the key and then see the key changed (seemingly always the "same changed key") > that would actually make sense if NM is not discriminating between Hex and > non-hex keys and re-hashes all of them despite the type selected in the > drop-down menu, which means, is clearly a bug in NM rather than the wireless > drivers. That was my immediate theory, but there's code in the applet to detect the key type and do the appropriate action. Two places: 1) when opening the wifi security dialog, the key is retrieved from the keyring and the type is detected; if it's 5 or 13 characters and all ASCII, then it's an ASCII key. If it's 10 or 26 characters and all hex, then it's a WEP Hex key. Otherwise, it's treated as a WEP passphrase. The appropriate item is selected from the combo box. 2) When hitting OK, the combo box specifies the key type; for "40/128-bit WEP Key", if the key in the entry is 5 or 13 characters, it's hashed as an ASCII key, or if it's 10 or 26 characters, it's a WEP Hex key. If the combo box is "128-bit WEP Passphrase", then it's hashed as a WEP MD5 passphrase. So the real question is, how was the router configured for the person who's having the problem? Was it configured with an actual WEP passphrase, irregardless of what the actual WEP key looks like? Becuase there's overlap between WEP passphrases and WEP Hex and ASCII keys, you can't simply autodetect the key type by looking at the key itself. The user simply has to know *exactly* what the key type is.
Still broken with kernel 2.6.27.21-170.2.56.fc10.i686, NetworkManager version 0.7.0.99 (Release 5.git20090326.fc10) and Broadcom-wl 5.10.79.10. Works fine with no WEP key. Not able to check with WPA.
(In reply to comment #18) > Still broken with kernel 2.6.27.21-170.2.56.fc10.i686, NetworkManager version > 0.7.0.99 (Release 5.git20090326.fc10) and Broadcom-wl 5.10.79.10. > > Works fine with no WEP key. Not able to check with WPA. When you're using WEP, you obviously know the passphrase or hex key. Can you check to see if, after a connection attempt fails, that the dialog that pops up shows the correct hex key for your AP? If you're using a passphrase, you can use a tool like: http://www.corecoding.com/utilities/wep2hex.php to find out the hexadecimal key that the passphrase gets hashed to.
(In reply to comment #19) > When you're using WEP, you obviously know the passphrase or hex key. Can you > check to see if, after a connection attempt fails, that the dialog that pops up > shows the correct hex key for your AP? If you're using a passphrase, you can > use a tool like: > > http://www.corecoding.com/utilities/wep2hex.php > > to find out the hexadecimal key that the passphrase gets hashed to. Key that I'm using (in hex): 696e7465726e6574706c65617a The site you linked gave a different key, but I think thats due to it expecting a passphrase, not an ASCII key. (13 character key) Key displayed in dialog: 696e7465726e6574706c65617a
I'm not one of the original posters on this bug, but I found this bug while trying to fix my problem with using WEP keys. I just managed to fix it. What I found was that somehow NetworkManager had the connection configured for shared key instead of open system. I used the nm-connection-editor to find and fix that.
I am still encountering this very same issue with NetworkManager as found in Fedora 11 Preview LiveCD image. What I have been able to determine is that somehow NM inserts wrong the key in the keyring and the only way to get the right key is to edit the keyring with the correct key. Only a few days back I had to reinstall Fedora 10 on my laptop, and sure enough, the problem with NM was still there, so I figured I'd update first the system using the ethernet connection and then try again, sure enough the problem was still there, so I ended up having to install seahorse or gnome-keyring-manager and edit the keyring so that the wireless key was the correct one. I just booted into Fedora 11 Preview a few minutes ago and the same problem was still present in F11 Preview with NetworkManager, now I do not know whether what we see in NM (changing the key) is inherently a problem in NM or if it may have to do with the IEEE802.11 kernel stack or the drivers or other userspace tool. What I don't get is why has this very same problem survived since Fedora 9 at some point all the way to Fedora 11, and what makes me think that the problem lies in NM or some common part is that this is not local to Fedora, I've seen it in other distributions (Ubuntu, Mint, etc) as well, only difference being that they ship seahorse as default with their live system images.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Has been reported above in Fedora 10 and 11beta. Can someone change the version as appropriate?
I've just been fighting with this issue on my IBM SL400. kernel 2.6.29.4-167.fc11.i586 wireless Intel Corporation PRO/Wireless 5100 AGN My "fix" was to Enable SSID Broadcast on the wireless router. I can reliably get and lose my wireless connection by enabling or disabling this. I did not need to do this on Fedora 10. The last FC10 kernel I was running was 2.6.27.24-170.2.68.fc10.i686.
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days