Routers Linux Embedded DE
Tired of proprietary firmware, John Lane gets to grips with LEDE, and discovers that his router is actually quite good...
Tired of proprietary firmware, John Lane gets to grips with LEDE (think an updated OpenWRT) and discovers that his router is actually quite good…
The Linux Embedded Development Environment, or LEDE, is a fork of the long-standing OpenWRT project. This is a Linux distribution for embedded devices, in particular network routers. It’s a complete replacement for the vendor-supplied firmware of a wide range of wireless routers. If your device is supported, then installing LEDE on it will release its full capabilities and enable you to fix vulnerabilities when vendors won’t.
In this tutorial we’ll set up a new LEDE router with basic internet connectivity and perform some customisation as the initial steps towards enjoying the full capabilities of this open source firmware. By doing this we’ll look inside this custom Linux distro and learn some of its configuration.
Support me!
Visit the LEDE website at https://lede-project/toh to find out if your device is supported and, if so, follow the instructions there to install LEDE on it. The process is very device-specific, as is the level of support that depends on the device’s specification – such as its chipset and amount of memory. You might even need to open its case to access its serial console port and may also need to use a soldering iron to connect to it.
Bear in mind that installing custom firmware on your router is most likely to void any warranty it might have, especially if hot molten metal is involved!
We’ll assume you already have a LEDE-capable device and have followed the device-specific instructions to install it. We used a BT Home Hub 5 (refer to the Introducing Our Router box for more information, aboveright) and then installed LEDE 17.01.04, which doesn’t suffer from the recently highlighted Krack WiFi vulnerability.
First contact
Before we begin, a little network setup may be required. You can perform preliminary configuration of your LEDE router alongside and without disturbing any other router you may have; you can keep your internet connection working and switch over when ready.
The default LEDE configuration sets the router’s IP address to 192.168.1.1 and runs a DHCP server that leases addresses in that \24 subnet. These are the same defaults that many routers use, so if this clashes with your network, you might want to disconnect your computer from it first. If your network differs (perhaps you’ve used the 10/8 or 172.16/12 private address ranges), you can use ip to manually assign an ad-hoc IP address like this: $ ip add address 192.168.1.10 dev eth0
Use an ethernet cable to connect the LEDE router. If your existing router uses the same address then you’ll need to temporarily connect the LEDE router directly to your computer to change its address as we describe below. Otherwise, connect it to a spare port on your existing router. Power it on, allow it some time to boot and then check that it’s accessible: point a web browser at http://192.168.1.1 to reach the LuCI (the Lua Configuration Interface) console.
LuCI initially has no password (we’ll fix that later). For now, navigate to Network>Interfaces and press the Edit button for the LAN interface. The screen presents options that you should modify to match your own network: choose an address and network mask that’s compatible with your local network. Enter the address of your existing router as the gateway and DNS server, then press the Save and Apply button at the bottom of the screen. If you directly connected the LEDE router, you should now reconnect it via your existing router.
Dropbear here
The initial network configuration should enable you to log in to the LEDE console. LEDE uses the lightweight Dropbear SSH implementation designed for embedded systems while being broadly compatible with the OpenSSH used by desktop Linux distributions. Use ssh to connect to the root account. There’s no initial password, so set one up now: computer$ ssh root@LEDE root@LEDE’s password: root@LEDE:~# passwd
Changing password for root New password: root@LEDE:~# exit
The password that’s just been set may be used to access LuCI, but it’s good practice to use key-based authentication for SSH. First upload your public key: computer$ cat ~/.ssh/id_rsa.pub | ssh root@LEDE ‘(umask 77 && cat >> /etc/dropbear/authorized_keys)’ root@LEDE’s password: root@LEDE:~# passwd Changing password for root New password: root@LEDE:~# exit That uploads your default key, placing it into Dropbear’s
authorized_keys file and ensures that its permissions are correctly set. Now log in again; this time no password should be necessary.
You may now further secure access by disabling password-based SSH logins. This requires modifying LEDE’s Dropbear configuration.
LEDE uses a homogenised configuration format called UCI – its Unified Configuration Interface – for its services. This uses text files stored in one place in the filesystem, at
/etc/config. Being text, you can use git to track your configuration changes which, should you wish to do so, is explained in the box ( overleaf). Dropbear’s configuration is in the UCI /etc/config/
dropbear file. Edit the options within to look like this ( vi is available; you can install nano if you prefer): config dropbear option PasswordAuth off option RootPasswordAuth off
This illustrates the UCI format. It’s plain text broken down into sections with their content indented by whitespace (spaces or tabs). Option values may contain whitespace if they are enclosed within quotation marks. An alternative to manually editing is to use the uci tool. To achieve the above result you would enter commands like this: $ uci set dropbear.@dropbear[0].PasswordAuth=off $ uci set dropbear.@dropbear[0].RootPasswordAuth=off $ uci commit Read https://lede-project.org/docs/user-guide/ introduction_to_lede_configuration to learn more about UCI configuration and the uci command. After changing configuration the affected service must be reloaded or restarted. To restart Dropbear: root@LEDE:~# /etc/init.d/dropbear restart
You should also enable SSL on the LuCI web server because the root password is used to log in to it and would otherwise cross the network unprotected. LEDE provides a package that does this. You use an opkg command to install packages from LEDE’s package repository, but its temporary package index must be updated prior to use. Do that and then install luci-ssl: root@LEDE:~# opkg update root@LEDE:~# opkg install luci-ssl
Bear in mind that it uses self-signed certificates, which browsers will warn about. If you wish, you can edit the selfsigned certificate parameters in /etc/config/uhttpd: config cert ‘defaults’ option days ‘730’ option bits ‘2048’ option country ‘ZZ’ option state ‘Somewhere’ option location ‘Unknown’ option commonname ‘LEDE’
The self-signed certificate will be generated when you restart the webserver, after which LuCI must be accessed using https, because http will no longer work. root@LEDE:~# /etc/init.d/uhttpd restart
On the air
To replace the existing router, LEDE must become the main internet gateway and Wi-Fi access point for your LAN.
Wi-Fi is initially disabled. The parameters in /etc/config/ wireless define a hardware device (wifi-device) for each radio (a dual band router will have two: one for 2.4GHz and another for 5GHz) and a logical wifi-iface interface for each of those. You can edit these parameters to select a channel and to set the SSID identifier and encryption parameters: config wifi-device ‘radio0’
option type ‘mac80211’
option channel ‘36’ option hwmode ‘11a’ option htmode ‘VHT80’ config wifi-iface ‘default_radio0’ option device ‘radio0’ option network ‘lan’ option mode ‘ap’ option ssid ‘LEDE’ option encryption ‘psk2’ option key ‘my secret key’ The initial configuration has a disabled setting. Be sure to remove or comment this out and then initialise the Wi-Fi: root@LEDE:~# wifi up You should now be able to connect a wireless device.
On the wire
The internet, or WAN, configuration is in /etc/config/ network. The required parameters will depend on both your ISP and how the service is delivered; a basic ADSL2+ service in the UK would be similar to this: config dsl ‘dsl’ option annex ‘a’ option xfer_mode ‘atm’ option line_mode ‘adsl’ config interface ‘wan’ option proto ‘pppoa’ option username ‘username@isp.example.uk’ option password ‘my password’ option vpi ‘0’ option vci ‘38’ option encaps ‘vc’ option ipv6 ‘0’ config device ‘wan_dev’ option name ‘pppoa-wan’ option macaddr ‘90:72:82:88:99:00’ They will differ for fibre (VDSL), which typically uses
pppoe. You’ll need to experiment to discover what works with your provider.
You should now remove your original router’s gateway and DNS from the LAN section. Now is also a good time to change the hostname from LEDE if you’d prefer something else. Look into /etc/config/system where you can also set your time zone: config system option hostname ‘gateway’ option timezone ‘Europe/London’
That completes the basic setup. Turn off the LEDE router and reposition it in your network with your DSL line connected to it and then power up. You should see WAN activity and have internet connectivity through the LEDE router.
A host with the most
At this point you have a basic internet gateway pretty similar to that provided by your ISP but with one major difference: decent firmware. You have a managed switch, a powerful iptables firewall, and a DHCP and DNS server. Anything else is probably available through the opkg package manager.
You can configure not only DHCP, but static hosts too, each defined in its own “domain” section within the `/etc/ config/dhcp` file. host blocks reserve DHCP addresses for specific hosts so they always get the same address. Both assign DNS names: config domain option name myhost option ip 192.168.10.1 config host option name otherhost option ip 192.168.10.2 option mac DE:AD:BE:EF:CA:FE You can also configure alternate DNS names using cname blocks: config cname option cname othername option target myhost Finally, a simple firewall rule makes a host accessible from the internet. Firewall rules are defined in /etc/config/firewall and an appropriate port forwarding rule looks like this: config redirect option name ‘Web Server’ option src wan option dest lan opeion dest_ip 192.168.1.2 option dest_port 22 option proto tcp`
Firewall rules work on zones, so the above redirects from the wan zone to the lan zone. Elsewhere in the same firewall configuration file you’ll find definitions that specify what network interfaces are in each zone. The interfaces are defined in the network file. After editing it, remember to reload the relevant configs: root@LEDE:~# /etc/init.d/dnsmasq restart root@LEDE:~# /etc/init.d/firewall restart
Get orf my LAN…
Many networks are being infiltrated by devices other than computers. Phones and tablets, children’s toys, so-called personal assistants like Alexa and whatever else the increasingly popular internet of things may bring. You can keep such devices out of your cosseted LAN using a de-militarised zone, or DMZ, by creating a virtual network interface. We’ll set up a DMZ to help learn more about LEDE’s networking configuration.
If you look at the network configuration, you’ll see that the existing LAN interface is bound to eth0.1, where the suffix tells us it’s a virtual interface. We can create a new virtual interface: copy the lan configuration, rename it to dmz and then use another suffix: config interface ‘dmz’ option type ‘bridge’ ifname ‘eth0.2’ proto ‘static’ ipaddr ‘172.20.0.1’ netmask ‘255.255.0.0’ config device ‘lan_dev’ option name ‘eth0.2’ option macaddr ‘54:64:d9:01:02:03’ We also allocate the new interface a MAC address and its own IP subnet ( ipaddr and netmask). To have the DHCP server issue addresses requires an addition to the /etc/ config/dhcp file: config dhcp ‘dmz’ option interface ‘dmz’ option start ‘256’ option limit ‘255’ option leasetime ‘12h’ The start value defines the first address in the block. In this example that would be 172.20.1.0 and the limit is the number of addresses in the block.
The firewall needs to allow the DMZ to access the internet. We allocate a DMZ firewall zone and specify a forwarding rule: config zone option name dmz list network dmz option input ACCEPT option output ACCEPT option forward ACCEPT config forwarding option src dmz option dest wan You can allocate one or more of the router’s Ethernet ports to the DMZ. The ports attach to a managed Ethernet switch within the router that’s configured using switch blocks in the network file. Our default looked like this: config switch option name ‘switch0’ option reset ‘1’ option enable_vlan ‘1’ config switch_vlan option device ‘switch0’ option vlan ‘1’ option ports ‘0 1 2 4 5 6t’ Here you can see the default VLAN for the LAN zone (the vlan parameter reflects the network interface suffix that we described earlier). It specifies the ports it includes. A point to note here is that these port numbers may bear no relationship to the order of the physical ports on the router. Some numbers may not be used (such as port 3 on our device) and there’s an additional logical port to which the router’s ethernet interface (for example, eth0) is internally connected. This is port 6 on our router, which has five physical ports.
Pack your trunk
The other thing to understand here is that a port may carry traffic for multiple virtual interfaces. These are known as Trunk ports and are specified by using a “t” suffix, such as in port 6 in the example. Network traffic between trunk ports is “Tagged” with the VLAN identifier which, as such ports can be in multiple VLANS, enables the switch to direct traffic to the appropriate one.
To allocate switch ports to the DMZ all we need to do is remove them from the LAN block and then add them to a new DMZ block: config switch_vlan option device ‘switch0’ option vlan ‘1’ option ports ‘0 1 5 6t’ config switch_vlan option device ‘switch0’
option vlan ‘2’ option ports ‘2 4 6t’
You can also create separate Wi-Fi access to the DMZ, which may be useful to provide a guest access. Augment the “wireless” config file: config wifi-iface ‘dmz_radio0’ option device ‘radio0’ option network ‘dmz’ option mode ‘ap’ option ssid ‘LEDE Guest’ option encryption ‘psk2’ option key ‘guest secret key’ option isolate 1
This looks similar to our main SSID, but connects to the dmz network instead of the lan. The optional isolate prevents Wi-Fi guests from seeing each other.
Remember to restart the appropriate services: network, wireless, firewall and dnsmasq (for DHCP). Or just reboot!
Protect ads, block kids and more!
Other things that you can do include parental controls ( https://lede-project.org/docs/user-guide/parentalcontrols), setting up an OpenVPN server ( https://ledeproject.org/docs/user-guide/openvpn.server), and one of the more simple and effective additions, which is running an ad-blocker.
It’s relatively simple to install the LEDE adblock package and it starts working automatically. The optional LUCI package adds a Services>Adblock menu where you can configure the service. You can choose which blocklists are used: there are several listed of which the default configuration uses three: $ opkg install adblock luci-app-adblock
Another interesting application is traffic monitoring, useful whether your broadband connection has a capped bandwidth or just because you want to keep watchful eye over the network. The easiest to setup is the Netlink Bandwidth Monitor, nwblmon, which adds some a nice pages to LuCI. Install it with opkg install luci-app-nlbwmon and select the new LuCI “Bandwith Monitor” page.
Go with the NetFlow
An alternative, or additional, method you can use is NetFlow. This protocol originated on Cisco routers as a way to collect data about network traffic. Devices send NetFlow data to a collector running on another host. One open source collector is nfcapd, part of NFDump ( www.nfdump.sourceforge.net) and can be partnered with a web application called Netflow Sensor, or NfSen ( www.nfsen.sourceforge.net) to make network traffic data available in a web browser.
To send NetFlow data, LEDE supports softflowd, which is easily installed ( opkg install softflowd ) and configured in /etc/config/softflowd: config softflowd option enabled ‘1’ option interface ‘pppoa-wan’ option host_port ‘192.168.1.10:2055’ option export_version ‘9’ option track_ipv6 ‘1’ In this example, host_port is the IP address where NetFlow packets should be sent. This is another Linux box on your network and so you’ll need to install nfsen and its dependencies on it.
LEDE is not just for routers. It also has uses on other non-network devices. For the full list of supported devices see the official Table of Hardware at https://lede-project/toh. Not that it also won’t be LEDE forever because an agreement has been reached to re-merge with the OpenWRT project and this will involve returning to the original name. Until that happens, the LEDE fork remains the most active and better supported one – just bear in mind that we expect that brand to disappear at some point.