NetworkManager won't share network interfaces, which is a problem

February 20, 2024

Today I upgraded my home desktop to Fedora 39. It didn't entirely go well; specifically, my DSL connection broke because Fedora stopped packaging some scripts with rp-pppoe and Fedora's old ifup, which is used by my very old-fashioned setup still requires those scripts. After I got back on the Internet, I decided to try an idea I'd toyed with, namely using NetworkManager to handle (only) my DSL link. Unfortunately this did not go well:

audit: op="connection-activate" uuid="[...]" name="[...]" pid=458524 uid=0 result="fail" reason="Connection '[...]' is not available on device em0 because device is strictly unmanaged"

The reason that em0 is 'unmanaged' by NetworkManager is that it's managed by systemd-networkd, which I like much better. Well, also I specifically told NetworkManager not to touch it by setting it as 'unmanaged' instead of 'managed'.

Although I haven't tested, I suspect that NetworkManager applies this restriction to all VPNs and other layered forms of networking, such that you can only run a NetworkManager managed VPN over a network interface that NetworkManager is controlling. I find this quite unfortunate. There is nothing that NetworkManager needs to change on the underlying Ethernet link to run PPPoE or a VPN over it; the network is a transport (a low level transport in the case of PPPoE).

I don't know if it's theoretically possible to configure NetworkManager so that an interface is 'managed' but NetworkManager doesn't touch it at all, so that systemd-networkd and other things could continue to use em0 while NetworkManager was willing to run PPPoE on top of it. Even if it's possible in theory, I don't have much confidence that it will be problem free in practice, either now or in the future, because fundamentally I'd be lying to NetworkManager and networkd. If NetworkManager really had a 'I will use this interface but not change its configuration' category, it would have a third option besides 'managed or '(strictly) unmanaged'.

(My current solution is a hacked together script to start pppd and pppoe with magic options researched through extrace and a systemd service that runs that script. I have assorted questions about how this is going to interactive with various things, but someday I will get answers, or perhaps unpleasant surprises.)

PS: Where this may be a special problem someday is if I want to run a VPN over my DSL link. I can more or less handle running PPPoE by hand, but the last time I looked at a by hand OpenVPN setup I rapidly dropped the idea. NetworkManager is or would be quite handy for this sort of 'not always there and complex' networking, but it apparently needs to own the entire stack down to Ethernet.

(To run a NetworkManager VPN over 'ppp0', I would have to have NetworkManager manage it, which would presumably require I have NetworkManager handle the PPPoE DSL, which requires NetworkManager not considering em0 to be unmanaged. It's NetworkManager all the way down.)


Comments on this page:

By Andrew at 2024-02-21 02:17:43:

I suspect that NetworkManager applies this restriction to all VPNs and other layered forms of networking, such that you can only run a NetworkManager managed VPN over a network interface that NetworkManager is controlling.

I don't think that's true. I don't do things this way anymore, but I used to have eth0 managed by ifupdown (and marked "unmanaged" in NM), while using NM-managed VPNs (because they were only transiently connected and that was the easiest way to do it). It never complained.

PPPoE may be different for silly reasons, I have no experience with it.

By kim s at 2024-02-21 13:14:23:

I've found Network Manager to be annoyingly inflexible. For example, my wired interface was configured as a bridge (for virtual machines), and it refused to touch that. And it didn't work well for DHCP interfaces with some static settings, and always wanted to rewrite resolv.conf. Also, corporate policy prohibited network passwords being saved on disk, but I don't recall being able to get it to prompt for but not permanently store the password.

For wi-fi, it turns out that it's not difficult at all to script wpa_cli. A reasonably simple shell script can send a GET_PASSPHRASE request to gpg-connect-agent and feed the result to wpa_cli (but then getting it to run dhclient or whatever takes a bit of extra configuration as root). The authentication-free wired network was just done using Debian's "if-up" stuff, which is... kind of okay, if one remembers to put " || true" after the pre-up/post-up commands. I'd prefer to have something like Network Manager with good support for hooks, scripts, and similar customization, so I could fully configure a network without being root. I haven't found anything yet.

Written on 20 February 2024.
« The flow of activity in the ZFS Intent Log (as I understand it)
What ZIL metrics are exposed by (Open)ZFS on Linux »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Feb 20 22:55:01 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.