Concerning state of OpenWRT and board support

For Developers
1

The current state of OpenWRT is very disturbing IMO, more and more boards are going to end up in landfill if v6.x.x/v5.x.x is pushed onto everyone, with no regards to bloat.

I am well aware that maintaining this isn't exactly easy, but I do not see why certain boards can not be kept on v4.x.x if they do not show any issues. CIP (https://wiki.linuxfoundation.org/civilinfrastructureplatform/start) guarantees support for v4.19 until 2029.

Let me give you an example. 4/16MiB is more than enough for use as a router, there is something wrong with the OpenWRT kernel config. Using v4.19, I was able to load in netfilter and still maintain busybox ntpd, etc., and still have more than plenty of memory during high throughput situations.

With regards to 4/16MiB, though, I did not use OpenWRT, I used an alternative buildroot project to which I added in support for said target (no dt, either, mach). I also did not use musl, I used uclibc-ng.

I found that if I modified the PLL config during early init, I could get up to 3.75MiB/s (SNAT). nbd, etc., is also possible on such a board, but I could not solve the weird segfaults with running executables over the network (backtrace was all fucked, I did put effort into that >.>).

Of course, 802.11 would be probably infeasible unless you dropped down to an older tree, but still, shouldn't this be a point of concern if it's possible, but because of rubbish maintainer reasons, it is not?

Bootlog -> https://paste.debian.net/plainh/8b4e9f11

I think that 4-8/32-64MiB is more than plenty for usage as a router, however, so I think there is some weird upstream fetish going on here.

2

You joined the forum just to write this? Why?

3 Likes
3

I'm tired of abuse from maintainers over this, I want to see this settled, if anything. These boards are perfectly usable, they are basically telling users to effectively throw out usable equipment. I have seen forum posts about how new boards must have 128MiB of RAM or it's not worth it.

2 Likes
4

To trigger some reasonable consideration, may be ? Unfortunately, I have to agree to szrak in some respect. Being a traveller since retiring (and having done half a century of software development/project management) I have seen a lot of tiny routers used in not-so-rich countries. It does not make a lot of sense to me, to advocate security, as a reason to use new kernels and ever growing firmware images, when many owners in the not-so-rich countries simply can not afford to buy a new router, because of tiny resources. Thus, it could make sense, to maintain stable (shrinked down) openwrt versions and its images, only being updated because of bug fixes in critical packages or security updates for the kernel. Not to care about new tech features, as 2.4GHz is still very widespread and usually good enough, for example.

1 Like
5

what's stopping you ?

4 Likes
6

Another side of this question we have appearing from time to time is this:

How many of all the devices we have in the ToH are actually used anymore by anyone of the worldā€™s 11 billion people?

There are sometimes users asking in the forum why their device stopped working when upgrading with a 5year jump. And why no one of all the worlds users havenā€™t noticed the broken driver for at least 3yearsā€¦

3 Likes
7

@szarak - A few thoughts come to mind here.

First, you are correct that the hardware requirements have increased over time. But I will remind you that

  • OpenWrt provides up-to-date (or in the case of devices with deprecated support -- many years of additional) support for many hundreds of devices that have been abandoned by their manufacturers in terms of support and firmware upgrades/patches. This means more features and functionality, better security, and a lot more flexibility while extending the useful life of the hardware.
  • OpenWrt's requirements grow at a much slower pace than most firmware/software projects in the industry. It's worth remembering that we're talking megabytes here -- compare that to a phone which reuqires multiple gigabyes of storage and RAM to perform even basic functionality.

Technology is always marching forward. If OpenWrt stuck with old kernel versions, it would not be possible to support things like WPA3, Wifi 6, DSA, and even things like new VPN protocols and the like. Likewise, it would be impossible to support the new chipsets as they become available since they're not backported to old kernels.

It would not be practical to develop OpenWrt against multiple kernel versions simultaneously. That would make maintenence and support incredibly difficult, and it would be impossible to offer the breadth of packages that OpenWrt has in the repo if each had to be built aginst multiple older kernels. Compatibility couldn't be guaranteed, and testing would be a nightmare... the whole project would just collapse. Oh... and security... need I mention that? There are many patches that will never be applied to older kernels.

In case you're not aware, there has been a community effort to keep the really old devices running as long as possible. Heroic efforts of the core dev team aside, there's also the "tiny" branch. This provides a stripped down version of OpenWrt that people have carefully crafted to fit into the limited footprint offered by the old devices.

You can also customize your builds to remove all unnecessary packages (LuCI takes up a lot of space, btw), to extend the life of your hardware while operating on a newer versions of OpenWrt (within reason, depending on the details of the hardware). And, of course, you can take the security risk of running outdated firmware -- it's not like it suddenly stops working, it just may contain vulnerabilities that were not known at the time it was built.

If you really believe that OpenWrt is bloated, and that the situation is getting worse over time without a tangible benefit, you are welcome to start your own firmware project based on the old kernels.

12 Likes
8

None of these are needed, however, for operation. WPA3 has a lot more issues than WPA2.

It is not that hard to maintain a board farm with a bunch of boards, hooked up to mosfets and GPIO expanders. I mean, maybe not everyone can do that, however. JTAG would also be possible.

The kernel TCP/IP stack has been secure for the last two decades or so, I'd actually suspect that IPv6 has more issues. OpenWRT, by default, is running the DNS resolvers, etc., as root, so WTF are you going on about (cgroups, etc., jailing is a meme)?

9

Feel free to pull out your Comodore 64 or your IBM XT.

Or, in the case of wireless... nothing is perfect... but the fact is that you probably wouldn't go back to WEP on 802.11b, would you? So if you look at the progression, WEP > WPA > WPA2 > WPA3... those weren't generally back-ported to old kernels. You needed to upgrade to newer kernels to enable these new features. WPA (1) isn't considered secure anymore....WPA2 is the current 'standard' but it is going to eventually phase out. You can argue that WPA3 isn't critical right now, (but it is actually a requirement for Wifi 6E on the 6G band). And WPA is no longer considered secure... so if we stuck with old kernels, we'd never be able to progress.

You do realize that the project is run by volunteers in every respect, and that nobody is paid for this work. It costs money to build and "maintain a board farm." That's hard enough for some commercial ventures to do... not happening on a volunteer project. But again, you're welcome to start doing it this way when you start your own project.

Look at the release notes to see the CVEs that are patched with each successive release. Some of them are minor, others are major security vulnerabilities.

When you create your own firmware project, you can preach to others about how you don't need to upgrade or patch the kernel to resolve any security issues because you have created something that has no security flaws... something so perfect that none will ever be found.

11 Likes
10

While I understand your grievances, it comes down to manpower and other available resources, and those are scarce. The people actively contributing do so voluntarily; ordering them around to support older hardware certainly won't keep them onboard.

Nothing's stopping you from forking and rebasing onto a 4.19 kernel. It's open source. Can't have your cake and eat it.

That kind of tone certainly contributes to a constructive conversation.

7 Likes
11

No member of the currently active core developer base has interest or capacity to do that, so it is not done. The only way forward would be providing a longterm support downstream distribution, maintained by another group of volunteers.

9 Likes
12

None of these are exploitable WAN-side. Disabling the httpd would actually solve the majority of these vulnerabilities.

13

Does security within the lan suddenly not matter? What about wifi access as a function of KRACK?

8 Likes
14

If this is the viewpoint of what OpenWrt in combination of the complete ToH then I doubt this tread will get anywhere meaningful.

The truth is that most devices have no active testing or even any active developer once implemented in ToH. The new kernel is tested on a few device families and the rest is upgraded when ā€œtime for new stable releaseā€ runs out and we all hope for the best.

15

If that's the case, and you're willing to do the work, perhaps you should volunteer yourself as a maintainer for the "small" or "tiny" builds, then?

That's the way open source works. If someone has a need that's divergent from the needs of the wider project, feel free to step up and support it.

[I see this several times a year with Exim, the open source MTA. It rarely bears fruit.]

6 Likes
16

Let's just look at the ram side. Rule of thumb for buffer sizing for internet routers is 1*BDP (that is bandwidth delay product) per direction.
So 16 MB at an default internet RTT of 100ms will give us:
(16 * 8 * 1024^2 * 0.5) * (0.1 / 1000^2) = 6.7 Mbps per direction, or 13.4 Mbps total. But that assumes that all ram could be dedicated to network buffers. And yes for busy routers we can size buffers by BDP / squareroot(number of concurrent flows), but only helps if we disallow single 'link saturating' down/uploads.
Let's be honest here, sure 4/16 devices might still have some utility (e.g. if the alternative is no router at all), but let's not pretend all is rainbows and rose petals with 4/16 routers

8 Likes
17

OpenWrt is free and open.

You are free to maintain a "lite" version that meets your needs. If you think that maintaining support for older devices is worth the effort, go for it. If others want to join your project, or if you have the money to pay a team, good for you.

However, you are not entitled to demand how others spend their free time, period.

13 Likes
18

As a developer with a background in embedded systems, (started put my career in line/module controller development, layer 2/3 system x telephony if you are interested) image bloat is lazy programming. Fair enough, there's always elements outside your controlā€”kernels being one case; but if it works, don't touch it. Unless its security critical. I feel theres too much change just for change-sake, without any thought put into why.

Programmer: need to update my dev-stack to play with that new fangled MacGuffin that ive been looking forward to.

New dev stack goes into release.

Project manager: btw, target hardware now needs minimum 128MB flash RAM.

User: why?

Because some dumb ass programmer updated his dev stack without rhyme nor reason. But we cannot tell them that. "Oh, er, security".

19

Mods, this is turning into a shitpost.

Please lock this thread as nothing productive will come of this discussion. If you want to have the latest features on your tiny platform, you can (attempt to) compile it yourself.

A decade from a wafer of silicon locked to old speed standards is an acceptable lifetime.

If you need security beyond existing vulnerabilities, run a wireguard/ssh tunnel everywhere, including between your workstation and router.

5 Likes
20

Can we have one place where people can share latest builds/updates for old hardware. I know:

and

and this is rather for 4/32