Red Hat Bugzilla – Bug 479860
Toshiba Satellite L300-1AF RTL8187B wireless chipset establishes connection, but no traffic can pass.
Last modified: 2009-01-29 09:23:43 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): 2.6.27.9-159.fc10.i686 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 2.6.27.9-159.fc10.i686 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 2.6.27.9-159.fc10.i686 #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. http://fedoraforum.org/forum/showthread.php?t=208382
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.
Altered subject to better identify bug.
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?
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.
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. Ideas/Suggestions?
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... :-)
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)
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.
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.
I pushed a patch into 2.6.28.1-18.fc10 -- not sure when a build will have it...
Should also be fixed in 2.6.27.12-170.2.5 which is submitted for updates-testing.
Great news, will try the 2.6.27.12-170.2.5 kernel this evening. Will let you know.
Bingo! [jane@cobwebs ~]$ uname -a Linux cobwebs.darkglobe.int 2.6.27.12-170.2.5.fc10.i686 #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 (66.249.91.147) 56(84) bytes of data. 64 bytes from .google.com (66.249.91.147): icmp_seq=1 ttl=243 time=33.5 ms 64 bytes from .google.com (66.249.91.147): icmp_seq=2 ttl=243 time=31.0 ms 64 bytes from .google.com (66.249.91.147): icmp_seq=3 ttl=243 time=38.8 ms ^C --- 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.