Since kernel 3.15.x (used to work until 3.14.x) the wireless device rtl8188e doesn't work at all. It shows available wireless networks but when I try to connect to my home wireless network keeps trying to connect (and never acomplishes to connect). lspci: 07:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01) 08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 07) Until 3.14.x it worked. No config change or anything else. I run Arch Linux.
Tested with 3.16 rc1 and seems that it works. Expecting somebody to fix the bug to the stable kernel
What bug? The driver has worked with every kernel update since it was added to 3.10. You will have to be a lot more specific. Perhaps the difference is that I use NetworkManager. What wireless control method are you using?
I also use NetworkManager. The problem is that it tries to connect but at the end fails. I will test it out another time with the 3.15.1. Anyway works good on 3.16rc1
OK. Now it connects. But the connection is slower with 3.15.1. 3.16rc1 seems to work fine.
I rechecked and with 3.15.2 the network (wifi) is very unstable. Probably related bug from redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1108801
Another user and myself have been experiencing issues with the Realtek 8188EE as well. I was able to connect to networks, however it kept disconnecting. There's some information (dmesg) here : https://bbs.archlinux.org/viewtopic.php?id=183886
With kernel 3.15.5-1-ARCH, to the best of my knowledge it is not using the backported drivers from 3.16-rc1 Connecting to Library Wifi, econnman's indicator stays orange. On atk9 this did not happen. It would be green. There is no requirement to sign into this particular wifi network. I should also note that this library's wifi is particular strong. At this point in time, I'm about maybe 20~30 feet away from the nearest wireless relay. iwconfig reports that the signal level is varying between 20, 30,-40 and -68 dBm. `connmanctl also displays this when I check the services avaiable : *AR PawtLibraryEast wifi_645a045b2005_506177744c69627261727945617374_managed_none I'm not sure what the AR stands for, but with the atk9 chip in, it would say *AO. Perhaps this oddity with econnman/connman are bugs within the respective projects. However, connecting to various irc networks and a large amount of channels is possible. I noticed in `iwconfig` that Invalid misc at 27...for now. I pinged google.com 50 times. The results : --- google.com ping statistics --- 50 packets transmitted, 46 received, 8% packet loss, time 58029ms rtt min/avg/max/mdev = 10.372/75.281/799.489/125.141 ms `iwconfig` wlp5s0 IEEE 802.11bgn ESSID:"PawtLibraryEast" Mode:Managed Frequency:2.412 GHz Access Point: [removed] Bit Rate=65 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:off Link Quality=70/70 Signal level=-40 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:69 Missed beacon:0 `ifconfig` wlp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.95.38.213 netmask 255.255.255.0 broadcast 10.95.38.255 inet6 fe80::665a:4ff:fe5b:2005 prefixlen 64 scopeid 0x20<link> ether 64:5a:04:5b:20:05 txqueuelen 1000 (Ethernet) RX packets 21723 bytes 3516045 (3.3 MiB) RX errors 0 dropped 2971 overruns 0 frame 0 TX packets 3627 bytes 339862 (331.8 KiB) TX errors 0 dropped 0 overruns 0 carrier Using kernel 3.15.5...when I launched firefox to read through the Arch Wiki, the wifi started to act up. Before this, there hadn't been a problem for almost an hour and thirty two minutes...though at this point, the econnman indicator turned from orange to green and connmanctl had AO instead of AR. [Sat Jul 12 15:29:17 2014] wlp5s0: Connection to AP b8:a3:86:b2:08:90 lost [Sat Jul 12 15:29:17 2014] cfg80211: Calling CRDA for country: US [Sat Jul 12 15:29:17 2014] IPv6: ADDRCONF(NETDEV_UP): wlp5s0: link is not ready [Sat Jul 12 15:29:19 2014] wlp5s0: authenticate with b8:a3:86:b2:08:90 [Sat Jul 12 15:29:19 2014] wlp5s0: send auth to b8:a3:86:b2:08:90 (try 1/3) [Sat Jul 12 15:29:19 2014] wlp5s0: authenticated [Sat Jul 12 15:29:19 2014] wlp5s0: associate with b8:a3:86:b2:08:90 (try 1/3) [Sat Jul 12 15:29:19 2014] wlp5s0: RX AssocResp from b8:a3:86:b2:08:90 (capab=0x421 status=0 aid=6) [Sat Jul 12 15:29:19 2014] wlp5s0: associated [Sat Jul 12 15:29:19 2014] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready However, this only occurred once. While I'm writing up this message, I'm also compiling kernel 3.16-rc1 to see if there are any improvements, as reported by Roger. However, I may not be able to report my findings until Monday, at the latest.
With kernel 3.16-rc1, I no longer get a bunch of messages in dmesg, related to disconnections. The only thing I noticed in dmesg, was this : [Sat Jul 12 15:49:01 2014] rtl8188ee:rtl88ee_set_hw_reg():<0-0> switch case not process 5c `iwconfig` wlp5s0 IEEE 802.11bgn ESSID:"PawtLibraryEast" Mode:Managed Frequency:2.412 GHz Access Point: [removed] Bit Rate=65 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:off Link Quality=70/70 Signal level=-12 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:5184 Missed beacon:0 `ifconfig` wlp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.95.38.213 netmask 255.255.255.0 broadcast 10.95.38.255 inet6 fe80::665a:4ff:fe5b:2005 prefixlen 64 scopeid 0x20<link> ether 64:5a:04:5b:20:05 txqueuelen 1000 (Ethernet) RX packets 368345 bytes 505791362 (482.3 MiB) RX errors 0 dropped 900 overruns 0 frame 0 TX packets 223119 bytes 18168899 (17.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 It seems better...
My system has been up for roughly 60,000 seconds without any disconnects using kernel 3.16-rc2 from the wireless-testing git repo. The encryption is WPA2-AES. My ifconfig: wlp2s0 Link encap:Ethernet HWaddr 00:E0:4C:01:E0:F9 inet addr:192.168.1.121 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:4cff:fe01:e0f9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:112926 errors:0 dropped:0 overruns:0 frame:0 TX packets:19323 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:21504701 (20.5 Mb) TX bytes:2835872 (2.7 Mb) iwconfig: wlp2s0 IEEE 802.11bgn ESSID:"NETGEAR81" Mode:Managed Frequency:2.437 GHz Access Point: 20:E5:2A:01:F7:EA Bit Rate=72.2 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:off Link Quality=62/70 Signal level=-48 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:5122 Missed beacon:0
Using 3.16-rc1 I get this at school... (several times) [Mon Jul 14 15:00:11 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 15:00:28 2014] wlp5s0: authenticate with 00:1f:26:29:09:d1 [Mon Jul 14 15:00:28 2014] wlp5s0: send auth to 00:1f:26:29:09:d1 (try 1/3) [Mon Jul 14 15:00:28 2014] cfg80211: Calling CRDA for country: US [Mon Jul 14 15:00:28 2014] wlp5s0: authenticated [Mon Jul 14 15:00:28 2014] wlp5s0: associate with 00:1f:26:29:09:d1 (try 1/3) [Mon Jul 14 15:00:28 2014] wlp5s0: RX AssocResp from 00:1f:26:29:09:d1 (capab=0x421 status=0 aid=20) [Mon Jul 14 15:00:28 2014] rtl8188ee:rtl88ee_set_hw_reg():<0-0> switch case not process 5c [Mon Jul 14 15:00:28 2014] wlp5s0: associated [Mon Jul 14 15:00:40 2014] wlp5s0: authenticate with 00:1f:26:29:01:21 [Mon Jul 14 15:00:40 2014] wlp5s0: send auth to 00:1f:26:29:01:21 (try 1/3) [Mon Jul 14 15:00:40 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 15:00:40 2014] wlp5s0: authenticated [Mon Jul 14 15:00:40 2014] wlp5s0: associate with 00:1f:26:29:01:21 (try 1/3) [Mon Jul 14 15:00:40 2014] wlp5s0: RX AssocResp from 00:1f:26:29:01:21 (capab=0x421 status=0 aid=5) [Mon Jul 14 15:00:40 2014] rtl8188ee:rtl88ee_set_hw_reg():<0-0> switch case not process 5c [Mon Jul 14 15:00:40 2014] wlp5s0: associated [Mon Jul 14 15:00:40 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 15:00:57 2014] wlp5s0: authenticate with 00:1f:26:29:09:d1 [Mon Jul 14 15:00:57 2014] wlp5s0: send auth to 00:1f:26:29:09:d1 (try 1/3) [Mon Jul 14 15:00:57 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 15:00:57 2014] wlp5s0: authenticated [Mon Jul 14 15:00:57 2014] wlp5s0: associate with 00:1f:26:29:09:d1 (try 1/3) [Mon Jul 14 15:00:57 2014] wlp5s0: RX AssocResp from 00:1f:26:29:09:d1 (capab=0x421 status=0 aid=20) [Mon Jul 14 15:00:57 2014] rtl8188ee:rtl88ee_set_hw_reg():<0-0> switch case not process 5c [Mon Jul 14 15:00:57 2014] wlp5s0: associated [Mon Jul 14 15:00:57 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 15:01:07 2014] wlp5s0: authenticate with 00:1f:26:29:01:21 [Mon Jul 14 15:01:07 2014] wlp5s0: send auth to 00:1f:26:29:01:21 (try 1/3) [Mon Jul 14 15:01:07 2014] cfg80211: Calling CRDA for country: US [Mon Jul 14 15:01:07 2014] wlp5s0: authenticated [Mon Jul 14 15:01:07 2014] wlp5s0: associate with 00:1f:26:29:01:21 (try 1/3) [Mon Jul 14 15:01:07 2014] wlp5s0: RX AssocResp from 00:1f:26:29:01:21 (capab=0x421 status=0 aid=5) [Mon Jul 14 15:01:07 2014] rtl8188ee:rtl88ee_set_hw_reg():<0-0> switch case not process 5c [Mon Jul 14 15:01:07 2014] wlp5s0: associated It doesn't cut out, but I think it does slow down. I'll be testing on 3.16-rc2 from the wireless-testing repo soon.
It does eventually disconnect : [Mon Jul 14 15:08:23 2014] wlp5s0: send auth to 00:1f:26:29:09:d1 (try 1/3) [Mon Jul 14 15:08:23 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 15:08:23 2014] wlp5s0: send auth to 00:1f:26:29:09:d1 (try 2/3) [Mon Jul 14 15:08:23 2014] wlp5s0: send auth to 00:1f:26:29:09:d1 (try 3/3) [Mon Jul 14 15:08:23 2014] wlp5s0: authentication with 00:1f:26:29:09:d1 timed out [Mon Jul 14 15:08:23 2014] IPv6: ADDRCONF(NETDEV_UP): wlp5s0: link is not ready [Mon Jul 14 15:08:24 2014] wlp5s0: authenticate with 00:1f:26:29:01:21 [Mon Jul 14 15:08:24 2014] wlp5s0: send auth to 00:1f:26:29:01:21 (try 1/3) [Mon Jul 14 15:08:24 2014] wlp5s0: send auth to 00:1f:26:29:01:21 (try 2/3) [Mon Jul 14 15:08:24 2014] wlp5s0: send auth to 00:1f:26:29:01:21 (try 3/3) [Mon Jul 14 15:08:24 2014] wlp5s0: authentication with 00:1f:26:29:01:21 timed out [Mon Jul 14 15:09:03 2014] wlp5s0: authenticate with 00:1f:26:29:0a:51 [Mon Jul 14 15:09:03 2014] wlp5s0: direct probe to 00:1f:26:29:0a:51 (try 1/3) [Mon Jul 14 15:09:04 2014] wlp5s0: direct probe to 00:1f:26:29:0a:51 (try 2/3) [Mon Jul 14 15:09:04 2014] wlp5s0: direct probe to 00:1f:26:29:0a:51 (try 3/3) [Mon Jul 14 15:09:04 2014] wlp5s0: authentication with 00:1f:26:29:0a:51 timed out
I still get the constant stream of messages related to wlp5s0 in `dmesg` but overall on rc2 it seems a lot better. It only disconnected once, after about 45 minutes of uptime, but then immediately reconnected without any action from me.
It later disconnected a few minutes afterwards, [Mon Jul 14 17:09:18 2014] wlp5s0: deauthenticating from 00:1c:f9:c3:25:c1 by local choice (Reason: 2=PREV_AUTH_NOT_VALID) [Mon Jul 14 17:09:18 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 17:09:18 2014] wlp5s0: authenticate with 00:1c:f9:c3:25:c1 [Mon Jul 14 17:09:18 2014] wlp5s0: send auth to 00:1c:f9:c3:25:c1 (try 1/3) [Mon Jul 14 17:09:18 2014] wlp5s0: authenticated [Mon Jul 14 17:09:18 2014] wlp5s0: associate with 00:1c:f9:c3:25:c1 (try 1/3) [Mon Jul 14 17:09:18 2014] wlp5s0: RX AssocResp from 00:1c:f9:c3:25:c1 (capab=0x421 status=0 aid=2) [Mon Jul 14 17:09:18 2014] wlp5s0: associated [Mon Jul 14 17:09:18 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 17:09:19 2014] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready [Mon Jul 14 17:09:28 2014] wlp5s0: deauthenticating from 00:1c:f9:c3:25:c1 by local choice (Reason: 3=DEAUTH_LEAVING) [Mon Jul 14 17:09:28 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 17:09:48 2014] IPv6: ADDRCONF(NETDEV_UP): wlp5s0: link is not ready [Mon Jul 14 17:09:49 2014] wlp5s0: authenticate with 00:1c:f9:c3:25:c1 [Mon Jul 14 17:09:49 2014] wlp5s0: send auth to 00:1c:f9:c3:25:c1 (try 1/3) [Mon Jul 14 17:09:49 2014] wlp5s0: authenticated [Mon Jul 14 17:09:49 2014] wlp5s0: associate with 00:1c:f9:c3:25:c1 (try 1/3) [Mon Jul 14 17:09:49 2014] wlp5s0: RX AssocResp from 00:1c:f9:c3:25:c1 (capab=0x421 status=0 aid=2) [Mon Jul 14 17:09:49 2014] wlp5s0: associated [Mon Jul 14 17:09:49 2014] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready [Mon Jul 14 17:09:49 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Jul 14 17:10:30 2014] wlp5s0: authenticate with 00:1d:46:7c:42:b1 [Mon Jul 14 17:10:30 2014] wlp5s0: direct probe to 00:1d:46:7c:42:b1 (try 1/3) [Mon Jul 14 17:10:30 2014] cfg80211: Calling CRDA for country: US [Mon Jul 14 17:10:31 2014] wlp5s0: send auth to 00:1d:46:7c:42:b1 (try 2/3) [Mon Jul 14 17:10:31 2014] wlp5s0: send auth to 00:1d:46:7c:42:b1 (try 3/3) [Mon Jul 14 17:10:32 2014] wlp5s0: authentication with 00:1d:46:7c:42:b1 timed out [Mon Jul 14 17:10:32 2014] IPv6: ADDRCONF(NETDEV_UP): wlp5s0: link is not ready [Mon Jul 14 17:10:33 2014] wlp5s0: authenticate with 00:1c:f9:c3:25:c1 [Mon Jul 14 17:10:33 2014] wlp5s0: send auth to 00:1c:f9:c3:25:c1 (try 1/3) [Mon Jul 14 17:10:33 2014] wlp5s0: authenticated [Mon Jul 14 17:10:33 2014] wlp5s0: associate with 00:1c:f9:c3:25:c1 (try 1/3) [Mon Jul 14 17:10:33 2014] wlp5s0: RX AssocResp from 00:1c:f9:c3:25:c1 (capab=0x421 status=0 aid=2) [Mon Jul 14 17:10:33 2014] wlp5s0: associated I am quite close to the nearest wireless relay in an empty classroom...
Hmm. Kernel 3.16-rc2. It disconnects frequently. [Thu Jul 17 13:04:02 2014] wlp5s0: authenticate with 00:1f:26:29:01:21 [Thu Jul 17 13:04:02 2014] wlp5s0: send auth to 00:1f:26:29:01:21 (try 1/3) [Thu Jul 17 13:04:02 2014] cfg80211: Calling CRDA to update world regulatory domain [Thu Jul 17 13:04:02 2014] wlp5s0: authenticated [Thu Jul 17 13:04:02 2014] wlp5s0: associate with 00:1f:26:29:01:21 (try 1/3) [Thu Jul 17 13:04:02 2014] wlp5s0: RX AssocResp from 00:1f:26:29:01:21 (capab=0x421 status=0 aid=24) [Thu Jul 17 13:04:02 2014] wlp5s0: associated This just keeps repeating in dmesg. Though it changed to this and didn't come back afterwards... [Thu Jul 17 13:09:18 2014] wlp5s0: deauthenticating from 00:1f:26:29:01:21 by local choice (Reason: 2=PREV_AUTH_NOT_VALID) [Thu Jul 17 13:09:19 2014] wlp5s0: deauthenticating from 00:1f:26:29:01:21 by local choice (Reason: 3=DEAUTH_LEAVING)
Kernel 3.16.0-rc5-wl (from the wireless-testing repo...) commit : There are a few different networks I connect to during the day. The wireless network at school, no security enabled. Two WEP enabled networks at home, (though their signals are weaker...) (There is a third, but that one is undergoing changes...that one also happens to be the strongest one...) And finally, the local library's network, which has no security. The wireless adapter has issues at the school, (and at the library in the school, unless I'm really close to a wireless relay...) But my tablet has no issues connecting and staying connected, and as of yesterday, neither does Windows 8.1. At home, 3 (2 running Windows 8 and one Windows 7, though sometimes Arch Linux) other laptops, and my tablet, have no issues connecting, and staying connected to the weaker routers. Except this laptop. And then there's the local library. Usually I'm somewhat close to a wireless relay, but today not so much. The library has two networks, I guess each must be for each floor. Usually on the days I'm upstairs, it works fine. I'm downstairs today, and in a study room. I get : [Fri Jul 18 10:44:36 2014] wlp5s0: deauthenticated from b8:a3:86:b2:08:90 (Reason: 2=PREV_AUTH_NOT_VALID) [Fri Jul 18 10:44:49 2014] wlp5s0: deauthenticating from b8:a3:86:b2:08:90 by local choice (Reason: 3=DEAUTH_LEAVING) I can't get a real idea of the PWR level of the routers. airodump fluctuates way too much. Anything else I can do to (hopefully) get this wireless adapter working almost flawlessly? Debug info from `iw` ? In the meantime, I'm going to checkout commit 4a79e9ac8b12ff617786852eee41e463216b48ff and see if that makes any difference. *a few hours later...* Now testing on the kernel from wireless-testing, commit 4a79e9ac8b12ff617786852eee41e463216b48ff. I've moved the second floor of the library. It _seems_ better. `iw dev wlp5s0 link` reports that the signal is around 40dBm. Jumps around sometimes. So far, nothing in dmesg...
crap, forgot to include the commit I was at for kernel 3.16.0-rc5 commit : 1dabe76c348f9ced521e412b9bd63ee5ec4924fd
(In reply to Yomi from comment #15) > Kernel 3.16.0-rc5-wl (from the wireless-testing repo...) > commit : > > There are a few different networks I connect to during the day. > The wireless network at school, no security enabled. > Two WEP enabled networks at home, (though their signals are weaker...) > (There is a third, but that one is undergoing changes...that one also > happens to be the strongest one...) > And finally, the local library's network, which has no security. > > The wireless adapter has issues at the school, (and at the library in the > school, unless I'm really close to a wireless relay...) > But my tablet has no issues connecting and staying connected, and as of > yesterday, neither does Windows 8.1. > > At home, 3 (2 running Windows 8 and one Windows 7, though sometimes Arch > Linux) other laptops, and my tablet, have no issues connecting, and staying > connected to the weaker routers. Except this laptop. > > And then there's the local library. Usually I'm somewhat close to a wireless > relay, but today not so much. > The library has two networks, I guess each must be for each floor. > > Usually on the days I'm upstairs, it works fine. I'm downstairs today, and > in a study room. > > I get : > [Fri Jul 18 10:44:36 2014] wlp5s0: deauthenticated from b8:a3:86:b2:08:90 > (Reason: 2=PREV_AUTH_NOT_VALID) > [Fri Jul 18 10:44:49 2014] wlp5s0: deauthenticating from b8:a3:86:b2:08:90 > by local choice (Reason: 3=DEAUTH_LEAVING) > > I can't get a real idea of the PWR level of the routers. airodump fluctuates > way too much. > > Anything else I can do to (hopefully) get this wireless adapter working > almost flawlessly? Debug info from `iw` ? > > In the meantime, I'm going to checkout commit > 4a79e9ac8b12ff617786852eee41e463216b48ff and see if that makes any > difference. > > *a few hours later...* > > Now testing on the kernel from wireless-testing, commit > 4a79e9ac8b12ff617786852eee41e463216b48ff. > > I've moved the second floor of the library. > It _seems_ better. > `iw dev wlp5s0 link` reports that the signal is around 40dBm. > Jumps around sometimes. So far, nothing in dmesg... Is it usable with this last patch? It would be great to know that at least when 3.16 turns stable we will have a stable wifi connection.
It _seems_ usable. Speed is another issue, but that might be because of the number of people connected at the library currently. I'm just wondering how it'll perform at school. The previous experiences make me think it'll just start acting up again, but I won't know till I try.
Tested at home. It connects, and stays connected, but it disconnects with : reason 4: Disassociated due to inactivity. (from iw event -f) However, not as nearly as frequently as before. @Larry Finger. I'm sorry if this is a whole bunch of information that you have sift through. Probably won't mean much now, but I'm also sorry for filling up this bug report with all that information. I should have known... I don't want to assume, but if I had to guess from that post in the other bug opened about the rtl8188ee, I'd guess and say that's why you stopped responding here. So...I'll ask again, what can I do to help with this?
(In reply to Roger from comment #17) > Is it usable with this last patch? It would be great to know that at least > when 3.16 turns stable we will have a stable wifi connection. Roger : Sort of usable at my house / Works fine at the library. It isn't usable at all on campus though. They have a bunch of routers spread across the school to make sure everywhere is covered, but somehow I seem to get connected to the ones with less signal strength. (At least, it seems like that is what is happening, from what I can gather anyway...)
It is certainly possible that the driver is really bad at roaming, and that it is picking an AP very badly. If you use NetworkManager, you can always specify a BSSID (MAC address) as well as an SSID. That will lock you to a particular AP.
(In reply to Larry Finger from comment #21) > It is certainly possible that the driver is really bad at roaming, and that > it is picking an AP very badly. > > If you use NetworkManager, you can always specify a BSSID (MAC address) as > well as an SSID. That will lock you to a particular AP. According to the people in #connman, connman should handle that automatically. I was a bit of a loss of what to do next, so I decided to test with another wireless adapter, and it works nearly flawlessly. It's an Atheros. However, this isn't ideal, as the Atheros has two antenna connectors while the Realtek only has one connector. I imagine it has an adverse effect on signal strength. For now, I'll be switching back to the Realtek adapter and testing all commits affecting drivers/net/wifi/rtlwifi/rtl8188ee. I'll avoid overloading this bug report and simply provide commit ID's with a Good/Flaky/Bad message in one post. Or at least, that's the plan... Any suggestions, Larry? Also, things seem to get flaky with the rtl8188ee if I'm around -60 to -80dBm IIRC. I'll try to get a specific number, if possible.
Tried the connection with the recent 3.16 kernel. This bug was opened because on 3.15.x the wireless connection dropped quite often. As of 3.16 this doesn't happen, so I will mark this bug as fixed. This doesn't mean that now the drivers works flawlessly, actually It seems (difficult to test) that the connection speed is slower than before.
(In reply to Roger from comment #23) > Tried the connection with the recent 3.16 kernel. This bug was opened > because on 3.15.x the wireless connection dropped quite often. As of 3.16 > this doesn't happen, so I will mark this bug as fixed. This doesn't mean > that now the drivers works flawlessly, actually It seems (difficult to test) > that the connection speed is slower than before. Compiled 3.16 from the wireless testing repo. Tested on a network where it had trouble before, seems fine now. I'm not too sure if the connection speed is slower for me... --- google.com ping statistics --- 100 packets transmitted, 97 received, 3% packet loss, time 107887ms rtt min/avg/max/mdev = 12.477/47.516/305.344/57.239 ms Any idea what fixed it?
Hmm. I spoke too soon. It doesn't _seem_ slower, however the speed does seem to fluctuate quite a bit when downloading packages...it'll get really low, then high, then low...and so on...
No idea what fixed it, there are a lot of commits to rtl8188ee that clean the code, though. Speed connection is difficult to test although I think this device has never worked very well in terms of speed. I have the same problem as you, when browsing the web speed seems unstable (fluctuate). I opened a bug with a more related title: https://bugzilla.kernel.org/show_bug.cgi?id=81671
This is odd. Worked fine at another library, a library that it previously acted up with. But now I'm on campus and it's disconnecting again. If this keeps happening, is there any information I can provide you with? Or should I consider the possibility that there's something different with this network that is causing this problem?
(In reply to Yomi from comment #27) > This is odd. > Worked fine at another library, a library that it previously acted up with. > > But now I'm on campus and it's disconnecting again. > > If this keeps happening, is there any information I can provide you with? > > Or should I consider the possibility that there's something different with > this network that is causing this problem? I should clarify, it isn't disconnecting. Rather, it is repeatedly authenticating and associating with one particular AP, AFAICT.
What is the deauthentication reason? Please give me something to work with. You will find that information in the dmesg output. As I am not sure how long it will take to get the new Realtek drivers into a form that can be merged with the kernel, and I am rapidly losing motivation, I have created a new repo at GitHub.com containing the new code. You can get a copy by git clone http://github.com/lwfinger/rtlwifi_new.git It should build on any kernel 3.0 of newer.
The only deauthencation message I got was : [Mon Aug 4 17:51:04 2014] wlp5s0: deauthenticated from 58:f3:9c:e8:4a:01 (Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA) Everything else in dmesg is : [Mon Aug 4 17:48:53 2014] cfg80211: Calling CRDA to update world regulatory domain [Mon Aug 4 17:48:53 2014] wlp5s0: authenticated [Mon Aug 4 17:48:53 2014] wlp5s0: associate with 58:f3:9c:f9:27:91 (try 1/3) [Mon Aug 4 17:48:53 2014] wlp5s0: RX AssocResp from 58:f3:9c:f9:27:91 (capab=0x421 status=0 aid=3) [Mon Aug 4 17:48:53 2014] rtl8188ee:rtl88ee_set_hw_reg():<0-0> switch case not process 5c [Mon Aug 4 17:48:53 2014] wlp5s0: associated sometimes with : [Mon Aug 4 19:43:52 2014] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now (with some slight variations...) and something I've never got before : [Mon Aug 4 18:15:29 2014] rtlwifi:addbareq_rx():<10000-1> sta is NULL
(In reply to Larry Finger from comment #29) > What is the deauthentication reason? Please give me something to work with. > You will find that information in the dmesg output. > > As I am not sure how long it will take to get the new Realtek drivers into a > form that can be merged with the kernel, and I am rapidly losing motivation, > I have created a new repo at GitHub.com containing the new code. You can get > a copy by > > git clone http://github.com/lwfinger/rtlwifi_new.git > > It should build on any kernel 3.0 of newer. I tried the drivers from the github repo. I'm not sure if I installed it right (first time I've to install drivers out-of-tree.) I did `make`, `sudo make install` Everything succeeded. (had to redo `make install` I left sudo out the first time) It overwrote the drivers in the kernel I happened to be booted into (3.16-rc7?) I checked the details on the module, and the modification timed matched up. Anyway, after removing the previous modules in use, and loading the new one, it seemed to work fine (though slowly...) but then I rebooted and it started exhibiting the same behavior I mentioned yesterday, though there were not any deauthencation messages. Though for some reason I got : cfg80211: Calling CRDA for country: EC but then that later changed back to US.
The cfg80211 message may be caused by your EPROM having EU set inside. As long as it got changed to US, it is OK, I have made some changes in the repo. Change directory to rtlwifi_new, or wherever you placed the source and do "git pull ; make && sudo make install". After that finishes, then "sudo modprobe -rv rtl8188ee && sudo modprobe -v rtl8188ee debug=4". That will generate a lot of debug output in the system logs, but I hope it will show what is happening. Once the device shows the bad behavior, unload the driver and attach the output of the dmesg command.
Created attachment 145581 [details] rtl8188ee debug
I think I got it. There's also a gist : https://gist.github.com/anonymous/091477bce26856ce5552
I sent that link for the attachment to my contact at Realtek. He responded with =============================================================================== "AP off for 8 s" means that station did not receive any unicast frame or beacon from that AP within 8s. 1.I have viewed the log,and it it strange to see there are two stations interacting with rtl8188ee.May be it is the root cause. [Thu Aug 7 14:13:54 2014] rtlwifi-0:rtl_tx_agg_stop():<0-0> on ra = 58:f3:9c:e8:4a:01 tid = 0 [Thu Aug 7 14:13:54 2014] rtlwifi-0:rtl_action_proc():<400-1> ACT_ADDBADEL From :64:5a:04:5b:20:05 [Thu Aug 7 14:13:54 2014] rtlwifi-0:rtl_tx_agg_start():<0-0> on ra = 58:f3:9c:e8:4a:01 tid = 0 seq:270 [Thu Aug 7 14:13:54 2014] rtlwifi-0:rtl_action_proc():<200-1> Tx ACT_ADDBAREQ From :64:5a:04:5b:20:05 2.And the user can turn off dynamic method to see if this problems still can be reproduced. How to turn off dynamic method: modify base.c and comment out this line: rtlpriv->cfg->ops->dm_watchdog(hw); if the user has determined that dynamic method is the root cause,please tell me. ============================================================================ You have two options: (1) Find that line in base.c and comment it out, or (2) Use the following sequence of commands: cd rtlwifi_new git pull make sudo make install sudo modprobe -rv rtl8188ee sudo modprobe -v rtl8188ee disable_watchdog=1
According to `iw dev wlp5s0` the second MAC address: 64:5a:04:5b:20:05 is actually the MAC address of the rtl8188ee. I'll test the suggestion though.
I was only able to test for about an about an hour or so, but that suggestion seems to work. (wasn't with the latest changes to the rtlwifi_new repo, however.) Although I happened to have dmesg open and I noticed that that same message came up again : rtlwifi-0:rtl_tx_agg_stop():<0-0> on ra = 58:f3:9c:e8:4a:01 tid = 0 rtlwifi-0:rtl_action_proc():<400-1> ACT_ADDBADEL From :64:5a:04:5b:20:05 But it didn't get stuck in that same loop of frequently authenticating and associating with the AP. I'll continue testing this when I get the chance.
I got a chance to test more frequently. I pulled from the github repo : commit 8640820 Although it doesn't disconnect (afaict) it will get unbearable slow. weechat's lag indicator will start to count up. (but that slowness is already covered in another bug.) I'll report back if there's anything else I might have missed.
Created attachment 149661 [details] dmesg rtl8188ee debug level 5
Created attachment 149671 [details] dmesg output (likely incomplete log of reassoc/reauth loop of rtl8188ee)
Created attachment 149681 [details] iw scan iw scan log containing the access point I'm currently connected to.
Neither commenting out the line or using the parameter disable_watchdog=1 seems to make a difference.
I think you can close this. So far 12 minutes and no disconnect, AFAICT. I must have somehow messed up pulling from the github repo yesterday.
This bug is already closed. Although I still experience a slower connection than usual (example: Windows...). So there is another bug that reports the speed connection problem https://bugzilla.kernel.org/show_bug.cgi?id=81671