Re: NetworkManager behavior answers not found in docs
On Tue, 2018-11-06 at 12:23 +0100, Thomas HUMMEL wrote: > On 10/26/18 12:55 PM, Thomas HUMMEL wrote: > > > Generally, there are the device states "unmanaged" -> > > > "unavailable" -> > > > and "disconnected". For ethernet devices, a device is usually > > > "unavailable" because it has no carrier. > > > > As a matter of fact, when no udev rules for NM_UNMANAGED, the > > device is > > in the disconnected state. > > > > As for the traces, here's what I've got : > > > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5859] ifcfg-rh: loading from file > > "/etc/sysconfig/network-scripts/ifcfg-eth0"... > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5861] settings-connection[0x7fbffc006890]: constructed > > (NMIfcfgConnection) > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5870] > > settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1- > > d6edd65f3e03]: update > > settings-connection flags to visible (was none) > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5875] > > settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1- > > d6edd65f3e03]: disposing > > > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5878] > > settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1- > > d6edd65f3e03]: update > > settings-connection flags to none (was visible) > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6729] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6752] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6771] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6790] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6809] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6827] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6845] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6865] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6883] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0031] device[0x55a73f560c80] (eth1): sys-iface-state: > > external -> assume > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0033] device[0x55a73f560c80] (eth1): unmanaged: flags > > set to > > [user-udev,!sleeping,!loopback,!platform-init,!user-explicit,!user- > > settings=0x400/0x479/managed], > > > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0033] device (eth1): state change: unmanaged -> > > unavailable > > (reason 'connection-assumed', sys-iface-state: 'assume') > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0034] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/accept_ra': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0035] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/accept_ra_defrtr': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0035] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/accept_ra_pinfo': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0035] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/accept_ra_rtr_pref': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0036] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/forwarding': '0' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0036] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/disable_ipv6': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0036] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/hop_limit': '64' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0037] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/use_tempaddr': '0' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0039] device[0x55a73f560c80] (eth1): device not yet > > available for transition to DISCONNECTED > > Oct 26 12
Re: NetworkManager behavior answers not found in docs
On Wed, 2018-11-07 at 12:14 +0100, Thomas HUMMEL wrote: > Hello, > > I was playing with the externally managed concept and I experienced > the > following : > > modifying an autocreated/autoconnected profile corresponding to an > externally managed device seems to be (silently) auto-reapplied. > Afterward, once NetworkManager takes over (and really manages the > device), everything is back to normal. Is this a legit/normal > situation ? > > Ex : > > # ip address add 192.168.10.200/24 dev eth1 > # nmcli connexion modify eth1 802-3-ethernet.mtu 9000 > # ip addr shows eth1 has changed its mtu for 9000, no device > reapplied > or connexion up has been needed and no message (as in nmcli device > modify) telling anything has been reapplied. > > My guess is that's normal since telling a profile has been reapplied > would imply that de device is (normally) managed...Since behavior > surprised me. hi, yes, that is suprising and inconsistent. I wrote about that here: https://bugzilla.redhat.com/show_bug.cgi?id=1616363#c3 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
Hello, I was playing with the externally managed concept and I experienced the following : modifying an autocreated/autoconnected profile corresponding to an externally managed device seems to be (silently) auto-reapplied. Afterward, once NetworkManager takes over (and really manages the device), everything is back to normal. Is this a legit/normal situation ? Ex : # ip address add 192.168.10.200/24 dev eth1 # nmcli connexion modify eth1 802-3-ethernet.mtu 9000 # ip addr shows eth1 has changed its mtu for 9000, no device reapplied or connexion up has been needed and no message (as in nmcli device modify) telling anything has been reapplied. My guess is that's normal since telling a profile has been reapplied would imply that de device is (normally) managed...Since behavior surprised me. Thanks -- TH ___ 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/26/18 12:55 PM, Thomas HUMMEL wrote: Generally, there are the device states "unmanaged" -> "unavailable" -> and "disconnected". For ethernet devices, a device is usually "unavailable" because it has no carrier. As a matter of fact, when no udev rules for NM_UNMANAGED, the device is in the disconnected state. As for the traces, here's what I've got : Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5859] ifcfg-rh: loading from file "/etc/sysconfig/network-scripts/ifcfg-eth0"... Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5861] settings-connection[0x7fbffc006890]: constructed (NMIfcfgConnection) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5870] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: update settings-connection flags to visible (was none) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5875] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: disposing Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5878] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: update settings-connection flags to none (was visible) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6729] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6752] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6771] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6790] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6809] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6827] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6845] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6865] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6883] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0031] device[0x55a73f560c80] (eth1): sys-iface-state: external -> assume Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0033] device[0x55a73f560c80] (eth1): unmanaged: flags set to [user-udev,!sleeping,!loopback,!platform-init,!user-explicit,!user-settings=0x400/0x479/managed], Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0033] device (eth1): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume') Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0034] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_defrtr': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_pinfo': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_rtr_pref': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/forwarding': '0' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/disable_ipv6': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/hop_limit': '64' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0037] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/use_tempaddr': '0' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0039] device[0x55a73f560c80] (eth1): device not yet available for transition to DISCONNECTED Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0041] create NMAuditManager singleton (0x7fbffc00d0f0) Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0042] audit: op="device-managed" arg="managed:1" pid=1360 uid=0 result="success" corresponding to those actions : # ip link show eth1 3: eth1: 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 # nmcli -f GENERAL.NM-MANAGED device show eth1 GENERAL
Re: NetworkManager behavior answers not found in docs
On Fri, 2018-10-26 at 20:14 +0200, Thomas HUMMEL wrote: > On 10/25/2018 03:47 PM, Thomas Haller wrote: > > For example, > > > > nmcli connection up "$PROFILE" ifname "$DEVICE" > > nmcli connection modify "$PROFILE" +ipv4.addresses > > 192.168.77.5/24 > > nmcli device reapply "$DEVICE" > > > > is basically the same as: > > > > nmcli connection up "$PROFILE" ifname "$DEVICE" > > nmcli connection > > modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 > > nmcli device modify > > "$DEVICE" +ipv4.addresses 192.168.77.5/24 > > Got it. I guess that's what you meant by your cloned/invisible > live-in-ram active profile previously. > My understanding now is that device modify just modify an internal > copy > of the profile and then automatically calls apply on it, correct ? > Yes. `nmcli device modify` modifies the internal copy of the profile and makes the modifications happen. while `nmcli device reapply` modifies the internal copy to be the same as the current "normal" profile which is activated on the device (in case it differs after a `nmcli connection modify`), and then makes the configuration happen. They are quite similar in nature. "makes it happen" means to apply the settings. For example, restarting DHCP, adding/removing IP addresses, etc. In practice, this mostly applies to IP configuration, because lower layer changes (like the MAC address) require a full re-activation cycle, which device-reapply and device-modify refuse to do. 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-26 at 19:34 +0200, Thomas HUMMEL wrote: > On 10/25/2018 03:47 PM, Thomas Haller wrote: > > Remember, that a modification of the profile (`nmcli connection > > modify`) does not take effect immeiately (except "connection.zone" > > and > > "connection.metered" properties). You usually need to do a full re- > > activation for the changes to take effect (`nmcli connection up`). > > Oh yes, I was confusing device and connection modify, sorry. > Though what you said above just makes me think about the connection > reload command. > Granted you're not supposed to manually edit connection files but my > understanding and experience is that if you do and then nmcli > connection > reload, you still have to reactivate the connection with nmcli > connection up. So I don't quite understand the use of reloading ? Hi, reload (and `nmcli connection load $FILENAME`) load all (or one) profiles from disk. This is useful if you edited the profile files (/etc/NetworkManager/system-connections, or /etc/sysconfig/network- scripts/ifcfg-*). Reload can also delete profiles (if it delete a file that was previously loaded). It's really not much different than adding/modifying/deleting profiles via `nmcli` or GUI. 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/25/2018 03:47 PM, Thomas Haller wrote: For example, nmcli connection up "$PROFILE" ifname "$DEVICE" nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 nmcli device reapply "$DEVICE" is basically the same as: nmcli connection up "$PROFILE" ifname "$DEVICE" nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 nmcli device modify "$DEVICE" +ipv4.addresses 192.168.77.5/24 Got it. I guess that's what you meant by your cloned/invisible live-in-ram active profile previously. My understanding now is that device modify just modify an internal copy of the profile and then automatically calls apply on it, correct ? 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 10/25/2018 03:47 PM, Thomas Haller wrote: Remember, that a modification of the profile (`nmcli connection modify`) does not take effect immeiately (except "connection.zone" and "connection.metered" properties). You usually need to do a full re- activation for the changes to take effect (`nmcli connection up`). Oh yes, I was confusing device and connection modify, sorry. Though what you said above just makes me think about the connection reload command. Granted you're not supposed to manually edit connection files but my understanding and experience is that if you do and then nmcli connection reload, you still have to reactivate the connection with nmcli connection up. So I don't quite understand the use of reloading ? 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
Generally, there are the device states "unmanaged" -> "unavailable" -> and "disconnected". For ethernet devices, a device is usually "unavailable" because it has no carrier. As a matter of fact, when no udev rules for NM_UNMANAGED, the device is in the disconnected state. As for the traces, here's what I've got : Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5859] ifcfg-rh: loading from file "/etc/sysconfig/network-scripts/ifcfg-eth0"... Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5861] settings-connection[0x7fbffc006890]: constructed (NMIfcfgConnection) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5870] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: update settings-connection flags to visible (was none) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5875] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: disposing Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5878] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: update settings-connection flags to none (was visible) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6729] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6752] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6771] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6790] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6809] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6827] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6845] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6865] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6883] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0031] device[0x55a73f560c80] (eth1): sys-iface-state: external -> assume Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0033] device[0x55a73f560c80] (eth1): unmanaged: flags set to [user-udev,!sleeping,!loopback,!platform-init,!user-explicit,!user-settings=0x400/0x479/managed], Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0033] device (eth1): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume') Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0034] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_defrtr': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_pinfo': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_rtr_pref': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/forwarding': '0' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/disable_ipv6': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/hop_limit': '64' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0037] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/use_tempaddr': '0' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0039] device[0x55a73f560c80] (eth1): device not yet available for transition to DISCONNECTED Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0041] create NMAuditManager singleton (0x7fbffc00d0f0) Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0042] audit: op="device-managed" arg="managed:1" pid=1360 uid=0 result="success" corresponding to those actions : # ip link show eth1 3: eth1: 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 # nmcli -f GENERAL.NM-MANAGED device show eth1 GENERAL.NM-MANAGED: no # nmcli -f
Re: NetworkManager behavior answers not found in docs
On Fri, 2018-10-26 at 12:01 +0200, Thomas HUMMEL wrote: > On 10/26/2018 10:05 AM, Thomas Haller wrote: > > > > 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) ? There is none: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/nm-device.c?id=085b769729e9c623cc60bb0f88df36d1843cd22b#n16346 > > > > 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 > ? I mean, a flag (in NetworkManager public API) that exposes the user's intent of managing the device. That is, what `nmcli device set $DEV managed yes` sets. ... which may be slighly different than whether the device is actually "state != unmanaged". > > > > > > # 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: 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 ? ;-) hm, good question. I don't know, I would need to see the level=TRACE syslog (journal) of NM. Btw, for hints for getting the logfile see https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf Generally, there are the device states "unmanaged" -> "unavailable" -> and "disconnected". For ethernet devices, a device is usually "unavailable" because it has no carrier. 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/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: 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 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
Hi, 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 > > managed. > > This way of unmanaging a device is definite, > > Hello again, another use case I'm still wrapping my head around > (even > with the precious knowledge acquired thanks to your help!) > > Let's say I've got this setup : > > - eth0 NM_CONTROLLED=no > - 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 > NAME UUID TYPE DEVICE > > # 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 $? > 0 > # 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 > is > 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. https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=085b769729e9c623cc60bb0f88df36d1843cd22b > > # 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". > -> it's not unmanaged anymore, so it's managed > > # nmcli connection show > NAME UUID TYPE DEVICE > > -> still no connection, seems normal to me I agree. A connection would only be created via the "auto-default" mechanism, which depends on main.no-auto-default setting and /var/lib/NetworkManager/no-auto-default.state. 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 > not > 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 > 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. > > # nmcli connection add type ethernet con-name managed-eth1 ifname > eth1 > 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 > device. > 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 > newly > created profile > > -> what's happening here ? > best, Thomas signature.asc Description: This is a digitally s
Re: NetworkManager behavior answers not found in docs
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 managed. This way of unmanaging a device is definite, Hello again, another use case I'm still wrapping my head around (even with the precious knowledge acquired thanks to your help!) Let's say I've got this setup : - eth0 NM_CONTROLLED=no - 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 NAME UUID TYPE DEVICE # 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 $? 0 # 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 is the 0 return value legit here ? - 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." # nmcli device set eth1 managed yes # echo $? 0 # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show GENERAL.DEVICE: eth1 GENERAL.STATE: 20 (unavailable) -> it's not unmanaged anymore, so it's managed # nmcli connection show NAME UUID TYPE DEVICE -> still no connection, seems normal to me # nmcli device connect eth1 Error: Failed to add/activate new connection: Connection 'eth1' is not available on the device eth1 at this time. -> ok, seems normal to as well since auto profile creation must not work under NM_UNMANAGED conditions # nmcli connection add type ethernet con-name managed-eth1 ifname eth1 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 device. It's not active which also seems normal to me But then I cannon neither connect the eth1 device nor activate the newly created profile -> what's happening here ? 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 Wed, 2018-10-24 at 16:40 +0200, Thomas HUMMEL wrote: > On 10/24/2018 04:11 PM, Thomas HUMMEL wrote: > > > > 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). > > In fact I don't understand reapply anymore : > > - it doesn't affect the profile right, the profile is unchanged. > - a nmcli device modify (802-3-ethernet.mtu for instance) > seems > to immediatly (re)apply the change I'm doing to the active profile. > > So, I don't understand anymore when I'm supposed to issue a nmcli > device > reapply ? First of all, device-reapply might not be something that is frequently used. So, you can be perfectly fine, without ever using it. Remember, that a modification of the profile (`nmcli connection modify`) does not take effect immeiately (except "connection.zone" and "connection.metered" properties). You usually need to do a full re- activation for the changes to take effect (`nmcli connection up`). `nmcli device reapply` is mostly like re-activating the profile, however it does not a full re-activation. As such, it may be less disruptive. For example, if your device is a bridge (with vlan devices on top of it), a full `nmcli connection up "$BRIDGE_PROFILE"` needs to destroy all the vlans on top, and unenslave all slaves from the bridge. That's pretty disruptive. `nmcli device reapply` wouldn't. However, you can also reapply certain changes, like an IP address but not a MAC address change. It would simply fail if the changes are too invasive. Yes, it's not unlike `nmcli device modify $DEVICE`. For example, nmcli connection up "$PROFILE" ifname "$DEVICE" nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 nmcli device reapply "$DEVICE" is basically the same as: nmcli connection up "$PROFILE" ifname "$DEVICE" nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 nmcli device modify "$DEVICE" +ipv4.addresses 192.168.77.5/24 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 Thu, 2018-10-25 at 15:09 +0200, Thomas HUMMEL wrote: > On 10/25/2018 03:05 PM, Thomas Haller wrote: > > On Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote: > > > On 10/24/2018 01:19 PM, Thomas Haller wrote: > > > > > > > > > > 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. > > > > > > > > > Also, how can I check the status of a device autoconnect flag (as > > > set > > > by > > > nmcli device set autoconnect) ? > > > > > > > hi > > > > that would be: > > > >nmcli -f GENERAL.AUTOCONNECT device show "$DEVICE" > > Indeed. How is it that I don't see that property with a simple > single > nmcli device show ? try: nmcli -f ALL device show wlan > > Thanks > > -- > 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 Wed, 2018-10-24 at 19:58 +0200, Thomas HUMMEL wrote: > 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 ? Hi, Optimally yes. the profile for the externally managed device is at first in a way, that when the device disconnects (for example, because you remove the IP address again), that it gets automatically removed again. If you modify the profile, then the generated profile will no longer be automatically removed when the device disconnects later. It will continue to exist until you delete it (or until NetworkManager restarts, in case of `nmcli connection modify --temporary`). If you interact with such an externally managed device, then NM is supposed to fully take over... that in particular is the case with - nmcli device disconnect ... - nmcli device connect ... - nmcli connection up $ANY_PROFILE # on the device in question - nmcli connection down $THE_GENERATED_PROFILE - nmcli connection delete $THE_GENERATED_PROFILE where NM disconnects the device (and possibly fully activates a profile afterwards). optimally, the following would fully take over the device too, however in a graceful manner that does not affect your connectivity: - nmcli device reapply $DEVICE - nmcli connection modify $THE_GENERATED_PROFILE - nmcli device set "$DEVICE" managed yes after such an operation, the device should no longer be externally managed. But likely there are issues with this. They should be fixed, but to be safe, you should just fully re-connect the device with one of the above. also, optimally - nmcli device set $DEV managed no marks the device directly as unmanaged (including removing the generated profile), without interfering with the external configuration at all. There might be issues with this as well (meaning: it might touch the device and destroy some external configuration). 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/25/2018 03:05 PM, Thomas Haller wrote: On Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote: On 10/24/2018 01:19 PM, Thomas Haller wrote: 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. Also, how can I check the status of a device autoconnect flag (as set by nmcli device set autoconnect) ? hi that would be: nmcli -f GENERAL.AUTOCONNECT device show "$DEVICE" Indeed. How is it that I don't see that property with a simple single nmcli device show ? 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 Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote: > On 10/24/2018 01:19 PM, Thomas Haller wrote: > > > > 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. > > > Also, how can I check the status of a device autoconnect flag (as set > by > nmcli device set autoconnect) ? > hi that would be: nmcli -f GENERAL.AUTOCONNECT 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 10/24/2018 01:19 PM, Thomas Haller wrote: 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. Also, how can I check the status of a device autoconnect flag (as set by nmcli device set autoconnect) ? 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 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 04:11 PM, Thomas HUMMEL wrote: 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). In fact I don't understand reapply anymore : - it doesn't affect the profile - a nmcli device modify (802-3-ethernet.mtu for instance) seems to immediatly (re)apply the change I'm doing to the active profile. So, I don't understand anymore when I'm supposed to issue a nmcli device reapply ? Thank you -- TH ___ 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
Re: NetworkManager behavior answers not found in docs
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 # ? 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/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 ? 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
Thanks again. Your info are precious ! Some of them should make their way into the official doc to me. Again, a lot to digest but it's getting pretty clear. 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 ? What's the link between persistence, modification and reapplication of a profile ? 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 Thanks again! -- 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-17 at 19:34 +0200, Thomas HUMMEL wrote: > Hello, > > 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 > how > compatibility worked both ways (network-scripts <-> NM) > > > > There is little difference > > > >- `nmcli connection up "$PROFILE"` will find a suitable device > > automatically. > >- `nmcli device connect "$DEVICE"` will find a suitable > > connection > > automatically. Note this may create a new profile (see later). > >- `nmcli connection up "$PROFILE" ifname "$DEVICE" explicitly > > selects > > both the profile and the device. > > ok > > > As the profile contains the necessary settings for what to do with > > the > > device, you cannot ~configure~ a device without a profile. > > ok > > > re-activating can be done via `nmcli connection up` (or similar) > > and > > goes through a full re-activation cycle (and temporarily > > disconnects > > 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 > > restore > > IP address configuration (if it was modified, for example via > > iproute). > > > > > > You see, when a profile is activated on a device, the original > > settings > > were internally copied and those are "applied". And "nmcli device > > reapply" just updates the "applied" clone to be the current profile > > and > > 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 ? Yes. > > 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. 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 > > profile > > itself. > > So in a way, when a profile is autocreated and activated, it is > first > created with this property which make it then immediatly > (auto)connect, > 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 "connection.autoconnect=no". 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 "connection.autoconnect=no". 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 > a > 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 > > won't > > 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 > described) yes > Also, that profile autocreation works (when its not forbidden by > no-auto-default for instance) only on managed devices yes > So in your above example I don't understand how nmcli con up alone > or > nmcli device connect alone would actually create the profile without > the > device set managed ye
Re: NetworkManager behavior answers not found in docs
Hello, 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 how compatibility worked both ways (network-scripts <-> NM) There is little difference - `nmcli connection up "$PROFILE"` will find a suitable device automatically. - `nmcli device connect "$DEVICE"` will find a suitable connection automatically. Note this may create a new profile (see later). - `nmcli connection up "$PROFILE" ifname "$DEVICE" explicitly selects both the profile and the device. ok As the profile contains the necessary settings for what to do with the device, you cannot ~configure~ a device without a profile. ok re-activating can be done via `nmcli connection up` (or similar) and goes through a full re-activation cycle (and temporarily disconnects 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 restore IP address configuration (if it was modified, for example via iproute). You see, when a profile is activated on a device, the original settings were internally copied and those are "applied". And "nmcli device reapply" just updates the "applied" clone to be the current profile and 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 we then save the profile to disk of course) ? Regarding "autoconnect", that is a property of the connection profile itself. So in a way, when a profile is autocreated and activated, it is first created with this property which make it then immediatly (auto)connect, correct ? - per-device: nmcli device set $DEVICE autoconnect no this confuses me since we just said autoconnection was a property of a profile and this command deals with a device ? "Autoconnect" prefers profiles which were active last Same remark here If a device is unmanaged, NetworkManager does nothing with it. It won't 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 described) 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 or nmcli device connect alone would actually create the profile without the device set managed yes first ? Or maybe nmcli con up or device connect would create a profile and apply it but the device would still be unmanaged ? Also, since adding a profile creates a persistent profile (provided the save option is not set to false), is there a point to set a device to managed when a persistent profile for it exists ? I mean the persistent profile would make NM "manage" the device even if not really set to managed yes ? 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 stated or explicitly with "NM_CONTROLLED=yes") - eth1 has no connection file (neither ifcfg-rh style nor keyfile style, that is nothing for eth1 neither in /etc/sysconfig/network-scripts nor in /etc/NetworkManager/system-connections) - no NM_UNMANAGED=1 in udev test 1 : -> after boot, as expected eth0 is configured and up, nmcli shows a connection for it but eth1 has no connection. It has to be manually 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 anywhere which could match eth1 or any at all (I only have 10-slaves-order.conf in conf.d) By default, without any profiles files, would be my eth1 device managed or unmanaged (I would guess managed since I'm not in any case you describe where a device could be unmanaged) ? So shouldn't NM have auto created a temp profile and auto connected it for my eth1 ? man nmcli: connect ifname Connect the device. NetworkManager will try to find a suitable connecti
Re: NetworkManager behavior answers not found in docs
> > -> where is that magic described ? How does a simple connect > > CREATES > > a > > connection. Man states that connect looks for a matching EXISTING > > connection ? > > 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 >connect. > > ok. It's not described. That's a documentation bug. Hi, fixed: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1b732e28f7aafbbfb98748f6a873c98be361ef67 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-16 at 14:56 +0200, Thomas HUMMEL wrote: > I forgot : it seems to me that nmcli connection add also imply > "managed" > as in nmcli device set managed yes. > > Am I correct ? Then again when do we need those device commands > manipulation ? > I don't see that happening, and it shouldn't: $ nmcli device | grep ^eth0 eth0 ethernet disconnected -- $ nmcli connection add type ethernet con-name t ifname eth0 ipv4.addresses 192.168.10.5/24 ipv4.method manual ipv6.method ignore Connection 't' (deeb17f3-dd68-492a-b653-55800f9a3715) successfully added. $ nmcli device | grep ^eth0 eth0 ethernet connected t $ nmcli connection delete t Connection 't' (deeb17f3-dd68-492a-b653-55800f9a3715) successfully deleted. $ nmcli device set eth0 managed no $ nmcli device | grep ^eth0 eth0 ethernet unmanaged -- $ nmcli connection add type ethernet con-name t ifname eth0 ipv4.addresses 192.168.10.5/24 ipv4.method manual ipv6.method ignore Connection 't' (83fc7338-6897-4e2a-a4ec-1ecf396ccc68) successfully added. $ nmcli device | grep ^eth0 eth0 ethernet unmanaged -- that is, autoconnect does not kick in, because eth0 is unmanaged. If you however do $ nmcli device connect eth0 Device 'eth0' successfully activated with '83fc7338-6897-4e2a-a4ec-1ecf396ccc68'. or $ nmcli connection up t Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/12) then indeed, that implies a `nmcli device set eth0 managed yes`. But it didn't happen automatically. 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-16 at 14:40 +0200, Thomas HUMMEL wrote:
Hi,
>
> I'm considering migrating from a CentOS 6 HPC cluster to CentOS 7
> one.
> For this purpose I've read quite a lot of doc (man, guides, ...)
> about
> systemctl and NetworkManager to be fluent in their use.
>
> Regarding NetworkManager, I've been at first confused by the induced
> complexity or number of possible mixed old way/native use cases
> brought
> by the "network-scripts" compatibility layer provided by the ifcfg-
> rh
> plugin.
The compatibility layer doesn't need to concern you much. With this,
- connection profiles are persisted as ifcfg-rh files
- `ifup`/`ifdown` delegates to calling `nmcli connection up`
but there is no reason to even care about that and you can ignore
initscripts entirely. For example, the ifcfg-rh file format (`man nm-
settings-ifcfg-rh`) would only concern you if you plan to edit these
file manually. Which is more cumbersome then just using nmcli.
> As a matter of fact, I experimented a lot to be sure of who did what
> and
> how or when between network-scripts and NetworkManager.
>
> Digging deeper, things got clearer. Still I'm not really sure about
> the
> points described below.
>
> Notes :
>
> - I'm running NetworkManager-1.10.2-16.el7_5.x86_64 on a CentOS
> Linux
> release 7.5.1804 (Core)
> - I'm using default settings, so this must be ifcfg-rh plugin first,
> then keyfile otherwise
> - I'm talking only about ethernet connections/devices here
>
>
> 1. /run/NetworkManager/devices directory
>
>
> I know NetworkManager exports connections as
> /org/freedesktop/NetworkManager/Settings/ D-Bus objets
>
> What exactly is under /run/NetworkManager/devices/ path ? UUID
> inside those files don't always match what nmcli shows me ?
This directory is the internal per-device state. It should not be
necessary to be concerned with it (also: it's not stable nor public
API!). That said:
- the number is the "ifindex" of the device, as known to kernel and
visible in `ip link` output. This is the only real identifier for a
networking device in linux, as the name and MAC address may change.
That is why we usually match a profile against a device via attributes
like "connection.interface-name" or "ethernet.mac-address". This
ifindex is not meaningful after reboot. And so are all files under /run
(on RHEL/Fedora/CentOS this is a tempfs mount and lost after reboot).
- when NetworkManager is stopped, it writes there some state for each
file. In particular, so that `systemctl restart NetworkManager` works
better, with possibly few changes. One usually wouldn't ever restart
NetworkManager daemon (unless having good reasons, like package
update), but when doing so, the aim is that connectivity is not
affected. Hence the state directory.
- NetworkManger may also slightly behave differently whether it is
started the first time (for the current boot) or after a `systemctl
restart NetworkManager`. You see that in the logfile with
NetworkManager (version ...) is starting... (after a restart)
and this is also determined based on the presence of this "devices" directory.
If you stop NetworkManager and delete the directory, NetworkManager will think
it starts first time after boot. Again, the difference again shouldn't matter
and you shouldn't rely on this.
> 2. device vs connection
>
>
> My understanding is that there's a clear distinction between a
> device
> and a connection. To be more precise, that an active connection is a
> set
> of settings (potentially persisted on disk on a connection file via
> some
> plugin) "applied" to a device. The applied part is not very clear to
> me :
I find the name "profile" clearer. But we often say "connection" or
"connection profile". Sometimes also "settings connection" to
distinguish it from "active connection".
An "active connection" is the data associate with the fact that a
connection profile. There is the "device" ("networking interface"), the
profile, and when you activate a profile on a device, you also have an
"active connection". The active connection is usually not directly
visible in nmcli, except with `nmcli -f ACTIVE-PATH connection show`.
And of course, the current activation state with `nmcli -f NAME,STATE
connection show`.
> What's the difference between connecting a device (nmcli device
> connect)
> and activating a connection (nmcli connection up) ? Maybe my
> confusion
> comes from the fact that adding a connection automatically connects
> it
> to a device ?
There is little difference
- `nmcli connection up "$PROFILE"` will find a suitable device
automatically.
- `nmcli device connect "$DEVICE"` will find a suitable connection
automatically. Note this may create a new profile (see later).
- `nmcli connection up "$PROFILE" ifname "$DEVICE" explicitly selects
both the profile and the device.
As the profile contains the necessary settings for what to do with the
device, you cannot ~configure~ a device without a profile
Re: NetworkManager behavior answers not found in docs
I forgot : it seems to me that nmcli connection add also imply "managed" as in nmcli device set managed yes. Am I correct ? Then again when do we need those device commands manipulation ? thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
