Bug 74541

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?

Larry

Larry,

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?

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.

Larry

I too experiebce this ..

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

My AP is an ISP provided ADSL2+ Huawei HG521 firmware v.1.0.2

Are you also using wicd?

(In reply to Larry Finger from comment #6)
> Are you also using wicd?

Hi Larry
   Yes wicd here on archlinux x86_64

Created attachment 133531 [details]
wpa_supplicant log with kernel 3.14.1

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

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.

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.

@Alex: One further question: Does the connection work after you removed wicd?

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.

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.

Alex

The connection is still fine with wicd.

Thanks again.

Glad I could help. I will push the patch as a fix.

Larry

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.

Works fine with a non encrypted wifi network. Wpa2 does not work well. Tested on G and N access points.

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.

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

Sorry, the last fix was never pushed. Pull again - it should work now.

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.

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.

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.

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.

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.

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.

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?

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?

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.

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.