A target state based function-oriented config wizard GUI would be very helpful for less IT savy users and would open OpenWRT to more users.
The current GUI is not result-oriented, but config-file-oriented. E.g. even with the current LuCi GUI, it is a very steep learning curve, to enable VLAN via GUI, enable a dump access point, enable a guest wifi and so on, as the current Luci is aiming at breaking everything down into smallest config items and being settings-oriented.
A separate web menu that detects and groups the network local config into operation modes and offers single-transaction actions like:
wizard, to add a AP logic part (imagine a clickable assistent, that does this in one transaction for a selected subset of the ports, leaving the initial default router config in place)
wizard, to add a repeater logic part
wizard, to add a routed network logic part
wizard, to enable VLAN on the switch part (enabling it and reconfigurin the LAN interface in one stop)
move an active port from one logic part to another part
add a guest/admin/dmz/2ndlan network incl. routing or NAT in a single function oriented GUI
...
the same could be done for often used application server parts, e.g.:
end-to-end wizard, to fire up samba server functionality, including adding usb driver, partitioning usb stick, adding share, adding a user, enabling samba trash bin. Currently setting up samba for a newbee is at least a 2-4h task.
don't get me wrong, it all can be done with the existing config files and Luci, but it is practically a niche for experts to do so.
If you look at a typical QNAP or Synology, how they offer to setup a samba share, you get an idea of what I mean. I do not mean to replace the current config GUI, but add some helper wizards for the common tasks that get requested all the time via Forum every day. (Kind of like an integrated clippy version of psherman )
OpenWrt comes with regional wifi database - nevertheless I could configure "impossible" bandwidth settings (e.g. 320 MHz 5G/6G, which is not allowed in my configured country or 160 MHz Wifi 2G... the radio does not start after such changes it seems) - or it should indicate if I configure outliers.
6G Wifi needs WPA3 - so it should propose it
I like to easily rename physical ports. E.g. I have wan and lan1, lan2, lan3 (this is correctly labled in luci as indicated on device) - but then I have sfp1 and sfp2, which are eth2 and eth1 (correct: numbers are even swapped)
The thing with Luci is that it has absolutely no control over OpenWrt whatsoever, Luci isn’t even necessary for OpenWrt.
Luci is only a simple OpenWrt HMI/GUI, nothing more and nothing less.
This is a bold question. And first of all let me state that I live the project and appreaxeare all the hard work.
There are a few things I would love to be added/changed.
But I think most of all a better UI experience.
Some stuff in some locations is not logical. And for simple stuff sometimes I need a manual to find the settings. Or I need to go to ssh.
I would like nothing technical.
My wishes would be to know more about how the future of OpenWRT is being secured and how growth and sustainability is being handled.
OpenWRT is an essential tool for repurposing otherwise dead network hardware so I think it is HIGHLY important to ensure its longevity and resilience against politics and other influences which could have adverse affects.
Things I worry could affect its future are: IOT laws, Rights to Repair, Copyright and Intellectual Property rights and so on, you get the idea.
My vote is for stabilizing existing features, especially when it comes to issues affecting the usability of already supported devices (example).
Minor wishes:
The webui could use a little polish when it comes to UX and taking advantage of modern screen sizes (small and large). Some documentation could be embedded into the webui as an installable package.
More responsive OpenWRT wiki and website, more documentation in the wiki. The experimental new TOH is a massive improvement from the old one.
Dev blog (What is being worked on? What are some interesting obstacles developers ran into?)
Thanks for sharing this link - a quite interesting approach.
Regarding unbound:
I come from pfSense and this project switched to unbound years ago (from dnsmasq).
Unbound is a validating, recursive, caching DNS resolver that supports DNSSEC, DNS over TLS, and a wide variety of other security options. It can act in either a DNS resolver or forwarder role.
Unbound is better suited for environments where security, privacy, scalability and advanced DNS features such as DNSSEC, ZONE handling, and DNS over HTTPS/TLS are required. It is particularly suitable for larger networks or more demanding applications where DNS is used as a critical infrastructure. In addition, unbound is excellently documented and is being further developed as a DNS server by a comparatively large team of developers.
If OpenWrt wants to continue to focus only on 128MB routers, than the project should stay with the existing dnsmasq - in all other cases I would advocate a change. Since OpenWrt published the OpenWrt One with 1GB RAM as a blueprint for an “ideal router”, I hope that something will finally change in terms of sizing. Personally, I think it's long overdue.
In the LUCI interface, I miss the ability to select the basic use of the device with predefined settings (turning off the firewall, turning off the DHCP server, ...). These are:
router
AP
WiFi client
Mash
,....
I wonder why LUCI does not include a WPS option in the wifi settings.
In the LUCI interface, I miss easier management of VLAN networks.
In the LUCI interface, I miss the built-in ROM memory expansion to USB media for non-essential or all applications that would work after the update.
Old devices that have too little RAM and ROM, there could be some micro images that would only work as a network switch, AP, wifi client, mash, ...
Network Bonding with two or more WAN's using MPTCP as a one-click addition - My team are working on bringing MPTCP to a point where it can be used for commercial / business use. We have called the project Bondingshouldbefree. Would be great to get some help as we are still in the beta, but we are pushing hard to get this to the masses and seeing as this is built for OpenWrt would be great to have it available directly in every router.
We have created a dedicated tab for bonding with options such as interfaces you want in the bond or don't and graphing showing multiple WAN's at the same time so you can get an idea of where the traffic is going on a single graph. Soon we will have priority for WAN's so that if you have a cheaper broadband link you can make this a higher priority.
We will look to include QoS across different WAN's (SD-WAN and so forth) but our main focus is for the average person on the street to be able to bond.
We currently have this working on the BPI-R4, but we will be expanding to additional routers in time.
Theoretically, you could do this with QoSmate. There's a UI tab similar to the Connections tab of the Realtime Graphs, where you can sort (as you can in the Connections tab) and filter by IPs or ports.
If you simply click the "refreshing" text (top right) in the UI, it will pause the polling, giving you the desired effect.
The feedback I received (when I asked the same question =P) was that when one expands their root/overlay partition to fit more addon software you will run into issues when upgrading.
Ah, ok. I did not know. I use image builder for x86/64 firmware and specify 2GB root partition during packaging. The rest of the SSD is a separate partition for containers, etc. Ie. you can install SAMBA, LXC, etc in root partition but configure them to use the extra partition for data.
Not a single issue sysupgrading in several years.
Wait, that's interesting. You are saying that by specifying a fixed partition size in image-builder you can sysupgrade using the resulting image and still make use of the extra partitions beyond 1 and 2? That would be worth some careful description in the documentation for x86.
Well, yeah. The very first time you got to burn the image manually and then create an extra partition. After that you just use a regular sys upgrade. One of the first sys upgrade steps is to check partition layout (actual vs in sys upgrade file) and if it is the same, it does not touch it and just writes the contents into appropriate partitions (first two). I think it even prints a message about partition layout matching.
It does not care about the extra partitions after the main ones and when the router reboots it uses /opt/ (in my case) for data for samba, lxc, etc.
)