What has to be done so we remain able to build next years an OpenWrt image for 4/32 devices

For Developers
1

Hi all

Of course we all know that 4/32 devices are near EndOfLife but the fact is, these still are good devices. I, for one, can give oath that our ath79 devices are rock-solid and long-lasting devices. The fact that these can still be purchased new at the stores gives also a clue about how good they are.

I think we should do something to assure we are able to build images for them for as long as possible, and that could be good, not only for 4/32, but for 8/64 in the future, and, in general, to be able to build images as little as they can be. We should be able to build images for devices that vanished from stores for a minimum of five years, as this is not closed source software.

There are a lot of people out there that deploys these devices, so quite a few of us could be on the same boat.

However, fitting an up-to-date OpenWrt on 4 MB flash is going to be more difficult as each new OpenWrt release appears. so question is:

What has/should to be done so we remain able to build next years an OpenWrt image for 4/32 devices?

2 Likes
2

Learn how to build your own images if you’re on a current target. If your treasured, under-resourced router is on a dead target (ar71xx, as one) learn how and port it to an active target.

3 Likes
3

Just because you can does not mean you should.

Championing a community build for your favorite device would be easiest, so that you and like minded people can work together to achieve a common goal. Since with limited hardware resources compromises will need to be made and the you or community build will be able to focus on what is required. You need to be realistic your not going to get a full kit and others have already said they are not going to remove support from the code. So realistically coming up with your own list of compromises as an individual or community build and create your own firmware image.

So for example go to Community Builds, Projects & Packages and create a topic Need help creating a lightweight image for XXX and discuss with whoever is interested how to achieve a lightweight build based on the current release. The reason been when resources are that tight you can't go making generic fixes that will work everywhere, you will need to be specific to achieve the best result.

1 Like
4

I don't know if this is a matter for a community build, since I can still build that image without help.

However, I do see more people asking about, say, WR940N so anyway is not a bad thing to do. I'll probably do it next days, I think I could give my config.seed for WR940N v6.0 as a beginning.

The matter here, right now, could be: when and why do you think it will be impossible to build an image for ar71xx devices?

5

You might want to start a new topic for that because WNDR3700v4 is AR71xx and has 128/128.

If your asking about mips_24kc i don't see linux kernel or gcc dropping support anytime soon. Anything else depends on developers will to resolve issues when the build breaks just for a limited architecture or device family.

6

To build with LEDE 17.01.7 should help too, since its still supported (limited service releases) and running on an older kernel. Thats mean more space on the flash. You should check on Gluon to port back the ram saving measures that happened the last few releases. Or maybe you can build completely your images based on gluon. The same packages are available on their repo.

7

OK, I think about ar71xx_tiny devices.

8

Hi folks,

I want to remind everyone about Rule #12 here (Be Nice to Each Other).

This topic has been established for those who have good business reasons to continue working with 4/32 (or other difficult) devices. The people posting here are clear-eyed about the constraints and difficulties they face in keeping their (sometimes large) population of older devices running and secure.

Let's make sure that snarkiness doesn't creep into the discussion, and that your comments are supportive of their goals. Thanks.

Rich

5 Likes
9

I think v17 should be maintained with critical security fixes for the core parts for as long as the kernel is being maintained. It's somewhat smaller than v18 by default, and it works well for the stuff a 4/32 router can do. Don't know if there are any 4/32 routers that are only supported by v18.

10

That would roughly double the load on the development team, as the kernel version is different than that of the current release branch (and will diverge even further in a couple months as the project shifts to 4.19, and the wireless starts using the 5.x framework). I don't know that it could even be trimmed to ar71xx, because you'll have the Lanitq people saying "Why them and not us?"

Yes. 4.4 has an expected EOL of February 2022. Would this do anything but "kick the can down the road" a couple years?

No matter what comes of this thread, people need to realize that their hardware needs replacement soon and that it's "on life support" already, even if they just bought it.

Looking at effective use of limited resources across the range of devices, more than a development branch and a single release branch doesn't make much sense to me.

At least in my opinion, dropping the "tiny" target, which is a configuration change, not a code change also makes sense. Builds for a "normal" OpenWrt failing then become a bellwether for that device, rather than the security blanket of "It was fine on Chaos Calmer, 17.01, and 18.06, so I'll be good for another three releases." I think the "tiny" target had its transitional moment, but now it is a cost, not a benefit to the project overall. Somebody has to identify that the target is not viable, then switch it over to the tiny target, or drop it entirely. While some failures show up on the builders, many times it is not until a user flashes an image. Then there are the scores, if not hundreds of devices on a target that "nobody" tests because they're rare in the community of users who use OpenWrt and would report issues.

So, assuming that the position of the project is something along the lines of, for architecture/target X:

  • There is a single branch for a given architecture
  • There is a single configuration built for that architecture

Then any device that is supported by that architecture has the basis for anyone to choose how they want to compromise should the default build not be functional, at any reasonable time in the future.

For personal use, that should be sufficient.

For shared use, be it for free or otherwise, some assistance from the OpenWrt build system in meeting all the licenses' requirements would be helpful. You're "distributing" the firmware as soon as you post a link or give it to someone else.

There's not only GPL and the "corresponding source", but many other licenses. Virtually all the different licenses require distribution of something with the binary.

Did you know that your Android phone has in its ROM a copy of every license from every package, along with the differing copyright statements in each? Router manufacturers do the same thing, consuming 156 kB, gzip-ed, on a device I'm working with right now. Now that approach will kill a 4 MB device, so it could/should be distributed with the firmware, rather than in the firmware at the option of the builder.

So, adding to the above two bullets:

  • OpenWrt build system be able to identify every license and other required files or content in both the base system and packages
  • The build system automatically assemble this content into a single file and compress it as a normal part of the build process
  • The build system further assist the user in meeting the requirements for legal distribution of the resulting firmware by, at the option of the user running the build
    • Include the resulting "license bundle" in the firmware itself and/or
    • Include the license bundle than the ROM image in a single archive
    • Include a user-defined statement, such as how the recipient of the firmware can obtain the corresponding source in either or both of the above

(Yes, even if you give away your firmware, or just post a link, you're "distributing" it.)

5 Likes
11

Please could you remain on subject?

AFAIK nobody forces you ti give any answers, so could you

a) give advice/help
b) shut up

Thanks again

12

I don't see how fixing one thing maybe once or twice a year can double the work load. Almost all the commits to master are new features and fixes that are not security related. There are more security fixes to the 4.4 kernel, but few of them are vital to the core functions of OpenWrt.

To my knowledge the last really important issue was the KRACK related change, which took about 1000 lines to fix. It wasn't even all that critical because the clients were the real problem. Of all the security fixes in 17.01.6, only https://nvd.nist.gov/vuln/detail/CVE-2018-14526 seems important to users of the core router functionality. The fix is 43 lines.

If it turns out that the next critical security issue is very hard to fix because the kernels have diverged too much then fine, but please let the users know. Maybe it will even encourage someone else to try.

Being able to use something for 3 more years without having to buy a new one seems like an obvious advantage to me. It's one of the reasons why I use OpenWrt in the first place. The manufacturer hasn't maintained the firmware for years, so without OpenWrt I would need to buy a new router twice as often.

13

How do you decide what is an important fix or not without spending some time analysing each one. Even if no new releases are made, work needs to be done.

I think it is fairer on everyone if the current practice continues. This way difficult devices can be taken care off individually in community builds by interested persons, which might just involve tweaking the config to make it fit with some tradeoffs.

2 Likes
14

I read the CVE entry. They probably do a better job than most in analyzing the severity and extent of the issue. It usually doesn't take all that long to understand which use cases it affects.

15

Feel free to manage that release branch, I don't see anyone stopping you from doing so.

2 Likes
16

So where would you draw the line

Linux 4.4 CVE Details

1 Like
17

Not to mention that you've got to bring 4.4.x up to whatever is current at the time, refreshing and fixing all the backports and patches, and that's just for the kernel.

What about all the application software, which is also on a different branch?

Who is going to maintain the package repository, with all the changes that impact it and its security?

The task of maintaining a separate branch is a lot more than just a couple kernel patches now and again.

Past that, who's going to bring the improvements in wireless performance, CPU and memory tuning back to 4.4? Or do you think that people will be "happy" that their device is just running, although something very similar on a current release doesn't have the wireless problems or crashes that their device has because of those improvements.

Who is going to maintain a second branch of LuCI, when it moves forward, or the APIs on which it depends changes?

What about a new firewall system? Who is going to, for example, backport nftables, ulog, and rip out iptables?

5 Likes
18

They would need to be exploitable remotely, and of course relevant to OpenWrt. It's possible that's the case for https://www.cvedetails.com/cve/CVE-2018-10938/ , but I don't see any others. An OpenWrt developer would probably quickly know.

19

Nobody needs to do any of that. We're talking about supporting devices that have been in use for ages. It's highly unlikely that any critical feature bugs will suddenly appear. Yes, I think they'll be happy that they are still running. I haven't seen anyone asking for more. I'm still using v17 myself for other reasons, and it runs flawlessly with perfect uptime.

20

Reality doesn't support that, even without taking into account that you're going to freeze the user experience years in the past.

So, since you're not going to keep that branch consistent with what OpenWrt provides and documents, who is going to maintain the wiki and have many pages say

If you're running current OpenWrt, do this, its super easy
if you're running ancient OpenWrt, well,

  • You can't do this at all, or
  • You need to do it completely differently.

Who is then going to do all the things you believe you don't need to do when your user community says, "But I can do it on OpenWrt, why not on your firmware?" -- You're back where this all started.

1 Like