Considering that even high-end (mid-3 figure range) wifi routers often come with 256 MB NAND flash at most, of which around 20-90 MB tend to be available (for the overlay) after installing a basic OpenWrt, chances for this are zero from a mere (typically-) available flash space point of view to begin with. In-place upgrades require co-installability of (at least) libraries and kernels, the kernel side is out of the question due to bootloader constraints on the typical devices already (kernel needs to be in a dedicated, typically too small mtd, with very peculiar compression settings and size constraints), even if there are a/b dual-firmware slots, this won't allow in-place upgrades. The library side will fail quickly with -ENOSPC alone, before looking at the additional effort needed on the packaging side of things (which would amount to a paradigm shift and much more effort and checking needed). This would also require having kernel and rootfs on a writable filesystem, which is going to be difficult for the kernel (other expectations of the bootloader), but that also means no compression possible anymore (even less space) and no factory reset (see why easy recovering/ booting from removable media becomes much more important).
This is easy, if you are looking at x86_64 or SBC like platforms, with main storage measured in gigabytes, capable of booting (recovering) from removable media and platforms that allow grub-like bootloaders (or UEFI), but we won't be getting this luxury on common plastic routers for at least another half-dozen years (as even the most high-end platforms we see today, ipq957x or filogic 880 are miles away from supporting this, while x86_64 or SBC-like platforms continue to lack on the I/O side), so the point of when it might be conceivable to drop support for then-legacy platforms isn't even in sight.
Listening to Rust and LLVM has made me interested in Swift integration with OpenWrt. As a developer in the Apple ecosystem, I believe many others would also like to contribute useful functionalities to OpenWrt.
A simple way to edit/select the ports displayed in the "Port status" section of the "Status Overview" page in LuCI.
I have recently upgraded to FTTP from ADSL, and I still use the same modem/router unit.
The Port status section still shows the DSL Port, despite the fact that it is no longer used.
I can modify the behaviour through editting the /etc/board.json file, but not every user is comfortable doing this.
This edit is not retained during upgrades. To set that up needs deeper knowledge of the file structure over the different supported platforms.
Integrate ip6neigh or equivalent functionality into the core project.
This project allows the SLAAC based clients to properly work with DNS, esp with dynamic GUA prefix delegation.
This makes LAN based IPv6 usable but also allows things like Realtime Graphs -> Connections to show user friendly names for IPv6 connections.
Cool, hope it comes to fruition.
What would also be really helpful, would be Luci showing the contents of the config file(s) being changed real-time in Luci as changes are being made.
This would build a real familiarity with the config files and their relationship to Luci; what's going on under-the-hood so-to-speak.
This could be expanded to show the generated UCI command before finally becoming text in the config file, like what's shown in 'Unsaved changes'.
Centralised management would be good. I know there is OpenWISP but that feels like overkill for your typical home setup like mine where there's one device as the router and two devices configured in access point mode
It would be great if on first setup there was a simple wizard which let you choose if your device would be a single device or part of a cluster, if it's part of a cluster if it's going to be the main device or join an existing cluster and for the main device to be able to centrally configure the worker units interfaces, radios, services and display their status without hopping between multiple web interfaces
I wish a modern default theme and or the availability of more third party themes direct from the repositories, like the Argon theme.
Another topic that is feasible, but I think, very hard to do, is to implement the WiFi Alliance EasyMesh protocol. At least to set up nodes that use this standard but are not supported on OpenWRT to act as APs.
I know EasyMesh is not actual mesh, but a WPS setup with WDS and probably FT enabled. I know there is prplMesh and there are efforts to do that, but it would be amazing on OpenWRT.
A setup wizard could be amazing, too. Like many routers do when first set up.
I know it is hardware limitation but.
I wish the wifi-device and wifi-iface indexes were consistent across all devices.
For example, the wifi-device and wifi-face for 2.4GHz should always be indexed as 0, and for 5GHz it should always be indexed as 1 and so on.
This would allow for a predictable uci-defaults configuration:
# 2.4Ghz
uci set wireless.@wifi-device[0].disabled='0'
uci set wireless.@wifi-iface[0].ssid="OpenWrt-2.4Ghz"
# 5Ghz
uci set wireless.@wifi-device[1].disabled='0'
uci set wireless.@wifi-iface[1].ssid="OpenWrt-5Ghz"
With a lot of people moving from all-in-one setup to a router separate from access points, would be great is the downstream APs could be easily configured from the router.
I was thinking with the container support, perhaps like to start or for best integration in the network section of luci as well as being able to make 'interfaces' and 'devices' you would be able to make 'container' or 'network space' etc
I guess for this to work with the firewall as well you'd probably call the original non-container the 'main container' or something and then maybe in the gui, you'd have a drop down to switch containers but maybe although you could have a drop down, you could also just have it all listed out with color coding / boxes or what have you
Like many Linux distros: migrate to latest upstream efforts, polish existing features, and if time allows 1 or 2 'new' features per yearly release. Without getting into too much backend stuff:
25.xx wishlist:
Kernel: latest LTS (6.12?)
GCC: latest (14.x?)
APK (woot!)
LuCI: full polish pass on theme and features (shouldn't be too hard it's in a good place)
Full check on all default settings for performance/stability for new devices
Packages: polish pass to bring existing packages up to modern standards for javascript, nftables, etc. For example: Docker and mwan still installs iptables firewall code instead of nftables wtf? Do external drives properly dismount on reboot? Does HDD Idle work even after boot? Old yellow notification boxes at top of LuCI doesn't fit theme, etc.
WiFi 6 & 7: add options (driver dependent) in LuCI -> Network -> Wireless for: single WiFi sign-on with band-steering, 6/6E with OFDMA and Target Wake Time/Airtime Fairness (mt76 supports AF now), 7 with MLO.
Automatic firmware upgrade: owut features in LuCI, even if "power users" don't care, many users want this.
I also vote for "none of the above". IMO your efforts are best spent on continuous improvements to what we already have (which is a LOT) and keeping everything up to speed. As already mentioned, some packages need porting to nftables, for me personally it's mwan3.
Automatic updates / a rolling release on a router IMO wouldn't be worth the development and maintenance efforts. It's easy enough for everyone to build images on the firmware selector and flash them, sometimes jumping back and forth between stable and snapshot to test or use the latest features or fixes.
I think it would be interesting to have videos with clear voice overs on typical things people want to do with a router that are vetted by the community.
Start very basic like:
Video 1 would be how to get online for beginners. Start from a fresh OpenWRT install, setting the password then configuring WAN based on if the user has DHCP or PPPoE. Talk about how to enable wireless radios and configure SSID and encryption. That seems super basic but most people don't really need more than that and I know that some people think OpenWRT is daunting. However a clear and concise video can help break that barrier. Some people learn better visually.
If it proves to be successful then other ideas on things people want such as SQM with before and after examples for the gamer. Similar video here with other hardware/software got over 400k views so there is a need especially when it can be done in one router with OpenWRT.
A video on setting up mesh from scratch would also do pretty well. Title it something like: "An Eero killer mesh system for under $80??!!??" with the typical shocked face in the thumbnail.
