root

Slightly unrelated: what's the highest WiFi speed you achieved with the TinkerBoard? Mine doesn't seem to be able / willing to go beyond ~45 Mbps (access point is 2 meters away, no line-of-sight though - but no massive obstacles either).

Interesting, I wouldn't have thought of this - but it makes sense. With a Tinkerboard, Armbian and Wireguard I was able to get ~600 Mbps from the Tinkerboard to the Internet. I think I tested this up to 750 Mbps in my LAN (desktop to Tinkerboard), but the TB's CPU got really hot (I had to take the cover off in order to keep it running). Plus - with a single network interface, you're constrained to either an "out of band" gateway setup (the Tinkerboard is just another LAN box and your router provides the Tinkerboard's IP address as the default gateway to the other clients) or you're stuck to the ~250 Mbps that you could get through an USB network adapter (as there's no USB3 on the TB).

Try iperf3 instead - I found speedtest results to vary greatly (even when testing against the same server, which can be specified in the command line) for no apparent reason. Some public servers are listed at https://iperf.fr/iperf-servers.php.

Then choose a new one :). Or set up a VPS "near" (latency-wise) your provider which you can use as an intermediate Wireguard hop and do OpenVPN from that VPS to the provider. If you want more speed out of OpenVPN, the only choice is a better CPU. The performance scales pretty much linearly. Before Wireguard, I had a dual setup: OpenVPN set on the router (which was effectively capping all my "default" outgoing connections to ~25 Mbps) and then individual OpenVPN clients on the high-speed devices (desktops/laptops) which could take advantage of the faster CPU. That assuming your provider permits parallel connections and that you can set up proper exclusions at router level so that outgoing connections from the LAN to the VPN provider do NOT go through the default connection (so you don't do "VPN inside VPN", but rather through the public (ISP) gateway.

OpenVPN is dated. It is single-threaded and userspace (so no taking advantage of multiple cores and wasting a lot of CPU time switching back and forth between kernelspace and userspace). If you want a fast VPN on low-clock CPUs (so excluding the likes of i3/i5/i7, where the single core speed is sufficient), the solution you are looking for is Wireguard. Or possibly IPSec, which I haven't tested, but heard of being a pain to configure. Some speed tests I did a year ago: I was able to max out the Tinkerboard (RK3288) at about 650 Mbps with Wireguard in the meanwhile. As I upgraded my connection to gigabit fiber, I ended up getting a Zotac box with 2x LAN ports and a Celeron N series CPU, which does 900 Mbps easily. You have a brief tutorial on setting up Wireguard in that thread - or you can use one of the alternate sources in the Internet.

Confirmed about the onboard GbE - I got 930-940 Mbps out of with iperf. That's why I was thinking to use it as an "in-network gateway", which would be sufficient for my upgraded connection (450 Mbps down / 40 Mbps up). What I mean by that: That's what I was testing in the meanwhile: Current setup: PC -cable1-> router (Netgear R7000) -cable2-> Tinkerboard GbE interface -internal-> Wireguard encryption -internal-> Tinkerboard USB ethernet -cable3-> modem Tested setup: PC and Tinkerboard both plugged into LAN ports on the router (TB using the onboard GbE). The router WAN port goes to the modem. The packets travel PC -> router -> tinkerboard -> they get encrypted here -> router -> modem. I was able to get ~400 Mbps of Wireguard-encrypted traffic through the Tinkerboard, at the cost of ~45% CPU usage for Wireguard encryption. I *think* it could do up to ~600 Mbps without overheating the TB or consuming all the CPU. In the end, the point is relatively moot: - in my current setup, the bottleneck is the USB adapter. - with a single GbE (as tested above), the bottleneck is the GbE interface, which needs to do both the "in" and "out" (so would share its 1 Gbps). - with dual GbE (if they existed), the bottleneck would be the CPU, as it couldn't cope with 1 Gbps symmetric traffic. I know the Turris Omnia. Nice tools, but sadly, they're just 2x 1.6 GHz. The box on the Amazon link looks really interesting. Does anyone have any experience with Wireguard on J1900-based boxes? I cannot find a direct comparison in terms of computing power between the J1900 and the RK3288.

It appears to be a Lenovo adapter. lsusb output is too long to paste here, but it seems to be supporting all USB modes. Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) I'm using my TB as a VPN gateway (between the router and the modem, the router is effectively just a hub and Wifi AP in this setup). It worked fine on my 200/20 Mbps connection (getting full speed both ways), but since upgrading my line this has become the bottleneck. What if I just plug it into my router (gigabit on all ports) using the onboard GbE and then declare it as a gateway for all my network? Granted, the up/down traffic would flow on the same interface, so I'd never get a symmetric Gigabit connection, but it's better than 200-something Mbps, isn't it? That failing, any suggestions of a board / mini-PC which: - has at least a quad-core @ 2-something GHz or equivalent - has at least two physical GbE interfaces - runs Linux - (ideally) is fanless?

Anyone here playing with USB network adapters? I have a (noname) USB3 Gigabit ethernet adapter which seems capped at 250 Mbps. I know the Tinkerboard only has USB 2.0 (so a theoretical maximum of 480 Mbps), just trying to see if there are better parts out there I could try.

Hi @lampra. As far as I remember, I couldn't get it compiled with 4.11, as I couldn't find any suitable kernel headers version. My solution was to switch to the stretch branch - I could find everything I needed for that. Here's how my apt sources.list file looks like (note the last line): root@tinkerboard:~# grep -v ^# /etc/apt/sources.list deb http://ports.ubuntu.com/ xenial main restricted universe multiverse deb http://ports.ubuntu.com/ xenial-security main restricted universe multiverse deb http://ports.ubuntu.com/ xenial-updates main restricted universe multiverse deb http://ports.ubuntu.com/ xenial-backports main restricted universe multiverse deb http://beta.armbian.com/ stretch main restricted universe multiverse utils xenial-desktop root@tinkerboard:~# To switch to the latest kernel - note I run a Tinkerboard (RK3288) rather than a Cubieboard (A20). Your image name will differ -- most likely you need linux-image-dev-sunxi and linux-headers-dev-sunxi. After that (and a reboot) - do a full update (apt update && apt upgrade) and then follow the tutorial on wireguard.io: add-apt-repository ppa:wireguard/wireguard apt update apt install wireguard-dkms wireguard-tools As a side note, I was running the dev since my posts above (all the 4.14-rcX series, now just upgrading to 4.15.0-rc2) with zero stability issues.

Wondering if Jason (@zx2c4) is still hanging around here... Question: is there a description / manual for the Wireguard config file syntax (i.e. all possible parameters)? Background: I have two Wireguard tunnels set up. The first (call it wg0) is my "main" interface (all traffic is routed through it); the second (wg1) is only a site-to-site connection to a different location. So when going from my location to the remote location, the wg1 traffic goes through wg0 until it hits wg0's endpoint and over the public Internet afterwards. Problem: I cannot set up the second interface (wg1) using wg-quick - or, more accurately, I can bring it up using wg-quick, but I cannot bring it down. When I do "wg-quick down wg1", the entire connectivity goes MIA. Obviously, I am not too keen to do that on the remote site, where I don't have "hands and eyes" to reboot the box, so I ended up building my own (ugly) script to start and stop the tunnel. The exact moment where everything dies is (I have added a "set -x" in the del_if() function in wg-quick): + cmd ip -4 rule delete table main suppress_prefixlength 0 + echo '[#] ip -4 rule delete table main suppress_prefixlength 0' [#] ip -4 rule delete table main suppress_prefixlength 0 + ip -4 rule delete table main suppress_prefixlength 0 My limited understanding says wg-quick is taking down the main (routing?) table, which causes all connectivity to collapse. I am therefore wondering if there is a way to tell wg-quick that this is not a "main" tunnel, i.e. it is not supposed to use it for redirecting / un-redirecting all traffic (similar to OpenVPN's "redirect-gateway def1" option). I googled a fair bit, but couldn't find anything.

Oct 28th, says dpkg logfile. CVE-2017-13704 doesn't show in the changelog for the package though (but that's not an Armbian thing at all, purely Ubuntu - and I'm not being ironic).

Fair point. For most users, however, this is a philosophic rather than practical distinction. Perhaps a more recent package in the beta.armbian.com stretch repository would help? In the meanwhile, I have updated the package myself, took the best part of 5 minutes.

You may have read about the recent (one month ago, but hey, what's a month between friends?) security vulnerabilities discovered in dnsmasq. They have been patched in version 2.78 and, quoting the author: This is a bugfix release, and, amongst other things, addresses a set of serious security vulnerabilities. Update should be mandatory. The dnsmasq shipped with Armbian is a rather old 2.75 and it is enabled by default, so I see this as a rather significant risk. I have compiled the latest version and installed it by hand, following the instructions located here (obviously, with 2.78 instead of 2.76). Is there any chance of getting this package updated in the repository for Xenial Xerus (16.04.3 LTS)? My particular Armbian install version is 5.34.171105 (nightly, that is). The same stands for OpenVPN, which comes as an outdated ancient 2.3.10 (current being 2.4.4).

Thank you Jason (and Igor and Myy). Next hurdle from me: booting from a USB stick. All the tutorials I see reference Linaro-based distributions, which have a configuration file in /boot. I assume it's slightly more difficult with Armbian...

Until getting a second adapter, I set off to see if there's anything else that can be done with my current hardware. And... there is. I managed to make the TinkerBoard my VPN router using Wireguard. It would be similar with OpenVPN, but (see figures above) speeds are not that exciting. If anyone else is interested, here are the steps. I assume you are using a "standard" setup with your end equipment (laptops, PCs, TVs etc) connected to a router (I have a Netgear R7000), which in turn is connected to a cable modem / fiber modem / any other sort of uplink. What you need: TinkerBoard (TB for short) running Armbian, power supply, a network cable, case (optional, using the RPI 3 standard one), a WireGuard or OpenVPN connection to a remote endpoint. 1. Install Armbian on the TB. 2. Connect your TB to the router using a wired connection. You will get an IP address, say 192.168.1.5. The router is 192.168.1.1 and your PC is 192.168.1.10. 3. Perform a full update (apt update && apt dist-upgrade) and reboot (you will likely need to power cycle the box, mine doesn't reboot properly). --> Note: I believe the OpenVPN package in the Armbian is a bit old (I think I saw 2.3.10, current is 2.4); this may give you trouble with some options. 4. Set up your WireGuard or OpenVPN connection on the TB. Note Jason's hint above about removing the ipv6 route. Install the iptables package (apt-get install iptables). 5. Bring up your WireGuard or OpenVPN tunnel. You will get a new interface (called as you wish - we'll use wg0 for the Wireguard one and tun0 for the OpenVPN). So far so good, all standard steps. Now comes the slightly trickier part. 6. On your router, in the DHCP options (this typically sits in the LAN chapter, YMMV), set the default gateway (the one which gets sent out to clients) to 192.168.1.5 (the IP of the TB). 7. On the TB, issue the following commands to enable packet forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward /sbin/route add default gw 192.168.1.1 dev eth0 /sbin/iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT /sbin/iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE Above - eth0 is the router's interface which carries the IP address 192.168.1.1. wg0 is the Wireguard interface on the TB (tun0 would be VPN one). If you want to make the changes permanent, edit /etc/sysctl.conf for ip_forward and add the iptables and route lines somewhere (I'm lazy, so I've put them in rc.local) 8. Reconnect your computer to the LAN (replug the cable, ipconfig /release and /renew and so on). Your gateway should now be 192.168.1.5 (instead of the old 192.168.1.1 9. Try pinging a remote host, should work. Try a traceroute, the first hop should be 192.168.1.5, the second 192.168.1.1, the third your Wireguard/OpenVPN remote end. 10. If you have any special routes declared on the old router, you will need to carry them over to the Tinkerboard. For instance, add the necessary commands to rc.local (yes, lazy). 11. If everything works, don't forget to make your tunnel start automatically, prior to any iptables / route invocations. OpenVPN starts as a service, for Wireguard I've set a manual call in (no surprise...) rc.local. The result: I'm maxing out my Internet connection (200+ Mbps down) while using Wireguard. In order to do that with OpenVPN, I would have needed an i3 (at least, if not an i5) processor. I'm happy. Thanks to the Armbian team, to Jason for Wireguard, to Mullvad.net for providing the testing infrastructure.