Multi-AP. I don’t care about “mesh”, aka wireless uplink, personally, but I do care about the ability to do a competent multiple-AP deployment. Beyond just synchronizing configuration, I consider 802.11k, v and r to be table stakes. And I don’t mean “we use hostapd and you can, in theory, turn it on”. I mean actually deploying multiple instances, using an actual supported, documented and easy configuration, and ending up with a correctly configured network or three that actually work across APs near-optimally. And I should be able to configure and manage this all from one place. Heck, this should be the default configuration.
The fact that OpenWRT can’t do this is why I don’t use it any more. Otherwise I rather like OpenWRT.
There’s an open-source implementation of a WiFi alliance spec for Multi-AP called prpl that’s even based on OpenWRT. I’m sure it’s a mess and supports all manner of undesirable crap, but the good parts could be a good place to start.
That and so much that! Much as I like OpenWRT, it's still quite a pain to cover anything like an older (thick walled) house with more than one floor. I'm about to redo one of those networks as my Christmas holidays project and I dread the day I need to reconfigure the APs.
This seems a bit like saying “want to play pong on your gaming machine? All the groundwork has been laid and you can type apt install gcc. We even package SDL.”
Those docs convince me that someone has tried this and written some software, not that it’s anything like fully supported. Also, the same setup should get 802.11r, not just k and v.
DAWN wasn't flawless out of box about choosing bands, and would sometimes trash a bit... but it generally worked great for the 3x r7800's I had. And it would generally help band steer people to 5ghz in useful ways.
Usteer has everyone packed onto 2.4GHz. With very rare exception. It just doesn't seem to bandsteer well at all, in my view.
Agreed that this should be a top priority, so so much. Bandsteer and multi-AP are very similar problem-sets; even if users only have a single AP they need good steering to have a good experience. DAWN has started making that a reality (well before usteer) and continues to be the only viable open source option for people right now.
About a month ago I would've said the automatic upgrades. But a few weeks ago I tried to upgrade, my custom setup couldnt be resolved by the image builder (probably old software installed). I decided to backup, export the uci commands too and do a clean install. Setting up was super easy from the uci commands and it turns out the rest of my setup was not essential.
Then I had to join a vlan for my new ISP. That was a tough one! Evenings of reading threads and going through documentation and there was no clear answer. In the end I asked an LLM and the instructions were so easy, it made me wonder how I missed it.
So I would join some other calls in here for common setups.
I'd like to see more collaboration between OpenWRT and SBC makers like Banana Pi. While I love FriendlyELEC and GLi.Net for creating fantastic OpenWRT hardware, I abhor the fact that I they use OpenWRT forks. As an OpenWRT user, I really want to just upload my config files and hit the ground running. Not interested in fooling around with the user interfaces of these 3rd party spinoffs.
I'd also like to see the Wiki examples supported by complete configurations. A lot of the routing examples don't show enough of what's actually required to make them work. Perhaps create complete configurations that can be applied to a virtualized OpenWRT instance?
Is it really a burden worth complaining about to overwrite the factory fork with OpenWRT? It takes five minutes of your time. You should be doing this regardless, even if it shipped with vanilla OpenWRT, because factory firmware is often outdated out of the box.
Just recenty I wanted to quickly create guest wifi on AP. After following a long guide from the official wiki, it didn't work. I probably missed something and could make it work, if I would invest some more time. But instead, I just enabled a hotspot on my phone.
Honestly, guest WiFi should be a one-click adventure, not a weeks-long trawl through dozens of outdated wiki pages and forum posts from years ago.
Pretty much anything other than the most very basic configuration is unduly difficult.
While it's certainly nice to have every conceivable setting availble to you, only a fraction of a percent of people even know what they're all for or how to apply them.
What OpenWRT needs most of all is for anyone to be able to walk up and find the button that does what they want. Even for technically advanced users and career programmers, OpenWRT is obtuse and confusing. You have to spend hours researching how to do anything even slightly more complex than attaching an AP to a LAN bridge.
Unfortunately, that seems unlikely given OpenWRT (and DD-WRT before them) seem to prefer tinkering than making user-friendly products. It's one thing if it's a simple functional UI on the cheapest hardware possible, but when people are flashing hardware that cost $100, 200, 300 or more, you could have just bought into a more functional ecosystem/OS.
Things like Unifi, Eero, and Mikrotik kind of obviate the need for custom firmware with bad UI. It's not 2006 anymore with Linksys WRT54GLs. Guest networks, meshing, tunnels, routing protocols, basic traffic shaping and policing -- these are all point and click or even automatic in these ecosystems to varying degrees, all for less effort than I think you'd spend on a WRT setup.
Maybe their future is in low cost embedded boards and not home prosumer gear?
1. Simple Multi-WAN support in the UI. Take a look at the Fresh Tomato UI for a good example of how to do this.
2. Easy tailscale support. If my router goes wonky, I really want to be able to get to it, and there’s no guarantee that I can connect directly through my upstreams.
The core foundation of OpenWRT is very solid. It needs items that make using and maintaining OpenWRT devices easier. A way to have centralized management of multiple devices (why do I have to manually update my SSID on every AP?). Make it easy to update (like Attended Sysupgrade). Make common 'extras' easy: setup a Wireguard VPN server, connect your network/wifi to a WG VPN, use DNS over HTTPS.
Disappointing that "rust lol" is the top option in the poll, and none of the other options are about usability or utility.
No one gives a single shit what language the thing is written in. What users care about is how monstrously complex and difficult it is to use OpenWRT.
Anything more complex than changing SSID and password requires trawling through two different outdated wikis and years-old forum posts. That's if your search engine can even find something other than thousands of people asking the same question over the years.
OpenWRT needs to be usable and approachable. Any random person off the street should be able to walk up and configure their network. Even for highly technical users it's a struggle to do anything.
It does not matter one single bit whether there's rust in the codebase if it's never run because no one can figure out how to use it.
Rust is not a feature. It's an implementation detail that absolutely no one cares about and does not affect the user in any way. I'm really sick of this shit.
Every item on the poll is something that I - as someone who has never used OpenWRT but might be interested in it to replace what I have now - do know know why I care. If I developed OpenWRT I'd have an opinion on Rust, but since I don't I shouldn't have an opinion.
You can't extrapolate with polls with so many votes. I'm here an hour after you and Rust is at 4%. There's only been 66 votes so far, I bet you just ran into it very early.
Very true. I recently wasted days trying to setup IPSec on OpenWRT with no success. IPSec support is broken into dozens of packages without proper dependency resolution. No GUI support. Sparse documentation, and what little documentation is out there is outdated and mostly consists of sample configs rather than true documentation. You see, OpenWRT likes to break configs from version to version and the docs are never updated. You can't follow documentation from upstream because OpenWRT auto-generates the package's config files from its own configs. Which are sparsely documented.
"Helpful" forum posts mostly suggested to "use Wireguard" with a notion that IPSec is an archaic protocol that is not worth anyone's time to support, and the user is dumber for trying to use it.
I give a shit what language the thing is written in. Right now it's c for uhttpd + lua for luci. I would prefer to cut as much of both as possible from firmware of devices on my network. Not only that, trying to write decent modern UI on top of this stack is not worth the hassle and it dramatically reduces number of people who can volunteer such work.
I remember configuring my openwrt router wasn't fun. I'd say there's room for improvement with the UX, but it's possible it's already been improved and I don't know about it. I haven't bothered updating to the latest available versions simply because I remember the initial setup being so time consuming. I'm afraid I'll lose something with an update and have to go through the trouble again. It's my own conundrum.
I used to be a openwrt contributor. It was never anything fancy.
Automatic firmware updates would be my vote if i could vote.
I wish they had add "next gen firewall" to the list. Go compete with palo, fortinet, or sonicwall. Be able to have threatfeeds blocking. Having those extra features would be huge.
Yes, a built-in updater would absolutely be my vote. The OpenWRT device knows exactly which firmware build it needs, so having it download the update directly would be much faster and less error prone than having me do it.
I'd still prefer to manually click to initiate the update on my schedule, but the process could be more streamlined.
Attended Sysupgrade seems like the solution for this. It looks at your packages, does a cloud build for your board with your packages and you can push a button to update.
Be aware if you're on snapshot, that the packaging situation is iffy right now. opkg is being replaced with apk, and there's some rough edges. I had a sysupgrade build that ended up with neither package manager, and the automatic tool doesn't currently work for doing new builds from an apk system.
My wishlist item would be less churn or at least replacements should integrate as well as the old version.
Thanks, I wasn't aware of that package. I'll try it out. It should definitely be added to the default install once the devs are satisfied that it is stable.
I don't think you realize how powerful OpenWRT is. It's a whole Linux environment where you can write your own shell scripts and schedule jobs, etc. If you have created a set of your own personal customizations over the years, then it is nice that you can bring them over onto any subsequent OpenWRT-capable router you buy.
How much do you trust them to get it right and do security patches? There's a chance D-Link's problems are common across vendors, and they're ones being honest about it.
1. Updates, every single router manufacturer abandons their routers within a few years, so you either keep buying new ones when the updates stop or you use open source firmware that extends that life until it's obsolete.
2. OpenWRT (and the others) expose all the features you need where manufacturers often simplify this or charge you extra for them. The hardware becomes use to utilise as you please.
I wish Netgear and others directly supported open source firmware like they did in the past.
Why would you want 2fa on your router? You really should never expose the management interface to WAN, it should be locked down to only your local network.
If you for some reason absolutely need to manage it remotely, that's why we have VPNs and SSH keys.
So that infected tv/iot device doesn't bruteforce your router's admin account. I know you could set it up so it stops listening on 0.0.0.0 and firewall exists, but having 2fa on web ui and removing ssh should bring good enough security without much hassle.
Why remove ssh from the LAN? Brute-forcing a cert-based login is unrealistic, and passwords should of course be disabled. You can add a passphrase to your ssh key to make it useless when stolen.
u2f and webauthn require https (https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...), don't know if it accepts self signed certs and IPs instead of fqdn. Also the auth is locked to the host, so if you use IPs, changing IP means you need to remove 2fa first and re-enroll after. IMO just using a 60+ chars password stored in your password manager + moving the admin access in a separate vlan is simpler and enough.
Last time I tried it (~5 years ago) I think that I had trouble wrangling all the antennas to get them to cooperate on 5ghz. Maybe I'm wrong- it was awhile ago.
Multi-AP. I don’t care about “mesh”, aka wireless uplink, personally, but I do care about the ability to do a competent multiple-AP deployment. Beyond just synchronizing configuration, I consider 802.11k, v and r to be table stakes. And I don’t mean “we use hostapd and you can, in theory, turn it on”. I mean actually deploying multiple instances, using an actual supported, documented and easy configuration, and ending up with a correctly configured network or three that actually work across APs near-optimally. And I should be able to configure and manage this all from one place. Heck, this should be the default configuration.
The fact that OpenWRT can’t do this is why I don’t use it any more. Otherwise I rather like OpenWRT.
There’s an open-source implementation of a WiFi alliance spec for Multi-AP called prpl that’s even based on OpenWRT. I’m sure it’s a mess and supports all manner of undesirable crap, but the good parts could be a good place to start.
That and so much that! Much as I like OpenWRT, it's still quite a pain to cover anything like an older (thick walled) house with more than one floor. I'm about to redo one of those networks as my Christmas holidays project and I dread the day I need to reconfigure the APs.
Of course this possible and working:
https://openwrt.org/docs/guide-user/network/wifi/roaming
Follow the usteer path.
This seems a bit like saying “want to play pong on your gaming machine? All the groundwork has been laid and you can type apt install gcc. We even package SDL.”
Those docs convince me that someone has tried this and written some software, not that it’s anything like fully supported. Also, the same setup should get 802.11r, not just k and v.
I tried usteer on my recent wifi rebuild/updates, and I am for sure sticking with good old DAWN instead. https://openwrt.org/docs/guide-user/network/wifi/dawn
DAWN wasn't flawless out of box about choosing bands, and would sometimes trash a bit... but it generally worked great for the 3x r7800's I had. And it would generally help band steer people to 5ghz in useful ways.
Usteer has everyone packed onto 2.4GHz. With very rare exception. It just doesn't seem to bandsteer well at all, in my view.
Agreed that this should be a top priority, so so much. Bandsteer and multi-AP are very similar problem-sets; even if users only have a single AP they need good steering to have a good experience. DAWN has started making that a reality (well before usteer) and continues to be the only viable open source option for people right now.
Something like Aruba Instant On would be awesome...
I’d be fine with just plain Instant where it can group up APs from one master. Instant On would just be icing on the cake.
About a month ago I would've said the automatic upgrades. But a few weeks ago I tried to upgrade, my custom setup couldnt be resolved by the image builder (probably old software installed). I decided to backup, export the uci commands too and do a clean install. Setting up was super easy from the uci commands and it turns out the rest of my setup was not essential.
Then I had to join a vlan for my new ISP. That was a tough one! Evenings of reading threads and going through documentation and there was no clear answer. In the end I asked an LLM and the instructions were so easy, it made me wonder how I missed it.
So I would join some other calls in here for common setups.
I'd like to see more collaboration between OpenWRT and SBC makers like Banana Pi. While I love FriendlyELEC and GLi.Net for creating fantastic OpenWRT hardware, I abhor the fact that I they use OpenWRT forks. As an OpenWRT user, I really want to just upload my config files and hit the ground running. Not interested in fooling around with the user interfaces of these 3rd party spinoffs.
I'd also like to see the Wiki examples supported by complete configurations. A lot of the routing examples don't show enough of what's actually required to make them work. Perhaps create complete configurations that can be applied to a virtualized OpenWRT instance?
Is it really a burden worth complaining about to overwrite the factory fork with OpenWRT? It takes five minutes of your time. You should be doing this regardless, even if it shipped with vanilla OpenWRT, because factory firmware is often outdated out of the box.
This is all true, but then I have to wonder if the fork of OpenWRT they're using has drivers for hardware outside of the mainline.
BananaPi dont make anything from what I see. SinoVOIP is one manufacturer but who will make up the boards Device Tree Overlays????
Leave it to poor saps on a Wiki to do it for them...
Raxda has tried to support some but they use a shitty old u-boot Linero tree like many of these joke boards.
Hello. Please upsteam your work and get rid of the 2017 Uboot tree. Geez
Streamline configuring common things.
Just recenty I wanted to quickly create guest wifi on AP. After following a long guide from the official wiki, it didn't work. I probably missed something and could make it work, if I would invest some more time. But instead, I just enabled a hotspot on my phone.
Both AP and router are on OpenWRT.
Honestly, guest WiFi should be a one-click adventure, not a weeks-long trawl through dozens of outdated wiki pages and forum posts from years ago.
Pretty much anything other than the most very basic configuration is unduly difficult.
While it's certainly nice to have every conceivable setting availble to you, only a fraction of a percent of people even know what they're all for or how to apply them.
What OpenWRT needs most of all is for anyone to be able to walk up and find the button that does what they want. Even for technically advanced users and career programmers, OpenWRT is obtuse and confusing. You have to spend hours researching how to do anything even slightly more complex than attaching an AP to a LAN bridge.
Unfortunately, that seems unlikely given OpenWRT (and DD-WRT before them) seem to prefer tinkering than making user-friendly products. It's one thing if it's a simple functional UI on the cheapest hardware possible, but when people are flashing hardware that cost $100, 200, 300 or more, you could have just bought into a more functional ecosystem/OS.
Things like Unifi, Eero, and Mikrotik kind of obviate the need for custom firmware with bad UI. It's not 2006 anymore with Linksys WRT54GLs. Guest networks, meshing, tunnels, routing protocols, basic traffic shaping and policing -- these are all point and click or even automatic in these ecosystems to varying degrees, all for less effort than I think you'd spend on a WRT setup.
Maybe their future is in low cost embedded boards and not home prosumer gear?
API for central management of APs. And a server instance to do this.
Absolutely.
That's one thing that ubiquiti and the like do very well.
Combine that with the openwrt wiki/databases and you can support a LOT of different hardware with different capabilities relatively easily.
1. Simple Multi-WAN support in the UI. Take a look at the Fresh Tomato UI for a good example of how to do this.
2. Easy tailscale support. If my router goes wonky, I really want to be able to get to it, and there’s no guarantee that I can connect directly through my upstreams.
I want to see de-coupled DNS and DHCP by default so I do not have to manually replace dnsmasq with odhcp and nsd.
The core foundation of OpenWRT is very solid. It needs items that make using and maintaining OpenWRT devices easier. A way to have centralized management of multiple devices (why do I have to manually update my SSID on every AP?). Make it easy to update (like Attended Sysupgrade). Make common 'extras' easy: setup a Wireguard VPN server, connect your network/wifi to a WG VPN, use DNS over HTTPS.
Disappointing that "rust lol" is the top option in the poll, and none of the other options are about usability or utility.
No one gives a single shit what language the thing is written in. What users care about is how monstrously complex and difficult it is to use OpenWRT.
Anything more complex than changing SSID and password requires trawling through two different outdated wikis and years-old forum posts. That's if your search engine can even find something other than thousands of people asking the same question over the years.
OpenWRT needs to be usable and approachable. Any random person off the street should be able to walk up and configure their network. Even for highly technical users it's a struggle to do anything.
It does not matter one single bit whether there's rust in the codebase if it's never run because no one can figure out how to use it.
Rust is not a feature. It's an implementation detail that absolutely no one cares about and does not affect the user in any way. I'm really sick of this shit.
Every item on the poll is something that I - as someone who has never used OpenWRT but might be interested in it to replace what I have now - do know know why I care. If I developed OpenWRT I'd have an opinion on Rust, but since I don't I shouldn't have an opinion.
You can't extrapolate with polls with so many votes. I'm here an hour after you and Rust is at 4%. There's only been 66 votes so far, I bet you just ran into it very early.
Very true. I recently wasted days trying to setup IPSec on OpenWRT with no success. IPSec support is broken into dozens of packages without proper dependency resolution. No GUI support. Sparse documentation, and what little documentation is out there is outdated and mostly consists of sample configs rather than true documentation. You see, OpenWRT likes to break configs from version to version and the docs are never updated. You can't follow documentation from upstream because OpenWRT auto-generates the package's config files from its own configs. Which are sparsely documented.
"Helpful" forum posts mostly suggested to "use Wireguard" with a notion that IPSec is an archaic protocol that is not worth anyone's time to support, and the user is dumber for trying to use it.
Hardly.
I give a shit what language the thing is written in. Right now it's c for uhttpd + lua for luci. I would prefer to cut as much of both as possible from firmware of devices on my network. Not only that, trying to write decent modern UI on top of this stack is not worth the hassle and it dramatically reduces number of people who can volunteer such work.
I remember configuring my openwrt router wasn't fun. I'd say there's room for improvement with the UX, but it's possible it's already been improved and I don't know about it. I haven't bothered updating to the latest available versions simply because I remember the initial setup being so time consuming. I'm afraid I'll lose something with an update and have to go through the trouble again. It's my own conundrum.
First thing I want to see is the ability to configure beyond the basic default settings.
Things that should not require configuring are Basic Common Criteria, WHONIX settings,
Configurable everything.
For now, I am cobbling something akin beyond Debian APT configuration:
https://github.com/egberts/easy-admin
Warning: Bash programming.
I used to be a openwrt contributor. It was never anything fancy.
Automatic firmware updates would be my vote if i could vote.
I wish they had add "next gen firewall" to the list. Go compete with palo, fortinet, or sonicwall. Be able to have threatfeeds blocking. Having those extra features would be huge.
Yes, a built-in updater would absolutely be my vote. The OpenWRT device knows exactly which firmware build it needs, so having it download the update directly would be much faster and less error prone than having me do it.
I'd still prefer to manually click to initiate the update on my schedule, but the process could be more streamlined.
Attended Sysupgrade seems like the solution for this. It looks at your packages, does a cloud build for your board with your packages and you can push a button to update.
Be aware if you're on snapshot, that the packaging situation is iffy right now. opkg is being replaced with apk, and there's some rough edges. I had a sysupgrade build that ended up with neither package manager, and the automatic tool doesn't currently work for doing new builds from an apk system.
My wishlist item would be less churn or at least replacements should integrate as well as the old version.
Thanks, I wasn't aware of that package. I'll try it out. It should definitely be added to the default install once the devs are satisfied that it is stable.
The main issues with the current upgrader is it doesn't install old packages and it can't migrate breaking config changes.
What?
No nftables?
They moved to nftables a release ago, fw4 uses nft under the hood, and there are hooks provided if you want to run your own rules.
https://openwrt.org/docs/guide-user/firewall/misc/nftables
Make it less confusing to setup VLANs
Do new consumer routers still "need" aftermarket firmware?
I don't think you realize how powerful OpenWRT is. It's a whole Linux environment where you can write your own shell scripts and schedule jobs, etc. If you have created a set of your own personal customizations over the years, then it is nice that you can bring them over onto any subsequent OpenWRT-capable router you buy.
How much do you trust them to get it right and do security patches? There's a chance D-Link's problems are common across vendors, and they're ones being honest about it.
Two reasons
1. Updates, every single router manufacturer abandons their routers within a few years, so you either keep buying new ones when the updates stop or you use open source firmware that extends that life until it's obsolete.
2. OpenWRT (and the others) expose all the features you need where manufacturers often simplify this or charge you extra for them. The hardware becomes use to utilise as you please.
I wish Netgear and others directly supported open source firmware like they did in the past.
That's a very subjective question. What do you want your router to do, and can it do that out of the box?
Beyond features, it's also about reliability and security.
You mean firmware for all the proprietary hardware they are full of like Wifi? Likely yes.
Easy way to set it up to run as a wifi access point by default, not as a router.
I am surprised (hardware tokens based) luci 2fa is not on the list, I would think it is table stakes at this point.
Why would you want 2fa on your router? You really should never expose the management interface to WAN, it should be locked down to only your local network.
If you for some reason absolutely need to manage it remotely, that's why we have VPNs and SSH keys.
So that infected tv/iot device doesn't bruteforce your router's admin account. I know you could set it up so it stops listening on 0.0.0.0 and firewall exists, but having 2fa on web ui and removing ssh should bring good enough security without much hassle.
Why remove ssh from the LAN? Brute-forcing a cert-based login is unrealistic, and passwords should of course be disabled. You can add a passphrase to your ssh key to make it useless when stolen.
What am I missing?
u2f and webauthn require https (https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...), don't know if it accepts self signed certs and IPs instead of fqdn. Also the auth is locked to the host, so if you use IPs, changing IP means you need to remove 2fa first and re-enroll after. IMO just using a 60+ chars password stored in your password manager + moving the admin access in a separate vlan is simpler and enough.
I just wanted to say - about the same time you commented on hacker news I commented on openwrt forum about this feature :)
https://forum.openwrt.org/t/community-question-what-do-you-w...
Ooh, nice! It's great to hear.
Last time I tried it (~5 years ago) I think that I had trouble wrangling all the antennas to get them to cooperate on 5ghz. Maybe I'm wrong- it was awhile ago.
wrt3200acm