Are there any technical limitations for enabling WiFi driver updates via OPKG? I am not sure about other WiFi drivers, but mt76 specifically is under rapid development. To stay up-to-date with WiFi drivers it currently requires you to flash the latest snapshot images. In order to be able to use packages that you require, this requires you to compile your own firmware with the correct packages baked in.
While this isn't an issue for me (I have compiled custom firmwares many times), it does suck for less technically inclined people. And even for me, it does take away a certain amount of flexibility, since you cannot install new packages via OPKG. You either need to compile a completely new image, or you need to keep your own repository available.
I know upgrades via OPKG are generally a bad idea, since it can break stuff because ABI changes might not be compatible. However, for drivers this probably isn't an issue. It would also help immensely with testing. The mt76 drivers included in 18.06.2 are giving me and a friend also running a mt76 device many issues, whereas 18.06.1 used to be fine. The mt76 driver was updated multiple times in the 18.06 release branch going from 18.06.1 to 18.06.2. Regular updates via OPKG would have given 2 huge advantages:
Users on 18.06.2 could update their mt76 drivers to fix their issues.
Users on 18.06.1 would have gotten their mt76 updates as they became available, and users would be able to identify the commit that introduced the issue.
So my question are:
Are there any technical limitations that prevent driver updates via OPKG on stable branches?
Yes, kernel modules need to match the running kernel exactly - and the (micro-) kernel version differs between 18.06.1 and 18.06.2 (even more in master).
While it would be possible to build updated mt76 modules against the release kernels yourself (like @eduperez has been doing for mvebu/ mwlwifi), you'd have to do that yourself - at which point just building the whole image might not be much harder.
Agreed. That was one limitation that I was already aware of. But that isn't really a limitation per se. There's many kernel modules that already receive regular updates within the same branch. One example of this, is the Wireguard kernel module. I have updated Wireguard many times on the same branch, as it's generally advisable to keep VPN software facing the big bad internet up-to-date for security reasons.
My point exactly If this is possible, why is this done for for example Wireguard kernel module, but not for WiFi drivers?
Yes, you'd need keep recompiling kmods for all released versions and splice them in-place into the repositories. There is neither infrastructure nor tooling available to do that atm.
Maybe limit this only to the latest release, so in this case 18.06.2? This would make the most sense and give the most advantages in those cases anyway.
How is this being done for kernel modules such as Wireguard? Am I mixing stuff up? I could swear I have installed newer versions of the kernel module multiple times on the same image.
Gotcha. So I guess there is no easy way for non-technically inclined people. For people that do have the technical knowledge, it's probably easiest to simply download the OpenWRT SDK for a specific version (18.06.2 in this case), load the config.seed, change the kernel module makefile to point to the latest commit in the upstream repository, and compile said kernel module. The resulting file should then be able to be installed on the 18.06.2 device in question, correct?
I have tried compiling the mt76 kernel modules and succeeded. As part of my test, I opted to compile the same kernel module as included in the stock 18.06.2 image. The sha256 hashes do not match the sha256 hashes of the same kernel modules in the repository as checked here: https://downloads.openwrt.org/releases/18.06.2/targets/ramips/mt7621/packages/Packages
So, there's two reasons I can think off that caused this:
I screwed up somewhere.
Builds are not deterministic and the kernel module should be fine.
Care to elaborate whether packages are built deterministically or not?
Good catch! Unfortunately, the .ko file inside the .ipk installer also has a different hash, so it's not just the metadata. They do both have the same kernel hash dependency though, so it looks like they both built against the same kernel. I am just gonna try the installer and see what happens. Worst comes to worst, I will have to use recovery to revive the router. No biggy
If this is possible, why is this done for for example Wireguard kernel module, but not for WiFi drivers?