Support and updates on Openwrt

[jow]

@Camicia

I wonder if it would be possible to reorganize the repo to be able tto minimize the changes for device as new updates come out.

Patches are patches, no matter how much sugar coat and repo restructuring you perform around them. In the end of the day, someone has to forward port all patches to new kernel version, compile test all 40 targets and manually review patch conflicts in case of non trivial rebases. Its tedious, labor intensive work that can eat between a few hours and several days worth of work which is usually not payed for by everyone.

@Camicia

How does Ubuntu do it?

Ubuntu targets mostly targets x86 platforms and a few selected very capable ARM devices. I don't think space constraints are of any consideration for Ubuntu.

@Camicia

I am not saying: no progress. People on newer kernel may be more aggressive. I am saying that once they decide not to invest a lot time on certain devices, they should be still supported in a minimal way that guarantee security patches and performance/stability.

We do support devices in a minimal way with security and bug fixes, mainly by cherry picking relevant fixes from the master branch back into the still supported branches. There are autobuilders for each active branch which continuosly generate updated packages. If larger security issues come up (Spectre/Meltdown, KRACK, ...) we put out new maintenance releases with refreshed images.

I think this is about as good as it gets, any demands beyond that are unreasonable and impossible to address given OpenWrt's current personell capabilities. Nobody working on OpenWrt has the time and financial resources to provide support for devices 5, 6, 7 years down the road. It is simply not going to happen.

@Camicia

What I am saying is that for the average device the support to the latest version of Openwrt seems pretty short. Considering that major versions updates are introducing big breaking changes that end up resulting in a lot of routers not being supported anymore (or supported with high instability or performance problems), I think there should be a strategy to at least provides some backward support for devices.

I disagree. Taking for example the TL-WR1043ND which was first supported in 10.03.1, released december 2010 until at least 17.01.6, released in september 2018. This is almost 8 years free of charge support. not sure what else you expect beyond that.

@Camicia

As it is right now, even the service releases of the main version are not very frequent.

Where is this completely wrong notion coming from? What are frequent releases?

17.01.0 - Feb 2017
17.01.1 - Apr 2017
17.01.2 - Jun 2017
17.01.3 - Oct 2017
17.01.4 - Oct 2017
17.01.5 - Jul 2018
17.01.6 - Sep 2018
18.06.0 - Jul 2018
18.06.1 - Aug 2018

Not sure if you expect a new release every one or two weeks to be happy, but if this is the case then this is definitely not going to happen, sorry.

@Camicia

Update are usually shipped to either fix a bug or add a feature. The feeds are already a huge step in that direction. I just wonder why we cannot publish modules more often maybe adding kernel updates and notify the user that an update is available

If you want to always use the latest tip of the respective branches, use http://downloads.openwrt.org/snapshots/ or http://downloads.openwrt.org/releases/18.06-SNAPSHOT/, http://downloads.openwrt.org/releases/17.06-SNAPSHOT/

As for the notification infrastructure - someone has to implement it, add the necessary changes to OpenWrt, the gui, the builders etc.

@Camicia

So when there is an update in a package, the package can be made available on a beta feed. People can choose to subscribe the beta feed (ideally with just a checkbox on LEDE). Everybody may receive a notification it would just say that it is in beta and warn about instability... Once enough users would have confirmed that it works fine, the package can go out of beta and shipped on the regular update channel. If the package is still in beta, we can actually prompt in LEDE or on login on SSH a week after the update asking if everything works fine. You can add all the bells and whistles on top of it: checkbox for autoupdates, moving from "beta" to "stable" by device. You can even blacklisting devices where the upgrade was creating problems. Etc. I would argue that this would also increase participation. For example if a programer that notice that an update on a component that they care about is blacklisted on their router, they may decide to look what the problem is, fix it and submit a patch.

So the question here is - who is going to implement that, who is going to do the merging, categorization, greenlighting of packages. Who is going to test them, address bugs etc.? What you demand here is a lot of work the project simply isn't able handle.

@Camicia

What about adding some changes so that supporting multiple versions of a package (including the kernel) is easy. I am not sure what the current overhead for an extra version of the kernel is. You can add a new kernel for the new devices and still maintain the old one for older devices. I think it is better to have people pushing or doing the work to migrate their device to the new kernel if they really want to, than forcing them to upgrade removing support of a older kernel.

Upstream kernel development progresses so fast that this simply isn't feasible in the long term. Having out of tree drivers (mac80211, wireguard, mt76, ...) or even userspace (cake, openvswitch, ...) support widely different kernel versions is a lot of work which often is hindered by the lack of suitable hardware or suitable test cases to even assert the functionality of all the different version combinations. Each further version exponentially increases the effort required to keep stuff working.

Think about it, you demand a level support here which not even the OEMs can provide for their own device designs, and they only have to support a fraction of the environments OpenWrt supports, with full access to sources, schematics, erratas and so on.

@Camicia

I think Netgear still supporting the R7000 that was released 5 years ago should demonstrate that it is just a matter of deciding what it matters and what you want to do.

Correct - and the 4-5 active OpenWrt base contributors actually doing a majority of the work decided that they cannot handle providing support for all devices accress 40 targets for 5+ years while still developing OpenWrt and backporting latest upstream features into old kernels, merging patches, handling infrastructure and porting OpenWrt to new devices.

If you need that level of support then consider building a downstream distribution based on OpenWrt with support for a selected subset of devices and maintenance for a few years down the road. Maybe even take a stab at e.g. maintaining the 17.01.x branch out of tree and if it works out well, offer to take over the maintenance.

@Camicia

Absolutely in agreement here to stay as close as possible to mainline. And you also have to look at the context and the constrains. A device driver that runs on a Linux PC has less memory constraints than a router. The configuration system of Openwrt seems pretty powerful. Why cannot be easy to encode the dependencies on a older kernel?

Staying as close as possible to mainline and doing LTS are mutually exclusive requirements imho. Mainline does not care about LTS, mainline does not care about out of tree and mainline does not care about heavily resource constrained systems.

Encoding dependencies on a kernel version is the least part of the work, making sure that entire out of tree subsystems work across different kernel versions with wildly different APIs while simultaniously working on upstreaming them is the hard part. Most developers do not want to handle the load of juggling three to four distinct branches of components at any point in time.

@Camicia

I would be happy in a system similar to the one used in npm audit. There are other similar tools for other languages. If you can get a report of the current vulnerabilities on your devices, some people will move to fix the problem. The first step is make the situation visible .

https://sdwalker.github.io/uscan/
https://openwrt.org/releases/18.06/changelog-18.06.0#security_fixes

OpenWrt v18.06.1 Changelog

...

See also the recent work on tagging components with CPE IDs to allow for NVD cross referencing etc.

@Camicia

Currently people even on newer devices end up running Openwrt for 1 or 2 years on a device until it is supported with not super regular security patches. Most people after the support ends continue to run the device with no patches for a few more years. They eventually sell the device to somebody that keep using for even longer time. sometimes I wonder if relaying on the manufacturer's firmware may be a better option for some devices.

This is nothing OpenWrt can help with, unless you add mechanisms to forcibly disable the firmware after a set amount of time.

@Camicia

On https://openwrt.org/#why_use_openwrt Security is one of the bullet point. But I fell like that it is quite misleading.

Note that security not only comes from updating things all the time but also from providing a somewhat secure default configuration, from reducing the available attack surface, from providing source code access to at least have the theoretical ability to review and patch code and from giving the tools to lock down the system.

---

To summarize the discussion - lots of things you demand from OpenWrt here would exceed the level of support provided by distributions like Ubuntu or Debian with only a tiny fraction of the funding and developer resources available.

Did you ever wonder why you simply can't insteall Debian or Gentoo on a TL-WR1043ND or a Linksys WRT1900AC? It is because such embedded devices impose constraints on the distribution which render most traditional Desktop world processes unusable while simultaniously require a lot of specialized developer knowledge.

Such specialized knowledge is rare, even more so if its unpaid. And the people that do it for the "fun" of it will only do the things they deem interesting or worthwhile. Tedious grunt work and distribution maintenance will not attract developers, it requires monetary compensation or another motivating factor which I couldn't yet spot in these discussions.

Turning OpenWrt into a full-blown, LTS supported distribution with extensive regression testing and very narrowly focused future development roadmaps will exceed the capabilities of the current contributor base.

Implementing such a distribution requires a lot of professional organization and appropriate incentives which I simply do not see in the immediate future.