Description of problem:
I have a dell D620 with a BCM43xx card. I've used the bcm43xx driver and the
ndiswrapper driver with the same following result. I can see available access
points using iwlist and using the nm-applet. I can set up the wlan0 device to
associate with an AP using "ifup wlan0". However, NM refuses to associate with
the AP. It prompts for a WEP key, spins for a while, and then prompts me for
the key again, rinse and repeat until I cancel.
It appears from the log that it times out when dhcp can't get an address.
I used iwconfig wlan0 when NM was trying to associate and the settings for the
wlan0 device were identical to those seen when using ifup successfully.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. use NM to try and connect to an AP on its list
continually prompts for a password
connection to the AP
I'll attach a log of NM activities. First it asked me for the keyring password,
after a while it asked me for the wep key, and then after a while I canceled.
NM left the link unconnected even though I have a working wireless connection.
Created attachment 156484 [details]
log of NM activities from /var/log/messages
I see the same behavior with Atheros. Just spins then barfs. Sometimes the dhcp
server logs show nothing at all (when NM is helpfully attempting to dhcp with
the key not set) and sometimes the dhcp server assigns it an address but network
manager doesn't seem to notice. Really miserable. Also, the daemon is crashing
sometime between where its started at boot and when the user account logs in and
must be manually restarted.
I was having similar issues with 2.6.21-1.3194.fc7, using a sis162-based USB
key that was working with FC5 and ndiswrapper. I tried using 16k stacks but
it didn't help. Today I upgraded kernel to 2.6.21-1.3228.fc7, ndiswrapper to
1.47, and NM. I can associate with an open network, but with WPA-PSK
the connection is dropped after a few seconds.
There selinux problems. I'm using permissive mode, but all the SEL cruft in
the logs makes it hard to track the other wireless entries.
SELinux is preventing /bin/rm (hotplug_t) "unlink" to dhclient-wlan0.pid
SELinux is preventing /usr/sbin/wpa_supplicant (udev_t) "unlink" to wlan0
SELinux is preventing /usr/sbin/wpa_supplicant (udev_t) "rmdir" to
SELinux is preventing /usr/bin/killall (hotplug_t) "signal" to (NetworkManager_t).
This looks very much to the bug described in Ubuntu forums and which makes NM
unusable for **many** laptop owners (me included Thinkpad X40, Fedora 7, and
In a nutshell
Network manager does not associate, and keeps asking the same password. If I
disable Network Manager wireless and do:
sudo iwconfig eth1 essid <myessid> mode managed
then re-enable Network Manager wireless, it associates properly.
I really would like to the priority of this bug pass from low to high.
Is this still an issue with latest F7 kernel and NM 0.6.6 from F7 updates?
Are you _sure_ of what WEP authentication mode your AP is using [ Open System or
Shared Key ] and are you setting that mode in the dialog? madwifi is not WEXT
conformant for setting the WEP auth mode and therefore is unlikely to work with
Shared Key mode.
If you could attach your ifcfg-wlan0 file, that would be quite helpful.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.
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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 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.