Firmware Builds: v1.4.2 Commit 1652ef7

I made some builds of a slightly newer commit of the v1.4.2 branch. The reason was to get an additional security patch, and also to get a few more utilities and networking tools into the build.

These builds can be download through the Transmission BitTorrent client, which uses Distributed Hash Tables (DHT). You have to select File >> Open URL… and then paste in the magnet link.

  • libreCMC v1.4.2 commit 1652ef7 source
    • magnet:?xt=urn:btih:39bb40c25ddffbb8c3eeefdd7e685a29facf506b&dn=librecmc-v1.4.2-c%5F1652ef7.tar.gz
  • libreCMC v1.4.2 commit 1652ef7 TPE-R1100 Build
    • magnet:?xt=urn:btih:80ddaac008cf57a190ac7be2cb25c95a4ecf67f3&dn=librecmc-v1.4.2-c%5F1652ef7-ar71xx-generic-tpe-r1100-squashfs-sysupgrade.bin
  • libreCMC v1.4.2 commit 1652ef7 GL-AR150 Build
    • magnet:?xt=urn:btih:08fe7a21073a7622c65d52b60877d792cda78ec8&dn=librecmc-v1.4.2-c%5F1652ef7-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin

I haven’t started the GL-AR300M build yet.

Non-default features:

  • Luci + OpenSSL (instead of mbedtls)
  • Nano, Vim, and Zile editors
  • Default and Material LuCi theme
  • openvpn-openssl, openvpn-easy-rsa, luci-app-openvpn
  • nmap-ssl, nping, wget (full version) and tcpdump networking utilities

This bumped the image sizes up to 7.6 MB.

The patched vulnerability was CVE 2018-5332.

OpenVPN packages are included because of my OpenVPN projects. I find the nmap, nping, and tcpdump utilities useful when trying to troubleshoot an advanced network configuration issue on the router, such as when I couldn’t figure out why my OpenVPN tunnel didn’t seem to be working.

 

Layer 2 OpenVPN Endpoints

One idea I had for libreCMC was to run a Layer 2 OpenVPN tunnel with both server and client being libreCMC nodes.For the uninitiated: a Layer 2 OpenVPN tunnel allows someone on the client network to see the server network, as though he was directly plugged into the server network with an Ethernet cable. In other words, it allows you to remote into your home or work network from anywhere on the Internet.

“Layer 2” means that the traffic communicated by the VPN is straight from the Data Link layer (layer 2 in the OSI model), which is to say that the VPN (Virtual Private Network) becomes a long-distance Ethernet switch. OpenVPN setups usually are done in Layer 3 mode, which is on the IP layer (i.e., long-distance router). In my particular use case, I wanted a Layer 2 VPN because I wanted my customer to have a more direct access to the subnet, which I figured would make it simpler to access printers and file shares and such. If I had realized how little community support is available for Layer 2 OpenVPN, I might have chose a Layer 3 VPN instead. There also are a few other good reasons to prefer Layer 3 VPN. But at least I can say I’ve learned a little more than the average Joe in the process.

My idea was to set up one libreCMC node (a TPE-R1100) on the work LAN as the OpenVPN server, and then another libreCMC node (a GL-AR150) would be the OpenVPN client, which could be pocketed for business trips and such. So, someone with the client node would simply need to know the Wi-Fi password and then have access to the resources on the work LAN.

This has the advantage of simplicity as then I don’t need to run or configure special VPN software on the customer’s devices. Of course, it raises some obvious security concerns; but at least if the client node is stolen, that is pretty obvious and I could shut down the VPN or cut off that client’s access.

It was very challenging to figure out how to generate the certs and keys and such, and the put the right OpenVPN settings on both server and client. It was a slow process of many hours, tweaking the configuration settings, reading the logs for errors, and then looking at the the OpenVPN manual page for hints at what I must have set wrong. As I mentioned, there is unfortunately very little community help for folks wanting to set up a Layer 2 VPN, but the manual page gives very good descriptions of the configuration options. It is important that client and server have compatible settings.

In the most recent troubleshooting step, I figured out from the logs that the server and client were in fact communicating data properly (I could see MAC addresses from the client side showing up in the server logs) but for some reason I still could not send ICMP pings or HTTP traffic across the VPN. I discovered that actually it was a problem not with the VPN tunnel, but rather that my client interface configuration was somehow not allowing data to flow properly from my client bridge interface to the TAP VPN interface. (More on this later.)

I figured out a way to fix this problem, and the fix worked, and I was able to ping across the VPN tunnel both ways, as well as access an HTTP server. That was very encouraging. However, in the processes of committing the final settings, I accidentally set the the network setting wrong, and cut off all network access to the client node (“soft brick”). That was rather annoying. Fortunately though, I saved the working configuration, so tomorrow I should be able to reset the node and reload the configuration, if I am not too busy.

Once I’ve fixed my setup, I’m planning to finish the official documentation I have been working on, and also post more about it here on the blog.

libreCMC SSH Public Key Authentication

libreCMC uses dropbear SSH server. I was a little confused because I tried to put my id_rsa.pub and other *.pub files into ~/.ssh/authorized_keys, but that didn’t work. I discovered that you can use your ssh public keys, but you have to put them into /etc/dropbear/authorized_keys instead. Also, be sure that the authorized_keys files is set to 600 or 640 permissions.

There is also a box in the LuCi interface under System >> Administration for pasting in SSH keys. A trick though is that you must make sure that the paste process does not add any line breaks. And that is something that is pretty easy to do when trying to copy and paste out of a terminal.

I’m thinking one could hack the init files or something to make it use ~/.ssh/authorized_keys instead. But I believe that the root home directory is not preserved across firmware upgrades, so this would not be a good idea.

libreCMC v1.4.2 builds

These builds can be download through the Transmission BitTorrent client, which uses Distributed Hash Tables (DHT). You have to select File >> Open URL… and then paste in the magnet link.

I tried to put the magnet links inside hyper links, but wordpress.com mysteriously sanitizes out the important parts of the link.

  • libreCMC v1.4.2 source
    • magnet:?xt=urn:btih:000c0f25b4589eb5266569aa2af00b050795e876&dn=librecmc-v1.4.2.tar.gz
  • libreCMC v1.4.2 TPE-R1100 Build
    • magnet:?xt=urn:btih:f562a5919d6ff40ee5e8e7134740675eef551938&dn=librecmc-v1.4.2-ar71xx-generic-tpe-r1100-squashfs-sysupgrade.bin
  • libreCMC v1.4.2 GL-AR150 Build
    • magnet:?xt=urn:btih:0b03eef2b80f3be6872a850ebadf8095e30bbcfd&dn=librecmc-v1.4.2-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin
  • libreCMC v1.4.2 GL-AR300M Build (NAND)
    • magnet:?xt=urn:btih:2eda6279be9c42e8bbbbcb0fb800041c8ed76bcb&dn=librecmc-v1.4.2-ar71xx-nand-gl-ar300m-ubi-factory.img

These builds are similar to the official ones, but they have also the Zile text editor and the Material theme installed, as well as OpenVPN packages.