1. 15 Jun, 2022 8 commits
    • Lubomir Rintel's avatar
      nmcli/devices: add "checkpoint" command · 1c17e556
      Lubomir Rintel authored
      This is an interface to the Checkpoint/Restore functionality that's
      available for quite some time. It runs a command with a checkpoint taken
      and rolls back unless success is confirmed before the checkpoint times
      out:
      
        $ nmcli dev checkpoint eth0 -- nmcli dev dis eth0
        Device 'eth0' successfully disconnected.
        Type "Yes" to commit the changes: No
        Checkpoint was removed.
      
      The details about how it's used are documented in nmcli(1) and
      nmcli-examples(7).
      1c17e556
    • Lubomir Rintel's avatar
      nmcli: be less insistant on exiting when readline() gets no input · 47eaf963
      Lubomir Rintel authored
      When the input ends, we indeed eventually want to shut down.
      
      Nevertheless, it might be that we terminated the input *because* we're
      already shutting down and want do do our cleanup. Let's not take the
      shortcut to nmc_exit() in case the main loop is no longer running.
      
      This doesn't affect existing uses of nmc_readline(), but will be useful
      in a future patch.
      47eaf963
    • Lubomir Rintel's avatar
      nmcli/devices: use GPtrArray from get_device_list() directly · 5f9d2927
      Lubomir Rintel authored
      
      
      This makes get_device_list() return an array of NMDevices with a
      reference taken and a destroy notifier that unhooks disconnect_state_cb,
      so that it could replace the GSList of the same utility used by
      disconnect/delete commands.
      
      Suggested-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
      5f9d2927
    • Lubomir Rintel's avatar
      nmcli/devices: return GPtrArray instead of GSList from get_device_list() · 2074b289
      Lubomir Rintel authored
      A pointer array is slightly more efficient here, since we don't really
      need the ability to insert elements in the middle. In fact, we'd prefer
      if we could just add to the end, so that we'd spare some callers from a
      need to do a g_slist_reverse().
      
      Even though that alone being a good reason to use a GPtrArray instead of
      GSList, I'm doing this for so that I could actually use the returned value
      as-is in a call to nm_client_checkpoint_create() in a future patch.
      2074b289
    • Lubomir Rintel's avatar
      nmcli/devices: make get_device_list() terminate on "--" · 767afeff
      Lubomir Rintel authored
      Don't consider "--" a device name. Instead, treat it as a signal to stop
      reading the device list.
      
      If a caller expects nothing beyond the device names, it now has to
      check.
      767afeff
    • Lubomir Rintel's avatar
      nmcli/devices: make get_device_list() shift argc/argv · d576f4df
      Lubomir Rintel authored
      Prior to this patch, get_device_list() would give the caller no clue
      about how many options did it consume. That is okay -- it would always
      process all argument until the end, so the no callers would really care.
      
      In a further patch, I'd like to allow termination of the device name
      list (with a "--" arguments), so it will be possible to specify further
      arguments.
      
      Let's change the protype of this routine to use pointers to argc/argv,
      that it will be possible to adjust them.
      d576f4df
    • Lubomir Rintel's avatar
      glib-aux: add g_ptr_array_find() compat routine · e2fc81e2
      Lubomir Rintel authored
      I want it but GLib is no good. Sad.
      e2fc81e2
    • YsuOS's avatar
      nmcli: add nmcli gen reload usage · 7d499c4d
      YsuOS authored and Thomas Haller's avatar Thomas Haller committed
      !1257
      
      
      
      Signed-off-by: YsuOS's avatarRyosuke Yasuoka <yasuoka0830@gmail.com>
      7d499c4d
  2. 14 Jun, 2022 7 commits
    • Lubomir Rintel's avatar
      e5301e9a
    • Lubomir Rintel's avatar
      device: release slaves when an external device is going managed · 1f61f3f2
      Lubomir Rintel authored
      When we're deactivating an externally created device that has a master
      because we're activating a connection on it, actually remove the device
      from the master. Otherwise unpleasant things happen:
      
        active-connection[0x55ed7ba78400]: constructed (NMActRequest, version-id 4, type managed)
        device[0a458361f9fed8f5] (dummy0): sys-iface-state: external -> managed
        device[0a458361f9fed8f5] (dummy0): queue activation request waiting for currently active connection to disconnect
        device (dummy0): disconnecting for new activation request.
        device (dummy0): state change: activated -> deactivating (reason 'new-activation', sys-iface-state: 'managed')
        device (br0): master: release one slave 0a458361f9fed8f5/dummy0 (enslaved)(no-config)
      
      Note the "no-config" above. We'set priv->master = NULL, but didn't
      communicate the change to the platform. I believe this is not good.
      This patch changes that.
      
        device (br0): bridge port dummy0 was detached
        device (dummy0): released from master device br0
        active-connection[0x55ed7ba782e0]: set state deactivating (was activated)
        device (dummy0): ip4: set state none (was done, reason: ip-state-clear)
        device (dummy0): ip6: set state none (was done, reason: ip-state-clear)
        device (dummy0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed')
      
        platform: (dummy0) emit signal link-changed changed: 102: dummy0
            <NOARP,UP,LOWER_UP;broadcast,noarp,up,running,lowerup> mtu 1500 master 101 arp 1 dummy* init
             addrgenmode none addr EA:8D:DD:DF:1F:B7 brd FF:FF:FF:FF:FF:FF driver dummy rx:0,0 tx:39,4746
      
      Now the platform sent us a new link, the "master" property is still set.
      
        device[0a458361f9fed8f5] (dummy0): queued link change for ifindex 102
        device[0a458361f9fed8f5] (dummy0): deactivating device (reason 'new-activation') [60]
        device (dummy0): ip: set (combined) state none (was done, reason: ip-state-clear)
        config: device-state: write #102 (/run/NetworkManager/devices/102); managed=managed, perm-hw-addr-fake=EA:8D:DD:DF:1F:B7, route-metric-default=0-0
        active-connection[0x55ed7ba782e0]: set state deactivated (was deactivating)
        active-connection[0x55ed7ba782e0]: check-master-ready: already signalled (state deactivated, master 0x55ed7ba781c0 is in state activated)
        device (dummy0): Activation: starting connection 'dummy1' (ec6fca51-84e6-4a5b-a297-f602252c9f69)
        device[0a458361f9fed8f5] (dummy0): activation-stage: schedule activate_stage1_device_prepare
      
        l3cfg[ae290b5c1f585d6c,ifindex=102]: emit signal (platform-change-on-idle, obj-type-flags=0x2a)
        device (br0): master: add one slave 0a458361f9fed8f5/dummy0
      
      Amidst the new activation we're processing the netlink message we got.
      We set priv->master back, effectively nullifying the release above. Sad.
      
        device (dummy0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
        device[0a458361f9fed8f5] (dummy0): add_pending_action (2): 'in-state-change'
        active-connection[0x55ed7ba78400]: set state activating (was unknown)
        manager: NetworkManager state is now CONNECTING
        active-connection[0x55ed7ba78400]: check-master-ready: not signalling (state activating, no master)
        device[8fff58d61c7686ce] (br0): slave dummy0 state change 30 (disconnected) -> 40 (prepare)
        device[0a458361f9fed8f5] (dummy0): remove_pending_action (1): 'in-state-change'
        device (br0): master: release one slave 0a458361f9fed8f5/dummy0 (not enslaved) (force-configure)
        platform: (dummy0) link: releasing 102 from master 'br0' (101)
        device (br0): detached bridge port dummy0
      
      Now things go south. The stage1 cleans the device up, removing it from
      the master and the device itself decides it should deactivate itself
      because it lots its master regardless of the fact that it should not
      have one and it's in fact an unwanted carryover from previous activation.
      I believe this is also wrong.
      
        device[0a458361f9fed8f5] (dummy0): Activation: connection 'dummy1' master deactivated
        device (dummy0): ip4: set state none (was pending, reason: ip-state-clear)
        device (dummy0): ip6: set state none (was pending, reason: ip-state-clear)
        device[0a458361f9fed8f5] (dummy0): add_pending_action (2): 'queued-state-change-deactivating'
        device[0a458361f9fed8f5] (dummy0): queue-state[deactivating, reason:connection-assumed, id:298]: queue state change
        device[0a458361f9fed8f5] (dummy0): activation-stage: synchronously invoke activate_stage2_device_config
        device (dummy0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
      
      Now things are really weird. We synchronously go to config, effectively
      overriding the queued deactivation. We've really messed up.
      1f61f3f2
    • Lubomir Rintel's avatar
      device: only deactivate when the master we've enslaved to goes away · 1fe8166f
      Lubomir Rintel authored
      Sometimes weird things happen.
      
      Let dummy0 be an externally created device that has a master. We decide
      to activate a connection that has no master on it:
      
        active-connection[0x55ed7ba78400]: constructed (NMActRequest, version-id 4, type managed)
        device[0a458361f9fed8f5] (dummy0): sys-iface-state: external -> managed
        device[0a458361f9fed8f5] (dummy0): queue activation request waiting for currently active connection to disconnect
        device (dummy0): disconnecting for new activation request.
        device (dummy0): state change: activated -> deactivating (reason 'new-activation', sys-iface-state: 'managed')
        device (br0): master: release one slave 0a458361f9fed8f5/dummy0 (enslaved)(no-config)
      
      Note the "no-config" above. We'set priv->master = NULL, but didn't
      communicate the change to the platform. I believe this is not good.
      
        device (br0): bridge port dummy0 was detached
        device (dummy0): released from master device br0
        active-connection[0x55ed7ba782e0]: set state deactivating (was activated)
        device (dummy0): ip4: set state none (was done, reason: ip-state-clear)
        device (dummy0): ip6: set state none (was done, reason: ip-state-clear)
        device (dummy0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed')
      
        platform: (dummy0) emit signal link-changed changed: 102: dummy0
            <NOARP,UP,LOWER_UP;broadcast,noarp,up,running,lowerup> mtu 1500 master 101 arp 1 dummy* init
             addrgenmode none addr EA:8D:DD:DF:1F:B7 brd FF:FF:FF:FF:FF:FF driver dummy rx:0,0 tx:39,4746
      
      Now the platform sent us a new link, the "master" property is still set.
      
        device[0a458361f9fed8f5] (dummy0): queued link change for ifindex 102
        device[0a458361f9fed8f5] (dummy0): deactivating device (reason 'new-activation') [60]
        device (dummy0): ip: set (combined) state none (was done, reason: ip-state-clear)
        config: device-state: write #102 (/run/NetworkManager/devices/102); managed=managed, perm-hw-addr-fake=EA:8D:DD:DF:1F:B7, route-metric-default=0-0
        active-connection[0x55ed7ba782e0]: set state deactivated (was deactivating)
        active-connection[0x55ed7ba782e0]: check-master-ready: already signalled (state deactivated, master 0x55ed7ba781c0 is in state activated)
        device (dummy0): Activation: starting connection 'dummy1' (ec6fca51-84e6-4a5b-a297-f602252c9f69)
        device[0a458361f9fed8f5] (dummy0): activation-stage: schedule activate_stage1_device_prepare
      
        l3cfg[ae290b5c1f585d6c,ifindex=102]: emit signal (platform-change-on-idle, obj-type-flags=0x2a)
        device (br0): master: add one slave 0a458361f9fed8f5/dummy0
      
      Amidst the new activation we're processing the netlink message we got.
      We set priv->master back, effectively nullifying the release above.
      
        device (dummy0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
        device[0a458361f9fed8f5] (dummy0): add_pending_action (2): 'in-state-change'
        active-connection[0x55ed7ba78400]: set state activating (was unknown)
        manager: NetworkManager state is now CONNECTING
        active-connection[0x55ed7ba78400]: check-master-ready: not signalling (state activating, no master)
        device[8fff58d61c7686ce] (br0): slave dummy0 state change 30 (disconnected) -> 40 (prepare)
        device[0a458361f9fed8f5] (dummy0): remove_pending_action (1): 'in-state-change'
        device (br0): master: release one slave 0a458361f9fed8f5/dummy0 (not enslaved) (force-configure)
        platform: (dummy0) link: releasing 102 from master 'br0' (101)
        device (br0): detached bridge port dummy0
      
      Now stage1 cleans the device up, removing it from the master.
      
        device[0a458361f9fed8f5] (dummy0): Activation: connection 'dummy1' master deactivated
        device (dummy0): ip4: set state none (was pending, reason: ip-state-clear)
        device (dummy0): ip6: set state none (was pending, reason: ip-state-clear)
        device[0a458361f9fed8f5] (dummy0): add_pending_action (2): 'queued-state-change-deactivating'
      
      We decide to deal with this by enqueuing a deactivation. That is not
      great -- we shouldn't even have had this master!
      
      This patch takes the deactivation path only if we were willingly
      enslaved to the master in question.
      1fe8166f
    • Lubomir Rintel's avatar
      device: stop checking the IP configuration state when cancelling activation · 0fa8c5f9
      Lubomir Rintel authored
      The @bond_mode_8023ad test has been seen failing, with a log like this:
      
        <debug> [...3.0484] device[...] (eth1): Activation: connection 'bond0.0' master deactivated
        <debug> [...3.0484] device[...] (eth1): add_pending_action (2): 'queued-state-change-deactivating'
        <debug> [...3.0484] device[...] (eth1): queue-state[deactivating, reason:new-activation, id:709]: queue state change
      
      What happened is that eth1 has been activating. It was already enslaved
      to a bond and was in an ip-config state when the bond was removed.
      A change to "deactivating" state has been enqueued. But then this
      happened:
      
        <trace> [...3.0942] device[...] (eth1): ip4: check-state: state done => done, is_failed=0, is_pending=0,
                            is_started=0 temp_na=0, may-fail-4=1, may-fail-6=1; disabled4; manualip4=done; ignore6 manualip6=done
        <trace> [...3.0942] device[...] (eth1): ip: check-state: (combined) state pending => done
        <debug> [...3.0943] device[...] (eth1): ip: set (combined) state done (was pending, reason: check-ip-state)
        <info>  [...3.0943] device (eth1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
        <debug> [...3.0943] device[...] (eth1): add_pending_action (3): 'in-state-change'
        <debug> [...3.0943] device[...] (eth1): queue-state[deactivating, reason:new-activation, id:709]: clear queued state change
      
      The IP config succeeded and the queued "deactivating" change was
      overriden by the IP4 check result, prompting a change to "ip-check".
      With the master still missing. Not good.
      
      Let's terminate the appempts to check the IP state when we cancel the
      activation, so that it doesn't override the enqueued state change.
      
      Fixes-test: @bond_mode_8023ad
      
      https://bugzilla.redhat.com/show_bug.cgi?id=2080928
      !1245
      0fa8c5f9
    • Beniamino Galvani's avatar
    • Beniamino Galvani's avatar
      ppp: don't remove addresses from interface while IPCP/IPV6CP is running · b41b11d6
      Beniamino Galvani authored
      pppd also tries to configure addresses by itself through some
      ioctls. If we remove between those calls an address that was added,
      pppd fails and quits.
      
      To avoid this race condition, don't remove addresses while IPCP and
      IPV6CP are running. Once pppd sends an IP configuration, it has
      finished configuring the interface and we can proceed normally.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=2085382
      b41b11d6
    • Beniamino Galvani's avatar
      core: add nm_l3cfg_block_obj_pruning() · e8275d71
      Beniamino Galvani authored
      Add a function prevent the removal of addresses and routes from the
      interface for a given address family.
      e8275d71
  3. 11 Jun, 2022 1 commit
    • Beniamino Galvani's avatar
      device: ensure DHCP is restarted every time the link goes up · d6429d3d
      Beniamino Galvani authored
      Currently we call nm_device_update_dynamic_ip_setup() in
      carrier_changed() every time the carrier goes up again and the device
      is activating, to kick a restart of DHCP.
      
      Since we process link events in a idle handler, it can happen that the
      handler is called only once for different events; in particular
      device_link_changed() might be called once for a link-down/link-up
      sequence.
      
      carrier_changed() is "level-triggered" - it cares only about the
      current carrier state. nm_device_update_dynamic_ip_setup() should
      instead be "edge-triggered" - invoked every time the link goes from
      down to up. We have a mechanism for that in device_link_changed(), use
      it.
      
      Fixes-test: @ipv4_spurious_leftover_route
      
      https://bugzilla.redhat.com/show_bug.cgi?id=2079406
      !1250
      d6429d3d
  4. 10 Jun, 2022 1 commit
  5. 09 Jun, 2022 9 commits
  6. 08 Jun, 2022 1 commit
  7. 07 Jun, 2022 3 commits
  8. 03 Jun, 2022 2 commits
  9. 02 Jun, 2022 3 commits
  10. 01 Jun, 2022 3 commits
  11. 31 May, 2022 2 commits