It is interesting to note that OpenWrt originated following a GPL enforcement action by Software Freedom Conservancy that saw the release of Linux kernel, busybox and other code. Also just after OpenWrt joined Conservancy recently, Conservancy announced their plan to enforce the GPL again, in another area of the consumer electronics space, with the intent to again use the result to create an open source solution for the devices being enforced against.
If you are the person who uses rooted mobile then this is definitely your material. I had a router that stalled if i use torrent and had to reboot to get it to working. Then i explored and found this amazing project.
OpenWRT is one of my favorite projects, I won't buy routers unless I can put OpenWRT on them. Also interesting is that it's become a general embedded Linux platform, too.
I am the same way. My routers/APs must support OpenWRT.
I think it is hard for people to appreciate how great it is to have a legit Linux distribution for your router. The alternatives (e.g. DD-WRT, Tomato, etc) are "just firmware".
> older equipment is often saved from planned obsolescence by alternative solutions. [..] We seek to ensure they can do this for other types of electronic products. However, without the complete, corresponding source code (CCS), including the scripts to control its compilation and installation, the fundamental purpose of copyleft is frustrated. Consumers, hobbyists, non-profit e-recyclers and the general public are left without the necessary tools they need and deserve, and which the license promises them.
so true. OpenWrt is alot of networking fun and allows me to run a more current kernel on a measly (and perfectly fine for my uplink) MIPS device from 2012 than the one of the 450€ smartphone. But some chips will never see a reimplementation if datasheets and specs are missing. I pray for mainline kernel support, but while some SoC get integrated, GPU and peripherals are another story. As a consumer, this is sick. How is anybody even allowed to sell this way.
The 17th october marks the "international repair day" of the repair community. But even with "the right to repair" - without controlling the software, you still might hold a brick in your hands.
Are there any routers with open source WiFi drivers that also keep their firmware up to date? WRT1900AC/WRT3200ACM situation because worse after NXP bought Marvell:
Why not just have a separate router and AP(s) that are all running OpenWRT? That's what I've done so I can upgrade my wireless without having to redo my network.
It is hard to replicate OpenWRT's GUI, terminal tools, and online resources with a bespoke for solution.
I personally haven't really used OpenWRT, so I'm not familiar with its GUI.
However, the PFSense GUI is pretty straightforward. Shorewall has no GUI and is all text based configuration, but personally I prefer that.
If OpenWRT supports wireless APs then sure that seems like great software to use. In my experience most Wireless APs have proprietary firmware and are not supported by most open source solutions. I block all egress on them.
Having a router/AP combo that runs OpenWRT is great, the solution I proposed just expands your hardware options for non OpenWRT compatible hardware.
I have been looking into this exact route. You sound like you have experience with this, so maybe you could give some recommendations:
a. How critical is it to use such dedicated hardware - could I use a RPI4 with an added usb3-gigabit eth adapter? (I don't need a wired lan, only a wifi one).
How much worse would that be compared to the hw you link?
b. Which AP would you recommend? I think the Ubiquity AP lite one is reasonably low cost - are there better options with similar cost?
I'm not expert but I'm happy to share my learnings.
a. Running everything over a USB3 hub would probably work, you would just be looking at decreased total throughput ( depending on the hub ). Depending on what you're doing ( vlans ) the pi processor might become a bottleneck.
b. Most Wireless APs are mediocre and run some proprietary firmware ( including Ubiquity ). Personally I just got the cheapest one that supported my bandwidth requirements, and blocked if from being able to communicate with the internet ( the one I got would reach out to some AWS compute instance for who knows what ). Other than that they all kind of work the same. I know people who like the Ubiquity one because of it's nice UI.
Yeah, you could, but Intel doesn't sell good MIMO cards for parallel access. I think at most they sell 2x2 ones? What is out there that has more and also has an open source driver with up to date firmware (if it's open - even better).
I've got ath10k and it's been pain for quite a long time, until I saw a suggestion on the Openwrt forum to try different combinations of kernel module and firmware, and kmod-ath10k-ct + latest ath10k-firmware [0] works fine since a year or so
The main issue was instabilty manifested in random packets loss and randomly crashing/not working (either 2.4 or 5GHz) APs
This is both correct and incorrect at same time.
ath10k covers a whole bunch of different chips. Newer stuff can be less stable/tested.
The -ct (Candletech) firmwares/drivers in many cases can be better, but sometimes they have regressions of their own.
Edit: also as you mentioned kmod-ath10k-ct, it looks like you run it on some off the shelf wifi. Those tends to be trickier and less stable. AP that i assembled with compex cards were rock solid for years (ath9k + ath10k)
depends on what you buy, ath9k or ath10k. works well. those chips are mainly used for AP, so drivers are suitable. There is also more "AP Optimized" firmwares.
used my own builds for many years but lately bought two netgears R7800 and flashed them with openwrt.
the reason is that it's hard to find boards that can fit 2 oversized mini-pcie cards (one for 2.4 and one for 5) and cost of the build becomes too high. though on this compex shop they do have some "dedicated" boards, but they are somewhat underpowered if you want to throw a bunch of things on them.
One big upside, it's very educational.
After I read that, I removed openwrt on an old mips wifi router I had been using for years and moved to a fanless x86_64 running a minimal normal distro, set up via nmcli.
> In order to exploit this vulnerability, a malicious actor needs to pose as MITM, serving a valid and signed package index - e.g. one obtained from downloads.openwrt.org - and one or more forged .ipk packages having the same size as specified in the repository index while an `opkg install` command is invoked on the victim system.
You switched systems for this? Sure, they could have done defense in depth (not unlike Debian, which also relies on signatures), but this was a bug in signature verification and... Honestly, how would someone even exploit this?
As I mentioned there is no dnssec or tls on their archive site, with the package signature not being checked interested parties need to run a mirror of the real site with selected packages tampered and poison the dns of their target.
And then they can wait for the targets to update. They can do that pretty cheaply and over the 3 years and two major releases the broken opkg shipped on, just collect victims. That's what a lot of people in a lot of different countries are paid to do for a living.
Maybe so, but I have faith RH will generally check it better since they are better funded, and problems more likely to be found quicker since more users.
Could you expand on why you consider this vulnerability to be such a major indicator of incompetence, versus all the other major vulnerabilities that regularly pop up in software? They all seem obvious in hindsight, but as they say, hindsight is 20/20.
If archive.openwrt.org is like any other *nix package management software, it's likely that it doesn't need dnssec or tls. The signature of the packages get verified based on predefined public keys. If the packages aren't signed by openwrt's private keys, the software will reject it.
You'll notice many other package management software do the exact same thing.
In any case, this is based on what other package management software does. I don't know if this is indeed the case.
That is indeed the theory. But the point here is how openwrt broke that "last / only line of defence" package signature check and nobody noticed for three years and two major releases.
A bug in the package list parse logic of OpenWrt's opkg fork caused the package manager to ignore SHA-256 checksums embedded in the signed repository index, effectively bypassing integrity checking of downloaded .ipk artifacts.
Ha! apt-get had 17 vulnerabilities in the last few years, two of them with very high severity score, easily exploitable [0]. For example:
CVE-2019-3462 Incorrect sanitation of the 302 redirect field in HTTP transport method of apt versions 1.4.8 and earlier can lead to content injection by a MITM attacker, potentially leading to remote code execution on the target machine.
Yes, it's true... for redhat the worst rpm cve I could see from a quick google was back in 2012.
The CVE you mention is about the transport part, it's not easy to get right and everything that goes on the network is at some risk of that. Still that seems a different kind of implication than nobody checked if packages could be tampered successfully for 3 years and afterwards nobody changed the infrastructure.
Yes it was fixed when pointed out to them, after all openwrt users from 18.06+ had been exposed to this for three years. There's no known way to guard against bugs in the end, but... you can empirically test... they didn't check at all if their package signature check could detect tampering after patching it? For 3 years?
Then no infrastructure changes as a reaction to what happened? Like I said good for them, the PR mentions they will get some funding this is the kind of thing they can spend it on.
To be clear, a solution like that would not be nearly so easy to set up and modify as OpenWRT is, correct? OpenWRT has so many powers, I'm always thinking of something new to do with it. But I'm not a networking expert, and without OpenWRT, it seems like setting up a normal distro to do that stuff would be overwhelming, and take up many more hours than I have to give.
Is there a normal distro that is already set up similar to OpenWRT out of the box?
Right, it was more trouble and not as cheap as a commodity router, if you paid the same for a commodity router you'd be getting much more modern wifi like 11ax. However for people who considered OpenWRT, there are few equivalents... pfsense but it seemed I would have just moved sideways and the lesson of the CVE was to align with desktop type distros that have infrastructure teams and more eyes.
This has two mini PCI cards for wifi, one for 2.4GHz and one for 5GHz, they don't reach comparable speeds but it is very reliable. It also has 128GB msata SSD mini PCI.
Once Linux was installed, I was surprised nmcli + firewalld is really powerful now, I could set up a multizone AP with two mini PCI cards and Ethernet routing in a couple of hours googling, and it worked stably and just how I intended. For anything else, it's a normal Linux box with the kind of normal storage and packages you don't get on commodity routers.
I use Fedora on my VPS and up to date Firewalld is really limited compared to OpenWrt firewall3 config. Inter zone forwarding rules are still not a thing, MSS Clamping not sure, and not sure if there are anything close to OpenWrt mwan3. SFC is just legal representation, and joining it will not change anything to the development. As pointed by others, RCE (or equivalent) in package managers affected all of them, so this issue alone to switch seems an overreaction to me.
>> Conservancy will help OpenWrt continue to thrive and grow as its new fiscal sponsor.
That's what I think they need, to resolve their security and testing issues.
> Inter zone forwarding rules are still not a thing
I can believe that firewalld is not there on some things, but for what I wanted to do, including VPN service, it worked out great. I was expecting it to be a much harder ride, it would have been a few years ago.
> so this issue alone to switch seems an overreaction to me.
When I realized for 3 years there had been no package security on my own box I had thought was in better defensible shape than running manufacturer firmware, I realized I had been living in a fantasy. You're free to make up your own mind.
https://sfconservancy.org/news/2020/oct/01/new-copyleft-stra... https://sfconservancy.org/copyleft-compliance/enforcement-st... https://sfconservancy.org/copyleft-compliance/firmware-liber...