[Solved] rtl8188ce: unusable - dropping connection

Soukyuu · 2017-01-12 21:09:44

Looks like my "luck" for getting problematic hardware is as good as always.

I'm running a ThinkPad X220 laptop with a realtek 8188ce WiFi card. It is currently using the default kernel modules, with linux-firmware installed.

At first it appears to work fine, but the connection dies after a while even if you just continuously ping a server.

Pinging a local PC sometimes works fine and sometimes results in stuff like

PING 192.168.178.2 (192.168.178.2) 56(84) bytes of data.
64 bytes from 192.168.178.2: icmp_seq=1 ttl=64 time=102 ms
64 bytes from 192.168.178.2: icmp_seq=1 ttl=64 time=103 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=2 ttl=64 time=386 ms
64 bytes from 192.168.178.2: icmp_seq=2 ttl=64 time=386 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=3 ttl=64 time=3423 ms
64 bytes from 192.168.178.2: icmp_seq=3 ttl=64 time=3423 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=4 ttl=64 time=2407 ms
64 bytes from 192.168.178.2: icmp_seq=4 ttl=64 time=2407 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=5 ttl=64 time=1399 ms
64 bytes from 192.168.178.2: icmp_seq=5 ttl=64 time=1399 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=6 ttl=64 time=386 ms
64 bytes from 192.168.178.2: icmp_seq=6 ttl=64 time=386 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=7 ttl=64 time=103 ms
64 bytes from 192.168.178.2: icmp_seq=7 ttl=64 time=104 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=8 ttl=64 time=277 ms
64 bytes from 192.168.178.2: icmp_seq=8 ttl=64 time=585 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=9 ttl=64 time=106 ms
64 bytes from 192.168.178.2: icmp_seq=9 ttl=64 time=107 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=10 ttl=64 time=231 ms
64 bytes from 192.168.178.2: icmp_seq=10 ttl=64 time=424 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=11 ttl=64 time=103 ms
64 bytes from 192.168.178.2: icmp_seq=11 ttl=64 time=103 ms (DUP!)

Pinging a remote server usually results in high packet loss:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=8 ttl=50 time=44.5 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=50 time=1057 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=50 time=320 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=50 time=1054 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=50 time=1103 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=50 time=130 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=50 time=1278 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=50 time=279 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=50 time=130 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=50 time=335 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=50 time=131 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=50 time=278 ms

The longer it runs, the worse it gets. In the end the card just deauthenticates:

wlp3s0: deauthenticated from 38:10:d5:f2:41:a1 (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA)

Rebooting helps for about 2 minutes.

Things I tried:
- disabling power management -> no change

systool -v -m rtl8192ce
Module = "rtl8192ce"

  Attributes:
    coresize            = "53248"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "0"
    taint               = ""
    uevent              = <store method only>

  Parameters:
    debug               = "0"
    fwlps               = "N"
    ips                 = "N"
    swenc               = "Y"
    swlps               = "N"

- using rtlwifi_new-dkms from AUR -> no change in behavior
- using 8192cu-dkms from AUR -> not loading for my card
- using this: https://github.com/FreedomBen/rtl8188ce-linux-driver -> install script reported system is still using the stock drivers. Also tried "manual" make && make install, no change.

This is the first realtek chip that does not work out of the box for me. But looking around the internet, it seems they are actually famous for not working. Just my luck, eh?

Any suggestions?

Last edited by Soukyuu (2017-02-05 16:16:33)

ninian · 2017-01-13 10:11:13

Slightly different chipset, but could be same NetworkManger problem, if you use it?

lemniscattaden · 2017-01-13 19:09:36

I had same problem with my RTL8192CU. The problem was that two conflicting kernel modules was loaded for single device: rtl8192cu, rtl8xxxu. For my RTL8192CU works normal module is rtl8xxxu. rtl8192cu was blacklisted in /etc/modprobe.d/blacklist.conf:
blacklist rtl8192cu

Soukyuu · 2017-01-14 15:27:01

@lemniscattaden: the rtl8xxxu is for the USB version of the chipset - it does not load for me. But thanks for the hint.

@ninian: I think it was partially it, setting that option improved stability a bit.

However, I am still having problems with duplicate ping and it randomly starting to just time out, so it doesn't seem to be it.

To make sure it's not NetworkManager, I have switched to systemd-networkd + wpa_supplicant.
I am still having the same issues.

edit: interestingly, even though the pings get lost, ifconfig does not list them as being dropped.

Last edited by Soukyuu (2017-01-14 15:27:53)

Soukyuu · 2017-01-23 18:44:04

I still haven't been able to solve this. I've also tried ndiswrapper, but it fails to load the realtek driver with symbol import errors. From what I gathered on the net, the driver is not compatible with ndiswrapper - I've tried all x64 windows driver versions I could find, so that's no option either.

Any other suggestions I could try?

JohnBobSmith · 2017-01-23 18:56:51

Ndiswrapper is a terrible solution. It has a very high potential to cause further breakages, and should never be needed for more recent linux distributions, especially arch. Some things that haven't been mentioned yet are your signal strength/interference and kernel. For your kernel, which kernel are you currently using? You may want to try the -lts release and see if that helps. For the interference part, my network would always die completely (still does...) whenever a microwave was on. Do you have to go through any cement floors or large distances, that type of stuff? While I have no doubt that your troubles are driver related (trust me, I have a problematic card too, the ralinkrt3290), it's always important to rule out other, likely simpler causes. You wouldn't want to rip apart your OS only to find that moving the router 3 feet solved most of everything. Been there, done that...

Soukyuu · 2017-01-24 17:12:53

Well, last time I had a hard time with an atheros card, ndiswrapper worked like a charm, so it was worth a try.

I am literally 1m away from the nearest access point, it's in the same room. Also, all other WLAN devices have no problems whatsoever, plus the same hardware works well on windows - so that shouldn't be it. I'm currently on the latest stable kernel, 4.8.13. I just tried the current lts kernel, and it seems to work better - thanks for the hint. I'll monitor it for a while, but if a newer kernel broke my card, then it's bug reporting time...

severach · 2017-01-24 19:17:27

Soukyuu wrote:

The longer it runs, the worse it gets. In the end the card just deauthenticates:

Sounds like heat to me. What I find with Realtek Wifi is that the chips overheat and stop working. Can't be fixed by drivers.

Any chance you can switch to another brand like Atheros, Ralink or Intel? Even a USB mini would be better than what you have.

The Wikidevi is the only sane way to figure out what card will work for you.

Last edited by severach (2017-01-24 19:17:48)

Soukyuu · 2017-01-24 21:05:30

It's not heat - the laptops is very cool around the area the card resides in. I've also been running LTS for a few hours now, no WLAN issues anymore. It seems to be a regression in the recent kernels. I wonder if I should report that at the kernel bugzilla or if reporting it at the rtlwifi_new repo is more fitting.

JohnBobSmith · 2017-01-24 23:22:55

I'm glad the lts kernel has helped you, even if only slightly. I would submit a bug report to both the rtlwifi repository and the kernel. It shouldn't be redundant, given this affects both code bases, and both of them may be at fault until proven otherwise.

seth · 2017-01-25 08:57:50

Why do the parameters say "Y" and "N"? Should be "0" and "1" and if that isn't a display bug, "N" would likely be treated as "1", so this may be bad power saving?

luc · 2017-01-31 21:09:24

I will join this thread as I have very similar hardware (ThinkPad X220 + RTL8188CE) and the same problem (unstable connection, wpa_supplicant de authenticating), I hope you are fine with it and I don't violate any etiquette.

@Soukyuu: Do you still run the LTS kernel, does it help? And as you have the same chip as me: what kernel modules are you loading? I reviewed mine and get this:

$ lsmod|grep rtl
btrtl                  16384  1 btusb
bluetooth             499712  5 btrtl,btintel,btbcm,btusb
rtl8192ce              53248  0
rtl_pci                28672  1 rtl8192ce
rtl8192c_common        45056  1 rtl8192ce
rtlwifi                65536  3 rtl_pci,rtl8192ce,rtl8192c_common
mac80211              688128  3 rtl_pci,rtl8192ce,rtlwifi
cfg80211              516096  2 mac80211,rtlwifi

(Further remarks:
- I used netctl{,-auto} but the problem also occurs with plain wpa_supplicant+dhcpcd)
- it seems to be the OS (and not the hardware) as the live usb can use the card just fine
- until now I was running the vanilla kernel (4.9.6-1) I am trying the lts (4.4.45-1) right now, not successful yet
)

Soukyuu · 2017-01-31 23:07:50

Yes, for me LTS in it's current version works fine. Current 4.9.6 only really works if I set the "fwlps=0" module option. There also seems to be a bug that loads the wrong firmware for some chipsets, as mentioned here. I'm not really too thrilled about having to disable power management for wifi, but I guess that's better than not having working wifi at all.

luc · 2017-02-01 13:14:42

Thank you very much. I read through the github issue and am now running kernel 4.9.6 with the aur package rtlwifi_new-dkms and

options rtl8192ce_dkms fwlps=0

in /etc/modprobe.d/rtl8192ce.conf

This at least works for normal usage. (If I ping different sites I get around 15-20% package loss.)

I will try the lts kernel later.

loqs · 2017-02-04 08:45:18

https://bbs.archlinux.org/viewtopic.php?id=222679 seems to be the same issue fixed by applying patch to load correct firmware.

Soukyuu · 2017-02-04 15:19:11

The rtlwifi_new repo rtlwifi_new-dkms AUR package is based on already has this patch applied. I just installed it and I have 0% packet loss without any additional kernel module options enabled, running the current kernel.

I have also checked dmesg and running the stock kernel modules loaded the firmware with the capital U in it. The patched module loads the one without the capital U in it, just as in the thread linked by loqs - so it seems to be the same issue, indeed.

alfonsofernandezyf · 2017-07-13 01:05:12

ninian wrote:

Slightly different chipset, but could be same NetworkManger problem, if you use it?

This worked for me. I'm running Antergos Linux with 4.11.9-1-ARCH and RTL8188ce.

I added

[device]
wifi.scan-rand-mac-address=no

to /etc/NetworkManager/NetworkManager.conf and rebooted.

I'm using the default kernel drivers

$ lsmod | grep rtl
btrtl                  16384  1 btusb
bluetooth             487424  31 btrtl,btintel,bnep,btbcm,rfcomm,btusb
rtl8192ce              57344  0
rtl_pci                32768  1 rtl8192ce
rtl8192c_common        45056  1 rtl8192ce
rtlwifi                65536  3 rtl_pci,rtl8192ce,rtl8192c_common
mac80211              696320  3 rtl_pci,rtl8192ce,rtlwifi
cfg80211              520192  2 mac80211,rtlwifi

Arch Linux

#1 2017-01-12 21:09:44

[Solved] rtl8188ce: unusable - dropping connection

#2 2017-01-13 10:11:13

Re: [Solved] rtl8188ce: unusable - dropping connection

#3 2017-01-13 19:09:36

Re: [Solved] rtl8188ce: unusable - dropping connection

#4 2017-01-14 15:27:01

Re: [Solved] rtl8188ce: unusable - dropping connection

#5 2017-01-23 18:44:04

Re: [Solved] rtl8188ce: unusable - dropping connection

#6 2017-01-23 18:56:51

Re: [Solved] rtl8188ce: unusable - dropping connection

#7 2017-01-24 17:12:53

Re: [Solved] rtl8188ce: unusable - dropping connection

#8 2017-01-24 19:17:27

Re: [Solved] rtl8188ce: unusable - dropping connection

#9 2017-01-24 21:05:30

Re: [Solved] rtl8188ce: unusable - dropping connection

#10 2017-01-24 23:22:55

Re: [Solved] rtl8188ce: unusable - dropping connection

#11 2017-01-25 08:57:50

Re: [Solved] rtl8188ce: unusable - dropping connection

#12 2017-01-31 21:09:24

Re: [Solved] rtl8188ce: unusable - dropping connection

#13 2017-01-31 23:07:50

Re: [Solved] rtl8188ce: unusable - dropping connection

#14 2017-02-01 13:14:42

Re: [Solved] rtl8188ce: unusable - dropping connection

#15 2017-02-04 08:45:18

Re: [Solved] rtl8188ce: unusable - dropping connection

#16 2017-02-04 15:19:11

Re: [Solved] rtl8188ce: unusable - dropping connection

#17 2017-07-13 01:05:12

Re: [Solved] rtl8188ce: unusable - dropping connection

Board footer