Helpfull error messages for plasma-nm

Brainstorm
1

Recently my partner tried to connect to a VPN and it didn’t work.
Usually, when something won’t work on a computer, one might search the internet for something related to the error message…
In this case (and other times when NetworkManager is involved - especially with VPN) the only error message is “Connection failed”. While this might be a correct statement, it does not help to find the cause of the failure.

I found out that I can see NetworkManagers log messages with
$ sudo journalctl -f -u NetworkManager

Unfortunately, these were equally useless.

The solution was to first raise the logging level with
$ sudo nmcli general logging level DEBUG domains ALL

(See this this for more information)

The question here is: how can we help the avarage user to get helpfull messages in case of an error?

Always setting the log level to debug is probably a bad idea.

One idea would be a button (maybe right of “Configure”) with a title like “Connect with info”.
Pressing it will temporarily raise the log level, start the connection attempt and show the relevant output to the user. Ideally with some highlighting and, where possible, easy explanations for messages that might be cryptic to non-IT folk.

Any other thoughts?

1 Like
2

Shouldn’t at least minimal details of a failure be visible unregarding of the log level? This thread itself stems from the fact that you didn’t receive enough information to understand where to start looking while using Plasma like a common user would do.
I suppose an error like this should at least point to where a deeper explanation (for example with a button for debugging like yours, improving the standard logs or creating a new section for this cases); forcing the user to guess that the necessary details are hidden to the common user just seems bad design.

3

That’s a really interesting observation - I do think, as @Samuele indicated, that the core issue is a process step that’s failing, but not by default producing enough diagnostic information when it does fail.

In this case, unless I’m mistaken, that’s happening in the upstream NetworkManager code itself, located a level closer to the core of the system than where plasma-nm sits.

It does look like there are adjustments at times to what NetworkManager logs at the default “info” level vs. the more detailed “debug” level - some kind of recent discussion and change examples are located here platform: increase log level for adding or deleting ip/routes (!1600) · Merge requests · NetworkManager / NetworkManager · GitLab and here ndisc: log DAD failures at info level (922ef434) · Commits · NetworkManager / NetworkManager · GitLab

I could very well be thinking of this wrong, but depending on what the actual needed information was in your case, perhaps it’s something that could be considered upstream?

2 Likes
4

Well… yes, you’re (probably partially) both right. A big part of the problem is that the relevant information is not visible per default in the NetworkManager logs. And this is something that should be fixed upstream.

So what I’m proposing is actually, in part, a workaround. But… as much as I prefer real solutions to workarounds, from personal experience with NM, I believe that in this case having the stupid workaround might be justified.

For a bit of background:

Limits of my knowledge:

  • After more than 20 years of linux and IT in general, I’m not really sure what a normal user would do in this case - I’m just guessing.
  • I don’t know much about NM’s internals and development - also some guesswork here.
  • I have no idea how plasma-nm determines what information to show to the user.
  • I don’t know how the normal user is supposed to view any NM-output outside of what plasma-nm provides.

My related experience in the last ~10 years:

  • Ethernet
  • Wi-Fi
  • Problems with setup and use of at least 4 different types of VPN and one LTE modem (part own use, part helping others).

The first 2 usually just work nowadays (unless my password is wrong).

VPN and the modem are the real pain points. The only error messages that I remember to have encountered in the user interface are: “Connection failed” and “Authentification failed”. But VPNs are too complicated for that to be enough!

A VPN configuration might have multiple variables that affect those:

  • is the user password wrong, or is it the group password?
  • or the group name?
  • does the connection need a user certificate?
  • does the servers certificate check out?
  • maybe the certificate format is wrong? Or outdated?
  • did I really choose the right protocol?

All this is made worse by the fact that the instructions, configuration file or certificates you get for connecting are often for:

  • a specific windows-only-client.
  • an outdated version of a specific linux-client
  • a specific linux client that has not seen any updates for more than a decade and is unlikely to work on your system.

Instructions/files will often contain entries with a name that does not match anything in the nm-plasma config UI.

So in order to set it up with plasma-nm, you might need to:

  • find out which of the >10 protocols to use
  • install the appropriate backend
  • map values to the right fields in the UI
  • convert values or files to another format

As a bottom line: setting up / debugging a VPN connection is often a huge PITA

Ok… nothing new here, I guess… so how does all that relate to the topic?
Just 2 kinds of error message are not enough to help - far more detail is needed, and it should be easy to access. The button (or alternative solution to show full debug level output) would make this much easier.
(That’s also the not-a-workaround-part)

Then there is the point of fixing things upstream:
There are multiple backends for multiple protocols and I guess at least that many developers. Some of them might not even use the vpn protocols anymore.
On top of that, there are countless combinations of configuration parameters on the server side, which may cause different error messages in the client backend.

With all that in mind, I do not believe that all messages from all combinations appearing on the right log level is something that will happen anytime in the next decade. Things might improve, but there will likely still be revelant information missing from the info level.

And lastly we might argue about how useful debug level messages are to average users.
I think it’s worth it because, even if the user might not understand them, they might ask a friend, or the IT admin of their company (who might not have any linux experience) or post in a forum. Making the messages easy to access makes the whole process much less frustrating.