Bug 487687
Summary: | Activation (wlan0/wireless): association took too long. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dominick Grift <dominick.grift> |
Component: | kernel | Assignee: | John W. Linville <linville> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | centten, chiller, dcbw, jaroslaw.gorny, jns, kernel-maint, quintela |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-06-14 15:49:57 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: |
Description
Dominick Grift
2009-02-27 14:06:56 UTC
Looks like kernel issues since the supplicant cannot find the AP in question; it never moves out of the 'scanning' state. Does the latest rawhide kernel help this issue at all? 0.17x is out already which may have wifi stack changes to help issues like this. 2.6.29-0.197.rc7.fc11.x86_64 It does not work yet. Does it help if you (as root): rmmod iwlagn modprobe iwlagn disable_hw_scan=1 and then try to connect? This bug has been triaged. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers rmmod iwlagn modprobe iwlagn disable_hw_scan=1 That indeed helps (works). Thanks That is to say my computer can now establish a connection to the AP. But the quality of the connection is poor. Ugh; over to kernel then, as there are still problems with Intel drivers dropping scan requests on the floor. John; I'm thinking about Helmut Schaa's patches that just hit linux-wireless today, namely: Subject: Another "scan handling in mac80211" bug Date: Mon, 9 Mar 2009 18:38:16 +0100 (13:38 EDT) Subject: [PATCH] mac80211: handle failed scan requests in STA mode Date: Mon, 9 Mar 2009 15:47:08 +0100 (10:47 EDT) that sound an aweful lot like the real fixes to the scan-drop behavior that we fixed in RHEL 5.3 with a hack. I might add/underscore that this issue only happens when AP requires authentication. For example, i can connect fine to unsecured AP's. I can confirm that also am hit by this issue. After upgrade from F10 to F11/rawhide only way to connect to my secured (WPA2 Personal) AP is to: modprobe -r iwl3945 modprobe iwl3945 disable_hw_scan=1 My hardware is: # lspci |grep 3945 0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) Do you happen to be using a hidden (i.e. non-broadcast) SSID on your AP? I swear, I should just force disable_hw_scan to be the default... yes, hidden SSID I confirm that too - my AP also doesn't broadcast SSID. So in case the above isn't clear, for now drop a file into /etc/modprobe.d that contains a line like this: options iwl3945 disable_hw_scan=1 Does that work around the issue for you? sh-4.0# cat /etc/modprobe.d/hidden-ssid.conf options iwlagn disable_hw_scan=1 Does not work for me. Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) starting connection 'Hello_World!' Mar 23 20:38:48 notebook1 NetworkManager: <info> (wlan0): device state change: 3 -> 4 Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 23 20:38:48 notebook1 NetworkManager: <info> (wlan0): device state change: 4 -> 5 Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0/wireless): access point 'Hello_World!' has security, but secrets are required. Mar 23 20:38:48 notebook1 NetworkManager: <info> (wlan0): device state change: 5 -> 6 Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 23 20:38:48 notebook1 NetworkManager: <info> (wlan0): device state change: 6 -> 4 Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 23 20:38:48 notebook1 NetworkManager: <info> (wlan0): device state change: 4 -> 5 Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0/wireless): connection 'Hello_World!' has security, and secrets exist. No new secre ts needed. Mar 23 20:38:48 notebook1 NetworkManager: <info> Config: added 'ssid' value 'Hello_World!' Mar 23 20:38:48 notebook1 NetworkManager: <info> Config: added 'scan_ssid' value '1' Mar 23 20:38:48 notebook1 NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK' Mar 23 20:38:48 notebook1 NetworkManager: <info> Config: added 'psk' value '<omitted>' Mar 23 20:38:48 notebook1 NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Mar 23 20:38:48 notebook1 NetworkManager: <info> Config: set interface ap_scan to 1 Mar 23 20:38:48 notebook1 NetworkManager: <info> (wlan0): supplicant connection state: scanning -> disconnected Mar 23 20:38:48 notebook1 NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning Mar 23 20:38:50 notebook1 kernel: gvfs-gdu-volume[3317]: segfault at 18 ip 00000030c1a0ac41 sp 00007fff9bf53400 error 4 in libgdu.so.0.0.0[30c1a00000+2 1000] Mar 23 20:39:03 notebook1 NetworkManager: <info> wlan0: link timed out. Mar 23 20:39:13 notebook1 NetworkManager: <info> Activation (wlan0/wireless): association took too long. To be clear, did you reboot or execute 'modprobe -r iwl3945 ; modprobe iwl3945' before the last comment? Are you using iwl3945 or iwlagn? I restarted, didnt work. then after your last comment i did the modprobe -r iwlagn; modprobe iwlagn, and it connected to the ap but the connection was virtually non existent. (very poor connection if any at all) I am the guy that has the iwlagn, the other reporter has the other module This appears to be fixed. I am able now to connect to the hidden AP and the quality of the connection is good Well sometimes there are still minor glitches but there is improvement Closing on the basis of comment 17... This is broken again with todays rawhide update... probably this: Apr 15 17:57:54 Updated: iwl4965-firmware-228.57.2.23-5.fc11.noarch This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping F11 final release is out now and this bug still hasn't been fixed yet. Super annoying for me because my ethernet (Broadcom BCM 50906M) apparently suffers from a bug too. So my laptop (Lenovo 3000 N200) can't connect to the internet. None of the above worked for me. "modprobe -r iwl3945" on my laptop leads to some kind of freeze : blue screen with the fedora logo in the center and the caps lock LED flashes constantly. I have to unplug and replug the power cable to restart the computer. chiller -- your report would appear to have exactly nothing to do with the rest of this bug report. Feel free to open a new bug for the issue you are experiencing, but please do not hijack this one. Speaking of which...domg444, how are things for you with F-11? Maybe I wasn't clear enough... I'm running F11 Final release and I'm experiencing the very same problem described in the bug description (ie Activation (wlan0/wireless): association took too long) with the very same device (Intel Corporation PRO/Wireless 3945ABG [Golan]). So, I believe my report has everything to do with the rest of the bug report. I was just pointing the fact that the solutions given earlier (file with "options iwl3945 disable_hw_scan=1", ...) didn't solve the problem for me and that typing "modprobe -r iwl3945" as suggested provoked some kind of freeze on my computer. And I reported my Broadcom BCM 50906M ethernet problem here thinking it may be related to this one. Well since my last comment #20 i have disabled the feature to hide my access point. Last time i tried it did not work. I will try again asap and report back. I also have other issues with this module. Which i think i also had when f10 was just released (was later fixed in f10) This issue is that i have several identical laptops and when i try to connect the second laptop to my access point then connection is poor on the second laptop. I get disconnected after a short while on the second notebook. The first notebooks connection stays connected fine, but not the second. afaik the same hardware setup/ module. So all in all i think there are still problems with this module. Anyways ill report back on the hidden access point issue asap. I will take that back (broadcast ssid issue) I just tried it (configured my AP to not broadcast SSID) and i was able to connect by choosing "connect to hidden wireless network" in the network manager applet. quality of the connection also seems good. as far as i am concerned this bugzilla can be closed. ( i do have the other issue described above. i might report a bugzilla about that in the future if i have some information to offer besides "does not work") Seems my other issue is also solved now.. must be the latest kernel and of iwl firmware update that solved it... forget it. after a while the connection on my second notebook just becomes a zombie. unfortunately intel iwl still buggy (might file a bz about that issue later). But anyways this "hidden ssid" thing is fixed here. I still have the same log infomation. fedora keeps asking password. cannot connect to the router."took too long" Aug 15 15:57:15 localhost NetworkManager[588]: <info> (wlan0): supplicant interface state: inactive -> scanning Aug 15 15:57:40 localhost NetworkManager[588]: <warn> Activation (wlan0/wireless): association took too long. Aug 15 15:57:40 localhost NetworkManager[588]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0] Aug 15 15:57:40 localhost NetworkManager[588]: <warn> Activation (wlan0/wireless): asking for new secrets Aug 15 15:57:40 localhost NetworkManager[588]: <warn> Couldn't disconnect supplicant interface: This interface is not connected. Aug 15 15:57:40 localhost NetworkManager[588]: <warn> Couldn't disconnect supplicant interface: This interface is not connected. Aug 15 15:57:44 localhost NetworkManager[588]: <info> (wlan0): supplicant interface state: scanning -> inactive Aug 15 15:57:46 localhost NetworkManager[588]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Aug 15 15:57:46 localhost NetworkManager[588]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Aug 15 15:57:46 localhost NetworkManager[588]: <info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0] Aug 15 15:57:46 localhost NetworkManager[588]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Aug 15 15:57:46 localhost NetworkManager[588]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Aug 15 15:57:46 localhost NetworkManager[588]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Aug 15 15:57:46 localhost NetworkManager[588]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] Aug 15 15:57:46 localhost NetworkManager[588]: <info> Activation (wlan0/wireless): connection 'Wireless connection 1' has security, and secrets exist. No new secrets needed. |