Introducing the LEDE project – A reboot of the OpenWrt community

199 81 10 years ago

Zekio• 10 years ago

More of this type of projects is good, gives consumers/developers more choices.

pferde2• 10 years ago

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.

grandalf3• 10 years ago

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?

voltagex_• 10 years ago

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.

malcolmputer2• 10 years ago

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.

ae_keji• 10 years ago

What about the Pi 3?

revelation2• 10 years ago

OpenWRT is an embedded linux distribution that works similarly to something like the Yocto project.

I don't see how it relates at all to one hardware vendor, with rather terrible track record on all things networking to boot.

__jal• 10 years ago

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.

tyingq2• 10 years ago

OpenWRT does run on the Rpi (https://wiki.openwrt.org/toh/raspberry_pi_foundation/raspber...)

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.

newman314• 10 years ago

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.

grandalf3• 10 years ago

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.

wtallis5• 10 years ago

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.

easp6• 10 years ago

"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.

easp6• 10 years ago

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.

ge0rg• 10 years ago

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.

embeem2• 10 years ago

This announcement comes as a surprise to all the other developers, myself included.

- mbm (openwrt founder)

pferde2• 10 years ago

This all sounds to me like it was some kind of misunderstanding among the devs. I hope you guys can resolve this and remain together.

While forks can be good, they are not always so.

JeremyNT• 10 years ago

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.

deelowe• 10 years ago

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!

saganus• 10 years ago

OpenWRT is awesome. Thanks for the hard work!

okigan• 10 years ago

OpenWRT is awesome, really would like to see one project (not split into two)

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/

tubelite• 10 years ago

Thanks for openwrt. One of the nicest Linux distros I've used. Love ubus and procd and all the shell interfaces.

I was literally just now using the image builder to create a custom image and ran into this news.

ausjke2• 10 years ago

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.

dman• 10 years ago

Maybe this is the first step towards launching a commercial offering?

ausjke2• 10 years ago

this is something to be found out

tyingq2• 10 years ago

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."

mcbridematt• 10 years ago

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?

wtallis5• 10 years ago

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.

RichardLake• 10 years ago

The devs have put up their meeting notes. http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016...

There is some discussion starting around 1230. My reading is that they thought that the OpenWPT reputation re: development matters was poor.

reitanqild• 10 years ago

BTW that seems to be a nifty irc bot:

http://wiki.debian.org/MeetBot

ricardobeat• 10 years ago

What about the reasons stated in the post?

    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.

yk• 10 years ago

All of these are made worse by a fork.

[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.

revelation2• 10 years ago

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.

lindadarnell• 10 years ago

I don't like it

Animats2• 10 years ago

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.

stephengillie2• 10 years ago

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.

jlgaddis• 10 years ago

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.

easp6• 10 years ago

A big part of the OpenWRT project is hardware support for wireless chipsets and SoCs.

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?

grahamburger• 10 years ago

I typical consumer wireless router runs quite a few programs - routing, switching, dns, firewall, dhcp, web server for configuration, etc.

nitrogen• 10 years ago

Also UPNP, media server, print server, VPN

brokenmachine• 10 years ago

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.

DiabloD3• 10 years ago

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.

Animats2• 10 years ago

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.

wtallis5• 10 years ago

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.

cnvogel• 10 years ago

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.

duaneb2• 10 years ago

Linux is the last choice for a good userland kernel.

symlinkk• 10 years ago

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.

embeem2• 10 years ago

Agreed, but the irony in that statement is that the OpenWrt developers who started LEDE are also DD-WRT developers.

creshal• 10 years ago

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.

DominikD• 10 years ago

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.

[1] https://www.lede-project.org/about.html [2] https://dev.openwrt.org/wiki/people

pmorici• 10 years ago

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.

patrickg_zill2• 10 years ago

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.

Hydraulix989• 10 years ago

I really don't understand why there needs to be a newly forked router firmware project every few years. Back in my day, we used DD-WRT, and it worked.

the-dude3• 10 years ago

They went over to the dark side.

randomchars• 10 years ago

How so?

chris_wot• 10 years ago

What are the benefits of using procd? And are you going to fork that also?

What's the scope of this project - really very interested...

bluesign• 10 years ago

"AGREED: 4/6 attendees agree to create and agenda and finding a date on the mailing list (jow_laptop, 13:05:51)" [1]

First major disagreement :)

[1] http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016...

ksec• 10 years ago

Slightly Offtopic, are there anything similar based on FreeBSD / BSD?

nissimk• 10 years ago

There are several listed here, but most of them only work on x86, not consumer routers.

https://en.m.wikipedia.org/wiki/List_of_router_and_firewall_...

patrickg_zill2• 10 years ago

Concerning those who complain about the fork - Debian has spawned Ubuntu and many other distros.

RedHat has spawned CentOS and Scientific Linux.

Is anyone arguing that this has destroyed Linux?

Introducing the LEDE project – A reboot of the OpenWrt community

Related Stories