Re: NetworkManager behavior answers not found in docs

[Thomas HUMMEL <thomas hummel pasteur fr>]

On 10/26/2018 10:05 AM, Thomas Haller wrote:

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

In any event, it may be confusing for the user or a script indeed which 
then could legitimely think the managed request succeeded.

> 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).

ok

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

Wait : what's the diffence (if any) between GENERAL.NM-MANAGED == no and 
GENERAL.STATE == 10 (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.

I don't see what you mean here by "the opposite" : maybe just a flag to 
reflect the request (and its ack) of the desire to manage the device ?



> > # nmcli device set eth1 managed yes
> > # echo $?
> > 0
> > # 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-
> CARRIER".

Well, it's a VMWare virtual interface but 'connected' in VMWare and 
iproute shows :

3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode 
DEFAULT group default qlen 1000
    link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff

It seems normal to me the device is down since no one as configured it. 
But it seems I'm in a different case than no carrier'...
Maybe I'm supposed to see a LOWER_DOWN ?

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

Obviously the reason here is that the device is still unavailable but 
the question is why ? ;-)

> > -> ok, seems normal to as well since auto profile creation must not
> > work
> > 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.

Ok, that's indeed what I understood first.


Thanks

--
Thomas