From ArchWiki
Jump to navigation Jump to search

Add recommendation to install dhclient

NetworkManager tries to use dhclient by default but falls back to dhcpcd if dhclient is not installed.

However, if NetworkManager uses dhcpcd, NetworkManager does not terminate dhcpcd when systemd tells NetworkManager to shut down. See this mailing list thread.

I wanted to suggest some ideas here before making any drastic changes.

I think there should be a recommendation to install dhclient in the "Base install" section, above "VPN support". Installing dhclient is preferred because it plays nicely with NetworkManager. Also, dhclient requires no configuration for NetworkManager to use it.

If adding a recommendation in the "Base install" section is too much, I would at least like to add this issue to the troubleshooting section so others are not baffled by NetworkManager leaving dhcpcd running.

KlipperKyle (talk) 03:54, 10 April 2014 (UTC)

The behaviour is obviously intentional as per the provided systemd unit:
# NM doesn't want systemd to kill its children for it
Ideally this problem would be resolved in the NetworkManager itself, feel free to submit a bug.
-- Lahwaacz (talk) 06:28, 10 April 2014 (UTC)
Thanks, Lahwaacz. It appears the NetworkManager team already knows about the dhcpcd issue (Bug 723746).
Also, after more poking around it appears that dhclient is left running after stopping NetworkManager. However, NetworkManager actually restarts dhclient when NetworkManager starts up. (NetworkManager does not restart dhcpcd when initializing.)
Shall I add a section about dhcpcd not properly restarting to the troubleshooting section?
KlipperKyle (talk) 02:20, 12 April 2014 (UTC)
Adding a note to our wiki will not help to resolve the real problem - please add comments to the upstream bug report you referenced. They are missing the detail about KillMode in systemd unit.
Additionally, could you test if resetting KillMode back to default control-group actually works? I.e. create the following file:
-- Lahwaacz (talk) 09:06, 12 April 2014 (UTC)

0xdelta (talk) 07:52, 10 July 2016 (UTC)

I'm sorry to bump such an old thread, but there are still some issues with NetworkManager and dhcpcd: At university we use the "eduroam" wireless network. To make things short, I could not connect to the internet via NetworkManager/dhcpcd, but using the console worked. Finally I installed dhclient and edited the NetworkManager config to use dhclient, and that solved my problem. But that took some hours for me to find out (I'm kind of a newbie). It would be nice to mention that workaround in the Troubleshooting section, what do you think?
NetworkManager with dhcpcd didn't work because networkmanager is built without dhcpcd support [1]. AFAIK it's recommended to use dhcp=internal. –– nl6720talk 08:15, 10 July 2016 (UTC)
You're right. But even the internal dhcp client wouldn't work with eduroam. It always timed out after 45 seconds. 0xdelta (talk) 08:22, 10 July 2016 (UTC)

Does really NetworkManager need to connect to

In general I do not think it is wise to let admins know when and from where arch users that did not read this entire wiki page are online.

Until May 2018 the server even kept logs, and the wiki was updated to include the information of this fact only in 2017.

Frankly, I do not know what to think of the decision to enable this "feature" (captive portals are already managed by GNOME outside of NetworkManager I believe) by default.

This is one of those fact that let users lose trust in their distro. I do not know if I want to use Arch anymore after discovering this. Tallero (talk) 23:52, 29 December 2018 (UTC)

I don't think this is the place for this type of discussion. IMHO you should take it to mailing list or bug report, preferably suggesting an alternative. -- Josephgbr (talk) 00:26, 30 December 2018 (UTC)

Split DNS vs Conditional Forwarding

Although NetworkManager uses "Split DNS" in its documentation, Split DNS usually refers to "Split Horizon DNS" whereas "Conditional Forwarding" is specifically for what the documentation describes. Apollo22 (talk) 07:54, 12 May 2019 (UTC)

I don't know which is the correct term, but since NetworkManager's documentation uses "split DNS" it should at least be mentioned in the article. How about keeping the current section title "DNS caching and split DNS"? -- nl6720 (talk) 12:39, 12 May 2019 (UTC)
I just did a PR about this on NetworkManager, so if its accepted, I'll get back to you. Otherwise, it seems appropriate to keep the vocabulary used in the documentation. Apollo22 (talk) 12:54, 12 May 2019 (UTC)
PR accepted, should Split DNS remain in the section title ? I think it's better to only use 'conditional forwarding', maybe mentionning that the gnome wiki hasn't yet been updated ?
Go ahead and update every occurrence, including the title. But I think "split DNS" should be mentioned once, since the term has been used for a long time, at least until networkmanager with updated documentation lands in the repos. E.g. in the first sentence: NetworkManager has a plugin to enable DNS caching and conditional forwarding (a.k.a split DNS) .... -- nl6720 (talk) 10:16, 18 May 2019 (UTC)
I think using Template:Note was too much. Special:Diff/573605. -- nl6720 (talk) 09:28, 21 May 2019 (UTC)
Agreed, I prefer your version. Apollo22 (talk) 09:46, 21 May 2019 (UTC)

Explain that encrypting passwords requires nm-applet (or equivalent?) to be running

When using Gnome Keyring to encrypt passwords, several interfaces to NetworkManager (at least nmcli and nm-connection-editor) will only have access to the passwords if nm-applet is running (as apparently it is the entity communicating with the keyring, through libsecret). This can be surprising when trying to use NetworkManager outside of Gnome (e.g. in Sway, or without a graphical user interface), see for more details.

Unless mistaken, I think this would be worth mentioning in the NetworkManager#nm-applet and/or the NetworkManager#Encrypted Wi-Fi passwords sections. What do you think?

Wehlutyk (talk) 13:00, 27 May 2019 (UTC)