Skip to content

Review: GL.iNet GL-AR750S-Ext Travel Router and EasyTether

I, along with my family, like to travel several times a year. The type of traveling varies – sometimes it is somewhere within a day or two driving distance and other times we take the a flight to somewhere more distant and stay longer. This is possible because I am a mostly (99% of the time) remote worker and can work from most locations so long as I have power for my laptop and accessories and high speed Internet. When I am stationary I try to use the local WiFi if possible, but if I am traveling or at a location that does not have suitable WiFi then I will use my Android smart phone (Verizon service) to fill the gap. Using my phone is fine for one device, but what if I need to connect more than one? When I’m at a hotel, do I really want to trust their WiFi? Well it turns out the answer to both of these questions is to pair my phone with a specialized router.

First some background: most phone carriers (at least in the US) allow hot-spots on the phone, but they come with a catch: you are limited, per month, in how much bandwidth you are allowed to consume. In Verizon-land it is somehow acceptable to cap this at 15GB per month which is a bit unrealistic in this day and age. The phone itself has unlimited data, but anything you wish to connect to the built-in hot-spot or otherwise tether to the phone is limited to 15GB per month. One day I got to thinking “so how can I tap into that unlimited side of the phone?” A bit of searching turned up a few options. Out of those options, I would say the top two are: PDANet+, which as been around for many years and EasyTether, a more recent addition. On the phone-side they are both paid apps on the Google Play Store, and while I own both, I have found EasyTether to work with more devices and it also seems to use closer to the phones full network speed.

What this looks like then is on my Android phone I use a paid app named EasyTether and on my laptop I use a free piece of software also named EasyTether. The creators of EasyTether provide client-side support for Linux, Windows, Mac, and some specialized devices. I personally have used it with Linux, Windows, and a few specialized routers. EasyTether can connect to the phone via Bluetooth or USB. The USB option is faster and will also trickle charge your phone. The Bluetooth option is good if you are unable to plug your phone in (i.e. you are also using it and having a cord is annoying) but are within 25 or so feet of your client-end (i.e. laptop), but Bluetooth 3 and 4 have a ~25 megabit/second limit. This means that you will run into a big bottleneck with Bluetooth while with USB you will probably top out your cell network bandwidth before you hit the 5gigabit/second limit of USB 3. These limits are of course on paper and other factors come into play.

My initial thought was to use a Raspberry PI and tether my phone to it, but that meant the access point was software which has never been very good in my experience. Then I got to thinking about specialized travel routers. After some searching and reading reviews I found the GL.iNet GL-AR750S-Ext Travel Router, hereafter referred to as the ar750s to keep things easy for me. The ar750s is a dual-band (2.4GHz and 5GHz) router, with external antennas, running OpenWRT (Linux-based) firmware and it has 3 gigabit Ethernet ports. The OpenWRT firmware can be customized in just about any way you could imagine. The ar750s has built-in OpenVPN client and server, dual flash, ac750, external storage (micro-SD), and has a bunch of included utilities. One of its features is the ability to connect to an existing WiFi as an extender, act as a broadband router, and the list goes on.

After I ordered the router from Amazon I expected to have to do a bit of hacking to make their pairing work, but it turns out both GL.iNet and EasyTether work together already. GL.iNet has a nice EasyTether guide. The only difference for me was the EasyTether version needed to be a newer (latest) version instead of the quite old one reference in the guide. If for some reason that guide is no longer available, what you need to do is extract the EasyTether file on your computer, find the ipk under “*\ar71xx\generic” and scp it to the router, ssh to the router as root (using whatever password you set in the web interface), run “opkg update” and “opkg install . Once you have the IPK installed, you need to run “easytether-usb” to set it up. Then edit /etc/config/network and add “config interface ‘wan’ \ option ifname ‘tap-easytether’ \ option proto ‘dhcp'” (where the “\” is, put a newline). Oh, and you will need to have USB debugging enabled on your phone.

This setup works pretty darn good, but requires ssh’ing into the router each time you want to bring the connection up or if it dies. So I wrote a simple SH script, available from my github. In case that dies, here it is in all its glory:

#!/bin/sh

# Version
version=0.04

# A simple script that checks for connectivity (including working DNS resolution)
# If no connectivity, reset tethering
#
# Requires easytether-usb to be installed and already setup/working
# Manual (one time) setting of the USB device ID of the tether device (TETHERDEV).

# Find the tethering device with lsusb. Example (Samsung/Verizon kids tablet):
# Bus 001 Device 013: ID 04e8:6860 Samsung Electronics Co., Ltd Galaxy (MTP)
TETHERDEV=04e8:6860
# 04e8:6860 is for Samsung’s USB identification (both Note 10 and kids tablet)

# Some highly available website to check (www.google.com is backed by lots of servers)
CHECKWWW=www.google.com

# How long before we check again?
SLEEPITOFF=60

while true; do
curl –connect-timeout 10 $CHECKWWW > /dev/null 2>&1

if [ $? != 0 ]; then
# No internet
echo “Network down, Houston we have a problem!” # FIXME: For debugging
# Reset the USB device
usbreset $TETHERDEV
# Wait a few seconds for device to be ready again
sleep 5s
# (re)start easytether-usb to make a connection
easytether-usb
else
# Internet working
echo “Network up, all good in the hood!” # FIXME: For debugging
fi
sleep $SLEEPITOFF
done


I put this file /usr/local/sbin and make sure it is executable. Then we need to edit /etc/rc.local (just before the ‘exit’) and add “/usr/local/sbin/fixnet.sh&” so it will start at boot. Be sure to change the TETHERDEV to match the USB ID of your phone (found with “lsusb”) in order for it to work. I use curl instead of ping, because ICMP packets are filtered/blocked in my testing.

Once you have everything up and running you only need to enable EasyTether USB on your phone via the app and plug it into the USB port on the router. The router is very easy to use and once configured I rarely need to do anything other than power it on. Speaking of power, the ar750s runs great from a battery pack. The battery pack that I use to charge my phone on the go will also power the ar750s for several hours.

So that covers mobile data (traveling) and places that have no Internet, but what about when I’m at a hotel or using some other network (be it WiFi or wired) that cannot be trusted? Well, for those incidents, I prefer to have my devices behind another layer of isolation via the ar750s. The ar750s supports being a router via Ethernet as well as acting as a WiFi repeater. If the hotel WiFi is not encrypted (often the case) I like to use OpenVPN whenever possible to close the gap. When I am using the router without my phone, the above script will keep trying to reset USB and connect EasyTether to a non-existent device. This has not caused any problems for me. However, it might be a problem if you try to use the USB port for something else – so be warned!

Nextcloud and Docker with Apache Proxy

I decided I wanted to try migrating away from Dropbox, Amazon Drive, and Google Drive to my own server using open source tools. After a bit of research I determined Nextcloud would be the best fit for what I wanted to do right now and some optional features later on. Nextcloud can be installed via packages in the major distributions, but I wanted to use this opportunity to test drive Docker at the same time. One of the reasons I wanted to use a container was so that the installation is mostly isolated from the host install which is good for security purposes but also makes it easier if I want to migrate the whole thing to a different host later on. Now the host I want to use already has a web server, Apache, listening on ports 80 and 443, so we’ll configure it to act as a proxy between the web server in the Nextcloud Docker image and the client. This will also fit well with the SSL certificate the host has.

The first step is getting Docker installed and running. This is pretty easy for most distributions and is covered in detail on the official Docker Community Edition site for Ubuntu, CentOS, and the Gentoo Wiki even has instructions as well.

Once you’ve got Docker up and running. let’s test it out first:

docker run hello-world


This should download the hello-world image and run it.

Now, let’s get to docker. First let me mention that I already have a database (PostgreSQL) that I used so I’ll skip that step here, but if you don’t already have a database available now would be the point to pause and go get that resolved. Since data is not saved between Docker containers, we will need to instruct Docker to create a mount point for the Nextcloud image that will keep our data safe. This can be accomplished with the ‘-v’ flag. We also need to tell Docker what port we want to open up, but in my case I don’t want it using port 80 or 443 so we’ll have to further instruct Docker to forward the port in our ‘-p’ flag.

docker run -d -v nextcloud:/var/www/html -p 8181:80 nextcloud


In the above command I have select port 8181 on the host to be passed to port 80 on the Nextcloud Docker image. Once the Docker container loads completely you should be able to access it via http://your_ip:8181 and see the setup page, but before we do that let’s setup our proxy.

On the host side we will create an Apache vhost with a few lines like this:

:80>
ServerName nextcloud.my_domain.com
http://localhost:8181/
Redirect permanent / https://nextcloud.my_domain.com


:443>
ServerName nextcloud.my_domain.com

>
Require host localhost
Require all granted

ProxyPass / http://localhost:8181/

ServerEnvironment apache apache


Header always set Strict-Transport-Security “max-age=15552000; includeSubDomains”


SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/my_certificate.pem
SSLCertificateKeyFile /etc/my_certificate-private.pem
SSLCertificateChainFile /etc/my_certificate-full.pem


What this configuration does is force all non-SSL connections to use SSL. Then under the SSL configuration it proxies all connections to port 8181 on localhost where nextcloud is running. Then finally we use our SSL certificate from the host. Don’t forget to setup DNS for your nextcloud domain!

At this point we should be ready to continue with the setup via web. Load up https://nextcloud.my_domain.com in your web browser and follow the on-screen instructions. One of the pages should detect the proxy setup and ask for additional domain(s) to be configured so be sure to add https://nextcloud.my_domain.com to the list in addition to http://host.my_domain.com:8181 (if desired).

One final step that I suggest is setting up a cron job on the host (not inside the Nextcloud Docker image). I have mine set to run ever 15 minutes. In order for this to work we need to install sudo in the container by entering the container:

docker exec -it 16765e565e25 bash


Update apt sources:

apt-get update

Install sudo:

apt-get install sudo


Now finally on the host (NOT container) create a crontab with this line:

*/15 * docker exec -d /usr/bin/sudo -u www-data /usr/local/bin/php /var/www/html/cron.php


Be sure to replace with the real one which you can find by running ‘docker ps’ on the host.

At this point you should have a fully functional Nextcloud server!

Client PPtP Connection From A VM

I encountered an issue recently with trying to make a PPtP connection from a Linux VM as the client to a remote commercial device or server where the GRE packets were being dropped. The same PPtP credentials worked on another server that is bare metal. This lead me speculate that the issue might be something between the routing devices and the client. After a bit of investigative work with wireshark I discovered the GRE packets were in fact getting to the virtualization host but not to the guest VM. I suspect this issue may be present with other types of virtualization software, but to be clear this particular VM host is running KVM/QEMU.

It has been a while (read: years) since I’ve done much with PPtP beyond just using it. Adding a configuration that was working on another server to this particular system I discovered the connection would not complete much to my dismay. Looking at what ppp logged to the system log revealed it never got a proper GRE reply. Well, there were a lot of things in the log but the one that stood out looked like this:

warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error


After a bit of Googling and reading the documentation for pptp-client I decided re-try the setup on the previously mentioned working system and watch the log closely for further clues. Where the second system was failing the original system sailed right past and worked fine. My next attempt was to look at what connections the first system had going which lead to me realize and make a mental connection to the documentation/Googling had revealed about PPtP using protocol 47 (GRE) on TCP port 1723 for the control. Watching another attempt on the second system showed the outgoing request for GRE but nothing coming back. Repeating the last test but watching for incoming GRE on the host showed that it was being received but not being passed on to the guest VM. Looking at my options I discovered that there is a whole set of modules and a kernel configuration option to allow forwarding of PPtP.

The missing pieces to the puzzle include adding a line to your sysctl.conf:

net.netfilter.nf_conntrack_helper=1


Then loading these kernel modules:

nf_conntrack_proto_gre
nf_nat_proto_gre
nf_conntrack_pptp
nf_nat_pptp


As soon as these were in place PPtP started working as expected in the guest VM. What started out as a mystery turned out to be a fairly simple solution. While there are probably not a lot of people still using PPtP these days, it is a better alternative to using a proprietary VPN client.