Re: nmcli connection down
On 11/13/18 4:13 PM, Thomas Haller wrote: Maybe. But the moment when you issue $ nmcli connection down "$PROFILE" the "$PROFILE" is in the process of deactivating. It's not yet fully deactivated. Hence, it is "the profile which is currently deactivating". Seems correct to me as-is, but no strong preference. WDYT? Ok. Me neither. I guess I said that because of the way the original sentence was written : " Thisincludes the just deactivated connection. So if the connection is set to auto-connect, it will be automatically started on the disconnected device again." I prefer your patch since it is technically accurate ;-) Talking about nmcli(1) man, I found this part unclear (to me at last) and only our previous discussions had me figure it out : "You can also specify particular fields. For static configuration, use setting and property names as described in nm-settings(5) manual page. For active data use GENERAL, IP4, DHCP4, IP6, DHCP6, VPN." To me, someone issuing 'nmcli device show' vs 'nmcli connection show' would deduce concerning properties that uppercase vs lowercase is a matter of device vs profile, not static vs active (the ambiguous term to me here is static). My understanding now is that device is just another way to say active or applied. However, even a disconnect device has got some GENERAL.* uppercase properties. To add to the confusion (mine at least), many nmcli connection add examples I saw, including nmcli-examples(7) use ip4, gw4 (not the same name as in nm-settings(5) and in lowercase) while to me using, ipv4.*, at least for nmcli connection add would do the same ? If you see what I mean. Keep in mind I might be mistaking and I might have missed a basic understanding ;-) For now in my mind is the following : upper case : applied profile, lowercase : profile (applied or not). Otherwise, I did write a quite long or not so short web page (markdown in our documentation software) doing a hopefully detailed and accurate reference about what we've talked together and more generally about the concepts we evoked. It was meant for myself and my team as a reference and holds the following sections : How to configure Network on a CentOS 7 system I. iproute2 - the manual method II. network scripts - the old method II.1 overview II.2 Details III. NetworkManager - the new method III.1 Service launch III.2 Concepts III.3 Devices : properties III.4 Profiles: properties III.5 Active connection creation III.7 Active connection modification III.7.1 "normal" profile modification III.7.2 applying changes III.7.3 volatile modifications III.7.4 Examples III.8 Persisting profiles / plugins III.8.1 keyfile plugin III.8.2 CentOS case III.8.3 Debian case III.9 Device discovery III.9.1 sysfs attributes III.9.2 udev(7) properties III.9.3 udev and NetworkManager III.10 management III.10.1 unmanaged III.10.2 managed III.10.3 externally managed III.11. profile autocreation III.10.1 execption 1 III.10.2.exception 2 III.10.3 exception 3 III.10.4 exception 4 IV. profile autoconnection IV.1 profile IV.2 device IV.3 autocreate/autoconnect IV.4 ethernet auto profile case V. return to the externally managed case (2 examples) VI dispatcher scripts X state directory It is quite informal and at the granularity level of what I asked here and almost wired ethernet only oriented. Would you be interested I translate it (from french to english) and send it to you in order for you to see if it can be of any help for anyone on any form (I don't have any blog myself) ? [don't look at the section numbering I just read I did not accurately copied it while writing this message, but you've got the idea ;-)] -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli connection down
On Tue, 2018-11-13 at 14:03 +0100, Thomas HUMMEL wrote: > On 11/13/18 1:56 PM, Thomas Haller wrote: > > > > I think this is just a documentation bug. > > > > Fixed: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f9801e07df0c544e0416c65cedc28727476e55 > > > > Thanks for actually reading the documentation and pointing out > > confusing/wrong parts!! > > Thanks for your time. > > By the way : isn't there a typo in your path ? > > + Note that the deactivating connection profile is > + internally blocked from autoconnecting again > > didn't you mean deactivatED ? > Hi, Maybe. But the moment when you issue $ nmcli connection down "$PROFILE" the "$PROFILE" is in the process of deactivating. It's not yet fully deactivated. Hence, it is "the profile which is currently deactivating". Seems correct to me as-is, but no strong preference. WDYT? 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: nmcli connection down
On 11/13/18 1:56 PM, Thomas Haller wrote: I think this is just a documentation bug. Fixed: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f9801e07df0c544e0416c65cedc28727476e55 Thanks for actually reading the documentation and pointing out confusing/wrong parts!! Thanks for your time. By the way : isn't there a typo in your path ? + Note that the deactivating connection profile is + internally blocked from autoconnecting again didn't you mean deactivatED ? -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli connection down
On Thu, 2018-11-08 at 16:30 +0100, Thomas HUMMEL wrote: > Hello, > > nmcli(1) states about the connection down command : > > "Be aware that this command deactivates the specified active > connection, > but the device on which the connection was active, is still ready to > connect and will perform auto-activation by looking for a suitable > connection that has the 'autoconnect' flag set. This includes the > just > deactivated connection. So if the connection is set to auto-connect, > it > will be automatically started on the disconnected device again." > > In the following simple test : > > # ls -l /var/lib/NetworkManager/no-auto-default.state > -rw-r--r-- 1 root root 0 Nov 8 16:25 > /var/lib/NetworkManager/no-auto-default.state > > # nmcli connection delete foobar > Connection 'foobar' (eedc4b58-5a81-45e9-9cac-586f9f25f61d) > successfully > deleted. > > # nmcli connection add type ethernet con-name foobar ifname eth1 > Connection 'foobar' (1c34b34b-f3ab-4d7d-8a19-3fdf618a16f3) > successfully > added. > > # nmcli -f connection.autoconnect connection show foobar > connection.autoconnect: yes > > # nmcli -f GENERAL.AUTOCONNECT device show eth1 > GENERAL.AUTOCONNECT:yes > > # nmcli connection down foobar > Connection 'foobar' successfully deactivated (D-Bus active path: > /org/freedesktop/NetworkManager/ActiveConnection/2) > > # nmcli connection show > NAMEUUID TYPE DEVICE > foobar 1c34b34b-f3ab-4d7d-8a19-3fdf618a16f3 ethernet -- > > # ip address show dev 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 > > > it seems to me I'd qualified to the "This includes the just > deactivated > connection." case ? So why doesn't the device auto-reconnects ? Hi, I think this is just a documentation bug. Fixed: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f9801e07df0c544e0416c65cedc28727476e55 Thanks for actually reading the documentation and pointing out confusing/wrong parts!! 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
nmcli connection down
Hello, nmcli(1) states about the connection down command : "Be aware that this command deactivates the specified active connection, but the device on which the connection was active, is still ready to connect and will perform auto-activation by looking for a suitable connection that has the 'autoconnect' flag set. This includes the just deactivated connection. So if the connection is set to auto-connect, it will be automatically started on the disconnected device again." In the following simple test : # ls -l /var/lib/NetworkManager/no-auto-default.state -rw-r--r-- 1 root root 0 Nov 8 16:25 /var/lib/NetworkManager/no-auto-default.state # nmcli connection delete foobar Connection 'foobar' (eedc4b58-5a81-45e9-9cac-586f9f25f61d) successfully deleted. # nmcli connection add type ethernet con-name foobar ifname eth1 Connection 'foobar' (1c34b34b-f3ab-4d7d-8a19-3fdf618a16f3) successfully added. # nmcli -f connection.autoconnect connection show foobar connection.autoconnect: yes # nmcli -f GENERAL.AUTOCONNECT device show eth1 GENERAL.AUTOCONNECT: yes # nmcli connection down foobar Connection 'foobar' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2) # nmcli connection show NAMEUUID TYPE DEVICE foobar 1c34b34b-f3ab-4d7d-8a19-3fdf618a16f3 ethernet -- # ip address show dev 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 it seems to me I'd qualified to the "This includes the just deactivated connection." case ? So why doesn't the device auto-reconnects ? Thanks -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
