Community question: What do you want to see in OpenWrt?

Hi,

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.

  • Rust in OpenWrt core
  • LLVM integration in core
  • Notification System. See https://github.com/openwrt/openwrt/pull/13137
  • Replace usign/ucert with px5g based tooling
  • Replace more ucode with init scripts
  • Automatic firmware upgrades
  • mobile focused web interface
0 voters

I didn't know but I can't extent the poll anymore, sorry! I collect ideas below, please like the linked posts.

9 Likes

Pleasd add "none of the above" or "stabilise existing features"

30 Likes

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.

7 Likes

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.

24 Likes

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?

2 Likes

Do you mean like the snapshots of OpenWrt main, particularly when coupled with luci-app-attended-sysupgrade or owut?

1 Like

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?

3 Likes

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.

3 Likes

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:
303348102-7a53c5b6-e199-43f6-a539-ea0aff5b21eb

1 Like

Voted for mobile interface :+1:, 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.

Device Poco X6 Pro.

Browser: Brave

It's a small change :+1:

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?

1 Like

Wifi 7 with MLO across all 3 bands. I want openWRT to close the gap to the latest Wifi technologies.

5 Likes

The meeting notes say this:

However, the poll option appears to say the opposite:

5 Likes

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).

15 Likes

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!?

1 Like

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.

1 Like

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?

2 Likes
  1. Luci Remote managemet like
ssh -R 443:localhost:443 user:pass@<domain>

with static address for a user for free and end-to-end encrypted

  1. apt-mirror (debian linux) like package cloning and downloading system (local server)

  2. encrypted MAC address (need to be developed from the client side also)

  3. Some programming language compiler for small task (better than bash script)

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.

5 Likes

What I would like to see:

  • 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.

4 Likes