Score:3

How do I set a network device to be managed?

in flag

My ProtonVPN connection keeps breaking. I'm using Ubuntu 18.04. ProtonVPN informs me that the issue is with Ubuntu, they won't help me fix it, and that I should post here. This is a cross-post of this Unix SE question.

Right now, in the broken state, the two ProtonVPN device profiles proton0 and ipv6leakintrf0 are listed as "unmanaged" and "disconnected", respectively, by nmcli:

$ nmcli d
DEVICE          TYPE      STATE         CONNECTION 
wlp3s0          wifi      connected     WifiAP
ipv6leakintrf0  dummy     disconnected  --         
enp2s0          ethernet  unavailable   --         
lo              loopback  unmanaged     --         
proton0         tun       unmanaged     --

ProtonVPN support has not been able to resolve the issue after working on it for nearly two months, but they did inform me they don't support unmanaged connections. So, I'm struggling on my own to make both proton0 and ipv6leakintrf0 be "managed".

From what I can piece together from the NetworkManager configuration documentation, NetworkManager configures devices from the following sources, in order:

  1. /usr/lib/NetworkManager/conf.d/
  2. /run/NetworkManager/conf.d/
  3. /etc/NetworkManager/conf.d/
  4. /etc/NetworkManager.conf
  5. /var/lib/NetworkManager/NetworkManager-intern.conf

Within the three directories, files are parsed in their listed order. On my system, the file /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf exists and contains the following directive:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan

This appears to set all non-wifi and non-wan network devices to "unmanaged", which would explain why proton0 and probably ipv6leakintrf0 are unmanaged. However, given how poorly-designed the NetworkManager UX is, there's no way for me to be certain that subsequent configuration I don't understand isn't overriding this directive.

I searched the above configuration list for another unmanaged-devices directive and found none, so I can only assume the one in 10-globally-managed-devices.conf is the only one. In that case, it seems like I could correct the problem and make proton0 a managed device by creating a file /usr/lib/NetworkManager/conf.d/80-proton-vpn.conf with the following contents:

[device]
match-device=interface-name:proton0
managed=true

[device]
match-device=interface-name:ipv6leakintrf0
managed=true

where I've pieced the syntax together as best I can from the poor documentation linked above. I restarted network-manager. ProtonVPN worked for several days before breaking again, giving the $ nmcli d output shown above that indicates proton0 (and probably ipv6leakintrf0) are still unmanaged, despite my best efforts at changing the config.

This AskUbuntu answer indicates that the listing of a device in /etc/network/interfaces will cause it to be unmanaged by NetworkManager. In my case that does not apply, the only contents of that file are

$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

I've also tried explicitly excepting the ProtonVPN devices in 10-globally-managed-devices.conf as suggested by a comment on the Unix SE post I linked above:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:interface-name:proton*,except:interface-name:ipv6leakintrf*

After restarting network-manager, this config made no change in the problem.

What else do I have to do to make these device profiles be managed by NetworkManager?

Edit

For the question "How do I set a network device to be managed?", the answer to start with is:

"Run the command

$ nmcli device set <name> managed yes

where <name> is the relevant entry under the DEVICE column of the output of $ nmcli d."

I've been working on this problem for such a soul-drainingly long time that I forgot to include the results of doing this. Here they are:

When I run

$ nmcli device set proton0 managed yes

it does not affect 'proton0' in any way. The output of $ nmcli d continues to show 'proton0' as "disconnected" (because I can't connect), and the output of $ nmcli device show continues to show 'proton0' as having GENERAL.STATE: 10 (unmanaged).

'ipv6leakintrf0' has appeared and disappeared throughout the troubleshooting process. I don't know why, but ProtonVPN support didn't find it noteworthy, so I assume it's expected. When it exists, running

$ nmcli device set ipv6leakintrf0 managed yes

has no effect. The output of $ nmcli d continues to show it as "unmanaged". When it doesn't exist, running the $ nmcli device set command returns the error Error: Device 'ipv6leakintrf0' not found., which seems normal. It currently does not exist.

extra info

Here is the 'proton0' portion of the output of $ nmcli device show:

GENERAL.DEVICE:                         proton0
GENERAL.TYPE:                           tun
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            1500
GENERAL.STATE:                          10 (unmanaged)
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               off
David avatar
cn flag
Is it possible to try another VPN provider just for a short time to test?
Darien Marks avatar
in flag
@David Working on that with Mozilla VPN. Currently waiting on their support team to respond for a different problem installing that.
Sebastian avatar
in flag
I am using ProtonVPN on Ubuntu 18.04 without any problem. I have the same entries in the `10-globally-managed.devices.conf` and `/etc/network/interfaces`, so I doubt that this is the problem. I assume you went through log files and disabling any additional functions like Killswitch, Netshield, Split Tunneling with Proton support already? Have you tried downloading their *.ovpn config files and loading those directly with openvpn?
Darien Marks avatar
in flag
@Sebastian I've done all of ProtonVPN's procedures many times. They suggested the OpenVPN thing, too, but I haven't tried it because that's not what I'm paying them for and because I expect OpenVPN to be the same type of user-hostile nightmare all of my dealings with unfamiliar open source software always turn out to be.
Darien Marks avatar
in flag
@sancho.sReinstateMonicaCellio Thank you for compiling that information, but I can't tell that you're suggesting anything. You link to the Udev Properties portion of the documentation, but as far as I know, I'm already forcing a managed connection via Network Manager configuration, so without a more explicit explanation, I don't know what you want me to do
sancho.s ReinstateMonicaCellio avatar
Well, I was actually suggesting a couple of things: 1) Compare your `10-globally-managed-devices.conf`, try using my version, post if you see anything worth reporting. 2) Compare your `/run/NetworkManager/devices/...` files, post if you see anything worth reporting. 3) Post the output of the command I listed. 4) Try using `nmcli device set...`, post if you see anything worth reporting. And I added a 5th action. If you have further doubts, please comment.
sancho.s ReinstateMonicaCellio avatar
PS: Sometimes an answer comes in a full, detailed, and specific list of commands/actions. Sometimes it comes as hints, partly because of the lack of full info on your system or because of a lack of absolute knowledge on the answerer. These answers may report possible directories/files to look for, information that has to be compared with what you have, etc., and that can set you on track to the final solution (requiring further research on the side of the OP). I wonder why you do not see this as: 1) a valid answer, 2) useful. Plus, posting requested info can help others help you.
Darien Marks avatar
in flag
1) There is no relevant difference between your `10-globally-managed-devices.conf` and mine. 2) Instead of files called `18` and `19`, I have files with different numbers in the `/run/NetworkManager/devices/` directory. That's not unexpected, since I imagine they're named randomly on each system. What I need is a way to determine which ones are related to ProtonVPN. Since my VPN doesn't work, I can't compare files between the connected and disconnected states like you can. Lacking any other method, I don't know what I'm comparing, so this is a dead end.
Darien Marks avatar
in flag
3) The output of `$ nmcli device show` is over 160 lines, and I'm certain most of those are not relevant. Including this would add a massive amount of clutter to the page and risk accidentally posting sensitive information, since the output is largely gibberish to me and I don't know what information it represents.
Darien Marks avatar
in flag
3) (continued) If there's a particularly useful subset of lines I could vet and post, I'd be happy to. I've edited my post to contain the 'proton0' section, for example. But better yet, you could explain what information I'm looking for and how it helps answer the question "How do I set a connection to be managed?", which would help not only me, but anyone in the future who finds this page by having the same question, and who can't all post their output for your review.
Darien Marks avatar
in flag
4) Your original post linked to the Network Manager documentation with little further explanation. Like all open source documentation, this documentation is unreadable dogshit. In particular, it was not clear from the author's presentation that the `nmcli device set ...` line was intended to be a terminal command rather than a line of configuration in `NetworkManager.conf`. Thank you for the explanation you added, it was extremely helpful in communicating what you wanted me to do.
Darien Marks avatar
in flag
4) (continued) In fact, I ran these commands many times while working with ProtonVPN on the issue. There is no output from them directly, but after running them the output of `$ nmcli d` shows that the 'proton0' device profile remains "disconnected", while the 'ipv6leakintrf0' remains "unmanaged" or else doesn't exist (it seems to come and go). I tried them again just now and got the same result.
Darien Marks avatar
in flag
5) As far as I can tell, there's nothing in `/etc/udev/rules.d/` that would relate to ProtonVPN or VPNs in general, only to my printer and to `snap`.
sancho.s ReinstateMonicaCellio avatar
1) Ok. 2) Files in `/run/NetworkManager/devices/`: "What I need is a way to determine which ones are related to ProtonVPN"... check modification times, as mentioned in my answer. They *seem* to correlate with connecting/disconnecting ProtonVPN. I don't know if this is true in your system.
sancho.s ReinstateMonicaCellio avatar
3) Output of `$ nmcli device show`: As mentioned above, this is one of the cases where I am not certain what information is valuable, until I don't see it. You can post whatever you consider (and this could be *nothing*, but if so it is good to state this clearly) a good balance between privacy, brevity (there is always pastebin), and expectation that it *might* be useful in the process of solving *your* problem.
sancho.s ReinstateMonicaCellio avatar
3) (cont) Whatever I know with certainty, I post it. Otherwise, I work by successive approximations. As a general rule, expecting that people answering are all Ubutnu gurus that will hit the nail in the head in the first hammering is not realistic, AFAICT.
sancho.s ReinstateMonicaCellio avatar
4) I am always available to clarifying (and I do so more happily when the request is somewhat more "polite"). 5) It is most useful to chain all added information in the OP, instead of scattered in comments. And I regret you didn't solve your issue. If I find anything else, considering your added information, I would post again. Still, no warranties on having all details and precision you seem to expect.
Score:2
pl flag

This is what I have

$ cat /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf 
[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma

I have two devices which I am certain they correspond to ProtonVPN, since their modification date are affected by connecting/disconnecting

$ cat /run/NetworkManager/devices/19
[device]
managed=true
connection-uuid=...
nm-owned=false
$ cat /run/NetworkManager/devices/18 
[device]
managed=true
perm-hw-addr-fake=...
connection-uuid=...
nm-owned=true
route-metric-default-effective=550

When I am disconnected, they look like this

$ cat /run/NetworkManager/devices/19
[device]
nm-owned=false
$ cat /run/NetworkManager/devices/18 
[device]
managed=true
perm-hw-addr-fake=...
nm-owned=true

I guess they are not meant to be manually modified, but this may help.

Please post the output of

$ nmcli device show

Also, forcing managed connections as shown in https://developer-old.gnome.org/NetworkManager/unstable/NetworkManager.html may help

Udev Properties

udev(7) device manager is used for the network device discovery. The following property influences how NetworkManager manages the devices:

NM_UNMANAGED If set to "1" or "true", the device is configured as unmanaged by NetworkManager. Note that the user still can explicitly overrule this configuration via means like nmcli device set "$DEVICE" managed yes or "device*.managed=1" in NetworkManager.conf.

So please post the result of using

nmcli device set proton0 managed yes
nmcli device set ipv6leakintrf0 managed yes

as shown e.g. here.

And check with ls -al /etc/udev/rules.d/ if there is any udev rule that may tell Network Manager to stop controlling an interface

Nate T avatar
it flag
Great answer! I like how you made it robust by offering alternate solutions at the end.
Darien Marks avatar
in flag
None of this helps me, but sure, enjoy your free default bounty
sancho.s ReinstateMonicaCellio avatar
@DarienMarks - Somewhat rude... I meant to help, please see my comments above.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.