Bug 574885

Summary:	[iwlagn] WiFi network stops being usable after DHCP
Product:	[Fedora] Fedora	Reporter:	Derek Atkins <warlord>
Component:	kernel	Assignee:	Stanislaw Gruszka <sgruszka>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	anton, dougsland, gansalmon, itamar, jonathan, joshua.bakerlepain, kernel-maint, rhel, sgruszka
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-03-19 14:29:10 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 Derek Atkins 2010-03-18 18:59:22 UTC

Description of problem:

I have a WRT610N AP running DD-WRT, and I have two networks, a 2.4GHz g network and a 5GHz a/n network (configured with different SSIDs). In order to fix a problem on MacOSX I changed the configuration from TKIP to AES(CCMP). Once I did that I started seeing Bug #536988 on my Thinkpad T500 with an Intel 5300 abgn. I started seeing tons of:

Mar 18 12:52:12 pgpdev kernel: iwlagn 0000:03:00.0: ERROR: No TX rate available.

Following the instructions in #536988 I upgraded from 2.6.31 to 2.6.32 and indeed the "No TX rate available" messages went away, however it didn't solve the network usability. Now, with the 2.6.32 kernel after the DHCP response I see:

Mar 18 13:49:11 pgpdev dhclient[2342]: bound to 192.168.248.100 -- renewal in 1686 seconds.
Mar 18 13:50:58 pgpdev kernel: iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:25:9c:ce:f5:71 tid = 0

And then the network is completely unusable. I can't ping. The arp table is empty. If I reset the network it will again bring up the net through DHCP and then die again.

Version-Release number of selected component (if applicable):
kernel-2.6.32.9-70.fc12.x86_64
NetworkManager-0.7.998-2.git20100106.fc12.x86_64
wpa_supplicant-0.6.8-8.fc12.x86_64

How reproducible:
100% with my 802.11 an network.

Steps to Reproduce:
1. Configure a 5GHz 802.11 a/n network with WPA2/PSK/AES(CCMP)
2. Tell NetworkManager to connect to that network
3. Type in your password, wait for it to connect
4. watch the logs, see that it connects, then immediately prints out the iwl_tx_agg_start message
5. try to ping and notice that you can't get anywhere
6. notice that the arp table is empty
7. reset the network through NM and watch it happen again.

Actual results:
Packets wont flow

Expected results:
A working 5GHz network

Additional info:
Ask and ye shall receive. :)

Comment 1 Derek Atkins 2010-03-18 19:20:23 UTC

FYI, I just reconfigured my network from "A+N" to "A-Only" and now it works fine..  So it's clearly something in the "n" network on the client.  (no, this bug is not fixed -- living in an A-Only world is not a valid workaround, and I'm sure this bug will show up in places where I cannot reconfigure the network).

So it's clearly a problem with the iwlagn 'n' network support.

Comment 2 Joshua Baker-LePain 2010-03-18 19:29:14 UTC

This is likely a dupe of bug 571753 --  have a look at the test kernels there and see if they help.

Comment 3 Derek Atkins 2010-03-18 20:39:48 UTC

Hmmm... Possibly.
I installed 2.6.32.10-83.sg_test.fc12.x86_64 and while it does seem to keep me on the network properly it seems like it's not attaching as an 'n' network.  For example, right now (with my network configured as AN-Mix with 40Mhz width), I see:

[warlord@pgpdev ~/Video]$ iw wlan0 station dump
Station 00:25:9c:ce:f5:71 (on wlan0)
	inactive time:	437 ms
	rx bytes:	89499251
	rx packets:	98951
	tx bytes:	11362545
	tx packets:	63725
	signal:  	-46 dBm
	tx bitrate:	54.0 MBit/s

Whereas before I would see a tx bitrate of 160 MBit/s

Also the network seems to be behaving slower than it did before..  (I'm seeing slower download speeds than I did on my g network, but that could be the koji source).

So I'm not sure if this is a dup or not.

Comment 4 Derek Atkins 2010-03-18 20:49:04 UTC

Okay, maybe my tests weren't quite accurate.. I did a pull from a different source and was seeing my 1.8MB/s, as expected.  So perhaps this is a dup..

We'll see if I get kicked off my network overnight.

Comment 5 Stanislaw Gruszka 2010-03-19 08:40:08 UTC

Hi Derek

If you are not experiences by performance problems, I'm going to close that bug. Otherwise we have to work on that performance issue. Please let us know. Thanks.

Comment 6 Derek Atkins 2010-03-19 13:19:38 UTC

Well, I do wonder why the txrate says 54 instead of 160, but I'm not seeing any performance issues that I cannot explain through delays at the other end.

So I think you can safely close this bug.

Comment 7 Derek Atkins 2010-03-19 13:19:59 UTC

( fixed in 2.6.32.10-83.sg_test.fc12.x86_64 )

Comment 8 Stanislaw Gruszka 2010-03-19 14:29:10 UTC

iw shows tx rate of last frame transmitted, you may try to do:

while true; do iw wlan0 station dump | grep "bitrate" ; sleep 0.5 ; done

then, start uploading some files and see how this will look. For downloading performance more important is at what bitrate RX frames are modulated.

Ok, I think everything is fine here. If you will have any troubles with iwlwifi just open new bug. Thanks.

*** This bug has been marked as a duplicate of bug 571753 ***