Created attachment 325465 [details] dmesg output from the system Description of problem: After a seemingly random period of time, the rt61pci wifi PCI NIC in my system will stop working. If I check dmesg, I see the following : ############ wlan0: deauthenticated wlan0: authenticate with AP 00:16:b6:da:8a:44 wlan0: authenticated wlan0: associate with AP 00:16:b6:da:8a:44 wlan0: RX ReassocResp from 00:16:b6:da:8a:44 (capab=0x1 status=0 aid=1) wlan0: associated wlan0: No ProbeResp from current AP 00:16:b3:da:01:44 - assume out of range ############ Sometimes it will be fine for hours, other times a few minutes. I've discovered that if I bring down the wlan0 interface (ifdown wlan0) and then bring it back up again, the problem is (temporarily) fixed. I am *NOT* using Network Manager on this system. I've attached dmesg output that includes the failure, plus a few wlan0 interface restarts afterwards. Version-Release number of selected component (if applicable): 2.6.27.5-117.fc10.i686 How reproducible: Very often Steps to Reproduce: 1. Boot up, watch wlan0 come up 2. Use the internet for a while 3. The connection dies eventually Actual results: Dead network connection Expected results: No dead network connection Additional info: 00:0c.0 Network controller: RaLink RT2561/RT61 802.11g PCI
If you don't want to use NetworkManager than you should use wpa_supplicant (even if you are not using WPA encryption). It will detect when the connection goes down and it will trigger a new association automatically.
OK, I can give that a try, thanks. Using wpa_supplicant is not intended to be a the actual solution, and just a workaround, right?
I'm not sure what there is to fix. A wireless connection might be lost for any number of reasons. All you can do is reassociate, which we depend on userland to tell us to do.
I just tried to setup wpa_supplicant, and it refuses to run with the rt61pci driver: Unsupported driver 'rt61pci'
The proper driver is "wext".
OK, I tried with wext, and wpa_supplicant starts up ok, yet never detects any network when doing a scan (and hence no AP is ever associated at all). Note, that without wpa_supplicant, the association works fine for some period of time. Also note, this isn't a laptop where I'm wondering around and the signal might change over time. Its a workstation sitting in a room that isn't moving anywhere (and the AP isn't moving either).
Please post your wpa_supplicant config, changing/obfuscating any keys or sensitive information. Running wpa_supplicant shouldn't cause scans to fail.
/etc/sysconfig/wpa_supplicant contains only the following: INTERFACES="-iwlan0" DRIVERS="-Dwext" OTHER_ARGS="-u -f /var/log/wpa_supplicant.log" wpa_supplicant.conf contains only the following: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel
That wpa_supplicant.conf doesn't know about your network, so it can't connect. You need a clause below the ctrl_interface_group line that looks something like this: network={ ssid="YOUR_SSID" key_mgmt=NONE wep_key0=0123456789abcdef0123456789 wep_tk_keyidx=0 } Obviously you need to change the ssid and wep_key0 lines to reflect your network. After making thise changes, you should restart wpa_supplicant. Does that improve things?
Hi, I have the same problem with my D-Link DWL-G510 ( 01:06.0 Network controller: RaLink RT2561/RT61 rev B 802.11g ), and kernel 2.6.27.9-159.fc10.x86_64. The dmesg output is : wlan0: associate with AP 00:13:64:28:47:ea wlan0: associate with AP 00:13:64:28:47:ea wlan0: associate with AP 00:13:64:28:47:ea wlan0: association with AP 00:13:64:28:47:ea timed out wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticated wlan0: associate with AP 00:13:64:28:47:ea wlan0: RX AssocResp from 00:13:64:28:47:ea (capab=0x461 status=0 aid=1) wlan0: associated wlan0: No ProbeResp from current AP 00:13:64:28:47:ea - assume out of range wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticated wlan0: associate with AP 00:13:64:28:47:ea wlan0: associate with AP 00:13:64:28:47:ea wlan0: associate with AP 00:13:64:28:47:ea wlan0: association with AP 00:13:64:28:47:ea timed out wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticated wlan0: associate with AP 00:13:64:28:47:ea wlan0: RX AssocResp from 00:13:64:28:47:ea (capab=0x461 status=0 aid=1) wlan0: associated wlan0: disassociating by local choice (reason=3) wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticate with AP 00:13:64:28:47:ea wlan0: authenticated wlan0: associate with AP 00:13:64:28:47:ea wlan0: RX ReassocResp from 00:13:64:28:47:ea (capab=0x461 status=0 aid=1) wlan0: associated I'm not use wpa_supplicant and use NetworkManager. The signal is low (yes, depends in part to access point) but when the connection is up the txpower is 9db and speed is ever 1MB. I insert the iwconfig command for txpower and the rate on rc.local. The problem is that the wireless card disconnect often, especially if run an update or a resource that need more of net traffic (but also with browser lost the connection with ap :-~).
Same bug here. I'm using wpa_supplicant + dhclient interface. No NetworkManager (but it happend also when I was using it). I don't know why but it happens mostly when i'm AFK and some kind of downloading software is running (www, bt, etc.). After connection hangs, there is no network visible using "iwlist wlan0 scanning". Killing wpa_supplicant and dhclient, and starting them again usually helps. Turning off AP creates the same output in dmesg, but after turning AP on again wpa_supplicant finds the network without problems → it's probably driver issue(?) FC10, fully updated. ************* lspci: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 03) 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 25) 00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0) 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0) 00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f) 00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f) 00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller 00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91) 00:06.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02) 00:0b.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter ********** dmesg: wlan0: No ProbeResp from current AP 00:1e:e5:7a:1d:3c - assume out of range b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac: 00:1e:e5:7a:1d:3c wlan0: authenticate with AP 00:1e:e5:7a:1d:3c wlan0: authenticate with AP 00:1e:e5:7a:1d:3c wlan0: authenticate with AP 00:1e:e5:7a:1d:3c wlan0: authenticate with AP 00:1e:e5:7a:1d:3c wlan0: authentication with AP 00:1e:e5:7a:1d:3c timed out
I've noticed an interesting thing. I was getting a lot of "APIC error on CPU0: 40(40)" messages in dmesg for a long time. Didn't bothered actually, 'cause no major problem occured. However, recently my connection dropped. I checked dmesg and found no messages like that after information about dropped connection. After reconnecting, messages instantly started to appear once again. I will try to confirm "this coincidence" in the future & check if it also happens when wired connection is running. *********** uname -r 2.6.27.19-170.2.35.fc10.i686
Problem still exists in kernel 2.6.29.1-30.fc10.i686 (from testing repo)
The problem remaining with Fedora 11 and the last kernel 2.6.29.5-191.fc11.x86_64.
Same problem in 2.6.29.6-213.fc11.i686.PAE. To developers: I do have a lot of time right now, so just tell me what you want to now, i will provide the answer.
I've just did some testing and that's what I found: -connection was broken (3 out of 3) when I was not doing anything with my laptop (typing, moving cursor etc.); there was only 1 active download process -HOWEVER network manager, and download software always reported the error soon after I've moved the mouse cursor, not when I was AFK, like the whole system was frozen (which is strange, cause I have Fedora configured not to sleep in any way when on AC Power) -error message was the same as written in previous posts -strangely, system clock also freezes when the problem occurs - I've twice reset the clock, reproduced this error by downloading huge file and than had a system clock delayed by 20 minutes (I was about 30 min. AFK)
That sounds completely bizarre. The system time being wrong suggests...well, I'm not sure what that suggests... But if something is resulting in system time being wrong then it isn't suprising that the measurement of time since the last received beacon would be wrong as well. Wojciech, I would suggest that you open a different bug relating to your loss of system time and then try to replicate this bug after that one is resolved.
I see your point, but the fact that both problems occurs when there is a download process going on (I couldn't find any other reason for such behaviour), makes me think that the source of the problem lies somewhere within wireless implementation. Also, first kernel mentioned in this bug (2.6.27.5-117.fc10.i686 ), brought a lot of wireless updates. I will wait for now, meanwhile will try to find any other reason for this weird system-clock behaviour.
As the originator of this bug, I wanted to comment that I just upgraded to F11, and this bug remains present.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.