What I wish I knew about OpenWrt before diving in

RollingStar · December 25, 2021, 12:44am

I'm pretty techy, and I've been running custom router firmware on and off for a decade. But I wasn't prepared for all the options in OpenWRT. Here's what I wish I knew.

Carefully evaluate your connection, CPU needs, and target platform.

By far the most important. I bought my router for a 50 Mbps connection then upgraded to 250. I didn't know the device I bought would top out around 120-140 Mbps down when running SQM. SQM was a big reason I wanted OpenWRT over stock firmware. There's probably other big CPU hogs like VPNs/containers.

I don't think I can naively copy over an entire config to a new device, so all the time you spend configuring is wasted if you change devices. Some of it probably can carry over, but other stuff that's specific to your radios (what makes wifi work) might not. Correct me if I'm wrong.

flow_offloading exists but is off by default

Important config item to be off by default. I believe either SQM or flow offloading should be on for best results.

Why it's off by default:

Note that flow_offloading_hw is apparently for hardware flow offloading:

github.com

openwrt/luci/blob/70a749020198367e188369646da9cf5adb767071/applications/luci-app-firewall/htdocs/luci-static/resources/view/firewall/zones.js

'use strict';
'require view';
'require rpc';
'require uci';
'require form';
'require network';
'require firewall';
'require tools.firewall as fwtool';
'require tools.widgets as widgets';

return view.extend({
	callConntrackHelpers: rpc.declare({
		object: 'luci',
		method: 'getConntrackHelpers',
		expect: { result: [] }
	}),

	load: function() {
		return Promise.all([
			this.callConntrackHelpers(),

This file has been truncated. show original

flow offloading vs. SQM

I still don't know enough about this.

Guest Network setup isn't bad if you do it over ssh/terminal

I dreaded doing this because the GUI looked incredibly complicated. But the terminal commands aren't bad. You can paste a block all at once.

OpenWRT is not maximally secure/private by default

Security is all about tradeoffs with usability. OpenWRT is wired only until you enable wifi (hopefully with a password). But other features or assumed features of commercial firmwares have to be proactively enabled. For example, guest clients can access the main network unless you isolate them. Administration is apparently open to 0.0.0.0 and thus the whole Internet? So set a really secure password until you disable that! The web UI technically adds attack surface, just like it does on commercial firmware. Disable it once you're done setting up stuff, if you know what you're doing.

DNS over HTTPS (DoH) and Cloudflare's 1.1.1.1 (the most private DNS I know of) are not enabled by default either. OpenWRT is more like a blank slate than a preconfigured storebought piece of hardware/firmware.

Other links:

mbo2o · December 25, 2021, 12:49am

But not to the WAN interface

slh · December 25, 2021, 12:55am

I wouldn't call that wasted, you can use your old configuration for reference, to shortcut the setup of your new router that way.

The networking side however, down to the hardware level, differs massively between devices, there is no reasonable way to make configurations possible crossing different models. Just to pick a few examples:

classic plastic router, 4+1 ports
sounds simple at first, but as soon as you leave the default (1* WAN plus 4* LAN), it gets complex really fast (what to do if your new router just has 2+1 or 3+1 ports (hello Xiaomi) and you have multiple VLANs configured)
- older routers only had 2.4 GHz wireless, what to do with concurrent dual-band routers
- some modern hardware has three radios (mesh repeater), what to do here
- there is quite a lot of hardware with very strange internal networking setups, multiple switches, WLAN offloaded to a second SOC only interconnected to the main SOC over a special VLAN (think Easybox 904 xDSL, Fritz!Box 7490, …)
RPi4, pretty popular towards the high-end, onboard ethernet for LAN
what to do about WAN? Popular choices are USB ethernet or a managed router ("router on a stick")
x86_64, 1+1 ports if you're lucky - very good interesting devices might have 4 individual ports…
how to deal with LTE/ 5g devices, which behave and look considerably different and also need very different routing strategies

…and that's only the beginning.

Case in point, I've migrated from a classic plastic wireless router to a x86_64 system last night.

transforming the networking setup (/etc/config/network) with multiple VLANs, wireguard and some other specialties took most of the time. This was a manual process, using the old configuration as example (and no, there is no way to do this in an automated way, as I went from 4+1 ports with different VLANs on LAN1+2 and LAN3, LAN4, to 1+1 ports (WAN + trunk port transporting multiple VLANs to a managed switch).
adblock, ddns, dnsmasq and firewall configurations could be migrated as is (after an audit)
system was redone, but easy enough
bcp38, nlbwmon, needed minor changes
collectd/ luci_statistics was started over from defaults
fstab just needed minimal adaption from defaults
irqbalance, just enable
p910nd, drop (well, I could have taken the old one)
tftpd-hpa just enable the service and configure the blockd/ fstab backed partition as backing store
uhttpd, I could have copied my old, but, easier to just insert my changes for the SSL cert generation
umdns, just needs minor changes for the listed networks
wireless, there is none on this device
sqm, set up from scratch - as my old router wasn't fast enough to do sqm at line speed, so this was a newly possible feature.

So after playing around beforehand, the actual configuration didn't take more than 15-30 minutes, including very careful auditing of rather complex setups.

mercygroundabyss · December 25, 2021, 1:15am

you can actually automate a lot of "re-setup" stuff using his scripts. (edit - https://github.com/richb-hanover/OpenWrtScripts/blob/master/config-openwrt.sh ) EG resetting up wifi securely and setting up SQM. There's even scripts on the forums that will sample your connection and dynamically rebalance your SQM rates.

As for Wifi? Here But. Double check your wifi is setup the same way. It may be different depending on your wifi setup.

# === Update WiFi info for the access point ================
# a) Assign the radio channels
# b) Assign the SSID's
# c) Assign the encryption/passwords
# To see all the wireless info:
#	uci show wireless

# === Assign channels for the wireless radios
# Set the channels for the wireless radios
# Radio1 choices are 1..11
# Radio0 choices are 36, 40, 44, 48, 149, 153, 157, 161, 165
#    The default HT40+ settings bond 36&40, 44&48, etc.
#    Choose 36 or 44 and it'll work fine
 echo 'Setting 2.4 & 5 GHz channels'
 uci set wireless.radio0.channel=auto
 uci set wireless.radio1.channel=auto
 uci set wireless.radio0.disabled=0
 uci set wireless.radio1.disabled=0

# === Assign the SSID's
 echo 'Setting SSIDs'
 uci set wireless.@wifi-iface[0].ssid=5GHz-Wifi #change this
 uci set wireless.@wifi-iface[1].ssid=2-4Ghz-wifi #change this

# === Assign the encryption/password ================
# Update the wifi password/security. To see all the wireless info:
#	uci show wireless
# The full list of encryption modes is at: (psk2 gives WPA2-PSK)
#	http://wiki.openwrt.org/doc/uci/wireless#wpa.modes
# Set WIFIPASSWD and the ENCRMODE, and then uncomment the remaining lines.
# 
 echo 'Updating WiFi security information'
 WIFIPASSWD='YOURPASSWORD' #Change this
 ENCRMODE=psk2+ccmp

 uci set wireless.@wifi-iface[0].key=$WIFIPASSWD
 uci set wireless.@wifi-iface[1].key=$WIFIPASSWD

 uci set wireless.@wifi-iface[0].encryption=$ENCRMODE
 uci set wireless.@wifi-iface[1].encryption=$ENCRMODE

 uci commit wireless

Breaks IPv6 right now. Disabling by default is wiser till properly patched.

Lan side only. So they would have to be plugged in when you boot it to "take it over". It is advised to setup a password once you boot and luci tells you to do so.

Both of those can be added / updated easily. Overriding your ISP's DNS for a better upstream is always good idea.

If you use that configureation script of Rich's?

# Configure DNS provider
uci -q delete network.wan.dns
uci add_list network.wan.dns="1.1.1.1"
uci add_list network.wan.dns="1.0.0.1"
 
# Configure IPv6 DNS provider
uci -q delete network.wan6.dns
uci add_list network.wan6.dns="2606:4700:4700::1111"
uci add_list network.wan6.dns="2606:4700:4700::1001"
 
# Disable peer ISP DNS
uci set network.wan.peerdns="0"
uci set network.wan6.peerdns="0"

uci commit dhcp
uci commit network
# Save changes

# Restart network + dnsmasq service to reflect changes
/etc/init.d/network restart
/etc/init.d/dnsmasq restart

slh · December 25, 2021, 1:16am

About SQM by default, there is no way to do this<fullstop>.

The router can't know how fast your uplink is, what overhead to account for, nor what your preferred strategies are (maximum throughput or minimum latencies, yes, these are slightly at odds), nor if your router is actually fast enough to do SQM at line-speed. If yours isn't, the choices are either to limit the throughput far below your WAN speed, so the CPU can just cope, or to disable SQM for the time being (until you have faster hardware - this is a policy decision the firmware can't do for you (if it did, the users wouldn't be happy at all).

You may point out that there are efforts to auto-detect the link rate, especially for variable speed links (3g/ 4g/ 5g, wifi, but also e.g. VDSL, congested cable, etc.), while that may help, it's not quite a solution either (what happens if the measuring peer goes down or rate limits its responses, if you have a fixed-speed link the results will be worse than hardcoding the speed limits yourself <-- not maintenance free either). Especially for metered WAN connections, any kind of link adaption (which relies on measuring artificial traffic to probe the link variables) will be costly, both in terms of concurrent link usage (dropping your usable speed) and financially, as you do have to pay for the 'useless' traffic necessary to do the link adaption; and this totally ignores how much your involuntary testing peers will love providing you an unpaid service.

guest network

There is no guest network in OpenWrt by default, nothing to hit a checkbox and get going.
You're configuring it from zero - and can (need to-) apply your access policies. If your guests have access to your internal LAN, you chose to allow it (or did something wrong), but it's down to making the policy decision of putting the guest network into its own firewall zone and to configure the inter-zone routing rules. The wiki guides might be clearer on this point (I haven't read them recently), but that's purely the user's policy decision while setting up the guest network.

Flow-offloading…

Hardware flow-offloading is only available on a rather small set of hardware, ramips (think of mt7621) at this point.

Software flow-offloading is possible on every device, but can be at odds with other wanted features…

as pointed out by mercygroundabyss, IPv6 before we've moved on to fw4 and nftables (soon, in master)
traffic accounting (nlbwmon, vnstat, vnstat2), offloaded traffic is lost to the eyes of these traffic counters, so your monthly results will by off by orders of magnitude
SQM, while combining SQM with hardware flow-offloading isn't possible at all, you can use it with software flow-offloading, but will still lose (most) of the advantages of offloading that way (as only a minor fraction of the sqm managed traffic can be offloaded)

mercygroundabyss · December 25, 2021, 1:19am

^this.

While there are dynamic scripts to do things like this. It is FAR better to take the Lego approach.

Give them a decent base to build on. Let users add what they require. They may want a aircraft carrier powered by paddle wheels.

mercygroundabyss · December 25, 2021, 1:31am

Some of what is in the wiki is down to community edits. It is possible to get a wiki account and do guides. Some guides are just well written forum posts in here. Documentation continues to evolve as the project continues and hopefully newer users will be less confused.

rexbinary · December 25, 2021, 2:05am

Thanks for this. I am just diving in myself and this is helpful information. On a side note I tend to think of Quad9 as more private than Cloudflare, but I could be wrong.

Hikari · December 25, 2021, 5:39am

Srsly I keep all my configs on Subversion repo.

OpenWRT's Subversion client doesn't support HTTPS, so I keep the working copy on my server and use rsync to keep them together.

I also have some editions of files like network and mwan3. I have a safe edition for when I write a new image, a vm edition for when I restore backup on a VM to make tests, etc.

RollingStar · September 21, 2022, 7:08pm

Months later, my OpenWRT journey is basically: 30-60 hours of learning and setup, and then basically stable since then (especially since moving to r7800 off my super underpowered device). So some of this stuff will look like nitpicks, and it does come from a place of love that my OWRT is now more of an appliance than a test bench.

My big time sinks were:

webUI
tweaking SQM and finding on two separate devices that they were too slow for CAKE at 250Mbps (apparently in 19.x the r7800 was fast enough for this, and so I was lead astray by forum posts)
guest network isolation
attempted firewall of my work PC from my home network
moving up from 2/5 star skill in Linux administration to 3/5 star (htop, ssh, nano, winSCP to load files on a remote machine but edit in my favorite windows text editor)
the complex matrix between CAKE, codel, their different configs (simple, simplest...), flow offloading, and various observed max speeds based on inputted speed limits
switching from official to forked builds and back
hard to diagnose wifi issues (I think I ended up just wiring everything rather than figure out why it was a problem; besides, could I really fix it?)

Some other stuff that comes to mind:
What is a radio, the relationship between LAN, VLAN, WAN, your wifi SSID. The way guest networks are shown in the UI. I've found my way around every consumer router webUI from 2003-2015 and two other community firmwares (DD-WRT, Tomato) and the way OpenWRT presents this stuff is not intuitive. Powerful but unintuitive.
Which interface I should put SQM on.
what LuCI is (unintuitive name, and it doesn't stick in the brain because of the ambiguous i vs. L; Luci would be more readable but obviously lose the presumed abbreviation)
what the name LuCI means (I still can't find it)
How to follow -only- stable OpenWRT security releases/updates. Non enthusiasts have no reason to care about pre-release updates, or really anything but security updates. I've settled on this: https://github.com/openwrt/openwrt/releases.atom
Which devices are most popular for OpenWRT. For enthusiasts it seems like the answer is WRT3200ACM, r7800 and similar CPUs, Raspberry Pi 4. Back in the day it was always fun to bring your own device to custom firmware, but these days my time is worth enough to buy a good $100-$500 device if it saves 20 hours of headache. Not only that, the gap between the worst and best consumer OWRT device has grown a lot since DD-WRT in 2005.
I tried and failed to isolate a physical ethernet port from my main network. I don't think this is such an unreasonable task.

A lot of this stuff is stuff you wouldn't encounter on a $150+ consumer router. These routers don't have the features OWRT does, but they are easier to understand for a novice. OpenWRT is incredible for free, open software, but it does have room to be more intuitive without sacrificing power.