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.
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.
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
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.
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.
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