Hardware Linux Networking Software

Ideal travel router: GL-AR750S

Right. With the pandemic and all none of us are going to travel much but still…

About a year ago I purchased myself an OpenWRT router to use on the plane and in hotels.

And so far I really like both the device and the Hong Kong based brand (launching new and updated products, and releasing relatively regular updates for older products). Pick a device that fits your needs (USB powered? LTE? Small form factor?).

The GL-AR750S aka Slate is fully customizable but runs a few nice things out of the box: WireGuard (with a physical button to turn it on or off), OpenVPN, shell access, Tor (requires the latest firmware), IPv6, DoH (Cloudflare only for now), multiple SSIDs (i.e. Guest WiFi), and more.

Oh and I specifically picked this version (compared to other or cheaper ones) because it had both 2.4Ghz and 5Ghz, as well as 3 Gbit ports (1x WAN, 2x LAN).

Pick whatever works for you…

I use the device on flights, where I connect to the network once in the air, purchase WiFi or use iPass “for one device” and then connect to the interwebs behind my NAT-router from my iPad, phone(s), laptop(s), and even Shan‘s devices if she is travelling with me.

In hotels, I either connect it to the wired ethernet, if still available (tends to be more stable), or connect it to the guest WiFi and then connect my devices to the router: saves me from connecting to a new network and typing the room number and login/password/family name on every device. And once again hides the true number of connected devices; quite handy trick for those pesky hotels providing free access only to two devices.

Sure it takes a bit of setup every time: find a working USB port, sign in to the web interface, search for new networks if this is a new hotel or I haven’t travelled on this airline, connect to said network, sign in with iPass, and optionally enable VPN)…

And once in a while some fiddling with VPN or DNS that’s borking up or being blocked by overzealous firewalls.

Also, some in-flight entertainment USB ports don’t provide enough power (and/or are often broken — looking at you Lufthansa in economy) so be sure to carry a couple of these (US-plug works best) — I’ve already forgotten one on my last flight from MUC-SIN on LH, but luckily I have pretty easy access to these.

If you travel a lot it’s totally worth the money.


Graph amount of OpenVPN users to Munin

Rather simple script. Using log file instead of management interface.


Part has to run as Root (due to Munin most likely not having access to read the log files. Working with the management interface could solve this.

Create /usr/local/bin/

echo "VPN.value `cat /var/log/openvpn-status.log | sed -e '1,/Common Name/d' | 
sed -e '/ROUTING TABLE/,$d' | wc -l`" > /tmp/.vpn_munin.txt

You can change the name of VPN.value to the VPN name and/or add multiple lines (each with a different NAME.value if you’re running more than one VPN user. Be sure to cat the right log file).


chmod +x /usr/local/bin/

Add this to root cron:

*/5 * * * * /usr/local/bin/ >/dev/null 2>&1

Now create /etc/munin/plugins/vpnusers:


case $1 in
 cat <<'EOM'
graph_category network
graph_title oVPN users
graph_vlabel users
VPN.label My oVPN
# add more labels like this:
#isazi.label Isazi VPN
 exit 0;;

cat /tmp/.vpn_munin.txt


chmod +x /etc/munin/plugins/vpnusers

You’ll need the correct NAME.label in the plugin depending on the name you choose in part one.

And restart munin-node:

/etc/init.d/munin-node restart

That’s it.

Check your Munin under “network”. It might take ~15+ minutes before the graph is generated.


Apple Errors Linux Networking Software

OpenVPN: Can’t assign requested address

For no clear reason, OpenVPN on Mac with Tunnelblick (any version, had this problem for a few years already) results in these kind of error messages (and refuses to connect):

2013-02-05 17:44:31 write UDPv4: Can't assign requested address (code=49)
2013-02-05 17:44:33 write UDPv4: Can't assign requested address (code=49)

This seems to appear more often when swapping WiFi/IP range (after my Mac goes into sleep). But also happens when connecting to the same WiFi. It doesn’t change anything whether I disconnect OpenVPN before putting the Mac to sleep.

The solution I’ve found to solve this is:

  1. Disconnect OpenVPN (via Tunnelblick)
  2. Turn off WiFi
  3. Run the script I’ve attached below (
  4. Fill in your admin/sudo password
  5. Hit ctrl+C if it doesn’t exit instantly (happens in 99% of the cases)
  6. Run the script once or twice more to be sure, it will exit correctly this time
  7. Reconnect to the WiFi
  8. Reconnect OpenVPN (via Tunnelblick): this time it will work

The script (name it, chmod +x, and run ./ via Terminal):

Edit: updated script (29/01/2014)

# Change IFACE to match your WiFi interface 
# (en0 on Macbook Air and Retina, en1 on old Macbook Pros with ethernet) 
sudo ifconfig $IFACE down
sudo route flush
sudo ifconfig $IFACE up

In case the script hangs (sometimes, route flush hangs): hit ctrl+C, and execute it again.

Errors Linux Networking Software

OpenVPN packet drops

I recently started to notice following error messages on my openVPN server.

ovpn-server[6306]: MULTI: packet dropped due to output saturation (multi_process_incoming_tun)

This basically means that the TUN or TAP interface is making more packets than the real (TCP) interface can handle.

As I need to run OpenVPN using the TCP protocol (instead of the faster UDP protocol; as UDP is often blocked in networks I use my VPN in) I experimented by increasing the tcp-queue-limit. The default is 64, and I’ve set it to 256. So far, everything still seems to be working fine (but more packets will be queued before being dropped by OpenVPN, requiring less retransmissions).

Add this to the OpenVPN server config:

tcp-queue-limit 256

And restart the daemon.

Errors Networking Software Windows

OpenVPN & Windows 7

There’s a great GUI out for OpenVPN & Windows, located here.

However, this GUI includes an old OpenVPN, that is no longer compatible with Windows 7 and Windows Vista.

The TUN/TAP driver will be blocked due to compatibility issues, and when trying to connect to a VPN, you’ll get an error along the lines of:

All TAP-Win32 adapters on this system are currently in use

The simplest fix, is to install the GUI package (including the old OpenVPN binaries), and reinstall OpenVPN afterwards.

You can find the latest OpenVPN binaries here and the latest version, when writing this post here.

This will overwrite the old files and update the driver with a Windows 7 compatible driver.

Try to connect now, everything should work like a charm. 🙂