Well, not sure that is something that requires the main developers, as it could be mainly be done by us forum dwellers... (Say we whip up a script for such a video and maybe run it past the devs, assuming they are willing to weigh in, and then record it ourselves).
Personally, I prefer written text to videos (text is more time efficient), but I accept that this is personal taste and others might prefer videos.
3 Likes
The problem with video for these kind of instructions is that you can’t copy-past code, text or anything else.
So then you need to do everything manually anyway by memory from the video.
2 Likes
If you had pictures of the code on the pc screen at each step at least you can copy it.........Sort of relevant to your comment but the only way I was eventually able to flash AX3000T was by following the video showing his actual commands on the pc screen - the one done by "John"- I think Malaysian?
Otherwise due to my lack of cli ability I would probably have thrown the router out the door in frustration.......
Personally I would rather have written for the reasons you say but not when it assumes a level of ability which may not be present.
As I said, I prefer text over videos, but I might be in the rough here. My main point was intended to be, videos is something we should be able to produce ourselves, no need to bother the devs with...
3 Likes
Thanks for the suggestion. I think this is different from my idea, as it focusses on the build system rather than the package / config documentation I had in mind. But I found the "talk about documentation" subforum and will create a thread there.
1 Like
Maybe you have seen some OneMarcFifty videos on YouTube?
A shame he hasn't been around for a hot minute, but what he put up was excellent IMO.
5 Likes
I prefer text as well, but regarding that particular point, people can have can the video playing side-by-side next to their router settings (whether that's in a separate window, a second monitor, or a second device), and just pause and resume the video as needed in small, step-by-step chunks. There's still some memory involved, but it can be short term.
I'd say the biggest problem with videos is that they are much more difficult and time consuming to update than text, as new major OpenWrt versions are released. It's similar to hacking a Nintendo 3DS, where the best practice is to always follow the continuously updated written instructions at https://3ds.hacks.guide. The fact that OpenWrt uses a wiki for its documentation means more people are able to edit it with the latest changes (if they have an account).
There's also the issue of different languages. Machine translation of text is usually far more accurate and intelligible than the gibberish provided by YouTube.
People with visual impairment or poor literacy can use text-to-speech, braille displays, etc.
1 Like
I voted for automatic firmware upgrades. Provided this can (a) not lose configuration and (b) not lose custom packages and overwritten files - even if those are in the R/O OS image (ie. from imagebuilder or even outright custom build...). ie. this is basically impossible to accomplish.
But even in spite of these limitations, automatic upgrades still seems more interesting then everything else that was listed as an option.
As for features:
I'd love to see SMS read/write functionality on my OpenWrt running cellular router (ZTE MF 286A or 286D). There's some way to set it up, but it doesn't just work out of the box.
I would also like to see some better / easier to setup support for multi-uplink devices. For example an OpenWrt cellular router with a non-OpenWrt cellular router as a secondary/backup uplink. Automatic failover, and load balancing. And a repeat of this for VPNs. I'd love to be able to create a network vlan/SSID backed by a VPN, while other network vlan/SSIDs aren't. The sanest way to make this work likely involves putting things in network namespaces... so perhaps some sort of native veth / net namespace support?
3 Likes
Maybe an approach to new features where we log "how many things can we solve with this addition" ?
Examples:
-
Feature #1: Add a "monitor" option to interfaces.
- finds the gateway, remember it
ping -I <if> -c1 -W4every 5 seconds- if 3 pings in a row fail then delete all non-/32 routes belonging to the interface
- if 1 ping succeeds add the routes again
-
use case: WAN failover scenario
-
.
-
Feature #2: Add interface type "VRF"
- Plus a "Routers" or "Virtual Routers" screen after Devices and Interfaces in LuCI
- Details screen with a dropdown to select which interfaces are enslaved
- The default non-VRF just shows all non-enslaved interfaces as "enslaved"
-
use case: bridged AP with both guest and lan networks (2+ bridged networks)
-
use case: WAN failover with routing daemon to select path
Feature request #2 has more use cases logged, so should look at doing that first =)
2 Likes
I'd like to see more reviewing and merging or rejection of contributions, instead of leaving them hanging with no feedback.
4 Likes
I don't think automatic updates would work for me because I'd like to see notes before committing to a new firmware
1 Like
Might sound silly, but can we have version codenames like the old times?
1 Like
The apk version could be "annoying aardvark".
4 Likes
Any auto-update feature would definitely be opt-in.
1 Like
Maybe have a single page where you could actually see what's going on in all of the dozen (or more) important repos... I'm thinking right now about @wxop's improved ToH interface, and dreaming of something that could aggregate the various github mirrors, select "Commits", "PRs" or "Issues", then select by date range ("most recent 7 days", "last comment over 1 month ago"), plus all the other search/select/sort bells and whistles.
If you could filter down to a list fitting your personal competence or interests, then you're more likely to do a review (I know a lot of stuff just goes completely under my radar until someone @s me or I stumble across it here on the forums).
2 Likes
If you've taken any responsible IT course unless there's a serious vulnerability that has to be addressed you should always wait to see if anything happens before committing your network to a newer "open source" firmware. Sure, while usually they go through extensive testing, people are flawed.
I believe the real testing begins when a load of people uses it in the real world on live production systems
I don't particularly care for this survey. It is to narrow in scope and I think there is a wide range to things that would be useful and or cool.
One of the things I didn't see mentioned was building a better recovery system into OpenWRT. I know it is hard to do but it would be nice to have a way to rollback the system to a previous state. This is useful for updates as well as rolling back a bad configuration change. My idea is that you could use some sort of snapshot system to track changes and to allow for quick rollbacks. There could be a very minimal recovery partition with a simple image that boots the system. If that system fails to boot it could perform a rollback. I say simple but this would require a lot of engineering to get right.
Also I would like to point out that OpenWRT is made up of a lot of smaller projects. Because of that a lot of feature requests from users are really either package requests or feature requests on a smaller project
3 Likes
Do you mean better testing? I think better testing before production releases would be good. I know it is hard to test for a few thousand devices to maybe there could be some sort of beta program.
Maybe there could be a first setup wizard that allows selection of a set of preconfigured options.
2 Likes
The biggest downside of OpenWRT is how complicated the software updates are. This is where pfSense shines. I got so tired of having to compile my own images that I switched to UniFi. The software updates are beautiful, and the feature set caught up to OpenWRT. Yes, the devices are more expensive, but the ease of software updates is worth a higher price in my book.
If OpenWRT could automate software updates (while preserving the settings of all packages), this would make OpenWRT competitive with pfSense.
4 Likes