What I wish I knew about openwrt before diving in

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.

  1. 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:

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:

But not to the WAN interface

3 Likes

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.

3 Likes

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 :slight_smile: 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
1 Like

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)
2 Likes

^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.

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.

1 Like

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. :man_shrugging:

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.