Bug 74541 - [BISECTED]rtl8192se wireless regression - unable to connect to WPA2 network
Summary: [BISECTED]rtl8192se wireless regression - unable to connect to WPA2 network
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
Depends on:
Reported: 2014-04-21 07:45 UTC by Alex Miller
Modified: 2015-03-20 13:22 UTC (History)
7 users (show)

See Also:
Kernel Version: 3.13
Regression: Yes
Bisected commit-id:

wpa_supplicant log with kernel 3.14.1 (35.38 KB, text/plain)
2014-04-24 09:09 UTC, Alex Miller
packet capture with kernel 3.14.1 (1.06 KB, application/octet-stream)
2014-04-24 09:11 UTC, Alex Miller
Proposed patch No 1 (612 bytes, patch)
2014-04-24 16:09 UTC, Larry Finger
Details | Diff

Description Alex Miller 2014-04-21 07:45:08 UTC
3.13 introduced a regression for my rtl8192se based wireless adapter.  I am no longer able to connect to WPA2 802.11n networks.  /var/log/messages shows:

Apr 21 09:17:07 gentoo-laptop kernel: wlp3s0: authenticate with 10:0d:7f:9c:5e:5
Apr 21 09:17:07 gentoo-laptop kernel: wlp3s0: send auth to 10:0d:7f:9c:5e:56 (tr
y 1/3)
Apr 21 09:17:07 gentoo-laptop kernel: wlp3s0: authenticated
Apr 21 09:17:07 gentoo-laptop kernel: wlp3s0: associate with 10:0d:7f:9c:5e:56 (
try 1/3)
Apr 21 09:17:07 gentoo-laptop kernel: wlp3s0: RX AssocResp from 10:0d:7f:9c:5e:5
6 (capab=0x431 status=0 aid=2)
Apr 21 09:17:07 gentoo-laptop kernel: wlp3s0: associated
Apr 21 09:17:15 gentoo-laptop kernel: wlp3s0: deauthenticated from 10:0d:7f:9c:5
e:56 (Reason: 15)

This repeats over and over.

Steps to reproduce:

1. Boot with any kernel later than 3.13
2. Attempt to connect to WPA2 802.11n network

I have run a git bisect which points to this commit as being the culprit:

commit 1bf4bbb4024dcdab5e57634dd8ae1072d42a53ac
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Feb 11 16:02:47 2014 +0100

    mac80211: send control port protocol frames to the VO queue

lspci -nn for the card:

03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller [10ec:8172] (rev 10)

If any more information is needed, just ask.

Comment 1 Larry Finger 2014-04-22 16:15:48 UTC
Thanks for bisecting the problem.

I have tested a 10ec:8172 (rev 10) card. Using kernel 3.14 from the wireless-testing tree, it could connect to 2 different AP's running 802.11n with WPA2 encryption, a third running 802.11g with WPA1, and a fourth using WEP. Unfortunately, I cannot duplicate the problem.

Reason 15 means "Authentication rejected because of challenge failure." I assume that your secret is correct, thus perhaps commit 1bf4bbb exposes some bug between the kernel and your AP. What is the make/model of the access point? Is the firmware up to date?

Do you have logs for wpa_supplicant? If you are using NetworkManager, please post its logs. I am not sure where Gentoo places those logs.

Do you have access to a separate computer that could use wireshark or kismet to capture the packets in the air?

Comment 2 Alex Miller 2014-04-23 00:27:05 UTC

Thanks for taking the time to look into this.  The secret is correct (I have tried re-entering it numerous times).  My AP is a Netgear WNDR3400v2 with firmware V1.0.0.48_1.0.69PRRU. This is the latest according to the Netgear website (in case you look yourself, this is a special firmware for Chinese users only, I purchased the AP in China and I am in China so therefore I am using the correct version).

I am using wicd.  I will have a look for the logs.  I will also try and setup the connection using wpa_supplicant alone and get some logs for wpa_supplicant.

My desktop has a wifi card that I should be able to use wireshark with.  I'll try and set it up tomorrow.  What do you need me to capture?
Comment 3 Larry Finger 2014-04-23 03:21:41 UTC
One of my APs is also a Netgear WNDR3400v2 with firmware V1.0.0.38_1.0.61. That is the latest for my model.

You should start the capture just before you start trying to connect with rtl8192se. If your neighborhood was a lot of traffic, you can cut the size of the posted capture file if you use wireshark to keep only those packets that have your AP as source or destination plus those that have the RTL8191SEvB as source/destination.

When you post the file, also indicate the MAC for the AP (10:0d:7f:9c:5e:56?) and the RTL8191SE.

Comment 4 Neil McCirrus 2014-04-23 13:22:54 UTC
I too experiebce this ..

Wireless fails to connect, downgrading to linux 3.13.8-1 fixes it

Additional info:
Network controller: Realtek Semiconductor Co., Ltd. RTL8192E/RTL8192SE Wireless LAN Controller (rev 01)

* package version(s)
linux 3.14.1-1

* config and/or log files etc.
[ 35.115184] Linking with MYSSID,channel:*, qos:1, myHT:1, networkHT:1, mode:10 cur_net.flags:0x40e
[ 35.115203] HTSetConnectBwMode():pHTInfo->bCurBW40MHz:0
[ 35.130497] ======>enter half N mode
[ 35.138997] Associated successfully
[ 35.139000] normal associate
[ 35.139008] Using G rates:108
[ 35.139009] Successfully associated, ht enabled
[ 35.139011] HTSetConnectBwMode():pHTInfo->bCurBW40MHz:0
[ 35.139353] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
[ 36.036847] dm_check_edca_turbo():iot peer is realtek_92se, bssid: 4c:ed:de:18:25:a2
[ 39.848432] RX: IEEE802.1X EAPOL frame!
[ 44.986068] RX: IEEE802.1X EAPOL frame!
[ 49.849483] disauth packet !

Steps to reproduce:
If using above wireless chipset upgrade kernel to 3.14.1-1

i will attempt to provide more info when i have access to that machine.
Comment 5 Neil McCirrus 2014-04-23 13:41:49 UTC
My AP is an ISP provided ADSL2+ Huawei HG521 firmware v.1.0.2
Comment 6 Larry Finger 2014-04-23 15:33:02 UTC
Are you also using wicd?
Comment 7 Neil McCirrus 2014-04-23 17:58:50 UTC
(In reply to Larry Finger from comment #6)
> Are you also using wicd?

Hi Larry
   Yes wicd here on archlinux x86_64
Comment 8 Alex Miller 2014-04-24 09:09:53 UTC
Created attachment 133531 [details]
wpa_supplicant log with kernel 3.14.1
Comment 9 Alex Miller 2014-04-24 09:11:26 UTC
Created attachment 133541 [details]
packet capture with kernel 3.14.1

Station MAC: 1c:65:9d:c9:2d:f0
AP MAC: 10:0D:7F:9C:5E:56
Comment 10 Alex Miller 2014-04-24 09:13:11 UTC
I have attached the wpa_supplicant log and a wireshark packet capture from trying to connect with kernel 3.14.1

I have removed wicd for now and I am starting the connection manually by running ifconfig ... up and then wpa_supplicant.
Comment 11 Larry Finger 2014-04-24 16:09:03 UTC
Created attachment 133581 [details]
Proposed patch No 1

Upon investigation, I see that the RTL8192SE has its V0 queue at the non-standard priority 6, not 7. This patch detects that condition, and makes a suitable change.
Comment 12 Larry Finger 2014-04-24 18:06:29 UTC
@Alex: One further question: Does the connection work after you removed wicd?
Comment 13 Alex Miller 2014-04-25 03:32:46 UTC
Hi Larry,

Without wicd I get the same behaviour.  Still no connection and the same messages in the logs.

I'm trying your patch now.
Comment 14 Alex Miller 2014-04-25 03:45:14 UTC
With your patch I now have a working connection.

I will replace wicd and test again, but I think it will be fine.

Thanks for your help in fixing this.

Comment 15 Alex Miller 2014-04-25 04:07:11 UTC
The connection is still fine with wicd.

Thanks again.
Comment 16 Larry Finger 2014-04-25 05:50:41 UTC
Glad I could help. I will push the patch as a fix.

Comment 17 ghost53947 2014-08-29 12:04:13 UTC
I tried the proposed patch. I see it is included in kernel 3.16 but I still cannot connect. Or with some kernels or distro's I can connect get an IP address. The interface is up and associated. But I cannot ping the gateway. I cannot ping any device on the network. Nor can any device ping me. No internet connectivety either. Is there no way to take the driver from the manufacture and modify it to compile on 3.x kernels? That driver worked.
Comment 18 ghost53947 2014-08-29 12:13:40 UTC
Works fine with a non encrypted wifi network. Wpa2 does not work well. Tested on G and N access points.
Comment 19 Larry Finger 2014-08-29 15:18:02 UTC
The latest vendor version, which will build on any kernel 3.0 or later, can be found at http://github.com/lwfinger/rtlwifi_new.git. Clone that repo, make and sudo make install. I have not yet gotten to testing rtl8192se yet (there are 10 different drivers), but the ones that I have tested seem to work well.

I am trying to get this code into kernel 3.18.
Comment 20 ghost53947 2014-08-31 00:26:15 UTC
I cloned the repo and tried building on two different machines. Here is the output http://privatepaste.com/31a6fa0ee0 it failed on both. I have the kernel headers installed. Both machines running arch linux on kernel 3.16-1
Comment 21 Larry Finger 2014-08-31 00:53:02 UTC
Sorry, the last fix was never pushed. Pull again - it should work now.
Comment 22 ghost53947 2014-08-31 09:15:51 UTC
Compilation worked. Installation without error. Still same issue. NetworkManager stays stuck at stage 4 of 5. What can I provide to see if its just my case or if the driver still has some issues. Archlinux users suggested I compile a kernel with this as a patch. Will post the result of that. Right now the module is loaded but I cannot see the device in ip link. Reloading the module did not help. Wireless interface still stays unknown to the system.
Comment 23 Larry Finger 2014-08-31 15:23:09 UTC
I have tested with the 1x1 version of the RTL8192SE (10ec:8171). It connected with my Netgear WNDR3400v2 running WPA2.

It will be quite difficult to add this driver as a patch to the kernel source. I'm doing that step now, and I expect it to take about 4 weeks to complete.

If the wireless interface is unknown using command iwconfig, then something is blocking. Is rfkill part of your standard configuration?

Load the module with 'sudo modprobe -v rtl8192se debug=3' and post the info logged in /var/log/messages, or in dmesg.
Comment 24 ghost53947 2014-08-31 17:37:25 UTC
I can add the driver as a patch in about 3 hours to the kernel and compile it. Just need to read up on how to make the patch. Modprobe reported that the firmware is too big.
Comment 25 Larry Finger 2014-08-31 19:10:23 UTC
It may take only a short time to do what you did, but my patches have to run scripts/checkpatch.pl with no errors, and not too many warnings or checks. For example, I am currently working on drivers/net/wireless/rtlwifi/btcoexist/halbtc8821a2ant.c. After about 4 hours, I have cleaned up about 25% of it.
Comment 26 leon.lewis 2015-02-06 13:03:13 UTC
Weell arch team was not that helpful in helping me patch my kernel. I am still having this issue with 3.18. With rtl8192se and rtl8192cu. I use the arch dkms packages.
Comment 27 Larry Finger 2015-02-06 15:22:40 UTC
The 3.19 kernel should be released this weekend. Get a copy of that source and try it. It certainly has all the latest patches for rtl8192se.
Comment 28 leon.lewis 2015-03-19 12:49:44 UTC
I finally got the 3.19 kernel in the arch core repo. It seems to fix the connection issues and if connect not having any network access. However after using it for and hour and a half NetworkManager told me that it lost connection to the device and after that happened I was no longer able to run a ip l, the command would hang. Trying to reboot the machine it was also hanging. I unplugged the device but no resolution came from that. Is this possibly related to the driver? If so which output would you like?
Comment 29 leon.lewis 2015-03-19 16:00:30 UTC
I finally got the 3.19 kernel in the arch core repo. It seems to fix the connection issues and if connect not having any network access. However after using it for and hour and a half NetworkManager told me that it lost connection to the device and after that happened I was no longer able to run a ip l, the command would hang. Trying to reboot the machine it was also hanging. I unplugged the device but no resolution came from that. Is this possibly related to the driver? If so which output would you like?
Comment 30 Larry Finger 2015-03-19 17:43:08 UTC
If you have unplugged the device, and the machine still cannot boot, then the Realtek driver is unlikely to be the problem, as it should not load in this situation.

You need to kill the boot animation (usually with the ESC key), and report the statement that fails on booting.
Comment 31 leon.lewis 2015-03-20 13:22:12 UTC
I guess I should have been more specific. I could not shutdown my computer. Even after remove the usb wifi card. This happened after NetworkManager reported that the device disconnected. Right now that hasn't happened again. However when I connect to a network I can surf the web and after a finite amount of time (while still connected) I can't surf anymore or ping the router anything. The exact same problem as before just now it takes some time to kick in.

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