Introducing the LEDE project – A reboot of the OpenWrt community
lede-project.org
lede-project.org
"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."
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?
There is some discussion starting around 1230. My reading is that they thought that the OpenWPT reputation re: development matters was poor.
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.
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.
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.
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.
- mbm (openwrt founder)
While forks can be good, they are not always so.
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.
May chat with nbd [1]?
Also checkout history [2].
[1] https://www.lede-project.org/about.html [2] http://meetings.lede-project.org/lede-adm/2016/
I was literally just now using the image builder to create a custom image and ran into this news.
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.
RedHat has spawned CentOS and Scientific Linux.
Is anyone arguing that this has destroyed Linux?
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.
Sure, they could move all that to BSD, but then if they wanted to do that, why didn't they do that in the first place, rather than working on Linux?
This is a job for a limited protected-mode OS that Just Works. L4, QNX, something like that.
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.
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.
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.
big business usually use their own network stack as stock bsd is at most suited for soho workloads
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.
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.
[1] https://www.lede-project.org/about.html [2] https://dev.openwrt.org/wiki/people
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.
https://en.m.wikipedia.org/wiki/List_of_router_and_firewall_...
What's the scope of this project - really very interested...
First major disagreement :)
[1] http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016...
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.
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 point still stands that a $30 router blows away a rpi in terms of network connectivity (which should matter for a router).
> 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.
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.
I don't see how it relates at all to one hardware vendor, with rather terrible track record on all things networking to boot.
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.
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.
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.
- 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.
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.
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.
Wow! What do you think is the best one that does do wifi?
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.