A recent post talks about the best way to request diagnostic information from people who are having trouble. Here's the "standard template" that people have been using:
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
These instructions require a SSH connection (already unfamiliar ground for newcomers) and then copy/pasting the info into the forum, making sure to use code formatting, etc.
I added a comment about a getstats.sh script that issues a "standard set of commands" (easily adjusted) that covers most circumstances. It still requires a SSH connection, but the (one-time) copy/paste is easier...
If the script displayed the "right stuff", my hope was that it could be part of the default OpenWrt build. That way, the newcomer could just SSH in, run the script, and copy/paste the output.
But that now seems silly: why couldn't that facility become part of LuCI?
Good idea? Potential problems? Let's talk about options here... Thanks
I think the idea of a simpler way to get diagnostic information is a good idea. Especially if something can be worked into LuCi to allow similar output to be obtained.
My main concern is that, as it stands, the script provides a lot of information that is generally not needed (or that useful) for the vast majority of troubleshooting queries. While that can obviously be worked around by changing the commands it runs, you do end up with a 'one size fits all' approach to the data request. The alternative is to have parameters passed to the script to determine the output, but that feels the opposite of making the process simpler...
Having said that, if it were in LuCi and there were simple checkboxes to select the required data it might not be too much of an issue.
What would be really useful would be some 'automation' to redact the usual suspects (password, MAC addresses, public IPs etc). While it wouldn't be fool-proof, we know where to (generally) expect that data to be in the config files so can target those.
Balancing the information requested - I prefer a script that "gets too much" as opposed to going back and forth requesting more... It's painful to say, "Oh, that's not what I expected... Would you also send the output of X?" (The latter also means more work for both parties.)
Also, using a script means that the newcomer doesn't have to get a bunch of arcane commands right - they type a single command and copy/paste the results....
Yes - checkboxes in a LuCI page might work.
Yes - a LuCI page could "know" which credentials to mask
I attach sample output from getstats.sh taken from my OpenWrt One in the Details below. I don't claim that this is the be-all, end-all, but it does separate the various bits of data fairly cleanly, and you can skip over the parts that don't matter in this situation
I think that is a good idea. It doesn't help the people that can't connect to Luci, but at least the ones that can. They open that specific page and it will give them all the information to copy and paste to the forums.
First of all the users that we must use this on often explain the problem in so diffuse ways and make worthless screenshots from luci to begin with.
Or they don’t get how to include formatted text here in the first place and insert it as normal text in gigantic posts, the formatted text button doesn’t even work anymore since the last forum upgrade.
And luci is useless for faultfinding or even help anyone configuring even the smallest complex setup they want to do.
So they need to learn ssh anyway.
ubus call system board, this is pretty much only used to check if they are obligated for support to begin with or they are trying to sneak in support for non official firmwares or not supported hardware.
My goal for this exercise is to answer questions efficiently on the forum, by:
Minimizing the pain of writing instructions about how to collect data
Minimizing the multiplicity of steps people must follow to provide that data
There's nothing we can do about vague questions that arrive over the transom. But if we think we understand what might be happening, and want to get corroborating information, it's valuable to have an easy way to request it (and to receive it).
The "standard template" is a compact description of the steps, but it's surprisingly difficult for a newcomer to follow. Not only must they contend with SSH (see below), but they have a bunch of "Don'ts" (passwords, fixed-width fields, etc) that just scare people away.
As for SSH, it is and will always be a crappy way to interact with a computer. Its only saving grace is that it runs on every device. But having SSH is not a reason to avoid providing a better facility. I wrote a lot of background material on the SSH For Newcomers page: I'm painfully aware of all the hurdles and stumbling blocks that aren't even mentioned.
Finally, I give everyone here permission to ignore posts regarding un-official firmware or unsupported hardware. Having an easy reporting facility that gives accurate information about the device/firmware makes it easier to recognize "counterfeits"...
Careful with ps/ top here, passwords (PPPoE and WLAN, probably more (e.g. ddns, if you happen to call ps just while it's trying to update) in advanced setups) easily sneak into the parameters processes are called with and those aren't that easy to filter out reliably.
