OpenWrt 23.05
openwrt.org
openwrt.org
* https://www.reddit.com/r/homelab/comments/hzvfih/new_router_...
I was running OpenWRT on my Xiaomi AX9000 (based on master but also IPQ807 specific forks), but everything OpenWRT is software-based so 1/ the AX9000's acceleration chips are idle & performance is quite limited (unless using one of the crazy experimental NSS builds where mostly everything is broken) 2/ the integration with the onboard switch itself is far from adequate, e.g. VLANS+batman-adv are quite broken - very few configurations yield a partially working network (e.g. randomly dropping ARPs).. and don't count of LACP to work even though it can be configured. That's forgiving the fact that we also have to manually patch the BDF files on OpenWRT for the AX9000 if you want the radios to be connectable, as OpenWRT do not want to ship with the correct BDFs for some vague legal liability reasons.
Used VyOS in Proxmox for a while too, but at the end of the day, the firewall boilerplate is quite huge (and can't easily be edited on the go in the house as necessary), tailscale is not natively supported, etc. Relatively sad to let go of IaaC and committing the configuration though, but somewhat manageable with snapshots.
Use qemu and bridge networking or pass through a physical network device.
> also run it on any x86 machine
With the stock wifi chip and antenna? Or would I need to upgrade?
Asked another way: my old PC can be the "server"? Just like any wifi base station?
It's supposed to perform a scan and then set the country that is advertised by nearby APs. The obvious problem is that it won't work if there are no other wifi networks, or if one is trasmitting the wrong country. Also you have to manually run the scan, before the radio is unlocked, but virtually all AP softwares don't know how to handle this properly and get stuck in a loop.
In any case, they're terrible in AP mode even after unlocking the 5GHz band, because are locked to a single VAP and are not dual-band (I mean, not at same time).
The antennae are useless for my use case, but they came with it and if I removed them I'd just have to find somewhere else to store them...
One problem that I have with it is that I'm running qemu-system-x86_64 in an init script which creates a tap0 interface and adds it to the br-lan interface. If I ever restart the networking these interfaces are removed from the bridge. I briefly looked for some sort of hook to run on network restart but didn't find one. I'd love to be able to run brctl after a network restart to add the interfaces back into the bridge.
Edit: ah I didn't see that you run openwrt on baremetal...
After a quick look on OpenWRT wiki there is unfortunately not much information on what to be attentive to when running in a vm.
https://firmware-selector.openwrt.org/?version=21.02.3&targe... https://openwrt.org/toh/raspberry_pi_foundation/raspberry_pi https://openwrt.org/docs/guide-user/virtualization/qemu
RC4 changelog includes bump to major components, most notably: hostapd, ucode, ubus, netifd.
https://forum.openwrt.org/t/openwrt-23-05-0-rc4-fourth-relea...
Don't get me wrong though, I very happy that such project exists but OpenWrt could be more stable and reliable with a better workflow. Anytime you flash a new version, you have this small fear of bricking your device (especially the exotic ones as Openwrt mainly relies on external testers).
OpenWrt has transitioned its default cryptographic library from wolfssl to mbedtls. This shift brings several changes and implications:
* Users should be aware that mbedtls 2.28 no longer supports TLS 1.3.
Am I reading this correctly? They switched to a different tls library that doesn't support TLS 1.3?"While mbedtls is now the default, users who have specific needs or preferences can still manually switch back to wolfssl or choose openssl."
Newer version have okay-ish support, I'd guess the next OpenWRT release will have it again.
Featureful (or simple if you want simple and go for the simple plugin), plenty of blocklists to pick from, auto-updates, all the things! OpenWrt is awesome.
For more modern purposes I use a Linksys WRT32X with divested[1] image, but you could also go for the 1900 or even 1200, depending on your needs...
Maybe also take a look here: https://www.libe.net/openwrt-devices
[1] https://divested.dev/unofficial-openwrt-builds/mvebu-linksys...
I tried several patches but nothing helped. As I understand it it's the closed source abandoned (?) WiFi firmware that's the issue. I suspect it can't handle interference , which which is why it works great for some and horrible for others.
I see there are new commits on the driver repository [3], so maybe I'll try again but I don't have my hopes up...
[1] https://openwrt.org/toh/linksys/wrt3200acm
[2] https://openwrt.org/toh/linksys/wrt32x?datasrt=ethernet%20gb...
Netgear WAX202
Belkin 3200
Banana Pi BPI-R3
Nano-Pi R5S
Cudy X6
While the Cudy is very cheap (40 Bucks here in Germany), I still like the Banana Pi BPI-R3 most. But until it gets really necessary, I'll stick with my 32X... for me it does work but I won't recommend it any more without that note.Here is some more info about the Banana Pi: https://wiki.junicast.de/en/junicast/review/bananapi-BPI-R3
Flashing them is always fun, because their stock GUI is in Chinese and you do this by looking at it through one of the camera translator apps on your phone.
I'd prefer to run OPNsense on it if I could, but it isn't available for ARM64 as of now.
Setting up a Wireguard VPN is way easier. They seem to backport anything that matters. They are sometimes marketed as travel routers, but they work fine as your main one. They just don’t take up a lot of space.
https://www.amazon.com/GL-iNet-GL-SFT1200-Secure-Travel-Rout...
If you want better than that? You should use a raspberry pi 4/5, with an extra gigabit USB adapter, as your router, and setup some routers as “dumb APs”. That way you can upgrade your wireless without messing with your core network and services.
Also RP4/5 are both fast enough to software route at gigabit speeds with advanced QoS management. My latencies don’t change if my connection is loaded or not.
My only gripe is that I wish it had a better CPU. Currently using CoDel the CPU maxes out at 750Mbps.
First, the distribution is bare bones to the extreme by default. Like Linux in the 90s bones. Understood, some old routers are tiny, but it makes a RasbPi feel positively ergonomic. Lucky you can install packages pretty easily, like htop etc. Have to install the web gui of course.
Could be wrong but don’t think you can upgrade with a command like Debian. Have to save config and reflash again. Hope not.
Speaking of which, there’s all these config files like nothing you’ve ever seen before. Learning curve steep. Have to bond physical interfaces with APs manually. Odd defaults like wifi clients not allowed to talk to each other. Better get used to hunting online for settings. Fixing that required changing an obscure multicast setting, buried in the gui, not isolation. This is a home not a cafe. :-D
The wiki for my device was hard to follow, basically cut and paste from multiple forum posts with a few critical tidbits missing for a new user. I hunted them down.
I kept very good notes and intended to improve the wiki, but guess what? not editable. Oh and folks who ask questions told to read the wiki fully. I did read it twice at least and have a lot of other experience so trudged through. Had to make an account on one server and ask for account on wiki. Was ignored, got no notifications at least. Post expired.
Now it’s been two weeks… have forgotten a lot and wiki page still shiti. Not how FLOSS is supposed to work. So yeah, happy with it in general but lots of room for improvement.
I think most people upgrade via reflashing through the admin interface (GUI). Read [1], "Can you keep settings?"
My experience is old, so I won't comment on the rest of the points.
[1]: https://openwrt.org/docs/guide-user/installation/generic.sys...
All of this is pretty understandable since openwrt is targeted to really low specs . 4MB storage/32MB RAM was the target until 2022. It's now 16MB storage, 128MB RAM which is still pretty low.
If you straddle the worlds of preferring a "normal" router to a custom built box but also want to keep your configuration history in git I think OpenWRT may be the best option.
I own a few Mikrotik HEXs boxes: now they were just upgraded from 0,5Gbps to 2Gbps! Wow!
It wasn't the end of the world since a standard openwrt image could be loaded over tftp, but it was annoying that it was impossible to recreate the images available for download.
My USG-3P died a few months ago, so I dusted off my old Asus router and made an unplanned switch to OpenWrt. This was meant to be a temporary solution until I could get a new UniFi device, but after setting it up and getting it working the way I want I'm more than happy to make this temporary solution into a permanent one.
I've also looked at installing OpenWRT on my USG, but only the snapshot version is available and the process is fairly involved[0] so I haven't really explored this.
At this point though, I'm not likely to go back to Unifi for routing. I needed to use the config.gateway.json (I think) workaround to add some DNS config[1] to my USG, whereas with OpenWrt I can do this entirely in the UI.
[0] https://openwrt.org/toh/ubiquiti/unifi_security_gateway_3p
[1] Just wildcard resolution so that *.internal.domain points to a reverse proxy server, nothing too extraordinary.
I'm still on 21.02.7 because they switched to nftables syntax for custom rules ("firewall.user") in 22.03 and I have a pile of them and haven't had the time to rewrite it all. This release means 21.02 will have no more security updates.
The device is stable and I'm the only one using it so I didn't feel any pressing rush to deal with the hassle since a lot of "security" issues are often from the inside not the outside.
So I would say don't stress overmuch about it.
I tend to minimize internal services as well. I don't use OpenWRT as a general purpose server.
Still, an LTS release from time to time would be good (the effort would be the same, as there would still be only two maintained releases: the current stable and the LTS).
https://wiki.nftables.org/wiki-nftables/index.php/Moving_fro...
But it might not cover all of your existing iptables rules.
They seem to be forcing the use of the UI for creating rules, but that doesn't cover some that I have (part of which are generated dynamically).
Worse, I'll have to go through 22.03 because they don't support upgrading from 21.02 to 23.05.