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
