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

English Network/Internet
#1

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:


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)



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

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/4techsecrets/optimize-and-fix-your-network-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

#3

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

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

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

#6

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

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

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

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

#10

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.

#11

First,
Develop a strategy for collecting relevant data with least effort. In other words, you can collect a ton of miscellaneous data, but then you’d need to inspect everything and filter only what is relevant, possibly saving he results in its own file for easier later access.

Unless you want or need to configure something server side, you can concentrate on capturing data only client-side, with traffic from specific websites.

So, for instance the Google search page is a very simple and minimalist page. Just use any other browser than Chromium or Chrome, which will initially display a saved page on the local machine. A browser like Firefox will fetch the page from the Google server every time (unless from the browser cache).

Speaking of which,
Although Wireshark is the tool for inspecting packets, it’s sometimes also useful to analyze how a web page is downloaded and displayed by using the browser’s Development Tools, in most web browsers you can select from the menu or with the keystroke combination CTL-SHFT-J

If you aren’t able to analyze a packet capture or other log file yourself, you can upload to a pastebin for others to view.

TSU

#12

http://www.lazygranch.com/images/sftp_session.png

The above link just shows the flow of a SFTP session. Data flows works for a while, then you get into a section of packet errors, then it works well again. Rinse lather repeat.

Wireshark is designed to capture the data, but the data here is not all that relevant. Rather what is relevant is the packet flow errors, hence the png file. I couldn’t figure out a way to do this directly in wireshark.