Bug 479860 - Toshiba Satellite L300-1AF RTL8187B wireless chipset establishes connection, but no traffic can pass.
Toshiba Satellite L300-1AF RTL8187B wireless chipset establishes connection, ...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-01-13 11:59 EST by Dave Russell
Modified: 2009-01-29 09:23 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 477086
Last Closed: 2009-01-29 09:23:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dave Russell 2009-01-13 11:59:03 EST
+++ This bug was initially created as a clone of Bug #477086 +++

Description of problem:
Toshiba Satellite Pro L300-1AF has an onboard Realtek RTL8187B chipset, fails to allow any traffic through. NetworkManager still recognizes it as connected, but no packets appear to go through.

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. Log in
2. Connect to a network, start utilising
Actual results:
Connection shown as live, but no traffic can pass.

Expected results:
Connection live and traffic should be able to pass.

--- Additional comment from drussell@redhat.com on 2009-01-12 13:00:32 EDT ---

Can you re-check this with the latest kernel?

I'm using and getting slightly different results.

Now the connection stays up, and associated, but no packets can go through at all.

Even if I reconnect, it's still dead as a dodo.

If it's the same for you on the latest kernel I'll upload logs etc.

--- Additional comment from drussell@redhat.com on 2009-01-12 15:13:39 EDT ---

[root@cobwebs ~]# lsusb
Bus 002 Device 002: ID 0bda:8197 Realtek Semiconductor Corp. RTL8187B Wireless Adapter
[root@cobwebs ~]# uname -a
Linux cobwebs.darkglobe.int #1 SMP Tue Dec 16 15:12:04 EST 2008 i686 i686 i386 GNU/Linux

Strangely it seems to have no problem associating with the wireless network, still thinks its connected, and gets an IP address... but I can't even ping the default gateway or any other ip address on the network.

I *can* ping its external ip address on wlan0

--- Additional comment from drussell@redhat.com on 2009-01-12 15:54:09 EDT ---

Created an attachment (id=328781)
dmesg output

--- Additional comment from drussell@redhat.com on 2009-01-12 15:54:57 EDT ---

Created an attachment (id=328783)
ifconfig output

--- Additional comment from drussell@redhat.com on 2009-01-12 15:55:32 EDT ---

Created an attachment (id=328784)
iwconfig output

--- Additional comment from drussell@redhat.com on 2009-01-12 15:56:23 EDT ---

Created an attachment (id=328785)
/var/log/messages output

--- Additional comment from drussell@redhat.com on 2009-01-12 16:03:14 EDT ---

Just one more user facing the same issue.

Comment 1 Dave Russell 2009-01-13 12:02:20 EST
Just a note, I have cloned the previous bug and slightly altered this new one to better reflect the issues (but not loose all the uploaded attachments).

Also, I have tried the latest F10 kernel available in koji 2.6.28-1.fc10.i686

Still the same symptoms, NetworkManager establishes a connection but it won't pass any traffic.

BTW This machine was a fresh install yesterday.
Comment 2 Dave Russell 2009-01-13 12:03:50 EST
Altered subject to better identify bug.
Comment 3 John W. Linville 2009-01-14 09:48:25 EST
This device is notorious for not playing nice with the mac80211 rate control algorithms.  You might want to try forcing a lower rate:

   iwconfig eth0 rate 5.5M fixed

Does that allow some semblance of connectivity?
Comment 4 Dave Russell 2009-01-14 10:04:07 EST
Yes, that does indeed work:

iwconfig wlan0 rate 5.5M fixed

This is on the 2.6.28-1.fc10.i686 kernel from koji.

So that's identified the problem... is there anything that can be done to limit to make these kinds of changes transparent to the user?

I'm going to pull down the latest rawhide kernel now and give that a shot too.
Comment 5 Dave Russell 2009-01-14 10:24:59 EST
Now this is interesting, the rawhide kernel seems to work out of the box, no rate limiting required.

2.6.29-0.35.rc1.git4.fc11.i686 pulled straight from koji.

Comment 6 John W. Linville 2009-01-14 14:02:57 EST
Nothing that isn't obvious (i.e. either use the fc11 kernel or add the iwconfig command to rc.local).

We probably need another rate control algorithm upstream for devices that don't properly report transmit status (i.e. devices like this one).  Let me know if you can think of a good algorithm... :-)
Comment 7 Dave Russell 2009-01-19 05:15:16 EST
Ok, for now I'm going to go with the F11 kernel.

One thing though, if there's no updated algorithm, I'm confused as to why the F11 one works, and the F10 one doesn't, I assume it's just the updated driver between the versions, but if that's the case, couldn't it be updated/fixed in the F10 kernel?

I'm curious if nothing else :o)
Comment 8 John W. Linville 2009-01-19 10:16:47 EST
There were some rtl8187b-related patches that might effect rate scaling.  I'll try to dig them out to see if we can improve F10.  However ATM I can't be sure how readily they apply to F10 and therefore can't commit to taking them if they are too disruptive or simply don't apply.
Comment 9 Dave Russell 2009-01-19 10:43:27 EST
Ahh ok. Well if you can, and you want a willing vict... test subject, just let me know and I'll give them a try.

Many thanks.
Comment 10 John W. Linville 2009-01-20 12:49:08 EST
I pushed a patch into -- not sure when a build will have it...
Comment 11 Chuck Ebbert 2009-01-21 11:19:28 EST
Should also be fixed in which is submitted for updates-testing.
Comment 12 Dave Russell 2009-01-21 12:28:47 EST
Great news, will try the kernel this evening.

Will let you know.
Comment 13 Dave Russell 2009-01-24 11:06:51 EST

[jane@cobwebs ~]$ uname -a
Linux cobwebs.darkglobe.int #1 SMP Wed Jan 21 02:09:37 EST 2009 i686 i686 i386 GNU/Linux

[jane@cobwebs ~]$ ping www.google.co.uk
PING www.l.google.com ( 56(84) bytes of data.
64 bytes from .google.com ( icmp_seq=1 ttl=243 time=33.5 ms
64 bytes from .google.com ( icmp_seq=2 ttl=243 time=31.0 ms
64 bytes from .google.com ( icmp_seq=3 ttl=243 time=38.8 ms
--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2489ms
rtt min/avg/max/mdev = 31.037/34.455/38.820/3.254 ms

Great work, all seems to be fine to me, please feel free to push this from testing into released...

Thanks for the effort that's gone into this.

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