based on yesterdays developer meeting I'm curious what people would like to see around OpenWrt. I'm specifically NOT asking for specific devices, but stuff in general. This can be something like a mobile friendly web interface, an automatic update service or whatever you can think of. I'll add a poll, too, so if you see your topic already no additional answer is required.
I'm not sure what is meant by "mobile focused web interface." The Luci theme "OpenWrt 2020" already works very well for that, in my experience. It's not installed by default, but it's easy enough to install from the repo.
I'd like to see an easier way to add useful configurations like guest wifi. The kind of this for example gl.inet firmware adds on top of openwrt.
I enjoyed setting it up on vanilla openwrt from scratch as you also learn things but it was also really handy setting it up on my travel router using gl.inets interface. That's why I am thinking on keeping one device on the vendor firmware and one on vanilla openwrt.
Would it be possible to move away from the existing upgrade procedures based on releases towards rolling release framework like in Arch Linux? I realise the need for flash changes may complicate this, but there may be ways to render this possible? Perhaps certain package upgrades would prompt a new flash?
Arch Linux doesn’t issue releases but rather one installs base system and then everything is updated on the fly using a single command according to a rolling release model. Kernel is periodically upgraded this way. I remember installing it once and a decade later everything still worked and was kept up-to-date. Amazing. I just wondered if something like this might have been possible in OpenWrt.
I remember how in Arch Linux single upgrade command to update everything worked so well.
Or are snapshots already the best approximation of this? One can’t upgrade packages without flashing new snapshot right? Could that be improved?
That's why I mentioned the existing add-on packages, luci-app-attended-sysupgrade and owut. The former is a GUI tool and the latter is CLI. They make it easy to check for firmware updates, request a firmware image with the packages you currently have installed, and preserve your existing configuration. Check out the links I posted.
You can even use them to upgrade all existing packages when there is no new OpenWrt version available (to avoid the soft-bricking that opkg can sometimes cause when upgrading packages). OpenWrt is also in the process of switching to the APK package manager from Alpine Linux, which will make it safer to upgrade packages in a live install without the risk of soft-bricking.
The danger with OpenWrt main is that major breaking changes can be suddenly introduced at any time. A safer middle ground for this would be to use release branch snapshots rather than main branch snapshots. For example, 23.05 snapshots and 24.10 snapshots. However, you would eventually still want to upgrade to a new release branch, which is when the bigger changes happen and when there may be more effort to migrate.
I had suggested this in „GitHub“, but maybe more attention will be seen here, so quoting myself:
„I also wonder about suggesting a language, that has an active translation prompt, since the explained phenomenon called – „the power of defaults“ is very real. One of two ways I could see this happening, if
A. The user's IP is identified in said country.
B. User selects the region in Wi-Fi settings.
If the country of origin has an translation package, then a small single time prompt will appear asking if they want to use insert language name here as the „LuCI“ system language.
This would be a very nice and highly impactful QoL (Quality of life) improvement, in my humble opinion.
What do you guys think?
I made a small example:
“
Voted for mobile interface , although some themes already are responsive and work on my phone, i don't mind of luci gets also more mobile responsive but maybe for a other time (not meaning huge changes).
The only issue i encountered are some luci fields in the firewall, when i have a dropdown to select a interface and then scroll it all the way down for manual input i cannot apply the field, pressing enter on the text field also does not apply it.
Is it technically feasible to organise flash in such a way as to facilitate partial flashes relating to upgrades of portions of the system rather than flashing entire system? Could that not bring advantages?
A wireless clients dashboard for all openwrt ap’s that can be installed on one ap as a package: for more than 2 ap’s (30 ap’s here) its difficult to diagnose/identify clients problems. Something like omada or grandstream but not too complex at the start, i will be glad to have only the clients signals, tx/rx stats and connection info (vht20/40/80 etc).
More clear longterm policy about kernel upgrades and stabilization of the rest of all open PR.
6.1 was supposed to be the best. But there are so many devices in ToH so we didn’t even implement them all before 6.6 was the best. And 6.6 was supposed to be so LTS so the developers was supposed to get a break from continuous kernel upgrades. And already before even 6.6 is in stable there is a new PR for 6.12!?
Last week I started experimenting with FIDO2 keys (yubikey, passkey etc.) and thought that it would be reall cool if I could login to openwrt panel using FIDO2 key. Openssh supports this natively, so I could configure this for ssh server. However www interface also exists and is very usefull. To my knowledge luci does not support FIDO2 keys. I wish there was package like 'luci-app-fido2' that would allow logging in to luci using FIDO2 keys. I think there could be two variants: a) FIDO2 key as second factor - you enter login and password and later authenticate with key; b) there are no text boxes for login and password just button 'log in using FIDO2' and pressing it would authenticate user.
This feature implemented + some wiki tutorial about the overall state of FIDO2 keys in openwrt.
That's still ambiguous. What is counted as an existing feature--only what is included out of the box in the default build, or also something that requires package installation?
I believe that for most users, a more streamlined upgrade process would be very much desirable. It doesn't have to be fully automatic, but it'd be great if OpenWRT could notify you when there is a new version (upon login that is) and update with the click of a button. Attended-sysupgrade kinda sorta already does this, but it'd be great if this functionality was embedded directly into OpenWRT core.
Apart from that, support for WiFi 7 hardware would be great, but I'm sure that is already being worked on anyway and it's more of a hardware feature.
more frequent updates to the LTS kernel in 23; there have been several high privileged vulnerabilities.
automatic firmware upgrades; for above
fixing features in the gui (struggling to properly bind ipv6 addresses to a device-I would like to forward ipv6 addresses to specific VMs on a machine)
more documentation on how to do things in the gui (may explain the ipv6 issue)
I have no idea why half of those items listed are even important. I can guess at Rust.