I'm a staunch defender of OpenWRT. Having used just about every "router distro" folks care to name (remember SmoothWall?) for the last 20~ years, OpenWRT is built like a tank and just keeps trundling along
I hope their experiments with the "OpenWRT One" keep going. I'd love to see OpenWRT take a (deserved) bite out of the "SMB firewall vendors" like Netgate or OPNsense. Or just undercutting Wi-Fi vendors like Ubiquiti who base their work on OpenWRT anyway
Something I'm excited to try myself in future is running "OpenWISP" [1] to manage a small fleet (three) OpenWRT devices in parallel for a deployment in a shared workshop. This seems to also be something that OpenWRT could be better at integrating, but it's nice to see "a vendor" tackling it
Ease of managing multiple OpenWRT devices is still its weakest link. OpenWRT is device centric, but I don't want to managed devices, I want to manage a network.
Modern mesh WiFi systems I've seen do that so well. I know in theory that I could create a VLAN + SSID on my OpenWRT router and APs just for iot devices to only access the internet. But setting that up on a TP-Link mesh was a couple of taps in their app. Doing it on my OpenWRT devices would be quite a bit more hassle.
Thinking about this more, I doubt I'll setup any OpenWRT APs on my network going forward. Most of the things I like about OpenWRT, and need it for, are related to being my router. My OpenWRT APs are just "dumb" APs. Wifi is off on the router.
For the APs, I could use a mesh kit like the TP-Link Deco unit I installed for a friend recently. Super easy setup, reasonable price (cheaper than equivalent OpenWRT hardware I'd buy), wired backhaul up to 2.5Gbps.
At home, I built an OPNsense box to evaluate (using Sophos XG135 Rev 3 hardware, along with an OpenWrt nice Netgear WiFi AP on POE), but then went back to a plastic OpenWrt all-in-one box.
OPNsense (and pfSense) are neat, but I personally don't need an IDS/IPS right now, and I like to be able to run the router fanless.
One thing that OpenWrt could use immediately, for basic home WiFi router functionality, is easier ways to add guest-like VLANs from the Luci Web-based admin UI. (I currently have a guest VLAN config that I partly cargo-culted with numerous steps in Luci years ago, largely based on a blog post, and that would be a pain to reconstruct on a new install.)
For techies whose households include non-techies, a little IDS/IPS could help keep some nasty traffic off your home Internet pipe, and I suppose that could now run alongside OpenWrt on some of the more powerful plastic boxes, or on a PC with the right WiFi devices/APs. (In addition to use of VLANs and routing to minimize damage from all the malware-infested devices, and also thinking "zero trust" for the techie stuff you run.)
You don't need a fan for OPNsense or pfSense? Plenty of folks running protectli boxes without a fan, they're one of the most popular platforms for both OS'
Netgate are _terrible_ at open source, though — they’re shit at accepting contributions, they’re shit at providing attribution, and they’re shit at providing any support whatsoever to anyone who prefers other hardware (even with their paid software).
Well there was that time you guys paid that absolute nutjob to write a 60,000 line of code disaster Wireguard client. Which you then shipped to customers and tried to force-commit to the FreeBSD project because you wanted a marketing advantage
Your behavior in this thread and this comment especially reflect poorly on you and your company. You've come swinging with something irrelevant to the conversation at hand. I'd never heard of this company, but I'll keep this in mind for the future, and I will perform similar espionage to what you've done.
yes, I contracted with Matt Macy, and I'd do it again, but he's well-employed now.
Funny how you didn't complain about his current employment at AWS, or his previous work at iX Systems (trueNAS, primarily responsible for the port of ZFS on Linux to FreeBSD) or the fact that the whole epoch based reclamation in the FreeBSD kernel is based on his work.
> a little IDS/IPS could help keep some nasty traffic off your home Internet pipe
the adblock package does a great job of blocking ads and other nasty stuff, it doesn't have fancy statistics or an interface like Pi-hole but it does its job without complaining
I definitely believe people underestimate the potential of OpenWRT as an app platform. Before getting sidelined with work I did some proof of concept WebRTC SFU on it https://github.com/atomirex/umbrella which worked surprisingly well.
Was also surprised, then not surprised, to learn it's used as the front end on many of the new generation of 3D printers.
I have a bunch of old WD MyBook Live NAS drives (PowerPC CPU) from an older project, and was surprised that OpenWRT was the best way to get a modern linux on them:
OpenWISP states in its docs that you should be running at least 20 devices to make it worth it. [1] So it's not supposed to be a easy way to manage a few devices for home users.
> However, OpenWISP may not be the best fit for very small networks (fewer than 20 devices), organizations lacking IT expertise, or enterprises seeking open-source alternatives solely for cost-saving purposes.
It's for exactly that reason I started with OpenSOHO.
It is targeted towards the typical home and small office network with less than 20 OpenWRT devices. (although there is no hard limit).
Initially I fiddled a bit with full Open wisp stack to try to make a smaller edition. But I quickly stopped that. But I know their two daemons well.
The config one is a neat little piece of software. It will merge UCI configs and check the connectivity. You can adjust virtually any file with it (although not always with merging). My main issue with it is that it can't be easily temporary disabled from the central controller (I currently implement it by not sending the config, but that triggers retries on the AP end)
The monitoring one spits out an amazing amount of data, although it needs some post processing to make it actually useful. Unfortunately that one can't be extented to add custom entries. I'm currently missing an easy way to see which MAC address is connected which LAN port since OpenWRT DSA puts everyone one the "br-lan".
The whole thing is polling based. So it is quite chatty on the network since I use lower polling rates to make the updates fast. (I suspect on a setup with 100+ you will have longer polling times). All in all the existence of these daemons saved me a ton of time handling networking corner cases. Kudos to the Openwisp team.
I had a GPT-5 agent help me think through a pull-only controller/agent model for OpenWRT. The controller keeps desired configs in git and serves the current version as a tiny tar/zip over HTTP(S), using the last commit ID as the ETag. Agents poll every ~5s with If-None-Match, so it’s usually a 304 and near-zero overhead; when the version changes they fetch the archive and apply it. The controller location is advertised via DHCP; no long-lived sockets or SSH push.
On the device side, the agent only activates if there’s no WAN (so the main router isn’t a client). A new AP gets a LAN IP via DHCP, discovers the controller, pulls its config, and if none exists the controller can hand back a default Wi-Fi setup to come online immediately. Start with Wi-Fi-only changes (reload instead of reboot), aim for a “plug into LAN + power and it just joins” UX, and avoid OpenWISP complexity. It’s built from boring, reliable primitives: DHCP, HTTPS, git, tar, Lua.
I think I'm going to have an agent start coding this up today and see where it gets.
I do notice quite some people focus the autodiscovery part where for me that's less of an issue (I do agree it would be VERY nice). The OpenWISP configuration on each AP is limited to: set IP address of controller & shared secret and click OK. The rest is all magically done for you by the controller.
I do like the 304 idea, in practice it uses the same conceptual idea as the OpenWISP system: check if the MD5 (instead of SHA1) for the current config and the controller config are still identical and download and apply if not.
An important reason I why chose the OpenWISP is that they "just work", are well tested and included in the OpenWRT package list. My main goal is to keep the OpenSOHO project as small as possible ;)
I've been weighing the pros/cons of using OpenWISP. I considered using DHCP to distribute the controller IP and shared secret.
For now, I like reasoning about /etc config files. I'm more familiar with those than OpenWISP. Adopting an abstraction like that offers some portability and possibly future proofing. But that is just the config format and how it is applied though really.
I think once the router is setup, most SOHO users only ever have to add/replace (provision) APs and manage the WiFi settings. I want to make that kind of provisioning and management automatic. Making the APs as stateless as possible - kind of like a Chromebook. The agent will only have basic dependencies (lua, curl, tar).
For this to really work it'll probably have to grow to support VLAN-backed SSIDs and wireless backhaul links. Wireless links would probably need to be wired for their first time setup. But I'd be happy even if it just solved managing my own APs and SSIDs.
The Openwisp agents running on the AP are surprisingly lightweight (they do use Lua, tar, curl and a bit of shell scripting)
VLAN backed SSIDs are one of main reason I started OpenSOHO (although support is not there yet) I don't want to log into each AP to set it up manually.
I do have a wired back haul, but support for wireless backhaul will probably arrive, since quite some people have one set up.
In case you would find an easy method of bootstrapping the setup via DHCP, certainly let me know! (Maybe that's easier to be discussed on GitHub)
"Or just undercutting Wi-Fi vendors like Ubiquiti who basse their work on OpenWRT anyway."
Not sure about today, but this company used to sell hardware whose capabilities were IIRC only "fully enabled" if the buyer used the company's closed source OS. An open source OS might work with the hardware but the buyer would not get the same performance.
At the time, the HN comments continuously supported this company. It appeared that for these commmenters, this was a worthwhile sacrifice. They would just keep recommending Ubiquiti. (Unsolicted recommendations)
Related, I used to love going to the monowall website gallery to see all the labgore. It's still there like a time capsule: https://m0n0.ch/wall/gallery.php
>I'd love to see OpenWRT take a (deserved) bite out of the "SMB firewall vendors" like Netgate or OPNsense. Or just undercutting Wi-Fi vendors like Ubiquiti who base their work on OpenWRT anyway
Why? You don't want competition in the space?
>Or just undercutting Wi-Fi vendors like Ubiquiti who base their work on OpenWRT anyway
Huh? The older edgerouters were based on vyatta. The newer ones on a custom linux distro, neither of which are OpenWRT. They hired the original author of pfsense to build them a firewall based on Debian from scratch when they realized vyatta wasn't going to meet their needs. The UDM kernel is very much not OpenWRT
Being excited about OpenWRT is great but spreading bad information and for reasons I can't fathom hoping for the downfall of other players in the market, not so much.
> They hired the original author of pfsense to build them a firewall based on Debian from scratch when they realized vyatta wasn't going to meet their needs. The UDM kernel is very much not OpenWRT
You're (perhaps unintentionally) also spreading bad information here.
The original 'author' of pfSense was Scott Ullrich, not Chris Buechler. While they were partners in the project, Scott was technical, and Chris did a lot of work back then on documentation, by by his own admission back then, "I am not a developer", and this, even though he was CTO.
Ubiquiti originally hired two of the devs out of Vyatta to maintain their fork of the Vyatta codebase. These two were known on the Ubiquiti forum as 'stig' and 'An Chen'. Both left in the first half of 2016, and then (and only then) did Ubiquiti hire Chris Buechler, in an attempt to maintain and extend the Ubiquiti firmware. Chris has since left Ubiquiti and is now at Alta Labs.
I don't know about newer devices, but the older ones (the Edge* devices) had software based on Vyatta. Not sure if that was in turn based on Debian, though.
The Complainant is the owner of the European Union trademark registration Nos. 012771457 for OPNSENSE (figurative mark), filed on April 8, 2014 and registered on August 20, 2014, for goods in class 9, and 016287716 for OPNSENSE (word mark), filed on January 26, 2017 and registered on May 9, 2017, for goods in class 9.
The Complainant also owns the domain name <opnsense.org>, registered on September 4, 2014, at which it promotes and enables users to download its open-source OPNSENSE firewall.
The disputed domain name <opnsense.com> was registered on April 8, 2014, and is not pointed to an active website.
---
I want you to look closely at the date April 8, 2014, and then I want you to look for anything that occurred before that date, vs. all that occurred after.
The Complainant further points out that the Respondent registered and used the disputed domain name in bad faith because the Respondent has no business activity at the disputed domain name and the only purpose of the registration and use of the disputed domain name is to bring discredit on the OPNSENSE products of the Complainant, by using degrading words and publishing a video, showing an actor interpreting Hitler, with the following phrase above it: “From deep within the OPNSENSE development bunker”.
You seem to not understand the difference between a fact "The disputed domain name <opnsense.com> was registered on April 8, 2014, and is not pointed to an active website." and an assertion or claim, "The Complainant further points out that the Respondent registered..."
How does bad faith exist when the domain "opnsense.com" was registered a full 8 months prior to the January 2, 2015 OPNsense announcement?
Point in fact, we published nothing. That website was not ours. We pointed the domain at it.
you also are ignoring this bit:
---
However, in contesting the Complainant’s supplemental submissions made by the Complainant to substantiate the asserted use of the trademark before the registration date of the disputed domain name, the Respondent introduces new elements which, in the Panel’s view, are relevant for the assessment of the Respondent’s position in this case and will thus be taken into consideration.
Indeed, in its Supplemental Filing, the Respondent states that a document submitted by the Complainant in its Supplemental Filing (as Annex 17) does not demonstrate the Complainant’s use of the trademark OPNSENSE but provides, instead, evidence of use of a trademark PFSENSE in which the Respondent has rights. The Respondent also informs the Panel that it is the manager of Electric Sheep Fencing LLC, a United States company which owns the United States trademark registration No. 3571276 for the trademark PFSENSE, registered on February 10, 2009 claiming first use as of February 19, 2005, for services in International class 42 relating to technical support services, maintenance and development of computer software; and of the International trademark registration No. 1176766 for the trademark PFSENSE, registered on August 28, 2013, for goods in class 9, including computer security software. The Respondent also states that its company Electric Sheep Fencing LLC has rights in a book referenced on the document submitted by the Complainant entitled “pfsense.org The Definitive Guide to the Open Source Firewall and Router Distribution”.
---
OPNsense were using the pfSense mark, and we were taking legal action to stop them.
I hope OpenWrt doesn't turn too commercial (like Netgate or opnsense) because that leads just to subscriptions, enshittification, feature gates, and drama. It is now in a good place as a solid platform to build upon, I hope it stays that way.
OpenWrt is what I use. I picked my routers specifically to be well supported by OpenWrt, immediately wiped whatever the original firmware and installed OpenWrt and that was about ten years ago. Then when I replaced the hardware I also looked for a compatible model with OpenWrt and did the same.
I never had any issue with OpenWrt which I couldn't solve and it just works. Its uptime is pretty much the uptime since when the power goes out due to storms and such.
Same. Been running OpenWrt for years now. I select hardware that runs OpenWrt and never (well, only once, truely) have had to reboot a device due crashing. That old "reboot your router" is just not a thing (touch wood).
I'm sure it helps that all my infrastructure is on a UPS. I've found that even Raspberry Pis can be long-term reliable servers, running ubuntu server and on the UPS.
Another thing that seems to help. I separate function. One box functions only as the router. The wifi boxes only provide wifi endpoints - they do not do routing. And so on.
What hardware did you go with? I was thinking of getting the second most recent glinet to run openwrt, but haven't convinced myself it's worth it since my current tplink is still pretty new and is just be getting it to tinker (I don't currently even run any vlans or anything fancy)
I went with a TP-Link Archer C7 V2. It's quite dated by now, but it's been sitting quietly in the closet and working for all these years and I am still happy with it. My speeds are also not that fast, I only pay for 100Mbps so something faster might overwhelm this hardware. I also don't have anything fancy on it, no vlans just a few wifi networks on 2.4ghz and 5ghz, some wired devices, and two usb drivers which I access via ssh (these do require I install a few extra packages to allow mounting them).
I run openwrt on an ancient Netgear WNDR3700 which is probably 15 years old by now. I can get around 900Mbps on my gigabit connection (wired). We only have two adults in our home using the Internet (for now until our two kids are older!) and it’s been totally fine for us. openwrt is a great way breath extra life into older routers. A lot of homes don’t really need anything fancy or recent.
Seconding all this. Ever since I had weird problems with the vendor firmware on a router, I just pick hardware I can put OpenWrt on right away. Works great.
But then you get annoying firmware providers like Broadcom who refuse to write OSS drivers for linux and a lot of work is being spent on the reverse engineering
The amusing thing about that is that broadcom, not Cisco, was the culprit in the original WRT54G GPL violation. Cisco, of course, were legally liable and should have checked that the code they obtained was not encumbered - although the usual way to do that is to specify contractually that your vendor will do the checking. It was a huge issue for them that they had tripped a customer who provided a significant fraction of their revenue into legal difficulties. I suspect that to this day, a big reason that parts of broadcom are reluctant to open-source stuff is because certain executives are still angry about the experience.
MediaTek chips are well supported by OpenWrt. Broadcom is not good supported.
Mainline Linux kernel supports recent MediaTek Wifi chips quite well [1]. MediaTek is also working on these upstream Linux drivers, but they still have a proprietary Linux driver in addition.
Also the rest of the recent MediaTek SoC is supported quite well by upstream Linux and OpenWrt.
You can run OpenWrt on recent MediaTek SoCs with all code running on the main CPU being open source, no closed source code needed inside the Linux kernel address space or in user space. The chips need firmware running directly on the IP cores. It needs a firmware running on the wifi core itself, there are probably one or more CPUs inside the wifi cores doing real time stuff. The Ethernet PHYs also need a firmware which is running on the PHY.
Ok, but this should not be a major limiting factor.
From my experience, there is sufficient amount of routers based on well-supported chips which work okay with OpenWRT.
When I consider to buy a new router, I go to the OpenWRT device support page, filter for features I would like to get and choose one of the supported routers listed there.
I gave up on openwrt when I realized that a lot of the recent WiFi standards seem to be badly supported. I think 802.11ac was significantly faster with vendor firmware than openwrt, for example.
> 802.11ac was significantly faster with vendor firmware
Yes, I also remember similar issues with TP-Link Archer C7 running earlier versions of OpenWRT. It got better with later versions when they started supporting some kind of flow off-loading.
I am unsure if at the moment the recent OpenWRT WiFi performance of this router is on par with the vendor firmware's WiFi performance.
But yes, your point is valid. However, I do not consider this kind of issues to be deal-breaking. If I remember correctly, a fair amount of devices can achieve the same performance with OpenWRT as with vendor firmware. I would just check for these potential issues in advance and buy only the devices which are confirmed to be working as fast as with the vendor firmware.
The point here is that I rarely have any preferences as to which brand of a router to buy. Many of the marketed features they offer, like proprietary software or mobile apps to control the router, are mostly irrelevant for me. So I choose primarily based on the OpenWRT support level.
OpenWrt accepts binary only firmware running outside of the Linux kernel address space on the wifi chip itself. This matches what upstream Linux also accepts. This works well with most recent Wifi drivers. OpenWrt does not accapt binary only kernel modules or binary only userspace applications, they are very hard to maintain if you do not have the source code.
This works well with Mediatek and also Qualcomm and most other vendors.
GPU vendors have come to the realization that the in-kernel driver needs to be open-source, but the userspace portion can be closed-source. There's just really no good reason to accept a design where outdated closed-source drivers could keep you from running a current kernel. WiFi NIC vendors have for generations been moving more complexity into the closed-source firmware blob that runs on the NIC's own processor core(s), so there's no good reason for the kernel driver to remain closed-source.
Broadcom has been doing FullMAC designs for over a decade now, and that is exactly what you describe: moving all the functionality into firmware and having thin opensource kernel driver
But I wished there was something similar but for "big" (in a relative sense) devices. I feel lot of the constraints OpenWrt is based on are not really that applicable when you have hundreds of megabytes of flash and RAM, and that is starting to become a common thing for routers these days. Even their own OpenWrt One router has 256M flash and a full gigabyte of RAM. That is not all that resource constrained anymore. What I would love is to have something that would be closer to "normal" linux distro while getting the networking goodies and ease of configuration from OpenWrt.
I have the opposite complaint. I wish OpenWRT ran on low-resource routers like those really cheap TP-link ones. DD-WRT does support a few of it, and my personal opinion is that it is better optimised than OpenWRT. By the way, you should explore OpenBSD ( https://openbsdrouterguide.net/ ).
Strongly agreed. I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together.
I'm super glad openwrt exists, and their uci config predates systemd's attempt to build a cohesive consistent whole system configuration pattern & is epic, but given the capabilities of these systems it feels so worthwhile to de-specialize the environment, to make it more boring.
What I really want is Kubernetes oriented tools that can manage hostapd & something like dawn or openert's usteer for band/ap steering. And some other ancillary wifi tools. Maybe maybe a setup for radius/enterprise, instead of just psk. You can do so much more with it, but at its core openwrt is 90% packaging for openwrt. It's not even particularly super well tuned hostapd: theres so much wireless config one can go try & enable that really is just additional 802.11 specs hostapd supports, they may improve your openwrt wifi experience.
> I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together.
I agree. I tried running OpenWrt as a wired router on an x86 mini PC, and found that it had some really powerful features and was certainly rock solid as a router. But there were some major annoyances, too. For example, their documentation includes a script for expanding the root filesystem [1] that left my system unable to boot. And while I didn't use it long enough to make it through an upgrade, their documentation on upgrades makes the process sound very brittle (it sounded like configs for installed packages don't carry over by default) and confusing.
I thought about trying to set up an Ubuntu (or other popular distro) box as a router, which I think would be much easier to maintain over time. But my concern is that I might overlook some important config that is set by default in OpenWrt, and leave my machine vulnerable to attack. Having a web UI that I can log into and view/make config changes is also kind of nice. Are there any good out-of-the-box solutions or guides for doing this? (I know that OPNSense/PFSense are really popular among homelab users, but unfortunately the Marvell NICs in my mini PC are not supported in FreeBSD).
> I tried running OpenWrt as a wired router on an x86 mini PC, and found that it had some really powerful features and was certainly rock solid as a router. But there were some major annoyances, too. For example, their documentation includes a script for expanding the root filesystem [1] that left my system unable to boot.
I have been doing this myself recently. The docs around this are pretty out of date. The docs as they’re written only work for the ext4 images if I remember correctly. I got it to work with the squashfs version, but it was really janky. The problem is the OS just writes the to the empty space at the end of the squash partition without changing the partition table. I could only successfully get it working if resized the partition on first boot before the writable overlay is created.
> And while I didn't use it long enough to make it through an upgrade, their documentation on upgrades makes the process sound very brittle (it sounded like configs for installed packages don't carry over by default) and confusing.
I feel similarly about the process. There is either a command or a place on disk where you can put files to protect them across upgrades, but I can’t remember just now. I think it works that way because it’s targeted at embedded devices where I would think you typically bake everything you need into the root file system at compile time. I’m not an embedded engineer so maybe there are better ways of doing it.
> The docs as they’re written only work for the ext4 images if I remember correctly
I was using an ext4 image and still ran into problems. And in addition to the scripts on the page that I linked above, I also tried this other variation from their docs [1]. They all ended up rendering the sytem unbootable.
Eventually I think I ended up using an Ubuntu Live ISO to boot the system and made the change there. Definitely a bit of a pain, and according to the docs it sounds like something I would need to do again after an upgrade.
I also tried following their steps for "building your own image with larger partition size" [2], but couldn't get that to work either.
I had fun playing around with OpenWrt. But in the end was forced to admit that I didn't really need any features in OpenWrt, and whatever benefits I was getting from it were not worth the effort. Also, even a minute of downtime for a reboot was pretty annoying to my family when they were trying to stream a movie, etc.
I know the answer to this. The ext4 filesystem that openwrt creates by default is just janky. To get well-working filesystem that you can resize etc, you need to build custom image with a small patch to fix up the ext4 fs creation.
> I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together.
Yup, that's the answer. Debian is rock solid, and a script with a bunch of iptables and iproute2 commands is so much simpler than the mess that is OpenWRT's network setup. I only use it for dumb APs, and even then it's questionable -- the UI is nice, but configuring it is unnecessarily complex IMHO.
I run OpenWRT on a 'big' device, this being a container on a Proxmox-managed DL380 G7. It works fine in this context, performance is good enough to be able to easily saturate the gigabit fibre link without breaking into a sweat.
Installing OpenWRT on such a device comes down to downloading openwrt-${version}-x86-64-rootfs.tar.gz and unpacking it in the target location. Boot the container or VM (or old PC or whatever) and follow the normal OpenWRT configuration procedure. Updating such an installation comes down to making a configuration backup in OpenWRT, unpacking the new distribution and restoring the configuration backup to the new install. Given the low resource requirements for such an installation it makes sense to first clone the working container or VM and performing the upgrade on one of the instances so you always have a working instance at hand.
Sure, openwrt works. I too have run it on x86 vm at a time. That being said, there is lot that could be improved. My biggest gripe is the weird filesystem layout with overlays and stuff in /tmp and whatnot. I can see it being needed on tiny devices, but on bigger ones can I just have regular ext4/xfs gpt partitions please? Another thing is just replacing the tiny versions of software with regular ones, like busybox->gnu or dropbear->openssh etc. Systemd could be at least considered as init.
All of this kind of things make sense when you consider openwrts origins. But on "big" system I'd just much rather have it be closer to "normal" Linux.
OpenWRT on x86_64 does not use overlay mounts, here's an overview of a current instance running in a Proxmox-managed container:
/dev/mapper/pve-vm--500--disk--0 on / type ext4 (rw,relatime,stripe=512)
none on /dev type tmpfs (rw,relatime,size=492k,mode=755,uid=100000,gid=100000,inode64)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
... more proc mounts...
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
... more sysfs mounts
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
udev on /dev/net type devtmpfs (rw,nosuid,relatime,size=65960672k,nr_inodes=16490168,mode=755,inode64)
none on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
lxcfs on /proc/cpuinfo type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
... more lxcfs mounts
udev on /dev/full type devtmpfs (rw,nosuid,relatime,size=65960672k,nr_inodes=16490168,mode=755,inode64)
... more udev mounts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=100005,mode=620,ptmxmode=666,max=1026)
... more devpts mounts
none on /proc/sys/kernel/random/boot_id type tmpfs (ro,nosuid,nodev,noexec,relatime,size=492k,mode=755,uid=100000,gid=100000,inode64)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,uid=100000,gid=100000,inode64)
No overlays, just a normal ext4 filesystem. Data in /etc is stored in /etc, data in /var is stored in /var, etc. OpenWRT running from a filesystem image is 'just another Linux distribution which happens to run the same software as that re-flashed router'.
Something with a more normal way of updating the packages and OS would be nice. I thought I'd heard someone was working on an Alpine-based thing a few years ago, but haven't heard anything since.
Agreed. When I last tried to update packages there was a scary disclaimer about it being likely to break the system, and that flashing a new firmware is preferred.
I nope'd out of that, and don't wish to go through the hassle of flashing again, so my AP is running a year+ old version. It works fine, and I'm not too concerned about it, but I would still like to be able to easily upgrade the system without worrying about breaking it.
You can build the image yourself, but have to switch off some packages or features - otherwise the image (linux-kernel + tools) is just too large or consumes too much memory. The original router has 8 megabytes RAM-memory and 2 Megabytes flash ("storage"). You can boot a recent kernel 6.16.5, but with 8mb there is not much left to work with 8-)
My uneducated guess is that that people that want this kind of symbolism aren't willing to actually become a maintainer and invest time in niche code for a declining user base?
Been a fan for a long time and use it on my Archer C7, but I had to disable hardware switching in order to use SQM, and now the switching performance is <200mbps. Having recently upgraded to home fiber, I'm probably going to get a native Unifi router.
Maybe have a look at Intel n100 boxes (Aliexpress -> Topton). They often have 4-5x 2.5GE Ports with high quality Intel cards. They are very cheap (100-200€) and suck not too much current (5-15W).
You can run OpenWRT on them using the x86 build.
We usually have 5-10x of them around for emergency network tasks if everything burns down in a building.
Honestly it is tempting. I do have an old Haswell-era industrial motherboard that would manage the task just fine, and I've definitely considered this path.
That said, I'd probably spend about as much on a power supply, case, and NIC for that machine as I would on just buying a Unifi gateway, and theirs comes with an integrated UI for the APs. I'm past the stage of life where I find joy in tinkering with the infrastructure I need to do my job (WFH) so I'll probably still just go off the shelf.
I bought a Fujitsu Futron S920 second hand for like 30 euros. Put a dual NIC PCI in there and now have a low watt router running very fast. Can easily run 1Gbit up and down
Agreed... probably the best experience for a SOHO router+wifi. I currently use OpnSense on an N305 mini pc for my router and the separate wifi AP has it's own management interface. Works for my needs.
Interesting, on my latest router (WRT3200ACM) I've had the opposite experience - I had to switch from OpenWRT to DD-WRT since the former was too buggy to use (couldn't get the WiFi to work reliably).
I'm a huge fan of OpenWrt. When I got 10 Gbit internet at home I had to replace my old Ubiquiti USG3 on the cheap so I built a router out of a $80 Lenovo ThinkCentre Tiny.
I tried OPNsense and pfSense on advice but they could never crack around 5 Gbps throughput even with a bunch of tweaking, but OpenWrt gave me the full 10 gbps out of the box with no hassles.
I also replaced the Ubiquiti firmware on an EdgeRouter with OpenWrt and it boosted the throughput from around 1.3 Gbps to 1.7 Gbps.
The OpenWrt UI for configuring the firewall is probably one of my favorite firewall UIs of all time. Before OpenWrt I could never wrap my head around those "local" etc ruleset names in more traditional routers, I had to look them up again every time I edited the config. Just being able to say "I have these networks, let this one do this to that one" is very easy to understand.
Openwrt is amazing. I had a wrt54gs, and then latter got a Netgear wgt634u with an astounding USB2 port! Served as a great office shoutcast playing server for the office, a decade before Sonos (for example) existed.
The hardware situation has felt very tenuous for years now. Qualcomm support has felt so so bodged in. It feels perpetually like "this new chipset will finally get us past all the horrible half working hacks of the last barely working chipset" on and on, usually sort of working but only barely. I did finally get my IPQ8074A based router going (rax120) but it took so long, and needs an older wifi firmware (their 2.7) to work. But it feels like maybe slowly it could be getting better, maybe perhaps support will be more mainline less hacked next time.
It's good to see MediaTek present in openwrt space. One of the only other highly present chipsets available. The price is often quite good for pretty new wifi standard supporting routers. The anec-data I've heard is that driver maturity is not great, but at least there's motion & movement within the kernel, which springs hope eternal.
All my accesspoints and routers run OpenWRT. Love it.
At some point I even ported OpenWRT to my unsupported tplink device. IIRC I hacked together a devicetree and made some small modifications to the tplink loader code.
Funnily enough when I made a PR on github it was basically ignored after I implemented the feedback. I proceed to instead send the patch to the mailinglist and it was merged the same day without comment. That must be some kind of skill filter...
And all it took was forcing one company to divulge its proprietary closed-source codebase because they screwed up and incorporated copyleft code deep into their core.
Imagine how much progress could be made if a few other companies were forced to crack open their proprietary closed-source codebases...
They were poopooing that before the OpenWRT case. I don't think there's evidence to suggest that the OpenWRT case made them less willing to use GPL (especially since use of GPL would always have implied they should open-source the firmware derived from it).
I assume that about 20% to 50% of the home routers, Access points and Wifi mesh devices sold world wide are based on OpenWrt. Often some old versions of OpenWrt with many vendor modifications, the UI is always custom.
I know that the main vendor SDKs from Qualcomm, Mediatek, and Maxlinear are based on OpenWrt. I think only Broadcom uses an own Linux distribution which is not based on OpenWrt in their main SDK. Linux has a market share of about 99% in this market, I haven't seen VxWorks in any recent home router or access point.
The WiFi silicon vendors seem to base their SDK/reference software on OpenWRT (albeit often badly-outdated versions), so almost everyone selling a WiFi box ends up using some variant or fork of OpenWRT. It's been a long time since the days of Linksys trying to cut DRAM costs by using something other than Linux. There are still exceptions like MikroTik where the OS and configuration tools are a main selling point (still Linux-based, but not OpenWRT).
Where does Ubiquiti use OpenWRT? I saw that claim elsewhere in this thread but I'm pretty sure their original devices were based on Vyatta, and their newer stuff is a custom Linux OS of their own that is loosely Debian-flavored. Poking around in the terminal all the Ubiquiti devices I have used are very clearly unrelated to OpenWRT.
Ubiquiti started in outdoor wireless, point to point and point to multipoint. All their outdoor radios, cameras, and unifi APs are all running a version of openwrt.
EdgeRouters started on vayatta and then that went away (AT&T acquired Vayatta) and then that forked into VyOS.
Some of the Ubiquiti EdgeSwitches are running some other OS, but I can't remember what it was.
Source - Spent 14 years helping alpha / beta test, debug code and wireless problems, etc.
I just started using OpenWrt on Incus via LXC and it works really well. The most difficult part was just learning the config file. It looks like upgrading OpenWrt (esp. on LXC) is the tricky part though so not looking forward to that. I considered moving it to a VM so upgrading it is easier but it runs so smooth on Incus.
> In our hyper-connected world, we've become slaves to the endless scroll. Social media, news, videos - the algorithm-driven content feeds are designed to capture and hold our attention indefinitely. We tell ourselves "just 5 more minutes" but hours disappear. Our brains are being rewired for constant stimulation, making us less capable of deep thought, genuine connection, and meaningful work.
> The Big Internet Button breaks this cycle by introducing friction back into your internet consumption.
Installed it on a TP-Link to replace my ISP router a couple days ago. I'm super impressed with how it needed almost no config (except to manually activate the Wifi and to set a password).
I'd recommend downloading the Material theme for anyone complaining about the barebones look.
there is often a "recovery feature", an alternate boot partition [ i posted about this some time ago.]
if you configure your router so that it "bricks" you can boot in the last working configuration before your changes; rescue; and save to overwrite the brick partition. presumably you can do this forever, as long as you dont brick both partitions.
3 interrupted boot cycles would cause a switch to last successful boot partition.
in my case i had problems because of the curious way we have power failures here.
the power would brown out and each phase of generation would send a peak and trough, equivalent to turning power on then off before boot completion 3 times.
if you want to be snazzy, you can play on this and work two partitions at once each configured for different purpose, and accessed by briskly cycling power thrice.
Unfortunately, they use Busybox under the hood with its plethora of unfixed bugs and security issues and a bug tracker that is almost always down. I cannot trust this project anymore and stopped using systems based on it.
Sorry, we know that the EU and NA distribution channels are not so good. The OpenWrt project depends on Banana Pi here. There are some resellers on Amazon.
About 10k OpenWrt one units were sold as of today. The first 900 were sold in about 3 days.
I switched from an ARM version of Openwrt on my Linkstar H68K to a Beelink EQI12 powered Proxmox instance running Openwrt on a VM. Used ChatGPT to debug it and set up multi-wan failover for it. Works excellently.
Fond memories of PirateBox.
Actually, fondness is directly proportional to which router I was hacking
- Thumbs down for TP-Link
- Many thumbs up for the GLI AR150, the sweetest of spots (hugging face emoji)
https://youtube.com/watch?v=DWmLVDAV5kY
His content helped me when I first made the plunge into OpenWRT earlier this year and realized I knew next to nothing about networking. He also has a video on policy-based routing that is cited in the PBR documentation as well.
Thanks, I'm looking forward to watching. I was totally frustrated by implementing DNS+IP parental controls on OpenWRT and am interested if there is better tooling now. My recollection is that there are multiple wrappers of configuration behind the webUI and trying to run AdGuard home on the same hardware lead to performance problems.
Apples and oranges. It is a nice tool for closed-source Broadcom devices that OpenWRT will never support. Otherwise it has nowhere near the complexity and features.
I use Tomato too, but I wouldn't say it offers many benefits over OpenWrt. The main thing is that routers based on Broadcom chipsets often only work with very old Linux kernels (such as 2.6.xx kernels), as the drivers are closed source. For these routers, the primary third-party router OS choice is to use Tomato.
I have not but if there was enough interest I could make a rough go at it. It's not a very complicated setup.
It's basically Alpine Linux with some custom sysctl and interface settings, sch_cake with custom settings, cdg, netfilter, Unbound DNS with some local zones for limited spam filtering and a cron based refresh of common domain names, blackhole routes for known clowns and DoH/DoT IP addresses, chronyd for NTP, dnsmasq for static and dynamic DHCP, gratuitous arp cron job to lower latency and steal back my IP if someone tries to take it and restore quickly from ISP router failover all running on a Protectli VPN class small business firewall with cron snapshots/backups from another node.
My first pass would probably just be a static page with linked text files of the configurations and a brief synopsis of what each file or in some cases individual settings are performing.
Another option (depending on your requirements) is to use normal "workstation" Linux distro like Debian on an regular x86 PC equipped with two NICs. I added an SFP28 dual NIC to an old gaming PC and now use it as a router/home server and can saturate the link (25Gbps). I get north of 4Gbps through Wireguard too. Routing and the firewall are built into the kernel so you don't really need a specific distro. I just added a DNS server (Unbound in recursive mode) and a DHCP server. For WiFi I use hostapd, but an external AP would be a better solution for most people.
Did you manage to get IPv6 prefix delegation working with dynamic prefixes? Best solution I found involves scripting to re-build config files and restart a daemon, where OpenWRT just does it out of the box.
Openwrt still has some strange footguns (imo) and the upgrade process is painful. I personally just prefer running general-purpose distros for my routing and firewalling needs. I realize the learning curve for this for someone who just wants a home router is unrealistic though :)
But out of all the router/firewall distros, OpenWRT it is by far the best.
I've been following OpenWRT for years, and finally made the jump.
This was after using DD-WRT and various flavors of Tomato (especially Shibby and FreshTomato) for two decades on probably ~100 routers in various locations. Some of those locations were business production environments, with the routers providing VPN connecting sites across the continent as a backbone for VOIP telephony, remote user access, etc. (before the likes of Tailscale).
It's an important project and I have a great appreciation for all the work the developers have put into it. But I have to admit, I was underwhelmed. LuCI wasn't as robust as I expected (the "queue all your changes as a batch of commands" approach is a great idea, but its implementation has some rough edges that simply don't work - IIRC, where the UI isn't aware of conflicting config changes you've already queued). And I found in practice getting it to do things that are easy and reliable on FreshTomato, was frustratingly unintuitive, taking more steps than I'd expect, some seeming brittle/error-prone. I'm not averse to scripting, having written short novels of commands for previous OS's, and even custom-compiled binaries (e.g. to install iPerf, before it was bundled with the OS) and a whole custom FreshTomato build that added some admin pages for long-term bandwidth/latency graphing. So I'm open to learning new things, I just felt like I was doing more fighting with the OS than should be necessary.
One small example was configuring a Let's Encrypt certificate. This feels like it should be a near one-click operation. In my case it took a bit of testing and tweaking to get right - I wound up contributing my short solution back to a SuperUser answer: https://superuser.com/a/1904844/75522
Properly disabling IPv6 took more than just a checkbox. I had "No default route present, overriding ra_lifetime to 0!" messages logged, until I added "net.ipv6.conf.all.disable_ipv6=1" to /etc/sysctl.conf.
Maybe I'm just getting snagged by doing things in 'weird' ways. e.g. My inaugural router on it is a MikroTik wAP ac. Turns out you don't get a WAN interface out of the box when flashed on that device, and I had to manually create it. There wasn't really any documentation warning about that, and it took a while before I realized life would go better if I used a lowercase rather than uppercase convention (for better integration with built-in stuff that relies on its existence).
A lingering issue I haven't figured out yet is how to make a reliable "toggle switch" to turn on and off access to the internet for one device on my network (by IP or MAC address). I set up a firewall rule, but wind up having to manually run "/etc/init.d/firewall reload" and "conntrack -D ..." each time to kill any established connections. On FreshTomato it was just a checkbox you turn on/off. If anyone has advice on this I'd be grateful.
One last tip for anyone else using it on a router plugged into a Starlink endpoint that's in bypass mode (i.e. you want to be able to port forward). You'll get messages in syslog every 5 minutes due to short-lived Starlink IP:
daemon.notice netifd: wan (####): udhcpc: sending renew to server
daemon.notice netifd: wan (####): udhcpc: lease of ###.###.###.# obtained from ###.###.###.#, lease time 300
You can suppress them by appending "-l 1" (without quotes) to the "procd_set_param command /sbin/netifd" line in /etc/init.d/network, then reboot the router (in my case running "/etc/init.d/network reload" didn't quite do it). On the plus side, the Dynamic DNS package is working well in my setup. (And yes, I understand the implications of using Let's Encrypt on a DDNS IP).
I'm not here to whine, just to suggest that anyone else thinking of making the switch manage your expectations and leave yourself some time to perfect things and get used to the new platform.
Its simple usability polish. Tomato had it, OpenWRT doesn't. But where it shines is in the reliability. I've been using it for over 10 years, and prior to that DD-WRT on a 54L.
That's the biggest challenge with many of these open source tools. They're built to solve a single or handful of problems, but don't always fit for a larger audience. I'm not complaining either, and I'd be happy to provide the polish, but right now, my time is spent with my clients ($$).
If you invest the time in getting it configured the way you want, you'll be happy too, for 10 years. ;)
Food for thought of why I'm exploring other options currently:
1. Need a WAN failover that can check with a custom heartbeat
2. Need an easy-to-configure VPN that doesn't use an open port, but will register against my own cloud server
3. Need an easy way to monitor traffic of particular devices - DNS queries and active connections
4. Need a big button to turn off the internet for all, and individual buttons to turn it of for specific devices
5. Need an easy way to manage VLANs and traffic routing rules (for local-only designated devices)
This is actually probably the best thing OpenWRT have done in quite a while. I got two (one for a backup) and I've been super happy. I've happily used TP-Link, GL.iNet, and Raspberry Pi 4 devices, with OpenWRT in the past, but nothing beats the "it just works" aspect of a first party device designed for this, fully open, and a reasonable price.
Most off-the-shelf devices have too slow of CPU for a low latency/buffer router. The Raspberry Pi 4 is easily fast enough but needs to use USB3 network adapters which require packages not in the default rpi4 OpenWRT image. Not insurmountable, but a consistent pain every upgrade.
I ended up building my own image of OpenWRT to make the package hell better on upgrade, and as a bonus, I was able to build in my configs too. Recovering from a failed Pi was as simple as flashing the most-recently-built image. Upgrading just required rebuilding the image (and resolving whatever went wrong, of course, though it was usually pretty light). As a bonus, it's easy to swap SD cards on the Pi so I can have the last "known good" config available while taking the update.
Now I run OpenWRT on one of those x86 mini PC boxes with 4x 2.5GBe Intel NICs because my wirespeed is 2 Gbps symmetric, so I needed just a bit more oomph than the Pi could provide. The hardware is somehow even _less_ reliable than a Pi 4 - I'm already on my third machine in 3 years. I would love to find something more reliable.
OpenWRT has also made it incredibly easy to package in any arbitrary pkg into image downloads from their website. You don't need your own build infrastructure now.
I'm curious what your experience would be like with a Pi5/CM5 solution using PCIe for your ethernet. It is pretty easy to have spare boards and SD cards around for Pi setups. I've had good reliability with Pi setups using good passive cooling (no fan to die).
Not a huge fan of the design decisions on that one. $250 target makes it a hard sell to anyone but network nerds. At $100, I would have no issues making that the default recommendation for anyone, regardless of technical knowledge. Being a premium point requires justifications beyond open source warm and fuzzies.
Network enthusiasts are likely to already have separate switches and WiFi points. Let the router just route.
The CPU in such switches is far too slow to do any data plane operations, so performance is entirely due to the hardware switching. Replacing Ubiquiti's OS with OpenWRT just gets you a different management interface for configuring the hardware features that actually handle traffic. (Unless for some reason you desperately want to have a VPN endpoint that would be limited to a few Mb/s at best.)
Ubiquiti make great hardware, however a lot of people hate the software as it is buggy and inconsistent. This at least gives those people options to run something a bit more opoen and manageable under the hood.
Evaluating a return to it from some time in pfSense--it is wonderfully simple. At the same time, its the wrong abstraction for most people who want to manage childrens' devices and iots because it is no abstraction, the operator must know many implementation details that aren't worth knowing outside the system.
Could you provide any specifics? Are you wanting a dumbed-down UI that hides most of the functionality, or are you wanting the existing functionality to be exposed to the user differently?
To be clear, OpenWRT is a great OS. The UI is a bit old fashioned, existing functionality could be exposed more cleanly, and the terminology could be more intuitive.
This is basically what gl-inet did! You can compare how they expose functionality. Of course, it’s limited, but eventually the remaining features in LUCI could be incorporated in the same UI.
IMO it's valid criticism and at the same time IMO GUIs are unnecessary frills.
If you've tried Cisco routers - you can export ALL configurations by running command `show running-configuration`, or `display current-configuration` on Huawei routers, or `show configuration commands`on Vyatta/VyOS/EdgeOS, which can then be restored onto a brand new router by just right click pasting that log into the ssh session.
That's VASTLY superior to ANY GUI. IMO. YMMV. IANAL. Views are my own. But it is.
All UCI configuration on OpenWRT is stored in /etc/config/, and exporting/importing it is as simple as one scp command. The GUI is great for discoverability, on the other hand.
I'm a staunch defender of OpenWRT. Having used just about every "router distro" folks care to name (remember SmoothWall?) for the last 20~ years, OpenWRT is built like a tank and just keeps trundling along
I hope their experiments with the "OpenWRT One" keep going. I'd love to see OpenWRT take a (deserved) bite out of the "SMB firewall vendors" like Netgate or OPNsense. Or just undercutting Wi-Fi vendors like Ubiquiti who base their work on OpenWRT anyway
Something I'm excited to try myself in future is running "OpenWISP" [1] to manage a small fleet (three) OpenWRT devices in parallel for a deployment in a shared workshop. This seems to also be something that OpenWRT could be better at integrating, but it's nice to see "a vendor" tackling it
[1] https://openwisp.org/
Ease of managing multiple OpenWRT devices is still its weakest link. OpenWRT is device centric, but I don't want to managed devices, I want to manage a network.
Modern mesh WiFi systems I've seen do that so well. I know in theory that I could create a VLAN + SSID on my OpenWRT router and APs just for iot devices to only access the internet. But setting that up on a TP-Link mesh was a couple of taps in their app. Doing it on my OpenWRT devices would be quite a bit more hassle.
Thinking about this more, I doubt I'll setup any OpenWRT APs on my network going forward. Most of the things I like about OpenWRT, and need it for, are related to being my router. My OpenWRT APs are just "dumb" APs. Wifi is off on the router.
For the APs, I could use a mesh kit like the TP-Link Deco unit I installed for a friend recently. Super easy setup, reasonable price (cheaper than equivalent OpenWRT hardware I'd buy), wired backhaul up to 2.5Gbps.
There might be a workaround for some people - get a big openwrt switch.
Openwrt supports the zyxel gs1900 switch, which goes up to 48 ports.
At home, I built an OPNsense box to evaluate (using Sophos XG135 Rev 3 hardware, along with an OpenWrt nice Netgear WiFi AP on POE), but then went back to a plastic OpenWrt all-in-one box.
OPNsense (and pfSense) are neat, but I personally don't need an IDS/IPS right now, and I like to be able to run the router fanless.
One thing that OpenWrt could use immediately, for basic home WiFi router functionality, is easier ways to add guest-like VLANs from the Luci Web-based admin UI. (I currently have a guest VLAN config that I partly cargo-culted with numerous steps in Luci years ago, largely based on a blog post, and that would be a pain to reconstruct on a new install.)
For techies whose households include non-techies, a little IDS/IPS could help keep some nasty traffic off your home Internet pipe, and I suppose that could now run alongside OpenWrt on some of the more powerful plastic boxes, or on a PC with the right WiFi devices/APs. (In addition to use of VLANs and routing to minimize damage from all the malware-infested devices, and also thinking "zero trust" for the techie stuff you run.)
>I like to be able to run the router fanless.
You don't need a fan for OPNsense or pfSense? Plenty of folks running protectli boxes without a fan, they're one of the most popular platforms for both OS'
the entire desktop line from Netgate is fanless.
Netgate are _terrible_ at open source, though — they’re shit at accepting contributions, they’re shit at providing attribution, and they’re shit at providing any support whatsoever to anyone who prefers other hardware (even with their paid software).
So I really can’t say I recommend their hardware…
I ask that you provide evidence of your assertions:
- they’re shit at accepting contributions
- they’re shit at providing attribution
- they’re shit at providing any support whatsoever to anyone who prefers other hardware (even with their paid software).
In addition to pfSense (which is what I think you're criticizing) and all of its open source, we're upstreaming things to FreeBSD and fd.io VPP
Try this on a fresh copy of FreeBSD 'src':
% git log --first-parent --since="1 year" | sed -E 's/\^.*Sponsored.\[Bb\]y:\[\[:space:\]\]*//p' | grep -i Sponsored | sed -E 's/.*\[Ss\]ponsored\ \[Bb\]y://' | awk '{$1=$1};1' | sort | uniq -c | sort -rn | head
or for VPP, look here:
https://www.stackalytics.io/unaffiliated?module=github.com/f...
Well there was that time you guys paid that absolute nutjob to write a 60,000 line of code disaster Wireguard client. Which you then shipped to customers and tried to force-commit to the FreeBSD project because you wanted a marketing advantage
https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
[flagged]
Your behavior in this thread and this comment especially reflect poorly on you and your company. You've come swinging with something irrelevant to the conversation at hand. I'd never heard of this company, but I'll keep this in mind for the future, and I will perform similar espionage to what you've done.
Weird flex of a comment after y'all got dragged (deservedly) for hiring Matthew Macy. But I guess we'll just have to agree to disagree
yes, I contracted with Matt Macy, and I'd do it again, but he's well-employed now.
Funny how you didn't complain about his current employment at AWS, or his previous work at iX Systems (trueNAS, primarily responsible for the port of ZFS on Linux to FreeBSD) or the fact that the whole epoch based reclamation in the FreeBSD kernel is based on his work.
I'm sure the LKML will enjoy his commits just as much as FreeBSD did
yes, I'm sure that FreeBSD actually does enjoy all of his work on OpenZFS and epoch-based reclamation.
No wonder y'all are pivoting to Linux I suppose :)
Also you should stop editing your comments after they're replied to. It makes it awfully confusing
We already have a linux-based product (TNSR).
Bringing that tech stack to a firewall is a logical move.
> a little IDS/IPS could help keep some nasty traffic off your home Internet pipe
the adblock package does a great job of blocking ads and other nasty stuff, it doesn't have fancy statistics or an interface like Pi-hole but it does its job without complaining
I definitely believe people underestimate the potential of OpenWRT as an app platform. Before getting sidelined with work I did some proof of concept WebRTC SFU on it https://github.com/atomirex/umbrella which worked surprisingly well.
Was also surprised, then not surprised, to learn it's used as the front end on many of the new generation of 3D printers.
I have a bunch of old WD MyBook Live NAS drives (PowerPC CPU) from an older project, and was surprised that OpenWRT was the best way to get a modern linux on them:
https://openwrt.org/toh/western_digital/mybooklive
They're slow, but great for stuff that doesn't need to be fast.
> I hope their experiments with the "OpenWRT One" keep going.
OpenWRT Two is scheduled for late 2025 from GL.iNet and should go for ~$250.
https://news.ycombinator.com/item?id=43512495
I read about this on lwn and am pretty excited for it.
I've been happy with the One, but two Ethernet ports is definitely not ideal for even casual home use.
OpenWISP states in its docs that you should be running at least 20 devices to make it worth it. [1] So it's not supposed to be a easy way to manage a few devices for home users.
> However, OpenWISP may not be the best fit for very small networks (fewer than 20 devices), organizations lacking IT expertise, or enterprises seeking open-source alternatives solely for cost-saving purposes.
1: https://openwisp.org/faq/#suitable
It's for exactly that reason I started with OpenSOHO. It is targeted towards the typical home and small office network with less than 20 OpenWRT devices. (although there is no hard limit).
https://github.com/rubenbe/opensoho
It is still a work in progress, but it is easy to deploy (one golang binary based on pocketbase)
Very interesting project! I was thinking of something that would fill this gap.
Based on your experience, as OpenSOHO seems to use OpenWISP, what do you wish you knew about OpenWISP before you started this?
Initially I fiddled a bit with full Open wisp stack to try to make a smaller edition. But I quickly stopped that. But I know their two daemons well.
The config one is a neat little piece of software. It will merge UCI configs and check the connectivity. You can adjust virtually any file with it (although not always with merging). My main issue with it is that it can't be easily temporary disabled from the central controller (I currently implement it by not sending the config, but that triggers retries on the AP end)
The monitoring one spits out an amazing amount of data, although it needs some post processing to make it actually useful. Unfortunately that one can't be extented to add custom entries. I'm currently missing an easy way to see which MAC address is connected which LAN port since OpenWRT DSA puts everyone one the "br-lan".
The whole thing is polling based. So it is quite chatty on the network since I use lower polling rates to make the updates fast. (I suspect on a setup with 100+ you will have longer polling times). All in all the existence of these daemons saved me a ton of time handling networking corner cases. Kudos to the Openwisp team.
I had a GPT-5 agent help me think through a pull-only controller/agent model for OpenWRT. The controller keeps desired configs in git and serves the current version as a tiny tar/zip over HTTP(S), using the last commit ID as the ETag. Agents poll every ~5s with If-None-Match, so it’s usually a 304 and near-zero overhead; when the version changes they fetch the archive and apply it. The controller location is advertised via DHCP; no long-lived sockets or SSH push.
On the device side, the agent only activates if there’s no WAN (so the main router isn’t a client). A new AP gets a LAN IP via DHCP, discovers the controller, pulls its config, and if none exists the controller can hand back a default Wi-Fi setup to come online immediately. Start with Wi-Fi-only changes (reload instead of reboot), aim for a “plug into LAN + power and it just joins” UX, and avoid OpenWISP complexity. It’s built from boring, reliable primitives: DHCP, HTTPS, git, tar, Lua.
I think I'm going to have an agent start coding this up today and see where it gets.
Nice idea!
I do notice quite some people focus the autodiscovery part where for me that's less of an issue (I do agree it would be VERY nice). The OpenWISP configuration on each AP is limited to: set IP address of controller & shared secret and click OK. The rest is all magically done for you by the controller.
I do like the 304 idea, in practice it uses the same conceptual idea as the OpenWISP system: check if the MD5 (instead of SHA1) for the current config and the controller config are still identical and download and apply if not.
An important reason I why chose the OpenWISP is that they "just work", are well tested and included in the OpenWRT package list. My main goal is to keep the OpenSOHO project as small as possible ;)
I've been weighing the pros/cons of using OpenWISP. I considered using DHCP to distribute the controller IP and shared secret.
For now, I like reasoning about /etc config files. I'm more familiar with those than OpenWISP. Adopting an abstraction like that offers some portability and possibly future proofing. But that is just the config format and how it is applied though really.
I think once the router is setup, most SOHO users only ever have to add/replace (provision) APs and manage the WiFi settings. I want to make that kind of provisioning and management automatic. Making the APs as stateless as possible - kind of like a Chromebook. The agent will only have basic dependencies (lua, curl, tar).
For this to really work it'll probably have to grow to support VLAN-backed SSIDs and wireless backhaul links. Wireless links would probably need to be wired for their first time setup. But I'd be happy even if it just solved managing my own APs and SSIDs.
OpenSOHO and OpenWisp do both send parts of /etc/config files to the AP.
While we're discussing: someone did an attempt in the OpenSOHO discussions to have a freshly flashed AP register automatically with OpenSOHO:
https://github.com/rubenbe/opensoho/discussions/1#discussion...
The Openwisp agents running on the AP are surprisingly lightweight (they do use Lua, tar, curl and a bit of shell scripting)
VLAN backed SSIDs are one of main reason I started OpenSOHO (although support is not there yet) I don't want to log into each AP to set it up manually. I do have a wired back haul, but support for wireless backhaul will probably arrive, since quite some people have one set up.
In case you would find an easy method of bootstrapping the setup via DHCP, certainly let me know! (Maybe that's easier to be discussed on GitHub)
This looks a lot closer to what I'm after. Bookmarked the git repo :)
I saw that. Admittedly I'm only interested in a few of its functions. Namely roaming and guest hotspots
I could wire up all of that manually. But I'm excited for the chance to learn something new
"Or just undercutting Wi-Fi vendors like Ubiquiti who basse their work on OpenWRT anyway."
Not sure about today, but this company used to sell hardware whose capabilities were IIRC only "fully enabled" if the buyer used the company's closed source OS. An open source OS might work with the hardware but the buyer would not get the same performance.
At the time, the HN comments continuously supported this company. It appeared that for these commmenters, this was a worthwhile sacrifice. They would just keep recommending Ubiquiti. (Unsolicted recommendations)
We once delivered a totally not router box running openwrt, just because it was very simple and bastardising openwrt was easier than yocto.
Related, I used to love going to the monowall website gallery to see all the labgore. It's still there like a time capsule: https://m0n0.ch/wall/gallery.php
I went smallwall after m0n0wall was shutdown. I recall the smallwall & smoothwall maintainers briefly considered joining forces.
>I'd love to see OpenWRT take a (deserved) bite out of the "SMB firewall vendors" like Netgate or OPNsense. Or just undercutting Wi-Fi vendors like Ubiquiti who base their work on OpenWRT anyway
Why? You don't want competition in the space?
>Or just undercutting Wi-Fi vendors like Ubiquiti who base their work on OpenWRT anyway
Huh? The older edgerouters were based on vyatta. The newer ones on a custom linux distro, neither of which are OpenWRT. They hired the original author of pfsense to build them a firewall based on Debian from scratch when they realized vyatta wasn't going to meet their needs. The UDM kernel is very much not OpenWRT
https://github.com/fabianishere/udm-kernel
Being excited about OpenWRT is great but spreading bad information and for reasons I can't fathom hoping for the downfall of other players in the market, not so much.
> They hired the original author of pfsense to build them a firewall based on Debian from scratch when they realized vyatta wasn't going to meet their needs. The UDM kernel is very much not OpenWRT
You're (perhaps unintentionally) also spreading bad information here.
The original 'author' of pfSense was Scott Ullrich, not Chris Buechler. While they were partners in the project, Scott was technical, and Chris did a lot of work back then on documentation, by by his own admission back then, "I am not a developer", and this, even though he was CTO.
http://freesoftwaremagazine.com/articles/interview_with_jeff...
Ubiquiti originally hired two of the devs out of Vyatta to maintain their fork of the Vyatta codebase. These two were known on the Ubiquiti forum as 'stig' and 'An Chen'. Both left in the first half of 2016, and then (and only then) did Ubiquiti hire Chris Buechler, in an attempt to maintain and extend the Ubiquiti firmware. Chris has since left Ubiquiti and is now at Alta Labs.
> vendors like Ubiquiti who base their work on OpenWRT anyway
I thought Ubiquity’s firmwares were all based on Debian. Is this no longer the case?
I don't know about newer devices, but the older ones (the Edge* devices) had software based on Vyatta. Not sure if that was in turn based on Debian, though.
the routers were based on the Vyatta stack.
The WiFi APs were not
> I'd love to see OpenWRT take a (deserved) bite out of the "SMB firewall vendors" like Netgate
I'll just leave this here: https://www.netgate.com/blog/pfsense-software-embraces-chang...
OPNsense are unlikely to be able to make this transition, as they can't even reliably work on the FreeBSD kernel.
Oh, was that before or after you spent however long spreading FUD by stealing their domain? The one that OPNsense had to go to the WIPO to fix?
https://web.archive.org/web/20160314132836/http://www.opnsen...
nobody stole anything.
Why do you lie about things that are so easily provable?
https://www.wipo.int/amc/en/domains/decisions/text/2017/d201...
I'm not lying.
From the URL
---
The Complainant is the owner of the European Union trademark registration Nos. 012771457 for OPNSENSE (figurative mark), filed on April 8, 2014 and registered on August 20, 2014, for goods in class 9, and 016287716 for OPNSENSE (word mark), filed on January 26, 2017 and registered on May 9, 2017, for goods in class 9.
The Complainant also owns the domain name <opnsense.org>, registered on September 4, 2014, at which it promotes and enables users to download its open-source OPNSENSE firewall.
The disputed domain name <opnsense.com> was registered on April 8, 2014, and is not pointed to an active website.
---
I want you to look closely at the date April 8, 2014, and then I want you to look for anything that occurred before that date, vs. all that occurred after.
The Complainant further points out that the Respondent registered and used the disputed domain name in bad faith because the Respondent has no business activity at the disputed domain name and the only purpose of the registration and use of the disputed domain name is to bring discredit on the OPNSENSE products of the Complainant, by using degrading words and publishing a video, showing an actor interpreting Hitler, with the following phrase above it: “From deep within the OPNSENSE development bunker”.
You seem to not understand the difference between a fact "The disputed domain name <opnsense.com> was registered on April 8, 2014, and is not pointed to an active website." and an assertion or claim, "The Complainant further points out that the Respondent registered..."
How does bad faith exist when the domain "opnsense.com" was registered a full 8 months prior to the January 2, 2015 OPNsense announcement?
Point in fact, we published nothing. That website was not ours. We pointed the domain at it.
you also are ignoring this bit: ---
However, in contesting the Complainant’s supplemental submissions made by the Complainant to substantiate the asserted use of the trademark before the registration date of the disputed domain name, the Respondent introduces new elements which, in the Panel’s view, are relevant for the assessment of the Respondent’s position in this case and will thus be taken into consideration.
Indeed, in its Supplemental Filing, the Respondent states that a document submitted by the Complainant in its Supplemental Filing (as Annex 17) does not demonstrate the Complainant’s use of the trademark OPNSENSE but provides, instead, evidence of use of a trademark PFSENSE in which the Respondent has rights. The Respondent also informs the Panel that it is the manager of Electric Sheep Fencing LLC, a United States company which owns the United States trademark registration No. 3571276 for the trademark PFSENSE, registered on February 10, 2009 claiming first use as of February 19, 2005, for services in International class 42 relating to technical support services, maintenance and development of computer software; and of the International trademark registration No. 1176766 for the trademark PFSENSE, registered on August 28, 2013, for goods in class 9, including computer security software. The Respondent also states that its company Electric Sheep Fencing LLC has rights in a book referenced on the document submitted by the Complainant entitled “pfsense.org The Definitive Guide to the Open Source Firewall and Router Distribution”.
---
OPNsense were using the pfSense mark, and we were taking legal action to stop them.
I hope OpenWrt doesn't turn too commercial (like Netgate or opnsense) because that leads just to subscriptions, enshittification, feature gates, and drama. It is now in a good place as a solid platform to build upon, I hope it stays that way.
If they had their money from hardware only, would that be the perfect route?
Selling hardware, or consulting services.
OpenWrt is what I use. I picked my routers specifically to be well supported by OpenWrt, immediately wiped whatever the original firmware and installed OpenWrt and that was about ten years ago. Then when I replaced the hardware I also looked for a compatible model with OpenWrt and did the same.
I never had any issue with OpenWrt which I couldn't solve and it just works. Its uptime is pretty much the uptime since when the power goes out due to storms and such.
Same. Been running OpenWrt for years now. I select hardware that runs OpenWrt and never (well, only once, truely) have had to reboot a device due crashing. That old "reboot your router" is just not a thing (touch wood).
I'm sure it helps that all my infrastructure is on a UPS. I've found that even Raspberry Pis can be long-term reliable servers, running ubuntu server and on the UPS.
Another thing that seems to help. I separate function. One box functions only as the router. The wifi boxes only provide wifi endpoints - they do not do routing. And so on.
I have my fibre ont and the wifi router on a cheap battery backup. It has always continued to work even during extended power outages.
What hardware did you go with? I was thinking of getting the second most recent glinet to run openwrt, but haven't convinced myself it's worth it since my current tplink is still pretty new and is just be getting it to tinker (I don't currently even run any vlans or anything fancy)
I went with a TP-Link Archer C7 V2. It's quite dated by now, but it's been sitting quietly in the closet and working for all these years and I am still happy with it. My speeds are also not that fast, I only pay for 100Mbps so something faster might overwhelm this hardware. I also don't have anything fancy on it, no vlans just a few wifi networks on 2.4ghz and 5ghz, some wired devices, and two usb drivers which I access via ssh (these do require I install a few extra packages to allow mounting them).
I've had the same for a number of years - mine is even more vanilla than yours
rock solid
I run openwrt on an ancient Netgear WNDR3700 which is probably 15 years old by now. I can get around 900Mbps on my gigabit connection (wired). We only have two adults in our home using the Internet (for now until our two kids are older!) and it’s been totally fine for us. openwrt is a great way breath extra life into older routers. A lot of homes don’t really need anything fancy or recent.
Seconding all this. Ever since I had weird problems with the vendor firmware on a router, I just pick hardware I can put OpenWrt on right away. Works great.
OpenWRT is such a good os for a router - simple but configurable UI, works reliably, I wish router companies would just ship it by default
But then you get annoying firmware providers like Broadcom who refuse to write OSS drivers for linux and a lot of work is being spent on the reverse engineering
The amusing thing about that is that broadcom, not Cisco, was the culprit in the original WRT54G GPL violation. Cisco, of course, were legally liable and should have checked that the code they obtained was not encumbered - although the usual way to do that is to specify contractually that your vendor will do the checking. It was a huge issue for them that they had tripped a customer who provided a significant fraction of their revenue into legal difficulties. I suspect that to this day, a big reason that parts of broadcom are reluctant to open-source stuff is because certain executives are still angry about the experience.
MediaTek chips are well supported by OpenWrt. Broadcom is not good supported. Mainline Linux kernel supports recent MediaTek Wifi chips quite well [1]. MediaTek is also working on these upstream Linux drivers, but they still have a proprietary Linux driver in addition.
Also the rest of the recent MediaTek SoC is supported quite well by upstream Linux and OpenWrt.
You can run OpenWrt on recent MediaTek SoCs with all code running on the main CPU being open source, no closed source code needed inside the Linux kernel address space or in user space. The chips need firmware running directly on the IP cores. It needs a firmware running on the wifi core itself, there are probably one or more CPUs inside the wifi cores doing real time stuff. The Ethernet PHYs also need a firmware which is running on the PHY.
[1]: https://elixir.bootlin.com/linux/v6.17-rc5/source/drivers/ne...
Ok, but this should not be a major limiting factor.
From my experience, there is sufficient amount of routers based on well-supported chips which work okay with OpenWRT.
When I consider to buy a new router, I go to the OpenWRT device support page, filter for features I would like to get and choose one of the supported routers listed there.
I gave up on openwrt when I realized that a lot of the recent WiFi standards seem to be badly supported. I think 802.11ac was significantly faster with vendor firmware than openwrt, for example.
> 802.11ac was significantly faster with vendor firmware
Yes, I also remember similar issues with TP-Link Archer C7 running earlier versions of OpenWRT. It got better with later versions when they started supporting some kind of flow off-loading.
I am unsure if at the moment the recent OpenWRT WiFi performance of this router is on par with the vendor firmware's WiFi performance.
But yes, your point is valid. However, I do not consider this kind of issues to be deal-breaking. If I remember correctly, a fair amount of devices can achieve the same performance with OpenWRT as with vendor firmware. I would just check for these potential issues in advance and buy only the devices which are confirmed to be working as fast as with the vendor firmware.
The point here is that I rarely have any preferences as to which brand of a router to buy. Many of the marketed features they offer, like proprietary software or mobile apps to control the router, are mostly irrelevant for me. So I choose primarily based on the OpenWRT support level.
Edit: clarification
160mhz ax 6ghz working here with a mediatek chipset
Can we accept a pragmatic world where we have OSS + binary blobs?
That's better than a fully commercial world or a fully "pure" world with no functionality.
OpenWrt accepts binary only firmware running outside of the Linux kernel address space on the wifi chip itself. This matches what upstream Linux also accepts. This works well with most recent Wifi drivers. OpenWrt does not accapt binary only kernel modules or binary only userspace applications, they are very hard to maintain if you do not have the source code.
This works well with Mediatek and also Qualcomm and most other vendors.
GPU vendors have come to the realization that the in-kernel driver needs to be open-source, but the userspace portion can be closed-source. There's just really no good reason to accept a design where outdated closed-source drivers could keep you from running a current kernel. WiFi NIC vendors have for generations been moving more complexity into the closed-source firmware blob that runs on the NIC's own processor core(s), so there's no good reason for the kernel driver to remain closed-source.
Broadcom has been doing FullMAC designs for over a decade now, and that is exactly what you describe: moving all the functionality into firmware and having thin opensource kernel driver
I would love that, but it seems like they are not doing that either
> That's better than a fully commercial world or a fully "pure" world with no functionality.
I would prefer a fully open world with full functionality.
Give them an inch and they'll take a mile. Things would be even worse if people didn't care about blobs.
There are some low-cost routers on amazon that do.
also, I think the linksys wrt1900 supported openwrt when it came out. (not perfectly, but they tried)
I love OpenWrt.
But I wished there was something similar but for "big" (in a relative sense) devices. I feel lot of the constraints OpenWrt is based on are not really that applicable when you have hundreds of megabytes of flash and RAM, and that is starting to become a common thing for routers these days. Even their own OpenWrt One router has 256M flash and a full gigabyte of RAM. That is not all that resource constrained anymore. What I would love is to have something that would be closer to "normal" linux distro while getting the networking goodies and ease of configuration from OpenWrt.
I have the opposite complaint. I wish OpenWRT ran on low-resource routers like those really cheap TP-link ones. DD-WRT does support a few of it, and my personal opinion is that it is better optimised than OpenWRT. By the way, you should explore OpenBSD ( https://openbsdrouterguide.net/ ).
Thanks for the OpenBSD guide.
Do you know whether 10Gb NICs are supported in OpenBSD, and can the link be fully saturated?
I'd be interested in building a DIY router on OpenBSD, but I need support for 10Gb SFP+, with an upgrade path beyond that.
Yes. Support is there for some 10Gb Intel devices ( https://man.openbsd.org/ix.4 ) and Broadcom devices ( https://man.openbsd.org/bnxt.4 ) including SFP+.
Great, thanks!
Yeah, I know openbsd is a thing. I just like Linux too much.
Strongly agreed. I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together.
I'm super glad openwrt exists, and their uci config predates systemd's attempt to build a cohesive consistent whole system configuration pattern & is epic, but given the capabilities of these systems it feels so worthwhile to de-specialize the environment, to make it more boring.
What I really want is Kubernetes oriented tools that can manage hostapd & something like dawn or openert's usteer for band/ap steering. And some other ancillary wifi tools. Maybe maybe a setup for radius/enterprise, instead of just psk. You can do so much more with it, but at its core openwrt is 90% packaging for openwrt. It's not even particularly super well tuned hostapd: theres so much wireless config one can go try & enable that really is just additional 802.11 specs hostapd supports, they may improve your openwrt wifi experience.
> I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together.
I agree. I tried running OpenWrt as a wired router on an x86 mini PC, and found that it had some really powerful features and was certainly rock solid as a router. But there were some major annoyances, too. For example, their documentation includes a script for expanding the root filesystem [1] that left my system unable to boot. And while I didn't use it long enough to make it through an upgrade, their documentation on upgrades makes the process sound very brittle (it sounded like configs for installed packages don't carry over by default) and confusing.
I thought about trying to set up an Ubuntu (or other popular distro) box as a router, which I think would be much easier to maintain over time. But my concern is that I might overlook some important config that is set by default in OpenWrt, and leave my machine vulnerable to attack. Having a web UI that I can log into and view/make config changes is also kind of nice. Are there any good out-of-the-box solutions or guides for doing this? (I know that OPNSense/PFSense are really popular among homelab users, but unfortunately the Marvell NICs in my mini PC are not supported in FreeBSD).
[1] https://openwrt.org/docs/guide-user/installation/openwrt_x86...
> I tried running OpenWrt as a wired router on an x86 mini PC, and found that it had some really powerful features and was certainly rock solid as a router. But there were some major annoyances, too. For example, their documentation includes a script for expanding the root filesystem [1] that left my system unable to boot.
I have been doing this myself recently. The docs around this are pretty out of date. The docs as they’re written only work for the ext4 images if I remember correctly. I got it to work with the squashfs version, but it was really janky. The problem is the OS just writes the to the empty space at the end of the squash partition without changing the partition table. I could only successfully get it working if resized the partition on first boot before the writable overlay is created.
> And while I didn't use it long enough to make it through an upgrade, their documentation on upgrades makes the process sound very brittle (it sounded like configs for installed packages don't carry over by default) and confusing.
I feel similarly about the process. There is either a command or a place on disk where you can put files to protect them across upgrades, but I can’t remember just now. I think it works that way because it’s targeted at embedded devices where I would think you typically bake everything you need into the root file system at compile time. I’m not an embedded engineer so maybe there are better ways of doing it.
> The docs as they’re written only work for the ext4 images if I remember correctly
I was using an ext4 image and still ran into problems. And in addition to the scripts on the page that I linked above, I also tried this other variation from their docs [1]. They all ended up rendering the sytem unbootable.
Eventually I think I ended up using an Ubuntu Live ISO to boot the system and made the change there. Definitely a bit of a pain, and according to the docs it sounds like something I would need to do again after an upgrade.
I also tried following their steps for "building your own image with larger partition size" [2], but couldn't get that to work either.
I had fun playing around with OpenWrt. But in the end was forced to admit that I didn't really need any features in OpenWrt, and whatever benefits I was getting from it were not worth the effort. Also, even a minute of downtime for a reboot was pretty annoying to my family when they were trying to stream a movie, etc.
[1] https://openwrt.org/docs/guide-user/advanced/expand_root
[2] https://openwrt.org/docs/guide-user/installation/openwrt_x86...
I know the answer to this. The ext4 filesystem that openwrt creates by default is just janky. To get well-working filesystem that you can resize etc, you need to build custom image with a small patch to fix up the ext4 fs creation.
https://github.com/openwrt/openwrt/issues/7729#issuecomment-...
https://github.com/openwrt/openwrt/compare/main...zokier:ope...
This is exactly the sort of thing why I'd want a openwrt for "big" devices. But I should get that patch also merged upstream...
> I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together.
Yup, that's the answer. Debian is rock solid, and a script with a bunch of iptables and iproute2 commands is so much simpler than the mess that is OpenWRT's network setup. I only use it for dumb APs, and even then it's questionable -- the UI is nice, but configuring it is unnecessarily complex IMHO.
I run OpenWRT on a 'big' device, this being a container on a Proxmox-managed DL380 G7. It works fine in this context, performance is good enough to be able to easily saturate the gigabit fibre link without breaking into a sweat.
Installing OpenWRT on such a device comes down to downloading openwrt-${version}-x86-64-rootfs.tar.gz and unpacking it in the target location. Boot the container or VM (or old PC or whatever) and follow the normal OpenWRT configuration procedure. Updating such an installation comes down to making a configuration backup in OpenWRT, unpacking the new distribution and restoring the configuration backup to the new install. Given the low resource requirements for such an installation it makes sense to first clone the working container or VM and performing the upgrade on one of the instances so you always have a working instance at hand.
Sure, openwrt works. I too have run it on x86 vm at a time. That being said, there is lot that could be improved. My biggest gripe is the weird filesystem layout with overlays and stuff in /tmp and whatnot. I can see it being needed on tiny devices, but on bigger ones can I just have regular ext4/xfs gpt partitions please? Another thing is just replacing the tiny versions of software with regular ones, like busybox->gnu or dropbear->openssh etc. Systemd could be at least considered as init.
All of this kind of things make sense when you consider openwrts origins. But on "big" system I'd just much rather have it be closer to "normal" Linux.
OpenWRT on x86_64 does not use overlay mounts, here's an overview of a current instance running in a Proxmox-managed container:
No overlays, just a normal ext4 filesystem. Data in /etc is stored in /etc, data in /var is stored in /var, etc. OpenWRT running from a filesystem image is 'just another Linux distribution which happens to run the same software as that re-flashed router'.Something with a more normal way of updating the packages and OS would be nice. I thought I'd heard someone was working on an Alpine-based thing a few years ago, but haven't heard anything since.
Agreed. When I last tried to update packages there was a scary disclaimer about it being likely to break the system, and that flashing a new firmware is preferred.
I nope'd out of that, and don't wish to go through the hassle of flashing again, so my AP is running a year+ old version. It works fine, and I'm not too concerned about it, but I would still like to be able to easily upgrade the system without worrying about breaking it.
They did replace opkg with apk recently https://forum.openwrt.org/t/major-change-notice-new-package-...
zyxel gs1900-48 - 48-port gigabit switch supported by openwrt (also versions with fewer ports)
I do find it sad/ironic/interesting to note that the router that started it all is no longer supported.
Not to bell the cat, but some sort of symbolic build for the WRT54G(L) should still be possible… right?
You can build the image yourself, but have to switch off some packages or features - otherwise the image (linux-kernel + tools) is just too large or consumes too much memory. The original router has 8 megabytes RAM-memory and 2 Megabytes flash ("storage"). You can boot a recent kernel 6.16.5, but with 8mb there is not much left to work with 8-)
A starter is here: https://intercity-vpn.de/files/openwrt/wrt54gtest/minimal/
I remember swapping the TSOP packages on a WRT54 to double the RAM.
Here's a blog post about this, not sure if it was the same one I followed:
https://blog.thelifeofkenneth.com/2010/09/upgrading-ram-in-w...
My uneducated guess is that that people that want this kind of symbolism aren't willing to actually become a maintainer and invest time in niche code for a declining user base?
Hence belling the cat
Been a fan for a long time and use it on my Archer C7, but I had to disable hardware switching in order to use SQM, and now the switching performance is <200mbps. Having recently upgraded to home fiber, I'm probably going to get a native Unifi router.
Maybe have a look at Intel n100 boxes (Aliexpress -> Topton). They often have 4-5x 2.5GE Ports with high quality Intel cards. They are very cheap (100-200€) and suck not too much current (5-15W).
You can run OpenWRT on them using the x86 build.
We usually have 5-10x of them around for emergency network tasks if everything burns down in a building.
Honestly it is tempting. I do have an old Haswell-era industrial motherboard that would manage the task just fine, and I've definitely considered this path.
That said, I'd probably spend about as much on a power supply, case, and NIC for that machine as I would on just buying a Unifi gateway, and theirs comes with an integrated UI for the APs. I'm past the stage of life where I find joy in tinkering with the infrastructure I need to do my job (WFH) so I'll probably still just go off the shelf.
I bought a Fujitsu Futron S920 second hand for like 30 euros. Put a dual NIC PCI in there and now have a low watt router running very fast. Can easily run 1Gbit up and down
I used DD-WRT forever, but holy crap was it buggy. Once I tried OpenWRT, there was no going back. Shit just works, and works well.
Tomato on the WRT-54G was the all time best in my opinion.
Agreed... probably the best experience for a SOHO router+wifi. I currently use OpnSense on an N305 mini pc for my router and the separate wifi AP has it's own management interface. Works for my needs.
I tried setting it up as a test router and ran smack into their ancient kernel and iptables not supporting statistics drop mode.
Interesting, on my latest router (WRT3200ACM) I've had the opposite experience - I had to switch from OpenWRT to DD-WRT since the former was too buggy to use (couldn't get the WiFi to work reliably).
I'm a huge fan of OpenWrt. When I got 10 Gbit internet at home I had to replace my old Ubiquiti USG3 on the cheap so I built a router out of a $80 Lenovo ThinkCentre Tiny.
I tried OPNsense and pfSense on advice but they could never crack around 5 Gbps throughput even with a bunch of tweaking, but OpenWrt gave me the full 10 gbps out of the box with no hassles.
I also replaced the Ubiquiti firmware on an EdgeRouter with OpenWrt and it boosted the throughput from around 1.3 Gbps to 1.7 Gbps.
The OpenWrt UI for configuring the firewall is probably one of my favorite firewall UIs of all time. Before OpenWrt I could never wrap my head around those "local" etc ruleset names in more traditional routers, I had to look them up again every time I edited the config. Just being able to say "I have these networks, let this one do this to that one" is very easy to understand.
Openwrt is amazing. I had a wrt54gs, and then latter got a Netgear wgt634u with an astounding USB2 port! Served as a great office shoutcast playing server for the office, a decade before Sonos (for example) existed.
The hardware situation has felt very tenuous for years now. Qualcomm support has felt so so bodged in. It feels perpetually like "this new chipset will finally get us past all the horrible half working hacks of the last barely working chipset" on and on, usually sort of working but only barely. I did finally get my IPQ8074A based router going (rax120) but it took so long, and needs an older wifi firmware (their 2.7) to work. But it feels like maybe slowly it could be getting better, maybe perhaps support will be more mainline less hacked next time.
One very recent example that's lovely to see is Qualcomm starting to mainline their Packet Processing Engine, for the IPQ9574 at least. Link and example hardware below. There have been various forks of openwrt that bundle in cobbled together versions of the software to use hardware offload/accelerators, lots of these. But it's been far from problemfree and are hard to maintain, especially trying to maintain kernel compatibility. https://www.phoronix.com/news/Qualcomm-PPE-Driver-Linux-6.18 https://www.524wifi.com/index.php/embedded-cpu-boards/dual-r... https://forum.openwrt.org/t/ipq806x-nss-build-netgear-r7800-...
It's good to see MediaTek present in openwrt space. One of the only other highly present chipsets available. The price is often quite good for pretty new wifi standard supporting routers. The anec-data I've heard is that driver maturity is not great, but at least there's motion & movement within the kernel, which springs hope eternal.
All my accesspoints and routers run OpenWRT. Love it.
At some point I even ported OpenWRT to my unsupported tplink device. IIRC I hacked together a devicetree and made some small modifications to the tplink loader code.
Funnily enough when I made a PR on github it was basically ignored after I implemented the feedback. I proceed to instead send the patch to the mailinglist and it was merged the same day without comment. That must be some kind of skill filter...
A lot of companies were built on this.
And all it took was forcing one company to divulge its proprietary closed-source codebase because they screwed up and incorporated copyleft code deep into their core.
Imagine how much progress could be made if a few other companies were forced to crack open their proprietary closed-source codebases...
I think many companies saw that and poopood GPL firmware.
They were poopooing that before the OpenWRT case. I don't think there's evidence to suggest that the OpenWRT case made them less willing to use GPL (especially since use of GPL would always have implied they should open-source the firmware derived from it).
Until then, some companies didn't seem to take it too seriously.
The first DJI drones (original Phantom at least) used OpenWRT on their "Range Extender" boxes.
I assume that about 20% to 50% of the home routers, Access points and Wifi mesh devices sold world wide are based on OpenWrt. Often some old versions of OpenWrt with many vendor modifications, the UI is always custom.
I know that the main vendor SDKs from Qualcomm, Mediatek, and Maxlinear are based on OpenWrt. I think only Broadcom uses an own Linux distribution which is not based on OpenWrt in their main SDK. Linux has a market share of about 99% in this market, I haven't seen VxWorks in any recent home router or access point.
It's fun to see that "Amazon choice" portable routers are based on OpenWRT, and run OpenVPN and Wireguard out of the box.
Ubiquiti uses a fork of OpenWRT. Starlink's routers run it as well. I'm sure a ton of other vendors are using it
The WiFi silicon vendors seem to base their SDK/reference software on OpenWRT (albeit often badly-outdated versions), so almost everyone selling a WiFi box ends up using some variant or fork of OpenWRT. It's been a long time since the days of Linksys trying to cut DRAM costs by using something other than Linux. There are still exceptions like MikroTik where the OS and configuration tools are a main selling point (still Linux-based, but not OpenWRT).
Where does Ubiquiti use OpenWRT? I saw that claim elsewhere in this thread but I'm pretty sure their original devices were based on Vyatta, and their newer stuff is a custom Linux OS of their own that is loosely Debian-flavored. Poking around in the terminal all the Ubiquiti devices I have used are very clearly unrelated to OpenWRT.
Ubiquiti started in outdoor wireless, point to point and point to multipoint. All their outdoor radios, cameras, and unifi APs are all running a version of openwrt.
EdgeRouters started on vayatta and then that went away (AT&T acquired Vayatta) and then that forked into VyOS.
Some of the Ubiquiti EdgeSwitches are running some other OS, but I can't remember what it was.
Source - Spent 14 years helping alpha / beta test, debug code and wireless problems, etc.
I just started using OpenWrt on Incus via LXC and it works really well. The most difficult part was just learning the config file. It looks like upgrading OpenWrt (esp. on LXC) is the tricky part though so not looking forward to that. I considered moving it to a VM so upgrading it is easier but it runs so smooth on Incus.
Big fan of it. Allows you to create experimental software for OpenWrt, like I did: https://github.com/ro31337/big-internet-button?tab=readme-ov...
> In our hyper-connected world, we've become slaves to the endless scroll. Social media, news, videos - the algorithm-driven content feeds are designed to capture and hold our attention indefinitely. We tell ourselves "just 5 more minutes" but hours disappear. Our brains are being rewired for constant stimulation, making us less capable of deep thought, genuine connection, and meaningful work.
> The Big Internet Button breaks this cycle by introducing friction back into your internet consumption.
Installed it on a TP-Link to replace my ISP router a couple days ago. I'm super impressed with how it needed almost no config (except to manually activate the Wifi and to set a password).
I'd recommend downloading the Material theme for anyone complaining about the barebones look.
about your TPLINK,
there is often a "recovery feature", an alternate boot partition [ i posted about this some time ago.]
if you configure your router so that it "bricks" you can boot in the last working configuration before your changes; rescue; and save to overwrite the brick partition. presumably you can do this forever, as long as you dont brick both partitions.
3 interrupted boot cycles would cause a switch to last successful boot partition.
in my case i had problems because of the curious way we have power failures here. the power would brown out and each phase of generation would send a peak and trough, equivalent to turning power on then off before boot completion 3 times.
if you want to be snazzy, you can play on this and work two partitions at once each configured for different purpose, and accessed by briskly cycling power thrice.
Unfortunately, they use Busybox under the hood with its plethora of unfixed bugs and security issues and a bug tracker that is almost always down. I cannot trust this project anymore and stopped using systems based on it.
Is the router only available on AliExpress?
No EU vendor?
Apparently the firmware is shipped without the GUI (LUCI). And only 900 units have been sold in 10 months. Something fishy is going on.
https://www.reddit.com/r/openwrt/comments/1h0pkbw/openwrt_on...
Sorry, we know that the EU and NA distribution channels are not so good. The OpenWrt project depends on Banana Pi here. There are some resellers on Amazon.
About 10k OpenWrt one units were sold as of today. The first 900 were sold in about 3 days.
Thanks a lot.
Can you please tell me if the router Luci-html-gui is available by default? I'd like to just point my browser to an 192... and configure it, thanks.
I switched from an ARM version of Openwrt on my Linkstar H68K to a Beelink EQI12 powered Proxmox instance running Openwrt on a VM. Used ChatGPT to debug it and set up multi-wan failover for it. Works excellently.
Fond memories of PirateBox. Actually, fondness is directly proportional to which router I was hacking - Thumbs down for TP-Link - Many thumbs up for the GLI AR150, the sweetest of spots (hugging face emoji)
OpenWRT is really cool. I recently figured out it has an "attended upgrade" feature which makes updating it very easy.
Can anyone recommend a guide on the firewall?
https://youtube.com/watch?v=DWmLVDAV5kY His content helped me when I first made the plunge into OpenWRT earlier this year and realized I knew next to nothing about networking. He also has a video on policy-based routing that is cited in the PBR documentation as well.
Thanks, I'm looking forward to watching. I was totally frustrated by implementing DNS+IP parental controls on OpenWRT and am interested if there is better tooling now. My recollection is that there are multiple wrappers of configuration behind the webUI and trying to run AdGuard home on the same hardware lead to performance problems.
Install Adguard home on it
all my routers run TOMATO
Apples and oranges. It is a nice tool for closed-source Broadcom devices that OpenWRT will never support. Otherwise it has nowhere near the complexity and features.
Curious what are the main benefits ? (I've only ever used DD-WRT and OpenWrt)
I use Tomato too, but I wouldn't say it offers many benefits over OpenWrt. The main thing is that routers based on Broadcom chipsets often only work with very old Linux kernels (such as 2.6.xx kernels), as the drivers are closed source. For these routers, the primary third-party router OS choice is to use Tomato.
All of mine are Alpine Linux. No UI but small, simple.
Have you written anything about setting this up somewhere?
I have not but if there was enough interest I could make a rough go at it. It's not a very complicated setup.
It's basically Alpine Linux with some custom sysctl and interface settings, sch_cake with custom settings, cdg, netfilter, Unbound DNS with some local zones for limited spam filtering and a cron based refresh of common domain names, blackhole routes for known clowns and DoH/DoT IP addresses, chronyd for NTP, dnsmasq for static and dynamic DHCP, gratuitous arp cron job to lower latency and steal back my IP if someone tries to take it and restore quickly from ISP router failover all running on a Protectli VPN class small business firewall with cron snapshots/backups from another node.
My first pass would probably just be a static page with linked text files of the configurations and a brief synopsis of what each file or in some cases individual settings are performing.
Another option (depending on your requirements) is to use normal "workstation" Linux distro like Debian on an regular x86 PC equipped with two NICs. I added an SFP28 dual NIC to an old gaming PC and now use it as a router/home server and can saturate the link (25Gbps). I get north of 4Gbps through Wireguard too. Routing and the firewall are built into the kernel so you don't really need a specific distro. I just added a DNS server (Unbound in recursive mode) and a DHCP server. For WiFi I use hostapd, but an external AP would be a better solution for most people.
Did you manage to get IPv6 prefix delegation working with dynamic prefixes? Best solution I found involves scripting to re-build config files and restart a daemon, where OpenWRT just does it out of the box.
Openwrt still has some strange footguns (imo) and the upgrade process is painful. I personally just prefer running general-purpose distros for my routing and firewalling needs. I realize the learning curve for this for someone who just wants a home router is unrealistic though :)
But out of all the router/firewall distros, OpenWRT it is by far the best.
I just recently started using OpenWRT and only have done one upgrade, but I‘ve found it really straightforward using Attended Sysupgrade https://openwrt.org/docs/guide-user/installation/attended.sy...
An easy-to-setup OpenWrt-based plugin to sell internet for satoshis: https://tollgate.me/
I've been following OpenWRT for years, and finally made the jump.
This was after using DD-WRT and various flavors of Tomato (especially Shibby and FreshTomato) for two decades on probably ~100 routers in various locations. Some of those locations were business production environments, with the routers providing VPN connecting sites across the continent as a backbone for VOIP telephony, remote user access, etc. (before the likes of Tailscale).
It's an important project and I have a great appreciation for all the work the developers have put into it. But I have to admit, I was underwhelmed. LuCI wasn't as robust as I expected (the "queue all your changes as a batch of commands" approach is a great idea, but its implementation has some rough edges that simply don't work - IIRC, where the UI isn't aware of conflicting config changes you've already queued). And I found in practice getting it to do things that are easy and reliable on FreshTomato, was frustratingly unintuitive, taking more steps than I'd expect, some seeming brittle/error-prone. I'm not averse to scripting, having written short novels of commands for previous OS's, and even custom-compiled binaries (e.g. to install iPerf, before it was bundled with the OS) and a whole custom FreshTomato build that added some admin pages for long-term bandwidth/latency graphing. So I'm open to learning new things, I just felt like I was doing more fighting with the OS than should be necessary.
One small example was configuring a Let's Encrypt certificate. This feels like it should be a near one-click operation. In my case it took a bit of testing and tweaking to get right - I wound up contributing my short solution back to a SuperUser answer: https://superuser.com/a/1904844/75522
Properly disabling IPv6 took more than just a checkbox. I had "No default route present, overriding ra_lifetime to 0!" messages logged, until I added "net.ipv6.conf.all.disable_ipv6=1" to /etc/sysctl.conf.
Maybe I'm just getting snagged by doing things in 'weird' ways. e.g. My inaugural router on it is a MikroTik wAP ac. Turns out you don't get a WAN interface out of the box when flashed on that device, and I had to manually create it. There wasn't really any documentation warning about that, and it took a while before I realized life would go better if I used a lowercase rather than uppercase convention (for better integration with built-in stuff that relies on its existence).
A lingering issue I haven't figured out yet is how to make a reliable "toggle switch" to turn on and off access to the internet for one device on my network (by IP or MAC address). I set up a firewall rule, but wind up having to manually run "/etc/init.d/firewall reload" and "conntrack -D ..." each time to kill any established connections. On FreshTomato it was just a checkbox you turn on/off. If anyone has advice on this I'd be grateful.
One last tip for anyone else using it on a router plugged into a Starlink endpoint that's in bypass mode (i.e. you want to be able to port forward). You'll get messages in syslog every 5 minutes due to short-lived Starlink IP:
You can suppress them by appending "-l 1" (without quotes) to the "procd_set_param command /sbin/netifd" line in /etc/init.d/network, then reboot the router (in my case running "/etc/init.d/network reload" didn't quite do it). On the plus side, the Dynamic DNS package is working well in my setup. (And yes, I understand the implications of using Let's Encrypt on a DDNS IP).I'm not here to whine, just to suggest that anyone else thinking of making the switch manage your expectations and leave yourself some time to perfect things and get used to the new platform.
Its simple usability polish. Tomato had it, OpenWRT doesn't. But where it shines is in the reliability. I've been using it for over 10 years, and prior to that DD-WRT on a 54L.
That's the biggest challenge with many of these open source tools. They're built to solve a single or handful of problems, but don't always fit for a larger audience. I'm not complaining either, and I'd be happy to provide the polish, but right now, my time is spent with my clients ($$).
If you invest the time in getting it configured the way you want, you'll be happy too, for 10 years. ;)
Food for thought of why I'm exploring other options currently: 1. Need a WAN failover that can check with a custom heartbeat 2. Need an easy-to-configure VPN that doesn't use an open port, but will register against my own cloud server 3. Need an easy way to monitor traffic of particular devices - DNS queries and active connections 4. Need a big button to turn off the internet for all, and individual buttons to turn it of for specific devices 5. Need an easy way to manage VLANs and traffic routing rules (for local-only designated devices)
What’s new with OpenWrt?
Relatively recently (early 2025) they've completed a serious rework, and released a new version, with WiFi 7 support.
Otherwise it Just Works™, as it should.
Apparently they released a router last year.
This is actually probably the best thing OpenWRT have done in quite a while. I got two (one for a backup) and I've been super happy. I've happily used TP-Link, GL.iNet, and Raspberry Pi 4 devices, with OpenWRT in the past, but nothing beats the "it just works" aspect of a first party device designed for this, fully open, and a reasonable price.
Most off-the-shelf devices have too slow of CPU for a low latency/buffer router. The Raspberry Pi 4 is easily fast enough but needs to use USB3 network adapters which require packages not in the default rpi4 OpenWRT image. Not insurmountable, but a consistent pain every upgrade.
I ended up building my own image of OpenWRT to make the package hell better on upgrade, and as a bonus, I was able to build in my configs too. Recovering from a failed Pi was as simple as flashing the most-recently-built image. Upgrading just required rebuilding the image (and resolving whatever went wrong, of course, though it was usually pretty light). As a bonus, it's easy to swap SD cards on the Pi so I can have the last "known good" config available while taking the update.
Now I run OpenWRT on one of those x86 mini PC boxes with 4x 2.5GBe Intel NICs because my wirespeed is 2 Gbps symmetric, so I needed just a bit more oomph than the Pi could provide. The hardware is somehow even _less_ reliable than a Pi 4 - I'm already on my third machine in 3 years. I would love to find something more reliable.
OpenWRT has also made it incredibly easy to package in any arbitrary pkg into image downloads from their website. You don't need your own build infrastructure now.
I'm curious what your experience would be like with a Pi5/CM5 solution using PCIe for your ethernet. It is pretty easy to have spare boards and SD cards around for Pi setups. I've had good reliability with Pi setups using good passive cooling (no fan to die).
There's soon going to be a new one manufactured by GL.iNet for OpenWrt https://news.ycombinator.com/item?id=43512495
Not a huge fan of the design decisions on that one. $250 target makes it a hard sell to anyone but network nerds. At $100, I would have no issues making that the default recommendation for anyone, regardless of technical knowledge. Being a premium point requires justifications beyond open source warm and fuzzies.
Network enthusiasts are likely to already have separate switches and WiFi points. Let the router just route.
I don't see the issue. Regular folks can go with the OpenWRT One, the Two is for the enthusiasts.
They’ve added support for a lot of switches. https://svanheule.net/switches/models
Is it recommended performance and feature-wise to use OpenWRT on Ubiquiti's switches?
The CPU in such switches is far too slow to do any data plane operations, so performance is entirely due to the hardware switching. Replacing Ubiquiti's OS with OpenWRT just gets you a different management interface for configuring the hardware features that actually handle traffic. (Unless for some reason you desperately want to have a VPN endpoint that would be limited to a few Mb/s at best.)
Ubiquiti make great hardware, however a lot of people hate the software as it is buggy and inconsistent. This at least gives those people options to run something a bit more opoen and manageable under the hood.
New Package Manager(apk) WIP
OpenWrt Upgrade Tool. retaining all of your currently installed packages and configuration
They are updating kernels on yearly basis. 6.12 WIP
web interface for mobile. I think there is an unoffical luci package and a native mobile app.
Notification system. WIP
See also https://forum.openwrt.org/t/community-question-what-do-you-w...
RIP Cucumber Tony.
Couldn’t developers of OpenWRT come up with a better UI?
It’s not user friendly at all.
Please for the love of all that is good do not change/remove the Bootstrap 2 LuCI theme. It's such a great and pragmatic design.
I come from OPNSense (different use case). Nice well-designed robust UI, even if people say opnsense is flexible and thus complex.
Given that, I feel GL-inet users rarely visit the advanced section (Luci).
> It’s not user friendly at all.
Evaluating a return to it from some time in pfSense--it is wonderfully simple. At the same time, its the wrong abstraction for most people who want to manage childrens' devices and iots because it is no abstraction, the operator must know many implementation details that aren't worth knowing outside the system.
There are a couple of Luci themes you can install
https://openwrt.org/docs/guide-user/luci/luci.themes
Could you provide any specifics? Are you wanting a dumbed-down UI that hides most of the functionality, or are you wanting the existing functionality to be exposed to the user differently?
See
https://www.wundertech.net/opnsense-vs-openwrt/
To be clear, OpenWRT is a great OS. The UI is a bit old fashioned, existing functionality could be exposed more cleanly, and the terminology could be more intuitive.
This is basically what gl-inet did! You can compare how they expose functionality. Of course, it’s limited, but eventually the remaining features in LUCI could be incorporated in the same UI.
IMO it's valid criticism and at the same time IMO GUIs are unnecessary frills.
If you've tried Cisco routers - you can export ALL configurations by running command `show running-configuration`, or `display current-configuration` on Huawei routers, or `show configuration commands`on Vyatta/VyOS/EdgeOS, which can then be restored onto a brand new router by just right click pasting that log into the ssh session.
That's VASTLY superior to ANY GUI. IMO. YMMV. IANAL. Views are my own. But it is.
this is why TNSR was API first with a CLI. https://docs.netgate.com/tnsr/en/latest/basics/config-databa...
We have a lot of requests for a GUI, so one is in development.
All UCI configuration on OpenWRT is stored in /etc/config/, and exporting/importing it is as simple as one scp command. The GUI is great for discoverability, on the other hand.
It is convenient then that Luci (openwrts web ui) is based on top of uci which is fully exposed through a CLI and/or config files.
What is your point of reference? What would you compare it to?
I find it easy to understand and to use. From my outside perspective it seems like basically just Linux with a nice web UI.
Get the Material theme.