joukewitteveen / netctl

Profile based systemd network management
https://gitlab.archlinux.org/archlinux/netctl
GNU General Public License v3.0
176 stars 65 forks source link

Incomprehensible error messages when device is soft blocked #151

Closed jaseemabid closed 7 years ago

jaseemabid commented 7 years ago

Some dell machines seems to be soft blocking the wifi interface after resuming from suspended mode[1].

It took me a very long time to debug this issue due to the lack of error messages by netctl.

netctl switch-to $profile failed with the error Could not create a WPA config file for interface '$Interface'. Arch forum suggested deleting some temporary files from /var/run/network and that correctly took me to the next step, which said Failed to bring up the network for profile... This confirmed my intuition that netctl is not correctly checking for the capabilities/permissions before it tries to bring up the network.

Executing sudo rfkill unblock $interface unblocked the device and netctl could work fine afterwards. This also clarified to me why netctl-auto never worked for me. It would be awesome if netctl could do this check before it tries to bring up the network and ask users to use rfkill to unblock the interface.

PS: Debugging this was annoying as hell. I honestly cannot remember having to reboot a linux machine in a very very long time because some software maintained dirty state somewhere. My bash skills suck, otherwise I would have written a patch for you. Archlinux is often a horrible PITA to use and let's please not make it any harder than it already is.

Sorry for the rant. Thank you for netctl.

1: https://bugs.archlinux.org/task/46465

joukewitteveen commented 7 years ago

Have you tried including

RFKill=auto

in your profile (see netctl.profile(5))?

If you want to use it in combination with netctl-auto, you have to include it not in your profile file but in /etc/netctl/interfaces/<interface> (see netctl.special(7)).

That said, I am always open for suggestions regarding error message improvements. In this case, I don't really know how netctl should know that there is a problem with a blocked interface when it is not instructed to look for that. Maybe, though, the real problem is that some clean-up is not done properly (that would explain the inappropriate Could not create a WPA config file error message).

jaseemabid commented 7 years ago

Thank you for the quick response.

  1. Can we check for the existence of the file and not err if its there already?

  2. I assume a significant number of archlinux users use netctl; its almost the default option and a lot of them (including me) might have no idea what rfkill is or why it matters. Why cant RFKill=auto be the default? I'm trying to make it just work for users rather than them having to wade through config options. This is also worsened by the fact that the config might be generated by wifi-menu and most users wont look into it till something actually breaks.

jaseemabid commented 7 years ago

Can you also please provide a sample file for an interface along with the existing examples?

joukewitteveen commented 7 years ago

Thanks for taking the time to make netctl better!

  1. The existence of what file?
  2. It is a strong quality of netctl that it does not try to 'just work'. It either works when it is set-up correctly, or it fails. It will not try to guess what the user wants, as this may lead to hard-to-debug and easy-to-go-unnoticed problems. As a consequence, it will not get involved with rfkill unless explicitly told to. This way, a problem with blocking (such as the driver issues in the bug report you mentioned) surfaces quickly and is not masked by pretend-to-be-clever network managers. Moreover, by separation of concerns, wifi-menu cannot include RFKill=auto in its profile files. It can easily be added manually (netctl edit <profile>) or added to the interface configuration (/etc/netctl/interfaces/<interface>).

That said, a tool like netctl absolutely needs good documentation and good error messages. While error messages are relatively easy to improve, the same is not true for documentation. As you said, no one likes to wade through config options, hence documentation must be kept succinct. If you have any specific suggestions, let me know!

jaseemabid commented 7 years ago

By embracing 'try not to just work', you are making life miserable for your users. Wifi is something users have all rights to expect to 'just work' in 2017. I would not complain if netctl was an unpopular tool and users really picked it for themselves, but sadly this is among the recommended tool for arch users. And it is absolutely not fair to expect users to know everything about rfkill before they can setup their machine.

You can easily make rfkill=auto the default and save users the pain. I really don't understand why wifi-menu cannot do that. At least an error which says something about rfkill would have been great.

There isn't an example interface file (/etc/netctl/interfaces/<interface>) file provided with the source which users can at least copy and edit. I'm really forced to read through the entire interface manual to figure out what the config file is supposed to look like. Adding a default file will ease some pain. wifi-menu can generate this as well.

Life is too short for netctl. I don't care. I want software that just works for things as fundamental as network management. I switched to network-manager and it worked out of the box without having to read a single line of documentation.

joukewitteveen commented 7 years ago

Apparently, you do not care enough about the integrity of your system or the ability to debug software (by making all side-effects explicit) to be part of the netctl target audience.

As I said before, specific suggestions for improving the documentation of netctl are always very much appreciated.