Problems associating to AP with rtl8192cu driver

Problems associating to AP with rtl8192cu driver

[Mark Cave-Ayland]

Hi all,

I have a RTL8188CUS wireless USB adapter which I've been trying to 
unsuccessfully use in WPA mode with the rtl8192cu driver. The adapter 
reports itself in lsusb as follows:

0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

What happens is that the adapter seems to repeatedly authenticate and 
associate with the AP without passing data (although a couple of times I 
have randomly managed to load a web page if I can catch the timing right).

The relevant excerpt from dmesg looks like this:


kernel: [ 1158.204831] wlan1: Connection to AP f8:d1:11:88:3b:92 lost
kernel: [ 1159.012203] wlan1: authenticate with f8:d1:11:88:3b:92
kernel: [ 1159.025043] wlan1: send auth to f8:d1:11:88:3b:92 (try 1/3)
kernel: [ 1159.127844] wlan1: send auth to f8:d1:11:88:3b:92 (try 2/3)
kernel: [ 1159.231872] wlan1: send auth to f8:d1:11:88:3b:92 (try 3/3)
kernel: [ 1159.335900] wlan1: authentication with f8:d1:11:88:3b:92 
timed out
kernel: [ 1165.866451] wlan1: authenticate with f8:d1:11:88:3b:92
kernel: [ 1165.879197] wlan1: send auth to f8:d1:11:88:3b:92 (try 1/3)
kernel: [ 1165.894702] wlan1: authenticated
kernel: [ 1165.897721] wlan1: associate with f8:d1:11:88:3b:92 (try 1/3)
kernel: [ 1165.912581] wlan1: RX AssocResp from f8:d1:11:88:3b:92 
(capab=0x431 status=0 aid=1)
kernel: [ 1165.912603] wlan1: associated
kernel: [ 1172.232843] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, 
try to reconnect now
kernel: [ 1172.232850] wlan1: Connection to AP f8:d1:11:88:3b:92 lost
kernel: [ 1173.044038] wlan1: authenticate with f8:d1:11:88:3b:92
kernel: [ 1173.056683] wlan1: send auth to f8:d1:11:88:3b:92 (try 1/3)
kernel: [ 1173.159669] wlan1: send auth to f8:d1:11:88:3b:92 (try 2/3)
kernel: [ 1173.263696] wlan1: send auth to f8:d1:11:88:3b:92 (try 3/3)
kernel: [ 1173.367724] wlan1: authentication with f8:d1:11:88:3b:92 
timed out
kernel: [ 1179.893884] wlan1: authenticate with f8:d1:11:88:3b:92
kernel: [ 1179.906836] wlan1: send auth to f8:d1:11:88:3b:92 (try 1/3)
kernel: [ 1179.912587] wlan1: authenticated
kernel: [ 1179.913534] wlan1: associate with f8:d1:11:88:3b:92 (try 1/3)
kernel: [ 1179.933971] wlan1: RX AssocResp from f8:d1:11:88:3b:92 
(capab=0x431 status=0 aid=1)
kernel: [ 1179.933994] wlan1: associated
kernel: [ 1183.428882] wlan1: deauthenticating from f8:d1:11:88:3b:92 by 
local choice (reason=3)
kernel: [ 1187.219901] wlan1: authenticate with f8:d1:11:88:3b:92
kernel: [ 1187.234505] wlan1: send auth to f8:d1:11:88:3b:92 (try 1/3)
kernel: [ 1187.240871] wlan1: authenticated
kernel: [ 1187.243514] wlan1: associate with f8:d1:11:88:3b:92 (try 1/3)
kernel: [ 1187.266015] wlan1: RX AssocResp from f8:d1:11:88:3b:92 
(capab=0x431 status=0 aid=1)
kernel: [ 1187.266042] wlan1: associated
kernel: [ 1193.818318] usb 4-1.2: USB disconnect, device number 5
kernel: [ 1193.818572] wlan1: deauthenticating from f8:d1:11:88:3b:92 by 
local choice (reason=3)


Can anyone provide any hints to debugging the issue? I've just updated 
to Linus' latest git master from earlier today and the issue still 
appears :(


Many thanks,

Mark.

Re: Problems associating to AP with rtl8192cu driver

[Mark Cave-Ayland]

On 23/08/13 19:55, Mark Cave-Ayland wrote:

> Can anyone provide any hints to debugging the issue? I've just updated
> to Linus' latest git master from earlier today and the issue still
> appears :(

I spent some more time today trying to debug what was happening, and 
ended up setting up a temporary hostapd access point so that I could get 
logs from both the AP and my laptop workstation.

The bug I'm chasing seems to be related to the EAPOL handshake between 
my laptop and the AP. A session with Wireshark shows something like this:

AP -> Laptop : EAPOL 1/4
Laptop -> AP : EAPOL 2/4

(pause - EAPOL timeout of several seconds)

AP -> Laptop : EAPOL 1/4
Laptop -> AP : EAPOL 2/4

This pattern is repeated throughout the connection attempts. Comparing 
wpa_supplicant logs from a workstation with an Intel iwlwifi card shows 
that the AP never sends the EAPOL 3/4 packet, suggesting that something 
in the EAPOL 2/4 packet was invalid causing the authentication attempt 
to be dropped.

Interestingly enough if I leave the wpa_supplicant running for a minute 
or two, then sometimes the laptop will authenticate successfully with 
the AP - this suggests that perhaps it may be an initialisation bug of 
some description?

Can anyone suggest any reasons why the AP never responds with the EAPOL 
3/4 packet as part of the 4-way handshake? To get more information, I 
set up a fake AP using hostapd with logging enabled and recorded the 
authentication attempts on both the AP and the laptop (note that 
remarkably the laptop managed to associate to the AP on the second 
attempt in this particular session):

AP hostapd log:
http://www.ilande.co.uk/tmp/hostapd-rtl8192cu-connect.txt

Laptop workstation log:
http://www.ilande.co.uk/tmp/wpasupplicant-rtl8192cu-connect.txt

Also just to confirm that all testing was done against commit 
6a7492a4b2e05051a44458d7187023e22d580666 and therefore should contain 
the WPA association fix "rtlwifi: rtl8192cu: Fix problem in connecting 
to WEP or WPA(1) networks" from commit 
5b8df24e22e0b00b599cb9ae63dbb96e1959be30.


Many thanks,

Mark.

Re: Problems associating to AP with rtl8192cu driver

[Larry Finger]

On 08/26/2013 01:12 PM, Mark Cave-Ayland wrote:
> On 23/08/13 19:55, Mark Cave-Ayland wrote:
>
>> Can anyone provide any hints to debugging the issue? I've just updated
>> to Linus' latest git master from earlier today and the issue still
>> appears :(
>
> I spent some more time today trying to debug what was happening, and ended up
> setting up a temporary hostapd access point so that I could get logs from both
> the AP and my laptop workstation.
>
> The bug I'm chasing seems to be related to the EAPOL handshake between my laptop
> and the AP. A session with Wireshark shows something like this:
>
> AP -> Laptop : EAPOL 1/4
> Laptop -> AP : EAPOL 2/4
>
> (pause - EAPOL timeout of several seconds)
>
> AP -> Laptop : EAPOL 1/4
> Laptop -> AP : EAPOL 2/4
>
> This pattern is repeated throughout the connection attempts. Comparing
> wpa_supplicant logs from a workstation with an Intel iwlwifi card shows that the
> AP never sends the EAPOL 3/4 packet, suggesting that something in the EAPOL 2/4
> packet was invalid causing the authentication attempt to be dropped.
>
> Interestingly enough if I leave the wpa_supplicant running for a minute or two,
> then sometimes the laptop will authenticate successfully with the AP - this
> suggests that perhaps it may be an initialisation bug of some description?
>
> Can anyone suggest any reasons why the AP never responds with the EAPOL 3/4
> packet as part of the 4-way handshake? To get more information, I set up a fake
> AP using hostapd with logging enabled and recorded the authentication attempts
> on both the AP and the laptop (note that remarkably the laptop managed to
> associate to the AP on the second attempt in this particular session):
>
> AP hostapd log:
> http://www.ilande.co.uk/tmp/hostapd-rtl8192cu-connect.txt
>
> Laptop workstation log:
> http://www.ilande.co.uk/tmp/wpasupplicant-rtl8192cu-connect.txt
>
> Also just to confirm that all testing was done against commit
> 6a7492a4b2e05051a44458d7187023e22d580666 and therefore should contain the WPA
> association fix "rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1)
> networks" from commit 5b8df24e22e0b00b599cb9ae63dbb96e1959be30.

I just retested and this message was posted from what lsusb says is a "Bus 001 
Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless 
Adapter [Realtek RTL8188CUS]" connected to an AP using WPA(1).

My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built 
3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I will build 
and test the mainline kernel, but it should not make a difference as the only 
code differences between wireless-testing and the mainline trees deal with 
cleaning up some sparse endian issues.

What is the make/model of the AP that fails? Is its firmware the latest 
available? Just to confirm, you are running WPA1 encryption.

Do you still have the wireshark file from the failed attempt? If so, could you 
filter out the traffic from APs and stations other than the units trying to make 
the connection, and send me (privately) the trimmed file?

For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400 running 
standard firmware, WPA1 with a Linksys WRT54GL running openWRT Kamikaze fw, and 
WEP with a Linksys WRT54G V5 running standard fw.

Larry

Re: Problems associating to AP with rtl8192cu driver

[Mark Cave-Ayland]

On 27/08/13 17:23, Larry Finger wrote:

Hi Larry,

> I just retested and this message was posted from what lsusb says is a
> "Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
> 802.11n Wireless Adapter [Realtek RTL8188CUS]" connected to an AP using
> WPA(1).

I'm actually testing a dongle from a Raspberry Pi that I've been 
experiencing issues with under load with the Realtek-written 8192cu 
driver. My understanding is that it is an OEM RTL8188CUS adapter from 
here: http://thepihut.com/products/usb-wifi-adapter-for-the-raspberry-pi.

> My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built
> 3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I
> will build and test the mainline kernel, but it should not make a
> difference as the only code differences between wireless-testing and the
> mainline trees deal with cleaning up some sparse endian issues.
>
> What is the make/model of the AP that fails? Is its firmware the latest
> available? Just to confirm, you are running WPA1 encryption.

It seems to be all of the ones I'm testing :/  Currently that's an old 
Netgear DG834G, a desktop PC running Debian Wheezy/hostapd using a 
zd1211rw-based WiFi dongle, and an O2 Wireless box (rebadged Thomson). 
The problem seems to be that association is difficult, and even when it 
does associate then the AP appears to drop out every minute or so.

The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP 
firmware should also be reasonably up-to-date. Access to all APs is fine 
using an Android phone, the zd1211rw desktop PC and a laptop with an 
iwlwifi driver. The APs are set to advertise both WPA and WPA2 encryption.

> Do you still have the wireshark file from the failed attempt? If so,
> could you filter out the traffic from APs and stations other than the
> units trying to make the connection, and send me (privately) the trimmed
> file?

Yes - I'm not sure if it's exactly that attempt, but I do have a 
representative wireshark trace of this which I will send to you privately.

> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.

Okay. So perhaps there is something slightly different about this 
particular WiFi dongle...


Many thanks,

Mark.

Re: Problems associating to AP with rtl8192cu driver

[Larry Finger]

On 08/27/2013 03:40 PM, Mark Cave-Ayland wrote:
> On 27/08/13 17:23, Larry Finger wrote:
>
> Hi Larry,
>
>> I just retested and this message was posted from what lsusb says is a
>> "Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
>> 802.11n Wireless Adapter [Realtek RTL8188CUS]" connected to an AP using
>> WPA(1).
>
> I'm actually testing a dongle from a Raspberry Pi that I've been experiencing
> issues with under load with the Realtek-written 8192cu driver. My understanding
> is that it is an OEM RTL8188CUS adapter from here:
> http://thepihut.com/products/usb-wifi-adapter-for-the-raspberry-pi.
>
>> My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built
>> 3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I
>> will build and test the mainline kernel, but it should not make a
>> difference as the only code differences between wireless-testing and the
>> mainline trees deal with cleaning up some sparse endian issues.
>>
>> What is the make/model of the AP that fails? Is its firmware the latest
>> available? Just to confirm, you are running WPA1 encryption.
>
> It seems to be all of the ones I'm testing :/  Currently that's an old Netgear
> DG834G, a desktop PC running Debian Wheezy/hostapd using a zd1211rw-based WiFi
> dongle, and an O2 Wireless box (rebadged Thomson). The problem seems to be that
> association is difficult, and even when it does associate then the AP appears to
> drop out every minute or so.
>
> The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP
> firmware should also be reasonably up-to-date. Access to all APs is fine using
> an Android phone, the zd1211rw desktop PC and a laptop with an iwlwifi driver.
> The APs are set to advertise both WPA and WPA2 encryption.

The accepted firmware has an md5sum of 943e9b714a926e630b8152d7aad91d2e for 
/lib/firmware/rtlwifi/rtl8192cufw.bin.

>> Do you still have the wireshark file from the failed attempt? If so,
>> could you filter out the traffic from APs and stations other than the
>> units trying to make the connection, and send me (privately) the trimmed
>> file?
>
> Yes - I'm not sure if it's exactly that attempt, but I do have a representative
> wireshark trace of this which I will send to you privately.
>
>> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
>> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
>> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.
>
> Okay. So perhaps there is something slightly different about this particular
> WiFi dongle...

Neither rtl8192cu nor 8192cu (the vendor driver) work with the 2x2 configuration 
such as found in a TP-Link TL-WN8200ND V1.0. That was reported to Realtek, but I 
have had no response from them.

Larry

Re: Problems associating to AP with rtl8192cu driver

[Mark Cave-Ayland]

On 27/08/13 22:19, Larry Finger wrote:

Hi Larry,

>> The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP
>> firmware should also be reasonably up-to-date. Access to all APs is
>> fine using
>> an Android phone, the zd1211rw desktop PC and a laptop with an iwlwifi
>> driver.
>> The APs are set to advertise both WPA and WPA2 encryption.
>
> The accepted firmware has an md5sum of 943e9b714a926e630b8152d7aad91d2e
> for /lib/firmware/rtlwifi/rtl8192cufw.bin.

Yes - that agrees with what I have here:

mca@kentang:~$ md5sum /lib/firmware/rtlwifi/rtl8192cufw.bin
943e9b714a926e630b8152d7aad91d2e  /lib/firmware/rtlwifi/rtl8192cufw.bin

>>> Do you still have the wireshark file from the failed attempt? If so,
>>> could you filter out the traffic from APs and stations other than the
>>> units trying to make the connection, and send me (privately) the trimmed
>>> file?
>>
>> Yes - I'm not sure if it's exactly that attempt, but I do have a
>> representative
>> wireshark trace of this which I will send to you privately.
>>
>>> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
>>> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
>>> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.
>>
>> Okay. So perhaps there is something slightly different about this
>> particular
>> WiFi dongle...
>
> Neither rtl8192cu nor 8192cu (the vendor driver) work with the 2x2
> configuration such as found in a TP-Link TL-WN8200ND V1.0. That was
> reported to Realtek, but I have had no response from them.

Understood. All of the O2 wireless box, desktop PC and Netgear AP I used 
in my tests here are b/g only, so I'm guessing that shouldn't be an issue?


ATB,

Mark.