Can we add, not necessarily as a factor in classification, but at least as a column in the ToH something any debricking or reverting to stock ease?
It didn't seem an issue. It shouldn't take long or effort, and it doesn't require configuration.
The more I think about a novice-friendly install badge, the more I think it should be a human decision in the end.
Take, for example, the recent thread on the TP-WA701ND. Sure enough, it is "OEM GUI" that you can use to install the image, but apparently only after you use a hex editor on the OpenWrt-supplied image, download the image builder or build chain from OpenWrt, and re-checksum the result. https://openwrt.org/toh/tp-link/tl-wa701nd
Perhaps the database install method is used to eliminate devices from the novice-friendly badge, but a human can judge in both ways, "Yes, well, this one isn't really an OEM GUI setup, but it's bulletproof and meets all the criteria in that list, so it is novice-friendly." as well as declaring processes like the TA-WA701ND not novice-friendly,
(In my opinion, our OpenWrt proprietary tools don't get a "pass" and fall into the same category at the Linkgear tooling.)
1 Like
What is about the idea to extend flash with new cheap Winbond-Chips and 64 MB RAM which both is less than 2 dollars or focus to give EXTROOT with minimal Luci on Openwrt18.06 with FTP/NFS/CIFS-Support to extend the flash to a NAS or USB-Port?
There is still a need for the old devices. These are the only devices with working drivers for major 5 points in my eyes:
- wireguard (to have a fast, modern, simple and secure connection to your home network)
- mesh-networks (wifi)
- low power consumption (That's the major point for the "old" 432 devices)
- highest possible througput like I read with "Flow offload" / HW NAT (more than 40 MBit/s - 50 MBit/s, like the original FW often achieve around 80 MBit/s which is in my opinion still ok atm under the major focus).
- USB-Function for Print-Server/NAS/external Wifi-Extensions or to build a low power stand alone internet radio for example.
@suppenkasper0815 That's what "Difficult" means
You also should take the time to examine what devices like the GL.iNet AR300M-Lite can do for US$18, delivered. They check every point on your list, have 16 MB of flash and 128 MB or RAM, and come with OpenWrt installed at that price.
You also get what you pay for, that's one ethernet port and fast ethernet. The latter isn't a huge drawback for QCA MIPS chipsets however.
I agree with almost all the points listed.
I'm still concerned about newcomers. (A rule of thumb in software companies is that every hurdle/new step you introduce into the demo process cuts your success rate in half.)
What devices would fall off the "Recommended" list if we only allowed devices that could install OpenWrt directly from the manufacturer's web GUI? (e.g., disallow tftp, etc.) Thanks.
I would ask you to be explicit about the reasons you see for the "need for these old devices." Price? Speed of processing? Functionality? Thanks.
Immediately coming to mind are the GL.iNet offerings that have NAND (and also have 16 MB of NOR flash). They run current OpenWrt, but you can't sysupgrade from NAND to NOR (with any OpenWrt, that I know of), and OpenWrt can't support NAND on the ath79 platform until Linux 4.19 (upstream rejected the approaches currently used). This would eliminate several good low-cost and moderate-cost devices, as well as what I consider to be the only viable, dual-band, travel router on the market (the AR750S "Slate"). These can be flashed with the OEM U-Boot's GUI however.
Reminds me of myself some years ago: Wanted to get away from OEM software and compared ddwrt / openwrt.
Started with ddwrt because it offered some kind of Amazon One Click installation whereas openwrt seem rather complicated :- )
Add: Or was it the "missing" GUI after installation....not quite sure. Re-installation of packages after an upgrade for sure was a first unpleasent experience on Lede
Here is an early feature request regarding Backup & restore of additionally installed packages, feel free to vote ;- )
swarm..... javascript......
if humans were not humans..... ideally..... there would be a form..... when you update, stop using...... download, install....
say this form had 5 sliders
How long have you run this firmware
How easy was it to install / maintain
How many issues scale 1-10 with the device
How feature rich would you rate 1-10
etc.....
Now, let's say in this ideal world, all the TOH / User guide pages had similar feedback boxes / sliders.....
i.e. A user might hit 20 pages trying to hard reset a device..... 13 are not relevant because they are
-
Out of date
-
Incorrectly labelled
-
Plain wrong
What happens to them..... they stay waiting for the next guy to go through 20 pages....
Next
We have the converse, the pages that were the best... the ones that work stay are they are..... No higher rating..... No "confirmed current"...... etc. etc.
Now
Obviously the majority of this is impractical..... as i've described... I'd be the first one to opt out of "feedback" options....... etc. etc.
So...... a lateral approach to gather metadata discussed.... ( something with forum accounts.....transparent mostly ) can solve a great many of the documentation, focus and misinformation foibles.......
my 2c anyway.... what's the chance i'd remember / bother to go back to a url to click a single button that says "worked for me"..... next to none..... if only there was a better way.
The topic has for use in the title, but the discussion seemed to have steered toward the getting started side of it. Are you guys excluding the ease of maintenance for a reason? I know that this is not device specific, but I see three major obstacles for un-experienced people.
- Infrequent releases require users to build their own images. Some good manufacturers release upgrades monthly.
- It is very annoying to have to re-install all packages that are not a part of the default image (Adblock, DDNS, SQM, etc) every time.
- There are often config changes that have to be merged manually as there does not seem to be a requirement to have backward compatible config changes. Adblock is a good example of that when it fixed the adguard source. So is uhttpd that recently limited the number of concurrent scripts and I had to apply this change manually. The list goes on.
Getting people to use OpenWRT is one thing, but it is at least equally important to find a reason for them to stay. With a right touter it is easy to start and do the initial configuration. The problems start when the firmware needs to be upgraded.
1 Like
I see the Recommended / Limited / Difficult discussion as a simplified form of a deeper discussion "How do we educate users about what is good hardware to buy, and what are good expectations for that hardware to perform at?"
One thing I think is problematic is how difficult it is to do a sophisticated search in the existing simple table of hardware. Working with a few others in private messages we'll be able to have a machine readable CSV or SQL file you can grab from the openwrt.org website soon. It should be relatively easy to create a javascript based interactive recommender from that, one where you do things like set a slider to your internet download and upload speeds, and a checkbox for whether you want SQM, a checkbox for which install types you will accept, and type a few letters of the manufacturer's name, and it gives you a table with the hardware that fits your criteria as well as a plot of RAM vs Flash and maybe some kind of performance graph.
Having good estimates of the processing power and ability to route/SQM/wireguard/OpenVPN at various bandwidths is something I'd like to work towards, but at the moment, just using number of cores and clock speed and doing a rough-and-ready back of the envelope version would help a lot in managing people's expectations. I think lots of people are caught off guard by upgrading their internet speed and not having their router keep up.
@fantom-x in the mean time while I was writing the above stuff, you make some good points too. But I don't think most of your points are hardware specific, they're more about OpenWrt as a distribution, it can be difficult to upgrade a custom install unless you have built one yourself with all your favorite packages (a task most beginner or even intermediate users don't want to take on).
There was a partial solution on the forums at one point, a script that looked at all the installed packages and figured out which ones needed reinstall. Perhaps that function could be turned into a LuCI app, ie before an upgrade the database of packages is built, and then after an upgrade there's a button "install my old packages" or something that reads it and does the package install.
2 Likes
This is already being addressed in master with some new sysupgrade options related to capturing user-installed packages. It also includes, as I understand it, only capturing changes from default in config, not every file on the list. This should help to reduce flash consumption on upgrade.
root@OpenWrt:~# sysupgrade --help
Usage: /sbin/sysupgrade [<upgrade-option>...] <image file or URL>
/sbin/sysupgrade [-q] [-i] [-c] [-u] [-o] [-k] <backup-command> <file>
upgrade-option:
-f <config> restore configuration from .tar.gz (file or url)
-i interactive mode
-c attempt to preserve all changed files in /etc/
-o attempt to preserve all changed files in /, except those
from packages but including changed confs.
-u skip from backup files that are equal to those in /rom
-n do not save configuration over reflash
-p do not attempt to restore the partition table after flash.
-k include in backup a list of current installed packages at
/etc/backup/installed_packages.txt
[...]
2 Likes
I do know they are not HW specific, but measuring success by how many users can this project attract is probably misleading if the said users do not stick around.
The ideas here are great, but is it possible that the approach discussed in this thread is backwards? If the router is not easy to maintain, does not auto upgrade, does not merge configuration settings, etc., then that will be a source of frustration for the new and inexperienced users that seem to be the target audience here and could cause bad reputation.
Most people are expecting their devices to be self upgradable and just work. Attracting them to something that is not like that is a dis-service to the users at the very least. The most they are willing to do is the initial setup. Then they want to forget about the device. Educating users that they need to be more active supporting their routers is noble, but there is no infrastructure to make that easy.
If someone does not want to upgrade their router, I bring up an analogy with a broken door lock: would you fix it right away? The answer is always a resounding YES. Now, your router is a constantly degrading door to at least 2B neighbours and the Internet eliminates a need for a physical presence to force one's way into this door. This changes the answer most of the time, but then a few minutes later I lose them again (for good this time) while explaining how this needs to be done properly.
So, do you really want to attract inexperienced users knowing that most will not survive the OpenWRT experience? At best they will just leave their OpenWRT router as is and never touch it again, at worst they will go back to easy.
I think @fantom-x has some important points, that deserves a thread of its own. Like any product, there are many facets, while all related to achieving a common goal, many can be addressed somewhat orthogonally.
2 Likes
I completely agree. I just created a new topic specifically for this conversation: Maintaining an OpenWrt Router
Let's keep "Getting Started" ideas here in this topic, and put "Continuing Maintenance" ideas over there. Thanks!
I would add info about the ability to regulate the radio power output. One would not want/need the highest power output when living in a highrise building. Not using 2.4GHz band and lower power output of the 5GHz radio will limit the reach and the number of people who can see this the AP to try to hack into from the convenience of their home.
2 Likes
....and perhaps switch off wifi at night with luci-app-wifischedule. It is "intelligent" and won't switch off if you are still connected. You also spare about 1.5W and more ;- ) iirc only measured with 5ghz on/off, 2.4ghz off
1 Like