Bug 979706 - WIFI Network rapid slowdown and freezes
Summary: WIFI Network rapid slowdown and freezes
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: i686
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: fedora-kernel-wireless-realtek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-29 16:52 UTC by Ali Akcaagac
Modified: 2014-06-08 10:23 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-12-23 14:15:12 UTC
Type: Bug
Embargoed:
aliakc: needinfo-


Attachments (Terms of Use)

Description Ali Akcaagac 2013-06-29 16:52:59 UTC
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.

Comment 1 Ali Akcaagac 2013-06-29 16:55:42 UTC
[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

Comment 2 Ali Akcaagac 2013-07-05 19:26:25 UTC
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.

Comment 3 Justin M. Forbes 2013-10-18 21:01:26 UTC
*********** 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.

Comment 4 Ali Akcaagac 2013-10-20 16:43:18 UTC
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.

Comment 5 John Greene 2013-10-21 14:07:50 UTC
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.

Comment 6 Fedora End Of Life 2013-12-21 14:12:02 UTC
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.

Comment 7 John Greene 2013-12-23 14:15:12 UTC
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.


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