Re: NetworkManager behavior answers not found in docs


On Thu, 2018-10-25 at 20:35 +0200, Thomas HUMMEL wrote:
On 10/18/2018 11:30 PM, Thomas Haller wrote:
Btw, note that if you configure the device as unmanaged via
NM_CONTROLLED=no in ifcfg, then the device cannot be set to
This way of unmanaging a device is definite,

Hello again, another use case I'm still wrapping my head around
with the precious knowledge acquired thanks to your help!)

Let's say I've got this setup :

- eth1 NM_UNMANAGED=1 via udev
(and suppose eth1 in no-auto-default.state)

here's what I'm testing

- about NM_CONTROLLED=no :

# nmcli connection show

# nmcli -f GENERAL.DEVICE,GENERAL.STATE device show
GENERAL.DEVICE:                         eth0
GENERAL.STATE:                          10 (unmanaged)

GENERAL.DEVICE:                         eth1
GENERAL.STATE:                          10 (unmanaged)

GENERAL.DEVICE:                         lo
GENERAL.STATE:                          10 (unmanaged)

# nmcli device set eth0 managed yes
# echo $?
# nmcli -f GENERAL.DEVICE,GENERAL.STATE device show
GENERAL.DEVICE:                         eth0
GENERAL.STATE:                          10 (unmanaged)

-> as you explained, unmanaging a device this way is definite, but
the 0 return value legit here ?

The return value of the nmcli command is odd, maybe a bug.

It returns success, because it successfully flagged the device that the
user wishes to manage it. However, there may still be other (stronger)
reasons, why the device stays unmanaged (NM_CONTROLLED=no).

Ah, there is also `nmcli -f GENERAL.NM-MANAGED device show eth0 `, but
this just returns (state != "unmanaged").

Optimally, there would be a nother flag which is the opposite of `nmcli
device set $DEV managed $VALUE`. So, when you issue device-set, it
would succeed and would toggle this flag, but that alone may not be
sufficient to make the device (fully) GENERAL.NM-MANAGED yet.

- about the following sentence in man regarding NM_UNMANAGED :

"You will still be able to attach a connection to the
device manually or observe externally added configuration such as 
addresses or routes."

I think this part of the manual should be improved.

# nmcli device set eth1 managed yes
# echo $?
# nmcli -f GENERAL.DEVICE,GENERAL.STATE device show
GENERAL.DEVICE:                         eth1
GENERAL.STATE:                          20 (unavailable)

state "unavailable", looks like the device has no cable plugged in (no
carrier). You'd also see that with `ip link show eth1` saying "NO-

-> it's not unmanaged anymore, so it's managed

# nmcli connection show

-> still no connection, seems normal to me

I agree. A connection would only be created via the "auto-default"
mechanism, which depends on setting and

Not sure whether that's the case, or because the device state is still
unavailable... either way, this doesn't seem wrong here (without
knowing all the details).

# nmcli device connect eth1
Error: Failed to add/activate new connection: Connection 'eth1' is
available on the device eth1 at this time.

Here, (I think), first nmcli tried to activate a profile on the device.
That failed, because no profile exists. Then it tried to create a new
profile (with ipv4.method=auto).

Activation of the created profile then probably fails, because the
device has no carrier (which is required for successful DHCP).

-> ok, seems normal to as well since auto profile creation must not
under NM_UNMANAGED conditions

no, I think this part of the manual is misleading.

A device is either "unmanaged" or not. Udev's NM_UNMANAGED is a way to
configure the device as unmanaged, and `nmcli device set $DEV managed
yes` can overrule that. Aterwards, there is no further difference
between other managed devices.

# nmcli connection add type ethernet con-name managed-eth1 ifname
Connection 'managed-eth1' (41727fca-d424-40d9-91e7-55197ff9a962) 
successfully added.

# nmcli connection show
NAME          UUID                                  TYPE      DEVICE
managed-eth1  41727fca-d424-40d9-91e7-55197ff9a962  ethernet  --

-> ok I managed to create a connection somehow linked to eth1
It's not active which also seems normal to me

It didn't autoactivate, because the device's state is "unavailable"

If you'd create a profile with ipv4.method=manual, you could also
activate it on a device with cabel unplugged.

But then I cannon neither connect the eth1 device nor activate the
created profile

-> what's happening here ?


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]