Bug 659341 - dropped wireless with 802.11n
Summary: dropped wireless with 802.11n
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-02 15:27 UTC by Jonathan
Modified: 2011-06-28 07:11 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-28 07:11:39 UTC
Type: ---


Attachments (Terms of Use)
dmesg from system that intermittently looses wifi while believing it is working (87.30 KB, text/plain)
2011-04-17 06:26 UTC, Jonathan
no flags Details

Description Jonathan 2010-12-02 15:27:08 UTC
Description of problem:
I'm having repeated interrupts in the network when I try to run 802.11n, while 802.11g is flawless. Running Fedora 14 with atheros ar9285 wireless card against a dlink dir-935 router. The interrupt in the 802.11n connection occurs without any sign that I have perceived. At first, it runs fine, and then at anything between 5 seconds and an hour, it fails. The network "meter" in the gnome bar always indicates connection with good signal strength, while webpages and ping start failing. The only way I have found to restore the connection is to click on the network and tell it to reconnect. It doesn't seem aware that the connection has failed.

Version-Release number of selected component (if applicable):
kernel.x86_64           2.6.35.6-48.fc14
NetworkManager.x86_64   1:0.8.1-10.git20100831.fc14


How reproducible:
always. Usually within minutes but can hold out for an hour.

Steps to Reproduce:
1.start fedora and connect to a 802.11n wireless network
2.
3.
  
Actual results:
browser fails to reach web servers and ping (even local) fails

Expected results:


Additional info:
iwconfig / ifconfig does not indicate any changes for working or dropped connection

Comment 1 Jirka Klimes 2010-12-20 14:32:23 UTC
Hmm, could be a driver issue. Do you see any interesting messages in dmesg?
Also grab /var/log/messages and /var/log/wpa_supplicant.log logs.

Comment 2 Jonathan 2010-12-28 02:37:02 UTC
Nothing interesting in the logs and I start to believe the issue is really the router. I keep finding "wireless restart" in the router log just before the network fails. 

My only concern with this is that the computer is not aware that the network has failed. Re-authenticating with the router always works but as the computer does not become aware that the wireless has failed, I have to do this manually.

This still feels like a bug that the system shows a working wireless link when the link is down.

Comment 3 Jeffrey Seguerra 2011-03-19 22:19:38 UTC
just want to add that I also experience this problem. any work around?

Comment 4 Jonathan 2011-03-27 20:42:21 UTC
No workaround that I have found. I think I've found some more symptoms of it though. When resuming from standby, NM tries to reconnect as expected and always succeed, it seems. It shows a "signal quality bar". There is no connection however. Sometimes it needs a few more manual reconnects to get a working link.

I am aware things fail sometimes but it seems to me that the worst problem is that NM thinks that the link is working when it doesn't.

Comment 5 Dan Williams 2011-04-06 15:58:49 UTC
NM says it's connected when the driver and supplicant say they're connected.  If you can't ping something when connected, then it's most likely that the driver is at fault here because it's reporting that it's connected but you can't pass any traffic.

What do you get in the output of 'dmesg' when things aren't workign?

Comment 6 Jonathan 2011-04-17 06:26:43 UTC
Created attachment 492670 [details]
dmesg from system that intermittently looses wifi while believing it is working

Comment 7 Jirka Klimes 2011-04-18 08:20:25 UTC
What could be problem here is this line:
[ 5816.791018] ath9k: Two wiphys trying to scan at the same time

It appears there is an issue in ath9m/mac80211:
https://patchwork.kernel.org/patch/114611/

I'm not sure whether it's been fixed yet. Reassigning to kernel for now to get an expert response.

Jonathan, would you provide the logs of:

iw event -t

when trying to connect.

Comment 8 Jonathan 2011-04-19 16:06:23 UTC
Successful manual reconnection:
$ iw event -t
1303229115.429373: wlan0 (phy #0): deauth 1c:4b:d6:5b:5e:cb -> 00:24:01:6a:d3:10 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS
1303229115.429503: wlan0 (phy #0): disconnected (local request)
1303229115.455605: wlan0 (phy #0): scan started
1303229115.659319: wlan0 (phy #0): failed to connect, status: 1: Unspecified failure
1303229115.678011: wlan0 (phy #0): scan finished: 2432, "?b\x80)D\xde|\xa5\x89NWY\xd3Q\xad\xac\x86\x95\x80\xec\x17\xe4\x85\xf1\x8c\x0cf\xf1|\xc0|\xbb"
1303229115.679203: wlan0 (phy #0): scan started
1303229115.679427: wlan0 (phy #0): deauth 1c:4b:d6:5b:5e:cb -> 00:24:01:6a:d3:10 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS
1303229115.679489: wlan0 (phy #0): failed to connect to 00:24:01:6a:d3:10, status: 1: Unspecified failure
1303229115.874303: wlan0 (phy #0): scan finished: 2432, "?b\x80)D\xde|\xa5\x89NWY\xd3Q\xad\xac\x86\x95\x80\xec\x17\xe4\x85\xf1\x8c\x0cf\xf1|\xc0|\xbb"
1303229115.884071: wlan0 (phy #0): auth 00:24:01:6a:d3:10 -> 1c:4b:d6:5b:5e:cb status: 0: Successful
1303229115.888145: wlan0: new station 00:24:01:6a:d3:10
1303229115.896175: wlan0 (phy #0): assoc 00:24:01:6a:d3:10 -> 1c:4b:d6:5b:5e:cb status: 0: Successful
1303229115.896264: wlan0 (phy #0): connected to 00:24:01:6a:d3:10

Comment 9 Jonathan 2011-06-28 06:58:11 UTC
I'm happy to say that I have not seen this problem since my upgrade to Fedora 15.
Now running 
kernel.x86_64  2.6.38.8-32.fc15
NetworkManager.x86_64           1:0.8.9997-4.git20110620.fc15

without any sign of this bug.
I can't say if this means that it is also fixed in F14.

Comment 10 Stanislaw Gruszka 2011-06-28 07:11:39 UTC
I'm closing bug per above comment ...


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