Bug 474270 - wlan0: No ProbeResp from current AP- assume out of range
wlan0: No ProbeResp from current AP- assume out of range
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
i686 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-02 20:50 EST by Lonni J Friedman
Modified: 2010-06-28 06:53 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:53:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output from the system (29.14 KB, application/octet-stream)
2008-12-02 20:50 EST, Lonni J Friedman
no flags Details

  None (edit)
Description Lonni J Friedman 2008-12-02 20:50:17 EST
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
Comment 1 John W. Linville 2008-12-03 10:14:56 EST
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.
Comment 2 Lonni J Friedman 2008-12-03 10:23:22 EST
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?
Comment 3 John W. Linville 2008-12-03 10:43:35 EST
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.
Comment 4 Lonni J Friedman 2008-12-06 17:24:18 EST
I just tried to setup wpa_supplicant, and it refuses to run with the rt61pci driver:
Unsupported driver 'rt61pci'
Comment 5 John W. Linville 2008-12-08 10:16:31 EST
The proper driver is "wext".
Comment 6 Lonni J Friedman 2008-12-14 19:09:43 EST
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).
Comment 7 John W. Linville 2008-12-16 11:34:19 EST
Please post your wpa_supplicant config, changing/obfuscating any keys or sensitive information.  Running wpa_supplicant shouldn't cause scans to fail.
Comment 8 Lonni J Friedman 2008-12-16 18:18:56 EST
/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
Comment 9 John W. Linville 2008-12-18 10:10:53 EST
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?
Comment 10 diego 2009-01-09 05:22:23 EST
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 :-~).
Comment 11 Wojciech Sluszniak 2009-03-15 14:58:41 EDT
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
Comment 12 Wojciech Sluszniak 2009-03-17 19:54:04 EDT
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
Comment 13 Wojciech Sluszniak 2009-04-19 15:54:19 EDT
Problem still exists in kernel 2.6.29.1-30.fc10.i686 (from testing repo)
Comment 14 diego 2009-07-08 15:09:26 EDT
The problem remaining with Fedora 11 and the last kernel 2.6.29.5-191.fc11.x86_64.
Comment 15 Wojciech Sluszniak 2009-07-26 10:04:34 EDT
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.
Comment 16 Wojciech Sluszniak 2009-07-26 17:17:13 EDT
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)
Comment 17 John W. Linville 2009-07-27 09:17:57 EDT
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.
Comment 18 Wojciech Sluszniak 2009-07-28 07:08:18 EDT
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.
Comment 19 Lonni J Friedman 2009-07-28 10:46:01 EDT
As the originator of this bug, I wanted to comment that I just upgraded to F11, and this bug remains present.
Comment 20 Bug Zapper 2010-04-27 08:26:44 EDT
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
Comment 21 Bug Zapper 2010-06-28 06:53:12 EDT
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.

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