Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: usb tether (rndis) slow download due to packet error and retransmission

  1. #1

    Default usb tether (rndis) slow download due to packet error and retransmission

    On the OnePlus 5 using usb tether, I get packet errors only on download. I have tried this on three different cables. It does work on windows, so that eliminates hardware issues. Wifi tether is not a problem.

    Here are some diagnostics:

    Code:
    linux-0u81:/home/mrg # ifconfig usb0
    usb0      Link encap:Ethernet  HWaddr (censored)  
              inet addr:192.168.42.145  Bcast:192.168.42.255  Mask:255.255.255.0
              inet6 addr: 2607:fb90:44e:3269:c4ed:e6ff:fed9:8d00/128 Scope:Global
              inet6 addr: fe80::c4ed:e6ff:fed9:8d00/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:1505 errors:482 dropped:0 overruns:0 frame:482
              TX packets:1450 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:1468188 (1.4 Mb)  TX bytes:242956 (237.2 Kb)
    Code:
    Bus 008 Device 002: ID (censor) 
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.10
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0 
      bDeviceProtocol         0 
      bMaxPacketSize0        64
      idVendor           0x2a70 
      idProduct          0xf00e 
      bcdDevice            4.04
      iManufacturer           1 OnePlus
      iProduct                2 OnePlus
      iSerial                 3 (censor)
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength           75
        bNumInterfaces          2
        bConfigurationValue     1
        iConfiguration          4 rndis
        bmAttributes         0x80
          (Bus Powered)
        MaxPower              500mA
        Interface Association:
          bLength                 8
          bDescriptorType        11
          bFirstInterface         0
          bInterfaceCount         2
          bFunctionClass        224 Wireless
          bFunctionSubClass       1 Radio Frequency
          bFunctionProtocol       3 RNDIS
          iFunction               7 RNDIS
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           1
          bInterfaceClass       224 Wireless
          bInterfaceSubClass      1 Radio Frequency
          bInterfaceProtocol      3 RNDIS
          iInterface              5 RNDIS Communications Control
          ** UNRECOGNIZED:  05 24 00 10 01
          ** UNRECOGNIZED:  05 24 01 00 01
          ** UNRECOGNIZED:  04 24 02 00
          ** UNRECOGNIZED:  05 24 06 00 01
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0008  1x 8 bytes
            bInterval               9
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass        10 CDC Data
          bInterfaceSubClass      0 Unused
          bInterfaceProtocol      0 
          iInterface              6 RNDIS Ethernet Data
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x8e  EP 14 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x0f  EP 15 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
    Binary Object Store Descriptor:
      bLength                 5
      bDescriptorType        15
      wTotalLength           12
      bNumDeviceCaps          1
      USB 2.0 Extension Device Capability:
        bLength                 7
        bDescriptorType        16
        bDevCapabilityType      2
        bmAttributes   0x00000006
          Link Power Management (LPM) Supported
    Device Status:     0x0000
      (Bus Powered)

  2. #2
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    Try changing your TCP/iP Congestion Control algorithm to something other than the default, maybe something for wireless.

    I wrote the following a long time ago for an earlier openSUSE, but everything in it should still apply to all current versions of openSUSE.

    https://sites.google.com/site/4techs...ork-connection

    Note that any algorithm cannot properly be a proper fix for a serious issue, but each algorithm tunes things like timeouts, TC/IP Windows sizes and more to account for the characteristics of different types of network connections which aren't an 802.3 wired, thereby addressing things premature resends due to a type of connection with higher latencies. My article also briefly describes the Microsoft algorithm which can explain why you might not see the same type of problems using Windows.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  3. #3

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    Quote Originally Posted by tsu2 View Post
    Try changing your TCP/iP Congestion Control algorithm to something other than the default, maybe something for wireless.

    I wrote the following a long time ago for an earlier openSUSE, but everything in it should still apply to all current versions of openSUSE.

    https://sites.google.com/site/4techs...ork-connection

    Note that any algorithm cannot properly be a proper fix for a serious issue, but each algorithm tunes things like timeouts, TC/IP Windows sizes and more to account for the characteristics of different types of network connections which aren't an 802.3 wired, thereby addressing things premature resends due to a type of connection with higher latencies. My article also briefly describes the Microsoft algorithm which can explain why you might not see the same type of problems using Windows.

    TSU
    I couldn't get any of those programs to run. However i seriously doubt this is a congestion issue. It isn't like I'm trying to run bit torrent.

    Now that I have updated to 42.3, things are worse. When I run beta.speedtest.net, I can't even get the upload to work. That wasn't a problem under 42.2. The download is still full of frame errors.

    I'm going to try some live linux disties to see if this is specific to Opensuse. As an aside, I have a old opensuse 13.2 partition on a different drive in this notebook. I couldn't even get the phone to work with 13.2 on usb.

  4. #4

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    Quote Originally Posted by gariac View Post
    I couldn't get any of those programs to run. However i seriously doubt this is a congestion issue. It isn't like I'm trying to run bit torrent.

    Now that I have updated to 42.3, things are worse. When I run beta.speedtest.net, I can't even get the upload to work. That wasn't a problem under 42.2. The download is still full of frame errors.

    I'm going to try some live linux disties to see if this is specific to Opensuse. As an aside, I have a old opensuse 13.2 partition on a different drive in this notebook. I couldn't even get the phone to work with 13.2 on usb.

    There is no problem with 42.3. It seems the openvpn app on my phone was causing problems with the speedtest upload. I have uninstalled that app for now.

  5. #5
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    Glad to hear the source of your problem was found.

    Point of clarification,
    The TCP/IP Congestion Control algorithm doesn't just address congestion.
    It addresses and can optimize and tune your networking so that it conforms to the idiosynchrosies of the type of network connection you're using.
    So, for instance it will compensate for greater latencies over wireless (particularly satellite).
    It doesn't matter what might cause lost or late packets, it will optimize for other causes over slow connections.
    And,
    To the other extreme a different algorithm can also take advantage of very high bandwidth, fat pipes of networking improving throughput.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  6. #6

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    Quote Originally Posted by tsu2 View Post
    Glad to hear the source of your problem was found.

    Point of clarification,
    The TCP/IP Congestion Control algorithm doesn't just address congestion.
    It addresses and can optimize and tune your networking so that it conforms to the idiosynchrosies of the type of network connection you're using.
    So, for instance it will compensate for greater latencies over wireless (particularly satellite).
    It doesn't matter what might cause lost or late packets, it will optimize for other causes over slow connections.
    And,
    To the other extreme a different algorithm can also take advantage of very high bandwidth, fat pipes of networking improving throughput.

    TSU
    Oh the problem isn't fixed unfortunately. Rather I figured out what was messing with the upload during the speedtest. The openvpn for android interaction was mysterious. I turned off openvpn at first and it made no difference. I then did a force stop and the problem went away. However restarting openvpn for android and turning on the VPN did not cause the speedtest upload to be blocked.

    In theory, and with software practice and theory are often different, openvpn for android should not effect tether because it doesn't allow openvpn to create the tunnel for tether. The notion being it could be a security problem since some hacker could permanently become a man in the middle. What you are supposed to do is run openvpn on the device you are tethering. That makes sense to me. I'm going to reinstall openvpn for android and hack some more.

    I spent about an hour trying every variation of the network manager for the connection to the phone. IPV6 auto, etc. I am tethering to Tmobile, which is ipv6 only, though that was never an issue with my blackberry Z10. (QNX surprisingly is way more linux friendly than Android. **** unfortunate Blackberry was the loser in the phone OS war.) I also did things like uninstall ADB, get rid of any MTP programs (though not the library). Nothing seems to alleviate the frame errors. I even changed the MTU.

    I did the tether with wicked. That didn't change anything. (I'm not a fan of wicked since it lacks the network manager widget or whatever you call it.)

    You can see the retransmissions on wireshark, though I'm not exactly worthy of doing wireshark analysis. In any event wireshark doesn't indicate why a packet was retransmitted, but just that it happened. It seems usbmon is not in 42.3.

    I downloaded ubuntu, which supposedly can be run live. If the problem is in the kernel, it should be a problem with ubuntu as well. But I suspect the problem is something else.

    If I didn't want to put myself in grub2 hell, I would replace that old Opensuse 13.2 OS on the other drive with Ubuntu. However there is nothing worse that boot problems (for me that is). Things you do daily are things you get good at. Things you do infrequently are always a struggle for me.

    I got a boot error when I upgraded to 42.3, but the notebook booted anyway. The first attempt at 42.3 had a bug due to a freakin' font being missing (liberation-2). This is not the thing that is missed in beta, so I assume it was a personal problem. I had to download the font from the interwebs, then the rest went smoothly.

  7. #7

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    As a follow up, I just installed Ubuntu on a usb stick and ran it live. (Props to live-usb-gui. That was sure easy.) Hardest part was to find out how to get a terminal on Ubuntu (control alt T as it turns out).

    Same frame errors on RX. So this is either kernel related or something wrong with the phone OS (OnePlus 5).

  8. #8

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    Quote Originally Posted by gariac View Post
    As a follow up, I just installed Ubuntu on a usb stick and ran it live. (Props to live-usb-gui. That was sure easy.) Hardest part was to find out how to get a terminal on Ubuntu (control alt T as it turns out).

    Same frame errors on RX. So this is either kernel related or something wrong with the phone OS (OnePlus 5).
    At this point I have run this test of Ubuntu, Fedora, and Mint in addition to Opensuse. No difference. RX has framing errors, TX no problem. I will try to do a live BSD flavor.

  9. #9
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    So it seems that you really need to define what your framing errors are... Layer 2? If Layer 3, then that's what the TCP/IP Congestion Control algorithm can do, which is to expand both in size and TTL the TCP/IP "windows" (similar to Level 2 Frames, but at a level above).

    If it's a Layer 2 error, then that's a fundamental communication error which would require researching your specific mix of hardware, connections, drivers, and possibly more. Although a non-Linux OS might use a different <driver>, it seems to me everything else would be the same so changing OS is problematic as a possible solution.

    Instead,
    I'd recommend you inspect frame sizes, number of frames, etc.
    Are you sure your Wireshark traces aren't telling you more?

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  10. #10

    Default Re: usb tether (rndis) slow download due to packet error and retransmission

    Quote Originally Posted by tsu2 View Post
    So it seems that you really need to define what your framing errors are... Layer 2? If Layer 3, then that's what the TCP/IP Congestion Control algorithm can do, which is to expand both in size and TTL the TCP/IP "windows" (similar to Level 2 Frames, but at a level above).

    If it's a Layer 2 error, then that's a fundamental communication error which would require researching your specific mix of hardware, connections, drivers, and possibly more. Although a non-Linux OS might use a different <driver>, it seems to me everything else would be the same so changing OS is problematic as a possible solution.

    Instead,
    I'd recommend you inspect frame sizes, number of frames, etc.
    Are you sure your Wireshark traces aren't telling you more?

    TSU
    I managed to get GhostBSD to boot. It refused to do use the RNDIS connection. I would select USB Tether on the phone, it would pause a bit, then turn off. Well it was worth a try.

    Wireshark blasts out a lot of data when surfing a web page. What would be a simple test that would yield a reasonably compact wireshark output? I have a VPS that I can use for a test interface. Maybe there is something I can set up with netcat. That is a simple file transfer with no overhead. I can send data over port 110 (not filtered by Tmobile and I dont use it.)

    The test VPS is set up for TLS, but I can undo that. Also turn off gzip. I'm using nginx.

    I know very little about networking, so I am open to suggestions.

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •