[ath9k-devel] Dlink DIR-655 firmware upgrade broke 11n

[ath9k-devel] Dlink DIR-655 firmware upgrade broke 11n

[Kevin Mitchell]

So about a month ago, I got a mail from my router (Dlink DIR-655
HW:A2) telling me that firmware 1.20 was available for download.  I
believe I had 1.11 before. Hoping to boost my new 11n capability
(thanks so much by the way), I went ahead with the upgrade.
Unfortunately now, I can no longer associate if the 11n is enabled on
the router. I must restrict it to 11g only mode. I can still associate
11n in XP.

You can see my wpa_supplicant debug log here.
http://pastebin.com/me286042. Line 205 may be significant "Driver did
not support SIOCSIWENCODEEXT"
Kevin

[ath9k-devel] Dlink DIR-655 firmware upgrade broke 11n

[Jouni Malinen]

On Oct 3, 2008, at 2:53 PM, Kevin Mitchell wrote:

> So about a month ago, I got a mail from my router (Dlink DIR-655
> HW:A2) telling me that firmware 1.20 was available for download.  I
> believe I had 1.11 before. Hoping to boost my new 11n capability
> (thanks so much by the way), I went ahead with the upgrade.
> Unfortunately now, I can no longer associate if the 11n is enabled on
> the router. I must restrict it to 11g only mode. I can still associate
> 11n in XP.

Which WLAN card do you use in the client? Which kernel/driver version?

> You can see my wpa_supplicant debug log here.
> http://pastebin.com/me286042. Line 205 may be significant "Driver did
> not support SIOCSIWENCODEEXT"

That's fine in the context of clearing keys. Does 'dmesg' output show  
any
messages when you try to connect with the AP? The driver seems to  
indicate
a successful association, but none of the WPA 4-way handshake messages
are shown in wpa_supplicant debug for some reason.

- Jouni

[ath9k-devel] Dlink DIR-655 firmware upgrade broke 11n

[Kevin Mitchell]

> Which WLAN card do you use in the client? Which kernel/driver version?

Sorry, that was sent a little too early in the morning for me.

Right now I am running the latest wireless-testing from git. This also
seems to occur with older 2.6.27 (both mainline and wireless testing)
as well as 2.6.24 augmented with compat-wireless.

My client is a Lenovo T60 with the AR5518 chip in it:

$lspci -vvvn
03:00.0 0280: 168c:0024 (rev 01)
        Subsystem: 168c:0033
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR+ <PERR- INTx-
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory@edf00000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel modules: ath9k, ath_pci

$lspci -vvv
03:00.0 Network controller: Atheros Communications Inc. AR5418
802.11abgn Wireless PCI Express Adapter (rev 01)
        Subsystem: Atheros Communications Inc. Device 0033
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR+ <PERR- INTx-
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory@edf00000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel modules: ath9k, ath_pci


> That's fine in the context of clearing keys. Does 'dmesg' output show any
> messages when you try to connect with the AP?

In fact it shows this rather interesting Warning/call
trace:http://pastebin.com/d350e74a7

> The driver seems to indicate
> a successful association, but none of the WPA 4-way handshake messages
> are shown in wpa_supplicant debug for some reason.
I should have been more specific, I does infact associate very
briefly, but it de-associates almost immediately. No 4-way handshake
and certainly no ip address from dhcp.

Ok, all of that said, after removing and reprobing the ath9k module a
few times, I can associate and get a functioning ip address when the
router is in 11n only mode. My router configuration page does say that
I'm using 11n, but only at 54Mbps:

SSID	MAC Address	IP Address	Mode	Rate (Mbps)	Signal (%)
hendecagon	00197E4109C1	192.168.1.102	802.11n (2.4GHz)	52	66

Here is the updated wpa_supplicant log: http://pastebin.com/m240ba17f.

This is the current output from dmesg (with successfuly, but low rate
association).

[  451.120264] cfg80211: Calling CRDA to update world regulatory domain
[  451.135051] ath9k: 0.1
[  451.135208] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[  451.135291] ath9k 0000:03:00.0: setting latency timer to 64
[  451.270732] phy0: Selected rate control algorithm 'ath9k_rate_control'
[  451.312642] Registered led device: ath9k-phy0:radio
[  451.312682] Registered led device: ath9k-phy0:assoc
[  451.312711] Registered led device: ath9k-phy0:tx
[  451.312740] Registered led device: ath9k-phy0:rx
[  451.313326] phy0: Atheros 5416: mem=0xffffc200047e0000, irq=17
[  455.357684] wlan0: direct probe to AP 00:1b:11:68:c9:f9 try 1
[  455.362015] wlan0 direct probe responded
[  455.362029] wlan0: authenticate with AP 00:1b:11:68:c9:f9
[  455.364463] wlan0: authenticated
[  455.364472] wlan0: associate with AP 00:1b:11:68:c9:f9
[  455.367604] wlan0: RX AssocResp from 00:1b:11:68:c9:f9 (capab=0x431
status=0 aid=1)
[  455.367610] wlan0: associated

Now, when I run iperf dmesg gives in addition:
[  819.303733] ath_tx_prepare: TX queue: 1 is full, depth: 492
(repeats many times)

Iperf also gives a really slow speed:

------------------------------------------------------------
Client connecting to 192.168.1.100, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.102 port 56349 connected with 192.168.1.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  8.62 MBytes  7.10 Mbits/sec

I am able to get these successful low rate associations on repeated
removals/reprobes of the module on the client. Now, however after
robooting the router, I'm back to square one. I am getting the same
call trace from dmesg and cannot associate.

Kevin

[ath9k-devel] Dlink DIR-655 firmware upgrade broke 11n

[Kevin Mitchell]

So upgrading to the 1.21 (9/30/2008) firmware on the DIR-655 router
allowed my AR5418 client to associate 11n at the speeds I was seeing
before. I am again using the current wireless-testing kernel as of
writing.

On client:
$ iperf -c 192.168.1.100
------------------------------------------------------------
Client connecting to 192.168.1.100, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.102 port 50197 connected with 192.168.1.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  35.3 MBytes  29.2 Mbits/sec

On remote machine w/ gigabit to router:
$ iperf -c 192.168.1.102
------------------------------------------------------------
Client connecting to 192.168.1.102, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.100 port 55712 connected with 192.168.1.102 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  47.9 MBytes  40.0 Mbits/sec

Actually this is a bit faster than I was seeing before. I'm guessing
there have been some improvements in the time that I have been
11nless. Keep up the good work guys!

I also noticed that my pastebin of the calltrace has dissapeared.
Here's an updated version of it using the same specs as above, but
with the 1.20 firmware on the router. I generated this just before I
upgraded the router firmware.

http://pastebin.com/m1c78423

Kevin

On Sun, Oct 5, 2008 at 4:35 PM, Kevin Mitchell <kevmitch@gmail.com> wrote:
>> Which WLAN card do you use in the client? Which kernel/driver version?
>
> Sorry, that was sent a little too early in the morning for me.
>
> Right now I am running the latest wireless-testing from git. This also
> seems to occur with older 2.6.27 (both mainline and wireless testing)
> as well as 2.6.24 augmented with compat-wireless.
>
> My client is a Lenovo T60 with the AR5518 chip in it:
>
> $lspci -vvvn
> 03:00.0 0280: 168c:0024 (rev 01)
>        Subsystem: 168c:0033
>        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR+ <PERR- INTx-
>        Interrupt: pin A routed to IRQ 17
>        Region 0: Memory at edf00000 (64-bit, non-prefetchable) [size=64K]
>        Capabilities: <access denied>
>        Kernel modules: ath9k, ath_pci
>
> $lspci -vvv
> 03:00.0 Network controller: Atheros Communications Inc. AR5418
> 802.11abgn Wireless PCI Express Adapter (rev 01)
>        Subsystem: Atheros Communications Inc. Device 0033
>        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR+ <PERR- INTx-
>        Interrupt: pin A routed to IRQ 17
>        Region 0: Memory at edf00000 (64-bit, non-prefetchable) [size=64K]
>        Capabilities: <access denied>
>        Kernel modules: ath9k, ath_pci
>
>
>> That's fine in the context of clearing keys. Does 'dmesg' output show any
>> messages when you try to connect with the AP?
>
> In fact it shows this rather interesting Warning/call
> trace:http://pastebin.com/d350e74a7
>
>> The driver seems to indicate
>> a successful association, but none of the WPA 4-way handshake messages
>> are shown in wpa_supplicant debug for some reason.
> I should have been more specific, I does infact associate very
> briefly, but it de-associates almost immediately. No 4-way handshake
> and certainly no ip address from dhcp.
>
> Ok, all of that said, after removing and reprobing the ath9k module a
> few times, I can associate and get a functioning ip address when the
> router is in 11n only mode. My router configuration page does say that
> I'm using 11n, but only at 54Mbps:
>
> SSID    MAC Address     IP Address      Mode    Rate (Mbps)     Signal (%)
> hendecagon      00197E4109C1    192.168.1.102   802.11n (2.4GHz)        52      66
>
> Here is the updated wpa_supplicant log: http://pastebin.com/m240ba17f.
>
> This is the current output from dmesg (with successfuly, but low rate
> association).
>
> [  451.120264] cfg80211: Calling CRDA to update world regulatory domain
> [  451.135051] ath9k: 0.1
> [  451.135208] ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [  451.135291] ath9k 0000:03:00.0: setting latency timer to 64
> [  451.270732] phy0: Selected rate control algorithm 'ath9k_rate_control'
> [  451.312642] Registered led device: ath9k-phy0:radio
> [  451.312682] Registered led device: ath9k-phy0:assoc
> [  451.312711] Registered led device: ath9k-phy0:tx
> [  451.312740] Registered led device: ath9k-phy0:rx
> [  451.313326] phy0: Atheros 5416: mem=0xffffc200047e0000, irq=17
> [  455.357684] wlan0: direct probe to AP 00:1b:11:68:c9:f9 try 1
> [  455.362015] wlan0 direct probe responded
> [  455.362029] wlan0: authenticate with AP 00:1b:11:68:c9:f9
> [  455.364463] wlan0: authenticated
> [  455.364472] wlan0: associate with AP 00:1b:11:68:c9:f9
> [  455.367604] wlan0: RX AssocResp from 00:1b:11:68:c9:f9 (capab=0x431
> status=0 aid=1)
> [  455.367610] wlan0: associated
>
> Now, when I run iperf dmesg gives in addition:
> [  819.303733] ath_tx_prepare: TX queue: 1 is full, depth: 492
> (repeats many times)
>
> Iperf also gives a really slow speed:
>
> ------------------------------------------------------------
> Client connecting to 192.168.1.100, TCP port 5001
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [  3] local 192.168.1.102 port 56349 connected with 192.168.1.100 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-10.2 sec  8.62 MBytes  7.10 Mbits/sec
>
> I am able to get these successful low rate associations on repeated
> removals/reprobes of the module on the client. Now, however after
> robooting the router, I'm back to square one. I am getting the same
> call trace from dmesg and cannot associate.
>
> Kevin
>

[ath9k-devel] Dlink DIR-655 firmware upgrade broke 11n

[Luis R. Rodriguez]

On Sun, Oct 19, 2008 at 08:31:13PM -0700, Kevin Mitchell wrote:
> So upgrading to the 1.21 (9/30/2008) firmware on the DIR-655 router
> allowed my AR5418 client to associate 11n at the speeds I was seeing
> before. I am again using the current wireless-testing kernel as of
> writing.
> 
> On client:
> $ iperf -c 192.168.1.100
> ------------------------------------------------------------
> Client connecting to 192.168.1.100, TCP port 5001
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [  3] local 192.168.1.102 port 50197 connected with 192.168.1.100 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-10.1 sec  35.3 MBytes  29.2 Mbits/sec
> 
> On remote machine w/ gigabit to router:
> $ iperf -c 192.168.1.102
> ------------------------------------------------------------
> Client connecting to 192.168.1.102, TCP port 5001
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [  3] local 192.168.1.100 port 55712 connected with 192.168.1.102 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-10.0 sec  47.9 MBytes  40.0 Mbits/sec
> 
> Actually this is a bit faster than I was seeing before. I'm guessing
> there have been some improvements in the time that I have been
> 11nless. Keep up the good work guys!

Give this patch a try as well:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/mac80211/aggrv10.patch

  Luis