1. 14 Jun, 2022 4 commits
    • 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
      NetworkManager/NetworkManager!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
  2. 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
      NetworkManager/NetworkManager!1250
      d6429d3d
  3. 10 Jun, 2022 1 commit
  4. 09 Jun, 2022 9 commits
  5. 08 Jun, 2022 1 commit
  6. 07 Jun, 2022 3 commits
  7. 03 Jun, 2022 2 commits
  8. 02 Jun, 2022 3 commits
  9. 01 Jun, 2022 3 commits
  10. 31 May, 2022 13 commits