This is missing a very important item: how to configure the router in an easy way. Will anyone call setting up a guest network easy? Easy-peasy, right?!.
I think the initial configuration subject deserves a separate thread.
1 Like
Initial config is a good question, I think intelligent high level configurator apps could be a useful thing... Like a site that could ask you questions about your use case and then spit out a tar.gz of config files that meet your high level needs. Luci is much more low level "change this option, enable this switch port, enter an additional DNS..."
As I am the one responsible for the creation of this thread, I am gonna expand on the original points from the other thread. I see three main issues with maintaining a router and these are the reasons I would not recommend anyone I know to use OpenWRT unless they are technically advanced: I do not have time to maintain everyone's router and this is not a router that an average person can maintain even if it is properly installed by someone who knows how to do that.
Configuration changes between minor & major releases and due to bug fixes.
Be that new regex in Adblock or a new parameter in uhttp, there is no way of knowing about them. Well, besides spending tons of time in this forum, but that is not for everyone. I see several possible solutions
- For novice & advanced users: a Luci app (installed by default) that allows them to see a side by side and file by file diff between default config (left panel), their local config (right panel), and an editable view of the local file itself (bottom panel). The file could be edited by copying and pasting lines from the diff above. The comparison view would refresh as the file is being edited. There is no need to do any automatic merge or re-implement meld here; the file is only saved at the end.
- A new policy for the apps to not store runtime configuration in the config file. Adblock's regex is executable and enabling/disabling a filter is configuration. These must not be in the same file as the user should not need to know what regex is and when properly separated the regex could be deployed independently from config (like recently happened Adblock needed to fix adguard source: it required merging the changes form the default config file).
- A longer term solution is for each feature to become responsible for upgrading their configuration either quietly. Having said that, if #1 and #2 above are both properly implemented, this might not be necessary.
Releases
I saw a proposal to generate upgrade images two or three times a year. I can tell you right away, that that will not be an easy sell as a good security practice. The argument will go like this: everyone else is releasing upgrades every month and that means they are more secure! Perception matters a lot and infrequent releases will be perceived as less secure. I think there should be a dot or dot-dot release/build once or twice a month. Sun Microsystems did refuse to play the perception game (CPU frequency) and look where that got them 
Asking users to use daily release snapshots will be perceived as the having to use unreliable and untested firmware. They will always chose an easy and familiar way.
Upgrade/Release Images
The entire industry has conditioned the users that firmware is a single file and going against that is futile. No-one wants to have to mess with figuring out what packages to install to get some functions. I also think that trying to address this by reinstalling packages individually is very error prone. Turris Omnia failed to handle all corner cases by using opkg (for two years) and they totally changed their approach now.
It would be simpler and more beneficial to generate a few standard images with all the basic packages already built-in for the routers from the easy list. The default feature set can be taken from one of the mainstream routers. I personally like ASUS routers and maybe Synology. The configs should be created based on a specific use case and I only see three of those for home use so far:
- A router appliance only (and my personal choice): Adblock, DDNS, SQM, Statistics, Bandwidth Monitor, BCP38, maybe a few more basic packages.
- #1 + NAS
- #2 + Media Streaming Server
Everything else (including VPN) should be delegated to advanced users who know what they are doing. None of the off the shelves routers can provide good performance over VPN with OpenWRT anyway.
P.S. I do have some thoughts to share about the pain of the initial config, but I hope there is gonna be a dedicated thread for that.
Forgot to mention, that auto upgrade or one-click upgrades are also very important. This should not be as big deal to implement for the predefined bundles upgrading to the new version of the same bundle. But I know there are a lot of people who will tell me all the reasons why that is a bad idea
1 Like
Do you see a non-technical person appreciating this process and also knowing what to do with a tar ball? Adding more steps to the setup will turn some people away. More steps, more people will not complete the procedure. To be usable it got to be a wizard within the default firmware file. But this discussion should be in a separate thread.
Upload it to the LuCI restore backup function... that'd be spelled out with screenshots.
The point of what I'm thinking of is to dramatically lower the number of steps needed to get a more sophisticated level of function. Imagine if you could go to a site and click a few buttons to say "I want a main LAN and 2 separate guest LANs, with ports 3 and 4 part of guest LAN2 and port 1 a port that will connect to a further AP (ie. become a tagged trunk port) ... etc etc. The questions would be goal oriented rather than technology oriented (like whether you want tags on port 3).
But yes, this should go to a separate thread: how to get started, slightly different from maintaining
And until a dedicated thread is created 
I see no reason for this not to be included in the firmware as a module or embedded into a page. Doing so will eliminate the need to upload any files at all.
It all depends on the back end technology you need, if it's lightweight fine. I imagined using some more heavy hitting tech than what you might want embedded.
New topic created: How to make getting started with configuring easier
Hi fantom-x,
if you like can you please elaborate a little?
regards
I do not have a link, but I did quite an extensive research recently and came across a remark from a frustrated Turris team member about how many corner cases opkg could not handle and so on. You can search forum about all the auto update issues.
There are also a lot of posts about the nightmare of configuration merge during the upgrade. These are big issues to solve.
Here you go https://forum.turris.cz/t/reboot-fails-but-automatic-update-works-despite-being-disabled/4861/13
1 Like
Another way to handle configuration merge during an upgrade would be to redefine how the configuration is managed and used. Let’s say a uhttpd installed a default version of its config file under /etc/config (for backwards compatibility the same location should be used). This file cannot be modified anymore. All user changes go into uhttpd.user file in the same location and the runtime merges the config via inheritance.
This way a new parameter added to limit the concurrency of scripts that it runs will be delivered as a part of the default config and user settings will not have to be overritten. When the router reboots it will merge the new default config into the user file and the upgraded config will be the latest.
Adblock could change its regex anytime and it is delivered the same way in the default config file while the adblock.user stays unchanged.
2 Likes
The structure of the config files does not really lend itself to hierarchical / merge approach.
I think something like a sqlite could be used to keep all parameters and the config files can be generated based on the parameters.
But I think all these types of approaches limit the flexibility of openwrt. It becomes like OEM hardware that is factory configured for one role only.
2 Likes
This will simplify a life of a developer at the expense of usability, yes.
No, if your an advanced user with many demands then just edit the config files yourself.
If your a novice and just want a wizard like experience then a user interface that keeps your settings in a database to be used for generating config files now or after an upgrade seems like a reasonable approach.
Especially now that low memory devices are getting phased out and newer devices have more resources to include nice UI features.
https://www.freebsd.org/cgi/man.cgi?mergemaster(8)
~40 kB
pkg updating is equally interesting, alerting users as to any changes in ports that they have installed that might require more than just an install.
Of course, none of this is really appropriate for the 4-8 MB crowd.
Yes. I just updated the OP to say that I would only insist that these improvements be available to Recommended devices. (People using "limited" or "difficult" routers will have been forewarned, and any niceties that come to OpenWrt may not be available to them.)
The structure of FreeBSD is very good indeed.
I wonder if this thread gonna be resolved like the one below and several other similar threads...
LEDE is not consumer software: LEDE is death hole for consumer
According to the FAQ on the Wiki:
Is OpenWrt suitable for me?
OpenWrt is primarily intended for power users, networking enthusiasts, wireless communities, and embedded device developers.
OpenWrt's default configuration, with the luci web interface, is a big improvement over the stock firmware of most wireless routers and similar devices. It provides all of the functionality most people will need. Additional packages can be installed with just a few clicks, to provide extended functionality if needed. A command line interface is also available.
I dare to say that “most consumers” don’t fall into that category. The group of people that do fall into this category still might need help/support but it will be on a completely different level.
Handling kernel updates, package updates etc while keeping all the configurations might just be to much for “embedded devices”. If you start targeting the high end devices for these features that would leave an even bigger group of people / devices behind than just cutting the 4/32 devices as discussed in another thread.
Doing a full update might only be suitable for those “dual boot” devices where the configuration can be (automatically) copies & pasted from the “other partition”. With a failsafe in place should this fail. Any package updating/adding settings should have its own script to handle those changes.
2 Likes