OpenWrt 21.02.0 Released
openwrt.org
openwrt.org
A range extender may not have an Ethernet port labeled "WAN", but that doesn't prevent you from using one of its "LAN" ports for that purpose. Likewise, if you want to take a device sold as a router and use it only as an extra access point within your network, you can repurpose its WAN port as an extra LAN port, or go for more complex network configurations where you use the router's built-in switch as a VLAN-capable managed switch.
So OpenWRT is pretty amazing. Incredibly hard work, incredibly good system, targeting so many different devices. The "uci" configuration system and "ubus" rpc layer are nearly unparalleled in software, have brought so many different systems under a consistent yoke & collar. OpenWRT is incredible.
But again it comes back to hardware. And wow what a tragedy we have been undergoing. It's a barren bereft world. There's really only one router, with a pretty mediocre MediaTek cpu/wireless chipset, that has 802.11ax support at all. Hopefully things swing around some & we figure out how to get operating systems installing atop more contemporary routers, but there have been so so so few advances, hardware has gotten so much more inaccessible. It makes me all the sadder that decent wifi addon cards are blanketly unavailable. Read it and weep, the forum thread on 802.11ax routers: https://forum.openwrt.org/t/802-11ax-routers/10484/354
I got a second openwrt router recently. It's been very interesting & surprising seeing how little cross-access point and cross-band steering clients do. I'm literally compiling openwrt fresh today, as I work on this problem, with some fresh new software systems that have only just cropped up in OpenWRT land. For a while OpenWRT had nothing, but we're finally developing some acumen for using multiple access points and that's so necessary & so great. I've grown more respect for the mesh based products that have taken over: not only do the routers have to mesh (and route across the mesh), but it's really up to them to steer clients ("stations") to the best access point: the problem is bedevilling crazy hard.
I've thought about trying to do everything in the NUC, but at some point, just configuring it all is sorta a pain.
Why not go for a separate router and access point? I know its not for everyone, but it makes debugging stuff and tinkering so much easier. As a bonus, you can run a different router OS (like OPNSense).
I personally run a Mini-ITX PC ( ~200€ from used parts, but with 2.5G link) and an Ubiquiti AP WiFi 6 lite flashed with OpenWRT - it's around 100€ new, has great hardware and is supported.
that's a pretty decent access point! it uses the one 802.11ax chipset which does have linux support, on mediatek chips. performance of mediatek cpus & mediatek wifi do not impress me but it is great that linksys, belkin, ubiquity all have some near $130 moderm wifi gear out that does, all in a, pretty well. hoping the rest of the world can compete! strong value. especially if we do decouple the router & ap (something i did until very recently), then some pretty good wifi counts for a lot!
I used to do something like this, but I found it to be (moderately) annoying to manage and keep updated. And I find it hard to justify running a PC 24/7 that draws many tens (or even more than 100?) of watts vs. purpose-built networking gear that draws much much less. Sure, I could build something with an eye toward low power consumption, but I still doubt I'd be able to do as well as most off-the-shelf networking gear.
> But again it comes back to hardware. And wow what a tragedy we have been undergoing.
Agree that the 11ax situation is terrible, but consider pretty much all WiFi support is terrible on Linux for a while after new hardware supporting new standards comes out. I'm hoping that this situation will just get better with time, though I do worry that manufacturers are locking these things down more and more and are becoming even more unfriendly toward open source than they have been previously... which has always been not great.
i do think perhaps im being a little glum about the wifi situation, even though we havent seen new/better hardware supported on openwrt for near half a decade. not just a "new standards" lag. on the hopeful side, codesourcery & others are doing a much much better job helping to make official open source image building a stable replicable manageable process. yes, almost always on linux 4.14 and or gcc-4 or ehstever and this infuriates me a bit, feels like a waste. but there is also more mainlinelining going on, both with cpus and with wifi cards. in fact it's almost just too well supported, that the problem is, now, that there's still not available hardware that has the new chips. for whatever reason the draft spec hardware all seemed to have bad errata, low/no drivers. and we just havent seen modern platforms with both the newer cpus and the newer wifi. still just not much hardware in general, even though draft spec equipment has been around for i believe years. progress isnt totally like i want but definitely some good signs too, and some just regular old "it takes a long long time before most chips start making their way jnto products". kudos to the hardwork of many who have been mainlining your drivers. you are doong the right thing. the future is exciting.
I haven't been watching the Linux+wifi space all that much lately, but what you outline still does sound much better than the situation even a decade ago. I get that it's slow, and I totally sympathize with and share your frustration there. I'm running 11ac gear at home, but I'll be due for a new laptop before too long, and would like to start the 11ax upgrade process. Seeing that I might have to forego OpenWRT (or just wait an uncertain amount of extra time) isn't really fun.
There are many MediaTek devices including UniFi 6 APs, but also in robimarko's dev branch, Qualcomm IPQ807x support is working very well. Modulo some kind of slow memory leak that seems to happen when an AP doesn't have clients :D but the "hard parts" are working. Speed is high on all radios, sysupgrade is working, thermal/clock management is working, there's even hardware offloads for NAT and other stuff I don't care about (I only use these devices as APs).
(2) It's interesting how much resources this requires now, though; 128MB RAM is recommended, and 64MB is barely sufficient. To fit into 32MB and run basic routing functionality, one needs to remove IPv6 from the custom configuration, for instance. Mere 15 years ago 16MB was almost plenty to run OpenWRT :)
I also wonder how much more compact a RAM footprint of a router can be if it only does routing, though competently: with IPv6, QoS, etc. Maybe it won't be much more compact even with a super-compact purpose-built kernel and network stack (not Linux).
Given that we have gone from two/three digit gigabyte disk to two/three digit terabyte disks, I'd say it held up pretty well ;)
[1]: https://www.friendlyarm.com/index.php?route=product/product&...
100TB SSD, $40k.
This is a performance point where general purpose Linux distributions ought to be competitive. The Debian project is really dropping the ball by not focusing a lot more on these use cases. Their debian-embedded working group used to lead worthwhile subprojects (known as EmDebian Grip/Crush/Baked) aimed at slimming down minimum requirements on all sorts of special-purpose hardware and even competing with the likes of Alpine and Void, but these have all gone nowhere. Hopefully they'll be picked up again since the mobile-phones use case is raising these same issues, albeit for other reasons.
I also just in general trust an open source project (sure, I know, I haven't personally audited the source or the build process) over close-source manufacturer firmware.
Since the previous time that I had to manage the AP, I had switched my laptop from Archlinux to Voidlinux.
I tried starting ubiquiti's stupidly over the top java based management daemon on my laptop in order to manage the access point (which I used because I don't own a smartphone and even if I did, I wouldn't want to run any proprietary applications on it). To my surprise the software relied on mongodb which basically no distro packages anymore because of their crazy license change. I tried to spend some time getting mongodb locally packaged for my laptop (I refuse to install software without the package manager backing it up) but compiling mongodb is apparently nontrivial and I couldn't get it to work.
So I gave up on getting that working and just put OpenWRT on it because it provided me with a nice simple command line interface as well as an optional web interface. I was also able to quickly cut down the firmware to the bare minimum as I just wanted to bridge WiFi interfaces to VLANs.
I had a minimal, reliable and easy to manage access point which has been running 24/7 since that day for the last 218 days without a single hiccup. I no longer stress about having to run some insane daemon when I want to modify the configuration of my access point.
In general, I find VMs a huge pain to manage compared to containers. I don't run any VMs at home anymore, aside from firing a temporary one up from time to time to try out some random ISO.
What's a good consumer router for OpenWrt? I don't do any fancy home lab stuff, just normal people watching videos and me posting on Hacker News.
Maybe other hardware doesn't work as well, but I think if you choose carefully, it's fine.
Openwrt aims for "near-mainline" blob-free kernel, currently on 5.4, with 5.10 in current master for many architectures.
And everybody know it, but somehow these devices always are at the top of some consumer recommendation list, and people keep plugging rpi4s etc everywhere.
Would anybody recommend that sort of setup over a Mikrotik Hex or Ubiquiti Edgerouter X?
[1]: Ubiquiti has had packet processing issues in the 2.x firmware series for what seems like forever, and lack of updates lately has prompted me to move to something that is arguably better anyway.
I only found some quick&dirty patch, that seems to make MTU up to 2000 functional. But since the patch aims for 9018, and only gets 2000, that does not seem like the "right" solution.
Anything MARVELL should mostly do, usually. But that's not the cheapest segment anymore, so the people are hurting themselves by buying the common plastic trash. Or use DD-WRT instead of OpenWRT, because they give a shit about binary-blobs and integrate that however they see fit, because they prefer to be able to use everything the hardware supports, instead of having an almost brick running open-source.
It is not always clear, but enabling QoS usually disables hardware offloading, for example with Ubiquiti devices[1] "Traffic to which QoS policies have been applied cannot also take advantage of the EdgeRouter's Offloading feature". The same is true for open source even with binary blobs. The chips simply can't do it.
Using QoS and implicitly disabling hardware offloading significantly drops the throughput as it becomes CPU bound. "Without offloading enabled, IPv4 traffic will be routed via the CPU and will be limited to around 300Mbps on the EdgeRouter Lite (ERLite-3). With offloading enabled, the throughput will be about 950Mbps." [1]
[2] https://en.wikipedia.org/wiki/Turris_Omnia
[3] https://docs.turris.cz/hw/omnia/omnia/
These two and similar were what I had in mind.
Though I don't have them. But considered them a few years ago. But I've chosen another path, of really dark art ;-> (Don't ask)
edit:
Oh, and
The smaller, and more affordable option from the makers of [1]
But this is all from three, or even four years ago?
I don't even know if that Turris Omnia thing is EOL meanwhile?
They wanted to make something even more modular.
Anyways, all MARVELL based and thus IIRC with working offloading under Linux, though not mainlined at the time.
[5] https://en.wikipedia.org/wiki/Marvell_Technology,_Inc.
edit: Funny, Amazon.com says they have 9 Turris in stock
[6] https://www.amazon.com/Turris-hi-Performance-printserver-Vir...
While amazon.de has 19.
So they should be available. But about 400, instead of maybe 40 to 200 for some cheap plastic trash which melts or resets if you look at it the wrong way.
At the time it had much better hardware at a similar price to more popular brands like Protectli and Qotom. Not sure what the scene is currently, but there a bunch of similar offerings on AliExpress.
Like you, I run a single x86 box with a handful of guests for random stuff - including Home Assistant!
I do want to ask though, has there been any downsides to using OpenWRT on x86?
I haven't really run into notable downsides. Installation was somewhat of a pain since I had to resize the partition (all of the prebuilt images assume small hardware), and all of the default packages are as minimal as possible - like busybox for userspace/shell. Upgrading on X86 is I guess possible (I haven't tried yet), but most of OpenWRT's upgrading instructions/support are geared towards reflashing firmware, not updating packages on ext4.
But, there are a bunch of available packages - coreutils, zsh/bash, etc., that can be installed as desired. In general OpenWRT is pretty set-it/forget-it for me.
If you're looking for a network connected server that happens to do a lot of packet processing you can go the rpi route but I'd still front the internet and rest of the home internet off a small cheap hardware box like the Hex.
https://forum.openwrt.org/t/adding-openwrt-support-for-xiaom...
I recently bought a GL.iNet Brume. It's a nice tiny ARM machine I use as a wired-only router. /proc/cpuinfo confirms it supports hardware crypto...
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
I might have tried the FriendlyELEC NanoPI R4S instead, which actually has two separate NICs. But if I'd ordered that I'd still be waiting for it...
One thing I don't care about: hardware NAT/routing offload. I think that's often unsupported by OpenWRT, and it's incompatible with SQM.
They look very nice (although unavailable till January)
I haven't read into the specifics yet, but it sounds like nft-tables configuration will be translated to a eBPF program, that will then hook into network flows, and tell the switching HW/NPE over some side channel which accelerations to use and shortcuts to take.
But do I really want to trust a "Black Box Network Processing Engine" bolted onto my CPU, that can route packets entirely outside the realm of control of the main CPU?
I always wonder about intentional or unintentional "in-band debug features", when people mention, that they run their home-lan on the same switch as the WAN-Uplink. I mean, is there really a HW vendor, that we trust to get the switching logic 100% correct/secure/performant?
My GL.iNet Brume supports DSA on its switch with OpenWRT 21.02, as does my older Netgear WNDR3800.
I'm not sure there's any hardware/software combination out there that supports offloading NAT/routing with proper QoS. So I'm puzzled when people talk about the importance of offloading or suggest using machines with very low-power CPUs. The Brume is Dual-Core ARM Cortex-A53 @1.0GHz, which gets the job done for me, but I wouldn't want to go any slower than that.
[1] https://www.kernel.org/doc/Documentation/networking/dsa/dsa....
To me, DSA (as a "convenient" means to access/name/treat individual switch ports) is a prerequisite to enable usage of whatever Switch-Chip-Level-Offloads the switch chip supports. Without DSA, vendors had to use nasty hacks to make use of e.g. HWNAT, which is why there never was mainline support for these acceleration features.
HWNAT is a routing function, and many/most? switches of the last decade support that. But, OK, true, most of them will probably not be able to HWNAT "with proper QoS". But newer devices are not "just" a switch-chip, they contain a "Network processing engine", which is not a "fixed-function" device, but rather a "programmable" accelerator, that you could perhaps even "teach" how to do PPP, Encrption/VPN wrapping, and/or "offloading NAT/routing with proper QoS".
And now that DSA and eBPF are in mainline, using eBPF to generate a program/set_of_rules for the Ethernet acceleration device from your nftable-rules seems like the natural next step for me.
Or where do you see my reasoning go off the rails?
No, I don't know of any problem in your reasoning. I'll look forward to that happening! I wasn't aware newer hardware was so flexible.
I just hope, "flexible" doesn't come with a large "Difficult-to-audit-caveat" side-dish. NPEs "governing" traffic could potentially substantially reduce the trust the user can have towards the platform.
Thanks to full duplex, clients are able to use the fibre uplink without slowdown. VPN is managed by a separate system, though we had some successful experiments with WireGuard. Both a colleague and I are running the exact same setup at home (with fibre uplink and VDSL).
It's a very capable and power efficient setup. I'd definitely go with a CM4+dual NIC board today.
I'm curious how they solved TLS non self signed certificate on local device problem described here: https://lwn.net/Articles/837491/
I tried to find info but I can't find any.
If I could get OpenWRT working on something like those I'd be so happy.
[0] Dropbear doesn't {didn't?} support ed25519 at the time I was using it for SSH, but it took me an afternoon of dead ends and "it's not DNS" feelings before I found that out.
[1] I know about the serial console, but I'd prefer a simple, direct access keyboard/mouse setup if I screw it up.
Many users report Wi-Fi connectivity issues[0]. When I did an upgrade, I was unable to connect my laptop and Roomba to wifi, and had to rollback to 19.07.8.
That shouldn't be the case. I've definitely had multi-month uptimes
It somehow wasn't a specific headline / item in the release note. But I thought updating to 5.4 was a big deal.
Unless there is some particular feature that someone wants or a device enablement that only possible starting with a kernel version, do most users care?
[1] https://openwrt.org/docs/guide-developer/releases/goals/21.0...
I was hoping, that 21.02.0 would still include that one.
In any case, many thanks for all the hard work to everybody involved!
Why is this so hard? I don't think we need OpenWRT on a router, do we? I mean, can we just set the DNS on the router to use a local machine, and can I use Bind9 or DNSMasq? https://tech.surveypoint.com/posts/installing-a-local-dns-se...
Macs, for example, can add "compname.local" to DHCP using Bonjour. Can I somehow use Wide-Area Bonjour or Zeroconf or something, to accomplish this?
I am not a network expert, all I want is to have a computer join the local network and run a DNS server, tell the router to forward all DNS requests there, and our DNS server will respond with our captive portal for any domain, so we can "take attendance" and checkins via wifi, and after people connect once, every time they walk into the room, their cookie will announce them to the captive portal, we register their attendance and then let the DNS pass through to whatever other DNS server they had.
PS: I guess this wouldn't work if they manually set DNS servers to be the IP address OpenDNS or something like that, right? What is the correct approach to captive portals in that case?
PPS: Why are captive portals so SLOW on every iPhone I ever owned? It takes like a minute or three to come up. What is causing the delays?