Re: NetworkManager behavior answers not found in docs
On 10/24/2018 06:22 PM, Thomas Haller wrote: Let's call this "externally managed". Not sure that's helpful, but in NetworkManager source code it's called like that. In nmcli output, you cannot really distinguish a regular activated profile from such an externally managed one. Except, that in the latter case the profiles was autocreated and its name is the device name (eth1). Understood. Now if I edit this connection matching an externally managed device (for instance using nmcli connection edit), would that turn it into a normally managed one ? Thanks -- Thomas Hummel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Wed, 2018-10-24 at 15:52 +0200, Thomas HUMMEL wrote: > On 10/24/2018 01:23 PM, Thomas Haller wrote: > > > Hi, > > > > An unmanaged device is in state "unmanaged". All other states (like > > "100 (connected)") are not-unmanaged, which means they are > > "managed". > > > >$ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > >$ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show "$DEVICE" > > Hello, > > That's what I thought but on a previously discussed case of an > externally configured device, here's what I'm experiencing : > > > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show eth1 > GENERAL.DEVICE: eth1 > GENERAL.STATE: 30 (disconnected) > > > # ip addr show eth1 > 3: eth1: mtu 1500 qdisc mq state > UP > group default qlen 1000 > link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff > > > # ip addr add 192.168.10.200/24 dev eth1 > > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show eth1 > GENERAL.DEVICE: eth1 > GENERAL.STATE: 100 (connected) > > But I thought we said that in such a case a profile would be > autocreated > (and autoconnected) but only to reflect that something is active but > which is not going to be managed (like for dhcp requests...) by NM ? > > Did I misunderstood ? I wasn't very clear here, sorry. So, the device can be in state "unmanaged" and that's it. If you have a device not "unmanaged" (that is, any other state), and you externaly add IP configuration (like you did here), this is the case 3) from my earlier email. I said, in this case the device is not actively managed by NM, meaning, NM does not do anything with it. This is different from the proper "unmanaged" case. The device looks managed, but NM also doesn't mess with it. Let's call this "externally managed". Not sure that's helpful, but in NetworkManager source code it's called like that. In nmcli output, you cannot really distinguish a regular activated profile from such an externally managed one. Except, that in the latter case the profiles was autocreated and its name is the device name (eth1). best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/24/2018 01:14 PM, Thomas Haller wrote: Hm, `nmcli device reapply` does not modify the profile at all, does it? Correct. Sorry, I did so many tests that I misinterpreted this one. Reapply doesn't seem to have any relevance with modification or persistance. Yes so now my understanding of reapply is more like "restore" (to its original settings). Does this make sense even with non disk backed applied profiled (I guess that's what you tried to explain to me in a previous message where you were talking about a clone of the profile). Thanks, -- Thomas H. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/24/2018 01:23 PM, Thomas Haller wrote: Hi, An unmanaged device is in state "unmanaged". All other states (like "100 (connected)") are not-unmanaged, which means they are "managed". $ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show $ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show "$DEVICE" Hello, That's what I thought but on a previously discussed case of an externally configured device, here's what I'm experiencing : # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show eth1 GENERAL.DEVICE: eth1 GENERAL.STATE: 30 (disconnected) # ip addr show eth1 3: eth1: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff # ip addr add 192.168.10.200/24 dev eth1 # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show eth1 GENERAL.DEVICE: eth1 GENERAL.STATE: 100 (connected) But I thought we said that in such a case a profile would be autocreated (and autoconnected) but only to reflect that something is active but which is not going to be managed (like for dhcp requests...) by NM ? Did I misunderstood ? Thanks. -- Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Tue, 2018-10-23 at 17:29 +0200, Thomas HUMMEL wrote: > On 10/17/2018 10:38 AM, Thomas Haller wrote: > > 3) if you do > > > >nmcli device disconnect eth0 > >ip addr add 192.168.7.5/24 dev eth0 > > > > NM now creates an in-memory connection "eth0". This means that > > NetworkManager*does not* manage this device. > > Among the things I forgot : I understand what you explained but I > cannot > figure out a way to make nmcli confirm that the device is not > managed. > > For instance : > > # nmcli -f GENERAL.STATE device show eth1 > GENERAL.STATE: 100 (connected) > > I guess the 'connected' hides the 10 (unmanaged) I can see in > different > situations ? > > # nmcli device show eth1 | grep -i managed > # Hi, An unmanaged device is in state "unmanaged". All other states (like "100 (connected)") are not-unmanaged, which means they are "managed". $ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show $ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show "$DEVICE" best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Tue, 2018-10-23 at 15:25 +0200, Thomas HUMMEL wrote: > On 10/18/2018 11:30 PM, Thomas Haller wrote: > > 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. > > > > > > So, would that be correct to think about it this way : > > it is a device which, by defaults, "wants" to autoconnect and try to > find a profile with connection.autoconnect property set to yes ? > > and device disconnect or device set autoconnect no inhibit > this > behavior ? > > I mean as opposed to a profile which would "want" to auto "connect" > to a > device ? Yes, kind of. Both the device and the profile must be willing to autoconnect for it to happen. It's both ways. That's why you can suppress autoconnect on both sides. And in various situations, autoconnect will also be internally blocked. For example for the device (after `nmcli device disconnect`) and or the profile (e.g. no secrets provided)). best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Fri, 2018-10-19 at 19:22 +0200, Thomas HUMMEL wrote: Hi, > > > > 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 > > > we > > > then save the profile to disk of course) ? > > > > Yes. But when you modify this profile, it usually gets persisted to > > disk. > > I see in my tests that a profile modification is persisted even > before > the call to nmcli device reapply : am I right ? Hm, `nmcli device reapply` does not modify the profile at all, does it? > What's the link between persistence, modification and reapplication > of a > profile ? A profile may be backed by a file on disk or not. Accordingly, it is persited or not. Whenever you modify a profile, you can also say whether it should be persited to disk or not. If the profile had a backing file on disk, making it in-memory only may or may not involve deleting the file. On the D-Bus API, it controlled via Update2 flags [1]. [1] https://developer.gnome.org/libnm/unstable/libnm-nm-dbus-interface.html#NMSettingsUpdate2Flags nmcli gives you some control over that, like `nmcli connection add save no ...` and `nmcli connection modify --temporary ...`. Reapply doesn't seem to have any relevance with modification or persistance. > > Maybe NM created such an "auto-default" (named "Wired Connection > > #"), > > but then you deleted it? It wouldn't create it again, see file > > /var/lib/NetworkManager/no-auto-default.state. > > The MAC is indeed in there although I don't remember deleting an > auto > created profile > best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
