This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 444847 - Unable to connect to Wireless network with WEP security on [NEEDINFO]
Unable to connect to Wireless network with WEP security on
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
i686 Linux
high Severity urgent
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
Depends On: 453390
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-30 23:22 EDT by Ranjan
Modified: 2009-07-14 12:43 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:43:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
dcbw: needinfo? (rphegde)


Attachments (Terms of Use)

  None (edit)
Description Ranjan 2008-04-30 23:22:38 EDT
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
Comment 1 Bug Zapper 2008-05-14 06:27:20 EDT
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
Comment 2 Jim Richardson 2008-05-22 19:18:30 EDT
I am experiencing these identical symptoms.
Comment 3 Jim Richardson 2008-05-22 19:23:58 EDT
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.
Comment 4 Ranjan 2008-05-24 17:34:58 EDT
I am still having the same problem. Is there any work around ?  
Comment 5 Ranjan 2008-05-25 01:57:20 EDT
I upgraded to most recent kernel and it now works !!
Comment 6 Bill C. Riemers 2008-07-02 09:52:24 EDT
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.

Comment 7 Bill C. Riemers 2008-07-03 08:31:23 EDT
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
Comment 8 Steven W. Carter 2008-07-03 09:59:15 EDT
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.
Comment 9 Steven W. Carter 2008-07-03 15:38:14 EDT
Hardware field should be updated, since I can confirm this is also an issue with
the x86_64 OS.
Comment 10 Han-Wen Nienhuys 2008-07-08 11:33:21 EDT
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.
Comment 11 Scott J Henson 2008-07-13 23:44:32 EDT
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.  
Comment 12 Bradley 2008-07-14 18:39:40 EDT
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)
Comment 13 Tim Pepper 2008-08-16 02:07:37 EDT
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.
Comment 14 Gian Paolo Mureddu 2008-11-25 01:32:03 EST
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.
Comment 15 Dan Williams 2009-02-17 07:10:38 EST
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.
Comment 16 Gian Paolo Mureddu 2009-02-17 12:23:21 EST
(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.
Comment 17 Dan Williams 2009-02-17 13:58:43 EST
(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.
Comment 18 Thomas Lake 2009-04-09 08:38:02 EDT
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.
Comment 19 Dan Williams 2009-04-09 09:27:36 EDT
(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.
Comment 20 Thomas Lake 2009-04-10 05:53:14 EDT
(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
Comment 21 Samuel Sieb 2009-04-28 01:03:54 EDT
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.
Comment 22 Gian Paolo Mureddu 2009-05-07 20:01:33 EDT
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.
Comment 23 Bug Zapper 2009-06-09 20:32:43 EDT
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
Comment 24 Thomas Lake 2009-06-12 07:33:24 EDT
Has been reported above in Fedora 10 and 11beta.
Can someone change the version as appropriate?
Comment 25 bylander 2009-06-20 18:17:41 EDT
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.
Comment 26 Bug Zapper 2009-07-14 12:43:49 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.