User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Fedora/3.0.5-1.fc9 Firefox/3.0.5 rndis upload speeds are 4x - 8x slower than WinVista when upload works at all. rndis download speeds are awesome, but upload speeds are slow and sometimes the upload connection just does not work. For instance, gmail inbox can be viewed, but can't open an actual email. Same with Yahoo email. http://www.dslreports.com/testhistory/368065/2f2d9 and look at the windstream ISP entries showing 66kbps, but the WinVista entry is 482kbps. In fact, most of my Fedora speedtests have not shown because the 50kb upload section never completes! usb 7-2: new full speed USB device using uhci_hcd and address 2 usb 7-2: configuration #1 chosen from 1 choice usb 7-2: New USB device found, idVendor=0bb4, idProduct=0b04 usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 7-2: Product: Generic RNDIS usb 7-2: Manufacturer: HTC usb 7-2: SerialNumber: 3fbf5000-xxxx-yyyy-zzzz-4241353abcde usbcore: registered new interface driver cdc_ether rndis_host 7-2:1.0: RNDIS_MSG_QUERY(0x00010202) failed, -47 eth1: register 'rndis_host' at usb-0000:00:1d.1-2, RNDIS device, 80:00:xx:yy:e8:00 usbcore: registered new interface driver rndis_host usbcore: registered new interface driver rndis_wlan eth1: no IPv6 routers present Reproducible: Always Steps to Reproduce: 1.attach HTC ppc6800 usb cable and initiate "Internet Sharing" on evdo cell phone. 2.You can navigate to gmail and yahoo mail, but actually try opening an email -- it will timeout. 3.dslreports.com/stest and do the java speedtest, the downloads will fly, but will hang at the first upload test - 50kilobits. That is practically telephone dial-up speed. Actual Results: The network connection seems to work ok, but then yahoo/gmail emails can't be opened, submittal of web forms may stop working. The java dslreports speedtest will hang when trying to upload. Expected Results: Should be able to open emails and get 256 - 512 kbps upload speeds. dmesg: usb 7-2: new full speed USB device using uhci_hcd and address 2 usb 7-2: configuration #1 chosen from 1 choice usb 7-2: New USB device found, idVendor=0bb4, idProduct=0b04 usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 7-2: Product: Generic RNDIS usb 7-2: Manufacturer: HTC usb 7-2: SerialNumber: 3fbf5000-xxxx-yyyy-zzzz-4241353abcde usbcore: registered new interface driver cdc_ether rndis_host 7-2:1.0: RNDIS_MSG_QUERY(0x00010202) failed, -47 eth1: register 'rndis_host' at usb-0000:00:1d.1-2, RNDIS device, 80:00:xx:yy:e8:00 usbcore: registered new interface driver rndis_host usbcore: registered new interface driver rndis_wlan eth1: no IPv6 routers present
This shouldn't have anything to do with NetworkManager, because these devices do all the connection sharing internally, and present a simple Ethernet interface on the USB port. Thus, its more likely some limitation/bug of the rndis driver in the kernel. Make sure when you test you're in the same physical location when you're doing the Windows tests too, just to rule out switching between EVDO rev 0 and EVDO rev A, which have different upload speeds.
Attempted to post this follow up comment from fc10 over rndis, but it times out. i knew it wasn't NetworkManager but the three other rndis bug reports i found were under NetworkManager. Thanks for changing to the kernel because i was looking for rndis. Yes, same physical location for Microsoft Windows and fc9 and fc10. The java upload test hangs in both fc9 and fc10 while connected via rndis, but works fine over standard ethernet.
Connection Reset When attempting to submit an "Additional Comment" here on BugZilla, the submittal times out with the following error error from Firefox 3.0.5 running on fc10 connected via rndis: Connection Interrupted The connection to the server was reset while the page was loading. The network link was interrupted while negotiating a connection. Please try again. (Posted via Windows)
Verified in: 2.6.27.5-117.fc10.i686 2.6.27.7-134.fc10.i686 2.6.27.9-159.fc10.i686
Hope to test if "473252 - Slow UMTS/3G upload rate" patch in the latest kernel fixes this rndis problem tonight.
Still a problem in FC9: Linux HP-821 2.6.27.19-78.2.30.fc9.i686 #1 SMP Tue Feb 24 20:09:23 EST 2009 i686 i686 i386 GNU/Linux
Still a problem in fc11. ScenarioGOOD: [ fc11 desktop <--EthernetOverCat5--> CradlePointCellularTravelRouterCTR350 <--rndisOverUSB--> WinCE-CellPhone ]: Both upload and download are OK at 1.5Mbps down / 300kbps up. ScenarioBAD: [ fc11 desktop <--rndisOverUSB--> WinCE-CellPhone ]: Both flash and java speedtests at dslreports and whatismyip do a decent download, but hang at upload. i can ping 208.67.220.220. i could probably load gmail.com and maybe sign in, but not actually be able to send an email. http://www.dslreports.com/speedtests/ http://www.whatismyip.com/speedtest/index.asp
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: ======= Using high speed cellular service by USB cable tethering a MS WinCE based cellphone results in OK downloads but practically non existent uploads. Consequence: ============ Filling out web based forms or sending gmail / new yahoo email may fail. Uploads fail. Fix: ==== The bug has NOT been fixed as of 20090923 / 2.6.30.5-43.fc11.i586. Possible workarounds: WorkAroundA: Connect to the phone via BlueTooth instead of the USB cable. Not verified. WorkAroundB: Use an intermediate router that can connect to the cell phone and the Fedora box. Custom made openwrt/dd-wrt or a CradlePoint router. Verified.
This bug is extremely similar to "Bug 473252 - Slow UMTS/3G upload rate" https://bugzilla.redhat.com/show_bug.cgi?id=473252 The difference may be that 47352 are dedicated 3G hardware USB/pcmcia devices whereas 480290 is for tethering to a phone using USB. http://article.gmane.org/gmane.linux.elitists/12515 "Bug 473252 - Slow UMTS/3G upload rate" was fixed: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/usb/serial/option.c;hb=HEAD but i am not sure how to tell if those buffer size changes made it into the driver used for tethering a phone. Initial tests at insmod option did not work to increase upload speed, but maybe i did something wrong.
FWIW, I quite regularly use a Windows Mobile (6.5) phone tethered via USB - EVDO Rev. A, Telus is the carrier - and have never noticed a problem like this. Works fine for me. System is my Vaio P netbook running F11. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
The other day, a knowledgeable friend brought up the inconceivable notion that USB is half-duplex. A few of us had a hard time believing this, but i thought that could very well explain this bug. Half-duplex would mean that as long as anything is being downloaded, you can't upload anything. Never did get that usb headset to simultaneously talk n listen at the exact same time, either. From http://en.wikipedia.org/wiki/Universal_Serial_Bus Two-way communication is also possible. In USB 3.0, full-duplex communications are done when using SuperSpeed (USB 3.0) transfer. In previous USB versions (i.e., 1.x or 2.0), all communication is half-duplex and directionally controlled by the host. Search for duplex in the following: http://www.usb.org/developers/whitepapers/bwpaper2.pdf Interesting http://www.usb.org/developers/whitepapers/usb_20g.pdf does not mention duplex at all. It is not clear to me whether there is full duplex operation within the USB subsystem inside the PC only, but just not over the wire or both. From http://www.everythingusb.com/superspeed-usb.html "USB 3.0 utilizes a bi-directional data interface rather than USB 2.0's half-duplex arrangement, where data can only flow in one direction at a time."
(In reply to comment #10) > FWIW, I quite regularly use a Windows Mobile (6.5) phone tethered via USB - > EVDO Rev. A, Telus is the carrier - and have never noticed a problem like this. > Works fine for me. System is my Vaio P netbook running F11. Do you know if that phone connected as a serial device or rndis?
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping