Red Hat Bugzilla – Bug 979706
WIFI Network rapid slowdown and freezes
Last modified: 2014-06-08 06:23:01 EDT
Description of problem: 1) Notebook Lenovo E-325 2) Build in WIFI "rtl8192ce" 3) Kernel 3.9.6-200.fc18.i686 I got a 100mbit line about 1.5 weeks ago and the cable modem's output is 100mbit (~12.5mb/s). I hooked an old WRT 54mbit WIFI router ontop of that modem to support the Notebooks with (theorectically) max. 54mbit. The remaining 46mbit is none of the concerns here (reserved for XBMC, but not installed and operating yet). 2 Notebooks and 2 iPhones are connected to the WRT 54mbit WIFI, reporting a connection of 18mbit (yet another loss but that's still not the problem). Theoretically the 18mbit provides 2.25mb/s download rate. One Notebook has a different WLAN radio build in and has a stable connection with 18mbit and receives these ~2mb/s without any issues. The Phones are only hooked up but idle. The other Notebook (named here) has the rtl8192ce build in and also shows 18mbit connection via iwconfig (also Networkmanager shows this). Sadly it has quite some issues with the bandwidth. The downloadrates starts at 1.5mb/s and then rapidly falls down to less than 70kb/s and floats around 40kb/s and 120kb/s (which theoretically is around 1mbit). Sometimes the connection is quite good and holds for a while and then from one moment to another it can't decide whether it wants to be 18mbit or 1mbit or whatevever. It then starts floating around 40kb/s and 1.5mb/s going ping pong here. Sometimes it simply halts, doesn't do anything for a couple of seconds and then continues. I then scanned the entire WIFI area here and detected a bunch of other people providing wireless lan. These devices run usually at channel 1 or 11. My WRT runs on channel 6. DB is around -58dbm and the link quality is around 58/70 which is a quite solid signal (more or less). Both notebooks are on the same table, so they share the same distance to the WRT (around 7meters). After googling for the issue I found SEVERAL (and i mean quite a lot) of people complaining about similar (if not the same) issues with this kind of hardware. Therefore I started to investigate into this issue and tried to build the original drivers that come from realtec. Compiling worked after some minor changes (3 lines of code). But the drivers cause the same issues. Later on I tried the same with the compat drivers from wireless.kernel.org but they cause the same issues as well. The thing I don't understand is this. 2 Notebooks, same table, same signal, same distance, same bit rate. The one performs niceley with the 2.25mb/s while the other with the rtl drivers go nuts here. What I also don't understand is, the notebook with the rtl drivers worked nicely with 2.25mb/s as well for over one week and then from one moment to the next dropped to under 1mbit/s (125kb/s). Now it sits here on the table and it looks like that it can't decide whether it wants to be 18mbit/s or 1mbit/s because I receive all kind of different values from 40kb/s to 1.5mb/s. Any ideas ? I tried quite some stuff here but wasn't successful. Xayde is the WRT I am using. The other is a device from one of my neighbours I think. -bash-4.2$ iwconfig wlan0 IEEE 802.11bgn ESSID:"Xayde" Mode:Managed Frequency:2.437 GHz Access Point: 00:0F:66:A7:18:77 Bit Rate=18 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr=2347 B Fragment thr:off Power Management:off Link Quality=48/70 Signal level=-62 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:93222 Missed beacon:0 -bash-4.2$ sudo iw wlan0 scan -u BSS 00:0f:66:a7:18:77 (on wlan0) -- associated TSF: 179716289473 usec (2d, 01:55:16) freq: 2437 beacon interval: 100 capability: ESS Privacy ShortSlotTime (0x0411) signal: -56.00 dBm last seen: 123 ms ago Information elements from Probe Response frame: SSID: Xayde Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 DS Parameter set: channel 6 ERP: <no flags> Unknown IE (47): 00 Extended supported rates: 6.0 9.0 12.0 48.0 Vendor specific: OUI 00:10:18, data: 02 01 04 WPA: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: (0x0000) BSS bc:05:43:15:54:03 (on wlan0) TSF: 243846618140 usec (2d, 19:44:06) freq: 2412 beacon interval: 100 capability: ESS Privacy ShortSlotTime (0x0411) signal: -46.00 dBm last seen: 3894 ms ago Information elements from Probe Response frame: SSID: was guckst du Supported rates: 1.0* 2.0* 5.5* 11.0* DS Parameter set: channel 1 ERP: Barker_Preamble_Mode RSN: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: (0x0000) Extended supported rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 WPA: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP * Authentication suites: PSK * Capabilities: (0x0000) Vendor specific: OUI 08:00:28, data: 01 01 00 02 00 ff 0f WMM: * Parameter version 1 * u-APSD * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec -bash-4.2$ iwlist wlan0 bitrate wlan0 unknown bit-rate information. Current Bit Rate=18 Mb/s Exactly 18mbit/s should give me 2.25mb/s and not the 100kb/s.
[11551.544731] wlan0: deauthenticating from 00:0f:66:a7:18:77 by local choice (reason=3) [11559.539999] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [11561.917508] wlan0: authenticate with 00:0f:66:a7:18:77 [11561.926439] wlan0: send auth to 00:0f:66:a7:18:77 (try 1/3) [11561.929678] wlan0: authenticated [11561.930056] rtl8192ce 0000:01:00.0 wlan0: disabling HT as WMM/QoS is not supported by the AP [11561.930062] rtl8192ce 0000:01:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP [11561.931069] wlan0: associate with 00:0f:66:a7:18:77 (try 1/3) [11561.933850] wlan0: RX AssocResp from 00:0f:66:a7:18:77 (capab=0x411 status=0 aid=1) [11561.934006] wlan0: associated [11561.934085] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
I figured out in another Bugreport here that people reported that a disconnect and re-connect get the old and expected speed back. This helped for me. Disconnecting and reconnecting to the WLAN helped to get full speed at 18mbit/s back. Though this is still a driver issue I believe.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
I am always with the latest kernels released and still I am on FC18 because I can't get along with the GNOME version that got shipped with FC19 and FC20 (last one tested). Kernel 3.11.5-100.fc18.i686 The only thing that I can say is that WIFI simply drops to less than 100kbs from a 100mbit line connected with 18mbit (~2.5 mbs). With recent kernels it even drops connection without letting me know this. Networkmanager still shows a connected line. So I need to manually disconnect and re-connect again. After manual re-connecting the line holds for 1-2 hours before it drops again or loses its connection.
Ali, You did a great job with giving details! This is a long discussion but the short story is this: The rtl family has this kind of issues, I think you are probably at the beginning of the improved reliability history in kernels starting around 3.9. Try to keep up with kernel updates if you must stay with with F18 for now. There are incremental driver improvements on the in-tree code that will help some. Your signal strengths look fine, likely it's the connectivity issue. Betting your logs have scenario displayed in comment 1 recurring cyclically. This driver, as you pointed out from internet search, is prone to issues with staying connected prior to 3.9. Can you post a log for wpa_supplicant? Its in /var/log/wpa_supplicant.log By the way, it's verboseness can be increased if you like: -d or -dd increases debug output to logs As to throughput issues: I think your expectations of throughput are pretty reasonable. Most of what I've seen with these devices being unstable in throughput stem from the connectivity being unstable. Upstream developer are making strides in this area. Keep your packages updated too: rkfill, wpa_supplicant, crda, networkmanager. dbus; wpa_supplicant and network manager mostly. I've not seen a silver bullet fix, but perhaps we can make it better with these also, but mostly driver updates are needed I think. wrt-54g is not a HT AP (802.11n) either, sometimes their firmware updates might help too. Can you upload a full dmesg log, lspci -nnvv, and the wpa_supplicant.log mentioned above? I can forward to vendor developer if you got some new stuff.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Haven't had activity in a couple months: is your problem is solved with a newer kernel, etc? If not, please feel free to reopen this or new bugzilla if you still need assistance.