OpenWrt: A Linux OS targeting embedded devices
openwrt.org
openwrt.org
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
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.
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.
Openwrt supports the zyxel gs1900 switch, which goes up to 48 ports.
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'
So I really can’t say I recommend their hardware…
- 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...
https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
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
Was also surprised, then not surprised, to learn it's used as the front end on many of the new generation of 3D printers.
https://openwrt.org/toh/western_digital/mybooklive
They're slow, but great for stuff that doesn't need to be fast.
OpenWRT Two is scheduled for late 2025 from GL.iNet and should go for ~$250.
> 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.
https://github.com/rubenbe/opensoho
It is still a work in progress, but it is easy to deploy (one golang binary based on pocketbase)
Based on your experience, as OpenSOHO seems to use OpenWISP, what do you wish you knew about OpenWISP before you started this?
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.
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 ;)
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.
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)
I could wire up all of that manually. But I'm excited for the chance to learn something new
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)
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.
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.
I thought Ubiquity’s firmwares were all based on Debian. Is this no longer the case?
The WiFi APs were not
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.
https://web.archive.org/web/20160314132836/http://www.opnsen...
https://www.wipo.int/amc/en/domains/decisions/text/2017/d201...
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.
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 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.
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.
rock solid
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...
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.
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
That's better than a fully commercial world or a fully "pure" world with no functionality.
This works well with Mediatek and also Qualcomm and most other vendors.
I would prefer a fully open world with full functionality.
also, I think the linksys wrt1900 supported openwrt when it came out. (not perfectly, but they tried)
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.
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.
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 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 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.
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...
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...
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.
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.
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.
/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)
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.
Not to bell the cat, but some sort of symbolic build for the WRT54G(L) should still be possible… right?
A starter is here: https://intercity-vpn.de/files/openwrt/wrt54gtest/minimal/
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...
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.
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 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.
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.
Imagine how much progress could be made if a few other companies were forced to crack open their proprietary closed-source codebases...
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.
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.
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...
> 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.
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.
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...
About 10k OpenWrt one units were sold as of today. The first 900 were sold in about 3 days.
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.
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.
But out of all the router/firewall distros, OpenWRT it is by far the best.
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
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.
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)
Otherwise it Just Works™, as it should.
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.
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.
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).
Network enthusiasts are likely to already have separate switches and WiFi points. Let the router just route.
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...
It’s not user friendly at all.
Given that, I feel GL-inet users rarely visit the advanced section (Luci).
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.
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.
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.
We have a lot of requests for a GUI, so one is in development.
I find it easy to understand and to use. From my outside perspective it seems like basically just Linux with a nice web UI.