EasyTether I/O disconnection error

Installing and Using OpenWrt
1

I've been using EasyTether for about a week now, and I'm having a disconnection error happening quite frequently between the phone and the router. When it works, it works quite well, and I have gone over 50GB in 36 hours without any disconnects on the carriers end. So I know from the phone to the carrier, it's working perfectly. But the phone to the router is experiencing a problem.

Overall, it works just fine if I'm only browsing the web, or watching a video. However, when I apply a heavy load to the router (multiple concurrent downloads), it'll work for anywhere between a few minutes (on the B1300) and a couple hours (on the WE1326), then it throws the following error:

Thu Oct 22 17:35:39 2020 daemon.warn easytether-usb[1858]: I/O error
Thu Oct 22 17:35:39 2020 daemon.warn easytether-usb[1858]: now CLOSING
Thu Oct 22 17:35:39 2020 daemon.warn easytether-usb[1858]: now CLOSED
Thu Oct 22 17:35:39 2020 daemon.notice netifd: Network device 'tap-easytether' link is down
Thu Oct 22 17:35:39 2020 daemon.notice netifd: Interface 'wan' has link connectivity loss
Thu Oct 22 17:35:39 2020 daemon.notice netifd: wan (1951): udhcpc: SIOCGIFINDEX: No such device
Thu Oct 22 17:35:39 2020 daemon.notice netifd: wan (1951): udhcpc: received SIGTERM
Thu Oct 22 17:35:39 2020 daemon.notice netifd: Interface 'wan' is now down
Thu Oct 22 17:35:39 2020 daemon.notice netifd: Interface 'wan' is disabled
Thu Oct 22 17:35:39 2020 daemon.warn dnsmasq[1230]: no servers found in /tmp/resolv.conf.auto, will retry

I've tested this problem on the following routers:
ZBT WE1326 (4G Router)
GL.iNet B1300
ZBT WG3526 (4G Router)

On all the routers, at some point, it would throw that I/O Error. It hasn't completely dropped the USB connection, because the phone still shows it's being charged via that USB port. Also, all I need to do is run the 'easytether-usb' command via SSH and it will instantly power right back up.
However, on my MacBook if I'm running EasyTether, it will not throw that error. I have a 2018 with USB-C connectors, so it's connecting to the computer via a dongle.
Another thing to note, is for some reason on the B1300 it only takes a couple minutes of downloading a large file and it will throw the I/O Error, however on the WE1326 I've downloaded 20-30GB before it threw the I/O Error.

One more piece of information which I'm not sure if it will help in the debug.
Without a load (Connected to the internet, background refreshes, but no downloading or web surfing), I can ping my phone (192.168.117.1) and it takes 2-5ms on average. When downloading it doesn't seem to change the ping time more than 1-2ms. But when I run a speedtest through the speedtest.net Mac application it will timeout my ping. If I just upload a file it will lag the ping, upwards close to 1s, but it won't completely kill the ping. Via the speedtest.net application, it produces the following:

Request timeout for icmp_seq 608
Request timeout for icmp_seq 609
64 bytes from 192.168.117.1: icmp_seq=605 ttl=127 time=5346.714 ms
64 bytes from 192.168.117.1: icmp_seq=606 ttl=127 time=4344.821 ms
64 bytes from 192.168.117.1: icmp_seq=607 ttl=127 time=3344.352 ms
64 bytes from 192.168.117.1: icmp_seq=608 ttl=127 time=2342.216 ms
64 bytes from 192.168.117.1: icmp_seq=609 ttl=127 time=1342.401 ms
64 bytes from 192.168.117.1: icmp_seq=610 ttl=127 time=342.249 ms
64 bytes from 192.168.117.1: icmp_seq=611 ttl=127 time=27.089 ms

Here's the following things I've been able to rule out:

  • It doesn't appear to be an amperage issue, because when plugged into my computer it only gets 0.487A, and plugged into the router it only produces 0.487A
  • It happens on more than one router. And it happens on both the ARM and MIPS processors. So I know it's not just processor specific.
  • I tried deleting the IPv6WAN, but that didn't fix anything.
  • I've kept the phone screen on, didn't fix it.
  • I tried keeping the EasyTether application open with the phone screen on, also didn't fix it.
  • Interfaces > WAN > Advanced Settings | Checking ‘Force link’ didn't fix it.
  • There's no difference between using OpenWRT and ROOter firmware - Neither firmware made a difference.
  • I installed the following USB drivers, but that also didn't help:
* kmod-usb-net
* kmod-usb-net-cdc-ether
* kmod-usb-net-rndis
* kmod-usb-net-ipheth
* kmod-usb2
* usbutils
* usbmuxd
* libusbmuxd
* libimobiledevice
* libimobiledevice-utils

I've reached out to the developers, but they are MIA and not-responsive.

Let me know if you have any ideas here on how to fix this error, aside from a bandaid of running the 'easytether-usb' command whenever it disconnects.

2

The bottom line here is that the Easytether application on the router crashes and you may need to seek support from them as it is closed-source.

Try removing all unnecessary USB network drivers. Let Easytether do its thing with the phone without interference from other drivers.

Use top to watch memory and CPU use while running. Differing time before the crash may be because of more memory available to leak or more CPU performance.

If maxing the CPU seems to cause the problem you either need a box with more CPU or traffic control to derate the connection speed.

3

I've removed all the usb drivers, watched the CPU, and there doesn't seem to be any difference on the I/O error.

For a bandaid solution, is there any way to inject a couple lines of code into the I/O error reporting, so that as soon as it throws the I/O Error disconnection, I can run the "easytether-usb" command and reconnect the interface? Is there a specific script which runs those messages I can hijack?

4

I have been fighting this problem with Easytether for years on a variety of devices. Unfortunately, there are not many good tethering alternatives for Linux, so I figured out a simple fix that works for me. As mk24 mentioned, because Easytetforumsher is a closed source application with poor customer service modifying the application is not feasible. Aside from writing your own apps, you really have no alternatives but to run a script in the background to monitor the Easytether app status.

My simple script basically checks to see if the tap-easytether interface is running and if the device has internet connectivity. If not, the script restarts Easytether. This script has allowed me to run for days and weeks without any disruptions. When I do get a disruption, it is usually caused by the phone updating or resetting. This script runs in an infinite loop with a 2 second delay. I usually don't notice the restarts, but they are posted in the log when they occur.

Here is my 'tetherstart' script:

#!/bin/ash

#### tetherstart ####

# to make executable run 'chmod +x tetherstart'

# To start during boot add  '/root/tetherstart 2>&1 &'  to the bottom of /etc/rc.local                 

logger -p local0.notice -t ${0##*/}[$$] "Starting Easytether Loop"

while true
do
        if (ip a s tap-easytether up > /dev/null 2>&1) && (nc -zw1 8.8.8.8 443)
        then
                echo "Easytether is Running"
        else
                logger -p local0.notice -t ${0##*/}[$$] "Restarting Easytether"
                echo "Restarting Easytether"
                killall easytether-usb
                easytether-usb
        fi
sleep 2
done

I hope this helps others in the saforumsme situation

Scott

5

I'm assuming you cannot just use the normal tethering function of your phone, right? Maybe your carrier has disabled it?
Because that is more stable and does not require an app.
And it also works fine on Linux.

If they have not disabled the phone function but they can detect that you are tethering and block traffic from the PC/router but not from the phone you can add a firewall rule to change the TTL of the packets to hide that they originated from another device.

or add this line to the "custom firewall rules" page in Luci web interface (or edit the /etc/firewall.user file if you are using commandline)
iptables -t mangle -I POSTROUTING 1 -j TTL --ttl-set 66
taken from this video where the guy is using this in his device https://www.youtube.com/watch?v=alMsu_tfZPE
also used by other people in the forums of GL-iNET routers https://forum.gl-inet.com/t/change-outgoing-ttl/2096

6

Hopefully this will help some people resolve there isssue with this. I have a router running OpenWRT 18.06.2. The router came preset with OpenWRT as the default firmware. It is a Cellular router it has a script called /sbin/wan-watchdog.sh running every minute via crontab by default. This script checks to see if the mobile modem is active if it is not then it does a reset on the USB devices you can see the code below. I was able to modify this code to ignore restarting the usb device that my phone is connected to. This keeps the easytether link active. Before I fixed this script my easytether link was being disconnected constantly. Below is the code. I have modified it to only find SAMSUNG connected devices and ignore them. The commented line is the original code

 usb_reset() {                                                                                                                                                                                                
         #local usbid=$(lsusb | grep -v "1d6b" | awk '{print $6}')                                                                                                                                           
         local usbid=$(lsusb | grep -v "1d6b" | grep -v $(usbreset | grep "SAMSUNG" | awk '{print $4}') |  awk '{print $6}')                                                                                      
                                                                                                                                                                                                                 
        for id in $usbid; do                                                                                                                                                                                     
            usbreset $id                                                                                                                                                                                         
        done                                                                                                                                                                                                     
    }

I searched but did not see this script in the github source for OpenWRT. So maybe this is just for my Router brand as it was purchased from a specific vendor and the Firmware was modified. But with any luck it may help someone else.

7

Thanks so much to [mochasatin] for that restart script! I was almost ready to give up on easytether, but things seem pretty stable now. I've made a few mods to your script which I'll share. I noticed some thrashing on the interface sometimes when it tried to restart. Sometimes it takes more than 2 seconds for the interface to come up and then it would try and restart multiple times before finally working again. Also I wasn't comfortable only hitting 1 test server, so I have a list of 12 now that it cycles through. It now requires 3 fails in a row before restarting, so if any 1 server has issues it won't needlessly cycle the interface. If it encounters a fail it sleeps 2 seconds and tries again. Otherwise it sleeps 10 seconds, so in normal conditions each test server will only be hit once every 2 minutes.

#!/bin/ash

#### tetherstart ####

# to make executable run 'chmod +x tetherstart'

# To start during boot add  '/root/tetherstart 2>&1 &'  to the bottom of /etc/rc.local

server_list="8.8.8.8 9.9.9.9 208.67.222.222 1.1.1.1 8.8.4.4 149.112.112.112 208.67.220.220 1.0.0.1 185.228.168.9 94.140.14.14 185.228.168.9 94.140.15.15"
fails=0
logger -p local0.notice -t ${0##*/}[$$] "Starting Easytether Loop"

while true
do
        for server in $server_list ; do
                echo "Checking against server $server"
                if (ip a s tap-easytether up > /dev/null 2>&1) && (nc -zw2 $server 443)
                then
                        fails=0
                        echo "Easytether is Running"
                        sleep 10
                else
                        let fails++
                        if [ "$fails" -gt 3 ]
                        then
                                logger -p local0.notice -t ${0##*/}[$$] "Restarting Easytether"
                                echo "Restarting Easytether"
                                killall easytether-usb
                                sleep 1
                                easytether-usb
                                sleep 10
                        else
                                echo "Fail $fails of 3"
                                sleep 2
                        fi
                fi
        done
done
8

Carmex,

I like what you have done to beef up the script by hitting the additional servers. Although I am also guilty of using a 2 second delay in my script above, I would note that measuring delays in seconds is a lifetime to a microprocessor. I would like to get the restart down to a few hundred milliseconds with more testing.

Since I posted my basic script a few months ago I accidently bricked my AR750s while working on an unrelated issues. I replaced the router with a powerful Odroid XU4 SBC that I had available. I loaded it with Ubuntu Mate, Easytether, UFW firewall and my script listed above. After making these changes, I suddenly got a huge jump in performance. My bandwidth jumped from 2-3 mbs to 25-30 mbs. The script is still needed to monitor disconnects, but delays are rarely noticed.

My conclusion is that the little routers just don't have the processing power/memory needed to manage tun/tap tether processing. The Odroid XU4, Pi4 or an old PC will do a much better job.

I cancelled my order for Elon's Starlink internet. LOL

Screenshot_20220304-151322
Screenshot_20220304-1513221080×2300 183 KB

9

Thank you sooo much for this script!

Call me crazy, but the consistent netcat traffic seems to somehow stabilize the whole system. Previously it would bog down and need a reset every few hours. After starting this script the problem seems to have vanished, and it's not even restarting the interface! Amazing and thanks again!