Re: NetworkManager behavior answers not found in docs

On Wed, 2018-10-17 at 19:34 +0200, Thomas HUMMEL wrote:

thanks for your answers. Very useful !
Much content to digest ;-)

you can ignore
initscripts entirely.

I know, I was just curious about how they used D-Bus and nmcli and
compatibility worked both ways (network-scripts <-> NM)

There is little difference

   - `nmcli connection up "$PROFILE"` will find a suitable device
   - `nmcli device connect "$DEVICE"` will find a suitable
automatically. Note this may create a new profile (see later).
   - `nmcli connection up "$PROFILE" ifname "$DEVICE" explicitly
both the profile and the device.


As the profile contains the necessary settings for what to do with
device, you cannot ~configure~ a device without a profile.


re-activating can be done via `nmcli connection up` (or similar)
goes through a full re-activation cycle (and temporarily
you). A more graceful way is `nmcli device reapply "$DEVICE"` which
takes the changes and configured on the device.

`nmcli device reapply` may also be useful if there are no actual
changes in the device. For example, it will re-start DHCP and
IP address configuration (if it was modified, for example via

You see, when a profile is activated on a device, the original
were internally copied and those are "applied". And "nmcli device
reapply" just updates the "applied" clone to be the current profile
does the changes.

ok, so those details apart,

- profile is applied or re-applied to a device
- connection is up-ed or activated
- profile is activated
- device is connected

are kind of synonymous ?


Usually, NetworkManager (the daemon) does not automatically create
connection profiles

But when it does (as in your cases), is it always only in RAM (unless
then save the profile to disk of course) ?

Yes. But when you modify this profile, it usually gets persisted to

Except case 4). But there it's not really NetworkManager who creates
the profile but nmcli/nm-applet. Such profiles to get persisted.

Regarding "autoconnect", that is a property of the connection

So in a way, when a profile is autocreated and activated, it is
created with this property which make it then immediatly
correct ?

Not necessarily.

When NetworkManager creates a bluetooth pan profile (case 1)), this one
will not be connected right away. Such a profile also has

For the auto-default profiles (case 2, "Wired Connection #"), the
purpose is to create a profile and activate it right away.
Indeed, such a generated profile has "connection.autoconnect=yes". But
it would work the same (and connect the profile) also with
NM here (auto)creates the profile and goes ahead to activate it. I
wouldn't call this behavior "autoconnect", but yes, kind of.

   - per-device: nmcli device set $DEVICE autoconnect no

this confuses me since we just said autoconnection was a property of
profile and this command deals with a device ?

The profile has a "connection.autoconnect" property. If it's "no", the
profile never autoconnects. Period.

But there also needs to be a device which is currently in a state where
it would like to autoconnect a profile. With `nmcli device set
"$DEVICE" autoconnect no" you can set that.

for example, `nmcli device disconnect "$DEVICE"` will block autoconnect
on the device. It would be pretty annoying, if you disconnect the
device and immediatley some profile autoconnects again.

"Autoconnect" prefers profiles which
were active last

Same remark here

When a device wants to autoconnect a profile, there might be multiple
profiles which are compatible candidtes. Then, the one is chosen with
the best "connection.autoconnect-priority" or as last, the timestamp
when the profile was activate the last time.

If a device is unmanaged, NetworkManager does nothing with it. It
autocreate a profile for it, and it won't autoactivate anything >
Depending on the reasons why it's unmanaged, you still can let
NetworkManager take over, either via

   nmcli device set $DEVICE managed yes

or simply `nmcli con up` or `nmcli device connect`.

My understanding is that a device is managed by default unless 
explicitly set to unmanaged (via one of the several ways you


Also, that profile autocreation works (when its not forbidden by 
no-auto-default for instance) only on managed devices


So in your above example I don't understand how nmcli con up alone
nmcli device connect alone would actually create the profile without
device set managed yes first ?

`nmcli con up` never creates a profile.
`nmcli device connect` usually does not create a profile either
(unless, no suitable profile exists).

The `nmcli con up` or `nmcli device connect` commands are clear
indications that the user wants NetworkManager to now manage this
device. It doesn't require the user to first issue

  nmcli device set $DEVICE managed yes

because it's clear(?) that this is what the user wants.

Actually, there was a change in this regard recently:

Or maybe nmcli con up or device connect would create a profile and
it but the device would still be unmanaged ?

No. unmanaged devices are not touched by NM. First the device gets set
to "managed". Then a profile may be created, then the profile gets

Also, since adding a profile creates a persistent profile (provided
save option is not set to false), is there a point to set a device
managed when a persistent profile for it exists ?

Sure. Unmanaged devices are not very useful, as far as NetworkManager
is concerned.

I mean the persistent profile would make NM "manage" the device even
not really set to managed yes ?

No it wouldn't. Unless you issue a client command like `nmcli con up`.
Especially, nothing would autoconnect, and now profiles are
automatically created by NetworkManager (case 4 doesn't count).

Let's take the following use case as an example :

- a host with 2 ethernet devices : eth0 and eth1

- eth0 has a network-script like connection file
(/etc/sysconfig/network-scripts/ifcfg-eth0) and is NetworkManager
managed (either by default because no "NM_CONTROLLED=no" is
explicitly with "NM_CONTROLLED=yes")
- eth1 has no connection file (neither ifcfg-rh style nor keyfile
that is nothing for eth1 neither in /etc/sysconfig/network-
in /etc/NetworkManager/system-connections)

- no NM_UNMANAGED=1 in udev

test 1 :

-> after boot, as expected eth0 is configured and up, nmcli shows
connection for it but eth1 has no connection. It has to be
connected for that matter. If done, NetworkManager seems to auto
magically CREATE the connection

I guess, on CentOS you have a package NetworkManager-config-server,
which installs a file /usr/lib/NetworkManager/conf.d/00-server.conf

That's not the case for me : I don't see any no-auto-default
which could match eth1 or any at all (I only have 10-slaves-
in conf.d)

Maybe NM created such an "auto-default" (named "Wired Connection #"),
but then you deleted it? It wouldn't create it again, see file

By default, without any profiles files, would be my eth1 device
or unmanaged (I would guess managed since I'm not in any case you 
describe where a device could be unmanaged) ?

Whether it's managed does not depend on the presence of connection
profiles. Possibly it would be managed, as you see in `nmcli device`
output. Everything where the state is not "unmanaged", is managed :)

Well, if you have an ifcfg-file that specifies NM_CONTROLLED=no, then
the device would be unmanaged. But such a ifcfg isn't a real
"connection" (you wouldn't see it in `nmcli connection`). 

Btw, note that if you configure the device as unmanaged via
NM_CONTROLLED=no in ifcfg, then the device cannot be set to managed.
This way of unmanaging a device is definite,

  nmcli device set "$DEVICE" managed yes
  nmcli device connect "$DEVICE"

will both fail. Not every device can be set to managed. For example,
"lo" is never manageble. But what I said above is still the case,

  nmcli device connect "$DEVICE"

safes you from explict `nmcli device set $DEVICE managed yes`. It
doesn't mean, that this will work with every device.

So shouldn't NM have auto created a temp profile and auto connected
for my eth1 ?

Possibly not. Is the MAC address in "/var/lib/NetworkManager/no-auto-
default.state" ?

man nmcli:

        connect ifname
            Connect the device. NetworkManager will try to find a
suitable connection that will be activated. It will also consider
connections that are not set to auto

ok. It's not described. That's a documentation bug.

So you confirm that unless a device in explictly unmanaged, a device 
connect would not only look for declared profiles but would also if
suitable profile is found create a temp profile creation and activate
it ?

Yes. First it tries to find a profile to activate. If there is none, it
would create one. But not a "temp" profile, it's persisted. And it's
not "automatically" created by NetworkManager daemon, but by you
(issuing the nmcli command).

Actually, first it might even need to set the device as managed, if it
was unmanaged before...

test 2 under the same conditions :

- reboot of the host
- only one connection (eth0) as expected
- create the foobar connection like this

      nmcli connection add type ethernet con-name foobar ifname

-> as expected a ifcgh-rh format connection file has been created
/etc/sysconfig/network-scripts/ifcfg-foobar and nmcli shows 2
connections : eth0 and foobar

- manually delete foobar connection file : rm

-> as expected nmcli still shows foobar connection

- reload connection files via nmcli connection reload

-> as expected nmcli only shows eth0 connection

So far, everything seems to work as expected BUT :

if instead of nmcli connection reload we RESTART (not reload, but
restart) NetworkManager via systemctl restart NetworkManager,
(different UUID and eth1 instead of foobar for the name)
auto created and auto activated

Yes, that is case 3). NM (re) starts and sees the the device is

you mean via the /run state dir we talked about ?

Partly. NM sees that the device is configured because it has an IP
In the state file it says that the connection with UUID XYZ should be
active on it, but no such connection exists anymore. At that point, NM
does not know what configuration (profile) should be used, and it
assumes the user externally handles it. Then, it generates this in-
memory connection (named "eth1") and pretends that it is active. But it
does not do anything with it! This is a problem, your DHCP addresses
will expire...

It has no configuration for that device

You mean no more persistent profile ?

Those 2 above facts seems contradictory to me : if the device is 
"already configured" doesn't it mean that it has some in RAM profile 
applied ? Then NM hasn' "no configuration for that device" ?

The device is configured with IP addresses in kernel. As you see with
`ip addr` and `ip route`. NM sees something is going on there... but
the configuration and original intent that lead to this configuration
are unknown to NetworkManager (in this example, because you deleted
files under NetworkManager's feet and it can no longer find the profile
that it previously activated there).

In general:

  - you usually don't need to restart NetworkManager. If you think you
do, you might do something wrong. Of course, restart during package
update or just for the fun of it, are good reasons. Restart is supposed
to work well and as non-disruptive as possible.
  - If you restart, avoid confusing NetworkManager, like deleting
files of NetworkManager without telling NM.
  - If you confuse NM, be prepared to manually fix the situation after
starting NM again. That may simply mean to explicitly `nmcli connection
up` the right profile afterwards, to get rid of this generated (case 3)

, so it assumes
somebody else was configuring it and does not touch it. This eth0
device is no longer managed by NetworkManager. For example, it does
DHCP and your addresses will time out.

Sorry for the confusion. I'm sure that when sorted out, those
are simple ;-)

I hope this helped :)


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]