Hide Forgot
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): NetworkManager-0.6.5-3.fc7 How reproducible: everytime Steps to Reproduce: 1. use NM to try and connect to an AP on its list 2. 3. Actual results: continually prompts for a password Expected results: connection to the AP Additional info: 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 (dhcpc_var_run_t). SELinux is preventing /usr/sbin/wpa_supplicant (udev_t) "unlink" to wlan0 (NetworkManager_var_run_t). SELinux is preventing /usr/sbin/wpa_supplicant (udev_t) "rmdir" to wpa_supplicant (NetworkManager_var_run_t) 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 madwifi driver) https://bugs.launchpad.net/ubuntu/+source/ndiswrapper/+bug/85468 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: http://docs.fedoraproject.org/release-notes/ 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.