A long time openwrt user here. What puzzles me the most is that, those who are forking openwrt are the the majority group of core developers for openwrt, so I don't know why they are leaving the project they're in control in the first place. It seems a few core developers left behind are also in shock, nobody knows why, and there is no dispute in the community that led to the split either, truly a mystery.
It could be that they just didn't want to cause any trouble with attempting to broaden the scope of OpenWRT to more general embedded development rather than a networking focus.
Number of active core developers at an all time low, no process for getting more new people involved.
Unreliable infrastructure, fixes prevented by internal disagreements and single points of failure.
Lack of communication, transparency and coordination in the OpenWrt project, both inside the core team and between the core team and the rest of the community.
Not enough people with commit access to handle the incoming flow of patches, too little attention to testing and regular builds.
Lack of focus on stability and documentation.
[Edit:] Since I am getting downvoted let me get through their stated reasons:
Number of active core developers at an all time low,
no process for getting more new people involved.
A fork is cutting the number of available devs in half and creates uncertainty for new people. So it should hurt in the short term.
Unreliable infrastructure, fixes prevented by
internal disagreements and single points of failure.
Then fix the infrastructure. ( If the fixes are actually prevented by internal disagreement, this may be a argument for a fork.)
Lack of communication, transparency and coordination
in the OpenWrt project, both inside the core team
and between the core team and the rest of the
community.
This may or may not be improved by a fork. It is certainly easier to manage a community half the size and a fork may be a fresh start, but it seems a better idea to try to improve their process.
Not enough people with commit access to handle
the incoming flow of patches, too little
attention to testing and regular builds.
Not enough people, so we are splitting the team.
Lack of focus on stability and documentation.
To some extend documentation and testing profit from enough available manpower.
Apart from the "internal disagreement" argument all of these arguments may be pain points but are not really arguments for forking the project, some are orthogonal some are actually arguments against a fork. So I wish them the best, but from the outside this fork does not look promising.
Your analysis seems predicated on your own ignorance of the OpenWRT project, and human nature.
How many system-level developers do you know who'd throw themselves into creating a new project, hashing out the governance, etc unless the alternative was even worse? I know, roughly, none.
I'm an OpenWRT user, not a developer, and it seemed pretty clear, even from that distance, that there was something broken given the way infrastructure problems were (or weren't) dealt with earlier this year.
I recognize many of the developers committed to the new project, and my understanding from others is that the new project includes many of the most active OpenWRT developers.
Clearly it would be better if they didn't feel this fork was necessary, but for now, I think this fork is promising.
The egcs fork from gcc was the only thing that finally gave the gcc devs the kick in the butt they needed to start making much needed changes, and then things eventually got merged. Maybe it will happen with OpenWRT/LEDE too.
Given that OpenWRT is the reference distribution of choice for networking chipsets these days, the reference goals do seem to be focused on making it better for that.
The last couple of OpenWRT releases have moved fast, in the future OpenWRT could move closer to the cutting edge without the pressure of users who want long term stability?
If so, this blurb from the about page seems interesting:
"LEDE is also an alternation of the phrase to lead, describing an introductory section of a news story that is intended to entice the reader to read the full story."
It is a real pity that the lack of developers is compensated by splitting developer focus on two different forks. If the reasons stated are true, let's hope it works out and strengthens embedded Linux, maybe even leading to a reunion like egcs/gcc.
OpenWRT is an impressive project and I've really enjoyed using it over the years.
It's always disappointing to see a project you use and rely upon face this kind of challenge. With technical forks, you can usually at least appreciate the motivations, but with political forks it can be difficult to understand what or how things will be improved (especially for users who only see events from the outside).
Best of luck to you and the rest of the team in resolving whatever issues are at play here.
I'm sorry man. Thank you for what you guys have provided. I still have my wrt54g (v2?) as well as a wrt54gl. I remember modding those routers with friends adding usb ports, expanding storage and all sorts of other things. I have several friends who became ccnps because of openwrt. Regardless of what happens with this, thanks again. You guys rock!
They have a point, maintaining something based on OpenWRT is extremely painful if you are not very in tune with the development.
I remember one instance where they just switched the entire package feed stuff around and didn't bother porting all old packages over. Or when core packages move around willy-nilly.
Another instance was when they changed over to a new freaking libc (musl). That's the kind of thing for major releases, and the fallout was that stuff like hwclock suddenly segfaulted.
oh boy more fragmentation! I wish the devs behind OpenWrt, dd-wrt, and LEDE would just work together for god's sake. OpenWrt is far from complete. the documentation alone is terrible.
Indeed. I increasingly find myself just biting the bullet and using x86 machines with Debian/Arch instead of OpenWRT. The quadrupled hardware cost is more than offset by having well-documented software.
Now if they could just get rid of Linux underneath and use something with better security. L4, maybe. After all, this is for embedded devices which basically run one program.
As far as I remember, L4 is such a minimal beast that you typically run something like a Linux-Kernel inside it, to do most of the boring stuff. And then use the guarantees on isolation provided by L4 to have timing or security critical functions into their own L4 tasks. Am I wrong there?
But even if L4 would provide the minimal set of functions expected to pass packets on an embedded device like a router: Would you really gain security if you had to rewrite most of the libraries involved for, say, user-interface and configuration (where all of the exploits reside) from scratch? The whole wpa/wpa2-hostapd madness, or VPN setup with all the many dozens of possible protocol combinations?
And even when one plans to rewrite hostapd, openvpn, dnsmasqd with all their dependencies from scratch, in a safer language than C, with reduced priviledges and isolated from the rest of the system: One still could run these replacements easily under a Linux kernel providing most of the necessary infrastructure and with hardly and bugs being discovered in the kernel core that would be relevant for such an embedded device.
I don't know why parent is being downvoted. Linux probably isn't the best OS for this, a microkernel OS or something based on BSD seems to be far saner, especially since we don't need weird hardware support, all home routers use the same three or four families of MIPS and ARM SoCs.
Home routers come with one of three instruction set families (MIPS, ARM, PowerPC) with CPUs or SoCs from at least six major manufacturers (Broadcom, Qualcomm-Atheros, Ralink/MediaTek, Marvell, Freescale/NXP, Realtek) and WiFi interfaces from any of them except Freescale but plus Quantenna. And there are multiple generations of hardware in the market at any one time. That adds up to a hardware ecosystem that is vastly more diverse than PCs; this is in no way a narrow scope of problem. And I'm ignoring all the devices that also have a cable, DSL, or cellular modem.
The boundaries of what tasks are handled by the CPU vs by dedicated offloads on the SoC vs by the NIC (which usually has software of its own) differs with every manufacturer and every hardware generation. The job we want our routers to do is a moving target as the industry continues to develop new routing and configuration protocols (eg. Homenet) and new QoS techniques and new WiFi rate control techniques that need to be incorporated into the software running on the CPU and/or NIC. The hardware is usually weak enough that the products can only get the job done by prioritizing performance over expensive security measures.
I could get behind the idea of a line-rate dedicated firewall+NAT with formally specified behavior. But any attempt to enumerate the core functionality of a modern wireless router will leave you with a job that is far larger than any successful formally specified/verified software project.
Running atop Linux is the only option that doesn't leave you stranded with a '90s-era feature set and a cripplingly small base of supported hardware, and the userspace stuff is the low-hanging fruit for securing anyway.
Your point about the diversity of the router hardware ecosystem is an important one, and from what I can tell, makes up a significant portion of the OpenWRT project.
I think though that the "industry" work on QoS and rate control has been pretty dismal and counter-productive. The major improvements in QoS in OpenWRT didn't come from the router industry, and the router industry hasn't been speedy about incorporating it. Fixes for queuing and rate control in the WiFi stack are also coming from outside (when they come), and who knows how long they will take to get mainstreamed.
Their hardware support is not as good as Linux, especially for WiFi and for embedded SoCs. Their network stacks are lacking in more advanced features like QoS that's not from the '90s (AQM, FQ, traffic shaping that accounts for the overhead your DSL or cable modem adds) and I'm not aware of any efforts to eliminate bufferbloat from NIC drivers the way BQL has for most Linux Ethernet drivers. I'm not sure how Linux compares against the BSDs for dumb packet forwarding and NAT performance, but for real-world performance the better QoS makes it no contest.
Linux is what the chipset manufacturers target, it's what the router manufacturers ship, it's what most of the academics seem to turn to when they're not using a network simulator, and Linux seems to have the most active networking developers. The only compelling argument for BSDs is that pf.conf is more approachable than the Linux tools, but BSD advocates usually don't mention that it's because pf does a lot less than tc and the other Linux tools.
FreeBSD has QoS available via PF and ALTQ. As for performance, Netflix chose FreeBSD for their CDN for the better network performance over linux.
I do take your point about hardware support on consumer routers though - most of these are based on linux so its relatively easy to get linux based *wrt installed on them
Stop thinking like QoS has a singular meaning. ALTQ provides the aforementioned '90s-era inferior QoS techniques, and it isn't even available on FreeBSD without recompiling the kernel. The dummynet module is a little more modern, and in February patches appeared implementing the CoDel and FQ-CoDel AQMs that Linux has had for four years.
Routers are on the front line of computer security. They need to be very resistant to attack. Patch and release won't work; many routers never get patched, and those that do implicitly have a backdoor in the update system.
This is a job for a limited protected-mode OS that Just Works. L4, QNX, something like that.
I think that using SELinux would be counterproductive. For this type of thing, the attacks that matter the most are web attacks (CSRF, etc) and attacks against the kernel.
For web attacks, the web UI has to be quite privileged unless you explicitly privilege-separate it, Sandstorm-style. That seems like a big project for a router.
For kernel attacks, SELinux just increases the attack surface. Throw a good seccomp filter at things, deny access to proc and sysfs to things that don't need them, and use hardening options.
The trouble with anything other than Linux or maybe FreeBSD is driver support. And, for a router, even if an attacker merely compromises the network stack instead of compromising the whole system, the attacker still mostly wins.
What would be interesting is a good verified boot or immutable storage model. For example, have the router boot into a mode in which it can't write to persistent storage unless a physical button is used at boot time. eMMC can do this, but I have no idea whether the NOR and NAND chips in most routers can.
One of the great advantages of OpenWRT is that you can make projects that use extra packages, eg to use it to create wifi webcams, alarm systems, and all kinds of things using GPIO pins as well.
They could use BSD underneath, like JunOS and Netscaler run on.
But maybe an operating system is too large in scope. You're right that these devices only run one application, why use a tool (operating system) that can run many applications?
It's a bit like running a hypervisor for only one operating system. There are benefits, true.
Well, there's the kernel, which handles flinging packets between interfaces, filtering, etc., but your average router has lots of services it provides as well: DHCP, DNS, file/print sharing via USB ports, etc.
Loading even more functionality into the kernel is at odds with security, stability and maintainability. Its also not going to save much/any in the way of resources.
It's interesting to compare contributors from both LEDE[1] and OpenWRT[2] sites. Most of the folks involved in LEDE seem to be from Germany. With OpenWRT devs mostly from DE to begin with, this fork may end up as something interesting. Hope it's not another libav/ffmpeg snafu.
What I can tell you, is that I found it very difficult to find what the situation was on the Netgear router that I wanted to work with.
A series of well-designed pages that would help me find the latest info, with notes of workarounds or "no it won't work" would have saved me a lot of Googling to find posts, then having to look at the date of each post to work out the chronology; and would go a long way to helping with adoption.
I was very pleased with OpenWRT even 5-6 years ago! I am sure that things are better now.
Interesting. I've always found OpenWRT a lot easier to use for embedded development than alternatives like OpenEmbedded even if I didn't care about the Wireless or Router focus of the project.
Not always. If a fork is made because some group wants to move in a different direction code-wise, it's good, because it gives users more choice. However, if the fork is made because of administrative reasons (as it seems to be the case here), then often all it does is muddy the waters and create confusion. We'll see how this one plays out.
While I'm excited about OpenWrt, why wouldn't the ecosystem move to Raspberry Pi at this point, considering that a Pi and multiple wireless NICs can be purchased for much less than a typical access point?
They are really completely different ecosystems, each with their own use cases, but off the top of my head:
1. Raspberry Pi boards (and rpi-similars) don't typically break out the ethernet interfaces, and require a USB>Ethernet.
2. Raspberry Pi boards (and rpi-similars) don't typically have onboard wifi, this means you will be putting all of your traffic over USB, which as AC rollout happens you don't have enough bandwidth/latency with USB 2.0
3. Raspberry Pi boards (and rpi-similars) don't typically have multiple ethernet interfaces.
A "Standard" OpenWRT router has between 2 and 5 onboard ethernet interfaces, a small power efficient processor, and between 1 and 6 onboard high power Wifi interfaces.
Now, Monowall/pfsense can be a great route to go, but even then you don't use an Rpi because you want your interfaces hanging off of PCIe instead of USB.
> The Raspberry Pi 3 shares the same SMSC LAN9514 chip as its predecessor, the Raspberry Pi 2, adding 10/100 Ethernet connectivity and four USB channels to the board. As before, the SMSC chip connects to the SoC via a single USB channel, acting as a USB-to-Ethernet adaptor and USB hub.
> Sadly, no, the Raspberry Pi 3 still seems to do everything over the USB bus. It'd make an awful router
Not exactly, the BT/WiFi chip is apparently running via SDIO.
But yes, that doesn't help with the Ethernet situation. I don't get why Broadcom, when they already do a custom SoC, didn't include one or two MII lines and use a real Ethernet PHY instead.
Throughput. The single Ethernet port on the Pi only gets somewhere between 30 and 40 megabits. Some smartphones can exceed this on WiFi and higher end Internet connections will definitely exceed this.
That's for a single connection before you even get to NAT/firewalls/IPv6 and VPNs.
Note that I haven't put the Pi3 through its paces yet but the extra CPU and RAM won't completely compensate for the USB/Ethernet limitations.
In addition to what other folks said, a big part of the user base for OpenWrt and similar use standard hardware from the big consumer electronics firms. I can imagine someone maintaining a port for random experimental platforms (assuming the codebase is amenable that sort of thing; I have no idea), a large part of the point of it for a lot of users would be gone.
But as others said, I can't imagine a Pi having anywhere near the throughput of the commodity AC APs I use at home at this time.
The RPi is tied to the 12-24 month product cycles of consumer electronics devices.
That's great in that it means relatively frequent upgrades. Though at this point, the RPi3 is a very unbalanced system. Particlarly, as others have noted, with regards to network I/O.
Router platforms are tied to the lifecycles of networking standards. The underlying standards change much more slowly, roughly ~5-10 years for major changes. The router SoCs and WiFi chips change somewhat more quickly, but not as quickly as consumer electronics SoCs.
This slow rate of change is probably a good thing for OpenWRT/LEDE, because it means that there is more time for software support to mature for each hardware generation.
But, the idea that it can run on a variety of platforms is one of the benefits. Rpi, for example, would be an odd choice as a base for a commercial hardware product, due to availability in volume, form factor, etc.
Different projects and goals as someone else mentioned.
However, it would be great if the *wrt projects could adopt the standardized update mechanism that OSMC has leveraged. It's made upgrading so much less painful.
Personally, I use ddwrt and would like to see that project take the charge up on this.
My comment is getting lots of downvotes. I'd argue:
- All the routers (buffalo, linksys) I've installed OpenWRT on have ended up being fairly unstable and have required reboots. The only consumer grade wifi router I've tried that seems stable is the Apple Airport Extreme.
- Most home users never come close to maxing out the throughput a pi can offer.
- If not a pi, perhaps another open hardware device -- seems like one could be sold for under $50 with nic support that addresses all the max USB bandwidth concerns (it may already exist).
- All the complexity of installing on random wifi router hardware (version maintenance, minimal storage space, etc.) seems prohibitive compared to the simplicity of a pi, risk of bricking the router, etc.
Throughput is hardly the only meaningful performance limitation the Pi has, but it's already enough of a limitation to disqualify it. The RPi really just doesn't come close to being suitable as a router.
Any open hardware device that is suitable for wireless router duty and fits within a $50 budget would have to be essentially a standardized PCB for a single-band Atheros ath9k SoC. It would provide almost no benefit over the dozens of commercial off the shelf products that use those chips and almost universally run OpenWRT flawlessly.
The complexity of installing on any random device is almost entirely with determining what exactly is inside that device, since basically every vendor routinely changes everything inside the product without changing the model number. OpenWRT already has the infrastructure that solves the version maintenance problem, since they do automated builds of the OS and packages for all the various supported hardware platforms. Automatic updates have been implemented by at least a few sub-projects and are being held back mostly by the storage space problem. The hardware vendors are in the process of transitioning from NOR flash to NAND flash, so that problem will take care of itself over the next few years.
The risk of bricking a router is probably a lot lower than you think it is. With almost everything, it's truly hard to screw up to an extent that flashing over TFTP won't fix. A lot of mainstream hardware is significantly more robust that that; I have a bottom of the barrel D-Link that provides a web interface in its bootloader for rescue flashing.
"Most home users" are never going to install OpenWRT on anything, RPi, or otherwise. Of those that do, it seems likely that they will max out the throughput of a RPi, especially now that >100Mbps internet is common place is some countries, and is becoming increasingly available in others (like the US).
There are some RPi like boards with a single GigE, but they suffer from having smaller developer communities, and still come up short on IO when compared to a networking platform, which will typically have 1-2GigE lanes to the SoC, integrated 2 or 3 stream 2.4 GHz WiFi and a 1-2x miniPCIe interfaces.
Right now, probably the cheapest most capable router is the Ubiqti EdgeRouterX for $50 (no wifi though). It has a 2 core/4 thread MIPS CPU that can do ~1Gbps NAT/ROuting with hardware offloads and ~500Mbps just using the CPU and DMA hardware.
