Bug 11680 - RTL8187B (0bda:8189) Communication Dropouts
RTL8187B (0bda:8189) Communication Dropouts
Status: RESOLVED DUPLICATE of bug 9143
Product: Drivers
Classification: Unclassified
Component: network-wireless
All Linux
: P1 normal
Assigned To: drivers_network-wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-30 21:06 UTC by Michael Short
Modified: 2008-10-03 07:47 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.27-rc8
Tree: Mainline
Regression: ---


Attachments
Realtek vendor driver (924.96 KB, application/x-gzip)
2008-10-02 14:07 UTC, Michael Short
Details

Description Michael Short 2008-09-30 21:06:18 UTC
Latest working kernel version: N/A
Earliest failing kernel version: 2.6.27-rc8 (Vanilla)
Distribution: Ubuntu 8.04
Hardware Environment: Gateway T-1625

Software Environment:
Vanilla 2.6.27-rc8 kernel compiled on Ubuntu with available packaging tools. (Basically everything is modularized.) Using NetworkManager to configure my network access.

Problem Description:
When using the new RTL8187B (USB Wireless) device driver, the wireless connection seems stable for the first few minutes. After about 2-3 minutes I can't seem to connect with anything, including my gateway. This problem is present when connecting with any network, encrypted or open.

Steps to reproduce:
1. Run Vanilla 2.6.27-rc8
2. Connect with any wireless AP.
3. Perform regular networking tasks.
4. After a few minutes, the connection will be dead.

Additional Details:
After realizing I couldn't connect with anything, I ran some ping tests (ping is possible).

# ifconfig
wlan1     Link encap:Ethernet  HWaddr 00:16:44:94:6e:dd  
          inet addr:70.182.101.238  Bcast:70.182.101.255  Mask:255.255.254.0
          inet6 addr: fe80::216:44ff:fe94:6edd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26294 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9698 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:20473002 (19.5 MB)  TX bytes:1112894 (1.0 MB)

wmaster0  Link encap:UNSPEC  HWaddr 00-16-44-94-6E-DD-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
70.182.100.0    *               255.255.254.0   U     0      0        0 wlan1
link-local      *               255.255.0.0     U     0      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 wlan1
default         70.182.100.1    0.0.0.0         UG    0      0        0 wlan1
default         *               0.0.0.0         U     1000   0        0 eth0
# ping 70.182.100.1
PING 70.182.100.1 (70.182.100.1) 56(84) bytes of data.
From 70.182.101.238 icmp_seq=2 Destination Host Unreachable
From 70.182.101.238 icmp_seq=3 Destination Host Unreachable
From 70.182.101.238 icmp_seq=6 Destination Host Unreachable
From 70.182.101.238 icmp_seq=7 Destination Host Unreachable
^C
--- 70.182.100.1 ping statistics ---
7 packets transmitted, 0 received, +4 errors, 100% packet loss, time 6003ms, pipe 2

Downloading files seems to work fine (before the connection drops out). However, I noticed that throughout the download, the connection speed will randomly drop to about 1/4 of the regular speed every 15-30 seconds then it will return to normal. The connection will also remain active until any active downloads are complete. Perhaps the issue is related to some kind of idle magic? It is NOT possible to restore the connection after the connection "drops". Reconnecting to the AP does not help.
Comment 1 Michael Short 2008-09-30 21:13:23 UTC
dmesg doesn't report anything when the dropout occurs. Everything seems to be running normally.

[   58.642322] wlan1: authenticate with AP 00:0d:67:0a:ab:37
[   58.644705] wlan1: authenticated
[   58.644720] wlan1: associate with AP 00:0d:67:0a:ab:37
[   58.650712] wlan1: RX AssocResp from 00:0d:67:0a:ab:37 (capab=0x421 status=0 aid=13)
[   58.650725] wlan1: associated
[   58.653829] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[   77.697041] wlan1: no IPv6 routers present
Comment 2 Michael Short 2008-10-02 14:07:01 UTC
Created attachment 18142 [details]
Realtek vendor driver

I've also noticed that the driver provided by Realtek (via e-mail) does not suffer from this dropout syndrome. I am posting it for comparison. This driver only works with the previous kernels (in my case 2.6.24). While Realtek's driver, Dmesg points out a number of gain corrections:

[  589.142687] UpdateInitialGain(): InitialGain: 3 RFChipID: 6
[  589.142692] RTL8187 + 8225 Initial Gain State 3: -78 dBm 
[  589.861274] StaRateAdaptive87B(): update init_gain to index 2 for date rate 22
[  589.861279] UpdateInitialGain(): InitialGain: 2 RFChipID: 6
[  589.861282] RTL8187 + 8225 Initial Gain State 2: -78 dBm 
[  590.819558] StaRateAdaptive87B(): update init_gain to index 3 for date rate 36
[  590.819565] UpdateInitialGain(): InitialGain: 3 RFChipID: 6
[  590.819567] RTL8187 + 8225 Initial Gain State 3: -78 dBm 
[  596.411247] wlan0: no IPv6 routers present
[  633.545252] StaRateAdaptive87B(): update init_gain to index 2 for date rate 22
[  633.545258] UpdateInitialGain(): InitialGain: 2 RFChipID: 6
[  633.545260] RTL8187 + 8225 Initial Gain State 2: -78 dBm 
[  633.831516] StaRateAdaptive87B(): update init_gain to index 3 for date rate 36
[  633.831522] UpdateInitialGain(): InitialGain: 3 RFChipID: 6
[  633.831524] RTL8187 + 8225 Initial Gain State 3: -78 dBm 
[  639.774935] StaRateAdaptive87B(): update init_gain to index 2 for date rate 22
Comment 3 Michael Short 2008-10-03 06:21:52 UTC
I disabled NetworkManager and wpa_supplicant in Ubuntu and connected using iwconfig. After 2-3 minutes, the connection still seems to die. I am willing to run further tests on my wifi card if asked.
Comment 4 John W. Linville 2008-10-03 07:47:07 UTC
I suspect that this is the same as bug 9143, and that both of them might be related to bug 11392.

*** This bug has been marked as a duplicate of bug 9143 ***

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