1. 09 Sep, 2020 1 commit
  2. 01 Sep, 2020 1 commit
  3. 31 Aug, 2020 1 commit
    • Beniamino Galvani's avatar
      device: fix autoactivating virtual devices after a failure · dac89c07
      Beniamino Galvani authored
      When a virtual device fails, its state goes to FAIL and then
      DISCONNECTED. In DISCONNECTED we call schedule_activate_check() to
      schedule an auto-activation if needed. We also schudule the deletion
      of the link through delete_on_deactivate_check_and_schedule(). The
      auto-activation attempt fails because the link deletion unmanages the
      device; as a result, the device doesn't try to auto-activate again.
      
      To fix this:
      
       - don't allow the device to auto-activate if the device deletion is
         pending;
      
       - check again if the device can be auto-activated after its deletion.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1818697
      !613
      (cherry picked from commit e404585e)
      dac89c07
  4. 28 Aug, 2020 1 commit
    • Thomas Haller's avatar
      device: fix casting pointer to enum for sriov_reset_on_deactivate_cb() · 32641b9f
      Thomas Haller authored
      Avoids a compiler warning:
      
          ../src/devices/nm-device.c:16079:26: error: cast to smaller integer type 'NMDeviceStateReason' from 'gpointer' (aka 'void *') [-Werror,-Wvoid-pointer-to-enum-cast]
                  deactivate_ready (self, (NMDeviceStateReason) reason);
                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Fixes: 121c58f0 ('core: set number of SR-IOV VFs asynchronously')
      (cherry picked from commit 918ebd60)
      32641b9f
  5. 26 Aug, 2020 1 commit
  6. 29 Jul, 2020 1 commit
    • Beniamino Galvani's avatar
      dhcp6: don't require a hardware address · 905d4eb3
      Beniamino Galvani authored
      The systemd DHCPv6 client requires a hardware address only to
      determine the IAID; NM always overrides the IAID with its own and
      therefore the hwaddr is not used.
      
      Removing such requirement allows DHCPv6 to run over PPP, which is
      useful with DHCPv6-PD to get a prefix from the ISP.
      
      To test this, I set up a server with pppoe-server, radvd and the Wide
      DHCPv6 server providing an address and a prefix. On the client, NM was
      able to obtain a prefix using both dhcp=dhclient and dhcp=systemd.
      
      Note that if there is no hardware address and you specify
      ipv6.dhcp-duid=ll or ipv6.dhcp-iaid=mac, a warning will be emitted and
      NM will use a random DUID/IAID.
      
      #478
      (cherry picked from commit 76a6a305)
      905d4eb3
  7. 24 Jul, 2020 1 commit
  8. 15 Jul, 2020 1 commit
  9. 10 Jul, 2020 3 commits
  10. 09 Jul, 2020 1 commit
  11. 08 Jul, 2020 1 commit
    • Beniamino Galvani's avatar
      ppp: fix taking control of link generated by kernel · 72d66fff
      Beniamino Galvani authored
      NetworkManager can't control the name of the PPP interface name
      created by pppd; so it has to wait for the interface to appear and
      then rename it. This happens in nm_device_take_over_link() called by
      nm-device-ppp.c:ppp_ifindex_set() when pppd tells NM the ifindex of
      the interface that was created.
      
      However, sometimes the initial interface name is already correct, for
      example when the connection.interface-name is ppp0 and this is the
      first PPP interface created.
      
      When this happens, nm_device_update_from_platform_link() is called on
      the NMDevicePPP and it sets the device ifindex. Later, when pppd
      notifies NM, nm_device_take_over_link() fails because the ifindex is
      already set:
      
       nm_device_take_over_link: assertion 'priv->ifindex <= 0' failed
      
      Make nm_device_take_over_link() more robust to cope with this
      situation.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1849386
      (cherry picked from commit 75bc21c4)
      72d66fff
  12. 06 Jul, 2020 2 commits
  13. 28 Jun, 2020 1 commit
  14. 26 Jun, 2020 1 commit
  15. 12 Jun, 2020 2 commits
  16. 11 Jun, 2020 1 commit
    • Thomas Haller's avatar
      lldp: only have GHashTable instance for LLDP neighbors when running · 0d41abea
      Thomas Haller authored
      When the instance is not running (after creation or after stop), there
      is no need to keep the GHashTable around.
      
      Create it when needed (during start) and clear it during stop. This
      makes it slightly cheaper to keep a NMLldpListener instance around,
      if it's currently not running.
      
      NMDevice already keeps the NMLldpListener around, even after stopping
      it. It's not clear whether the instance will be started again, so also
      clear the GHashTable. Also, one effect is that if you initially were in
      a network with many LLDP neibors, after stop and start, the GHashTable
      now gets recreated and may not need to allocate a large internal array
      as before.
      0d41abea
  17. 10 Jun, 2020 1 commit
    • Thomas Haller's avatar
      core: add "external" flag for connections of external devices · 96c9703b
      Thomas Haller authored
      When a device is not marked as unmanaged, but also not actively managed
      by NetworkManager, then NetworkManager will generate an in-memory
      profile to represent the active state, if the device is up and
      configured (with an IP address).
      
      Such profiles are commonly named like "eth0", and they are utterly
      confusing to users, because they look as if NetworkManager actually
      manages the device, when it really just shows that somebody else configures
      the device.
      
      We should express this better in the UI, hence add flags to indicate
      that.
      
      In practice, such profiles are UNSAVED, NM_GENERATED, and VOLATILE. But
      add an explicit flag to represent that.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1816202
      96c9703b
  18. 08 Jun, 2020 1 commit
  19. 29 May, 2020 2 commits
    • Thomas Haller's avatar
      device: inline nm_platform_ethtool_init_ring() function · 23d0a76b
      Thomas Haller authored
      nm_platform_ethtool_init_ring() only has one caller. It's simpler to
      drop the function and implement it at the only place where it is needed.
      
      Maybe there could be a place for a function to initialize NMEthtoolRingState,
      one option after the other. However, at the moment there is only one
      user, so don't implement it.
      
      This fixes various minor issues:
      
      - the function had a NMPlatform argument, although the argument
        is not used. Thus function merely operates on a NMEthtoolRingState
        instance and shouldn't have a nm_platform_*() name.
      
      - nm_platform_ethtool_init_ring() returned a boolean, but all
        code paths (except assertion failures) returned success.
      
      - as the function returned an error status, the caller was compelled
        to handle an error that could never happen.
      
      - the option was specified by name, although we already have a more
        efficient way to express the option: the NMEthtoolID. Also, the
        caller already needed to resolve the name to the NMEthtoolID, so
        there was no need to again lookup the ID by name.
      23d0a76b
    • Thomas Haller's avatar
      device: only ready existing ethtool ring settings if needed · 9c236416
      Thomas Haller authored
      Imagine you have a veth device. That device supports certain offload features
      (like "ethtool.feature-rx-checksum") but doesn't support any ring
      options. Even trying to read the current ring settings will fail.
      
      If you try to activate that profile, NMDevice previously would always
      try to fetch the ring options and log a warning and extra debugging
      messages:
      
        <trace> [1590511552.3943] ethtool[31]: ETHTOOL_GRINGPARAM, v: failed: Operation not supported
        <trace> [1590511552.3944] ethtool[31]: get-ring: failure getting ring settings
        <warn>  [1590511552.3944] device (v): ethtool: failure getting ring settings (cannot read)
      
      It does so, although you didn't specify any ring settings and there
      was no need to fetch the ring settings to begin with.
      
      Avoid this extra logging by only fetching the ring option when they
      are actually required.
      9c236416
  20. 28 May, 2020 2 commits
    • Beniamino Galvani's avatar
      core: clear IPv6 kernel token when deactivating a device · 49305559
      Beniamino Galvani authored
      Clear the IPv6 kernel token when deactivating a device.
      49305559
    • Beniamino Galvani's avatar
      device: set accept_ra to 1 when changing IPv6 kernel token · 1d6b9953
      Beniamino Galvani authored
      Setting the kernel token is not strictly necessary as the IPv6 address
      is generated in userspace by NetworkManager. However it is convenient
      for users to see that the value set in the profile is also set in the
      kernel, to confirm that everything is working as expected.
      
      The kernel allows setting a token only when 'accept_ra' is 1:
      temporarily flip it if necessary. Unfortunately this will also
      generate an additional Router Solicitation from kernel, but this is
      not a big issue.
      1d6b9953
  21. 27 May, 2020 1 commit
  22. 22 May, 2020 3 commits
    • Thomas Haller's avatar
      libnm: rename nm_setting_gendata_*() API to nm_setting_option_*() · 618ae93b
      Thomas Haller authored
      We are going to expose some of this API in libnm.
      
      The name "gendata" (for "generic data") is not very suited. Instead,
      call the public API nm_setting_option_*(). This also brings no naming
      conflict, because currently no API exists with such naming.
      
      Rename the internal API, so that it matches the API that we are going
      to expose next.
      618ae93b
    • Thomas Haller's avatar
      platform: make states of NMEthtoolCoalesceState indexed by ethtool_id · 1f4b1909
      Thomas Haller authored
      We already have NMEthtoolID to handle coalesce options in a way that is
      convenient programmatically. That is, we can iterate over all valid
      coalesce options (it's just an integer) and use that in a more generic
      way.
      
      If NMEthtoolCoalesceState names all fields explicitly, we need explicit
      code that names each coalesce option. Especially since NMEthtoolCoalesceState
      is an internal and intermediate data structure, this is cumbersome
      and unnecessary.
      
      Thereby it also fixes the issue that nm_platform_ethtool_init_coalesce() has a
      NMPlatform argument without actually needing it.
      nm_platform_ethtool_init_coalesce() does not operate on a NMPlatform
      instance, and should not have the appearance of being a method of
      NMPlatform.
      1f4b1909
    • Thomas Haller's avatar
      device: in _ethtool_coalesce_set() only fetch current coalesce settings if needed · 1f5f8408
      Thomas Haller authored
      In the common case, the user doesn't set any coalesce options. Avoid always
      fetching the current settings, unless they are actually needed.
      1f5f8408
  23. 20 May, 2020 2 commits
    • Antonio Cardace's avatar
      nm-device: apply ethtool ring settings when activating a connection · 2ce0e714
      Antonio Cardace authored
      nm-device now applies ethtool ring settings during stage 2 "device
      config" of the connection activation.
      
      ring settings will be then restored (according to what the state
      was before the connection got activated on the device) when the
      connection is deactivated during the device cleanup.
      
      One thing to be noted is that unset ring settings (in the profile)
      will not be touched at all by NetworkManager so that if the NIC driver
      sets some default values these will be preserved unless specifically
      overridden by the connection profile.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1614700
      2ce0e714
    • Thomas Haller's avatar
      platform: simplify NMEthtoolCoalesceState to only track one state · 12063d6c
      Thomas Haller authored
      Only in one moment we need the old and requested settings together:
      during _ethtool_coalesce_set(). But for that we shouldn't track both
      states in "NMEthtoolCoalesceState".
      
      Simplify "NMEthtoolCoalesceState" to only contain one set of options.
      By tracking less state, the code becomes simpler, because you don't
      need to wonder where the old and requested state is used.
      12063d6c
  24. 15 May, 2020 1 commit
    • Beniamino Galvani's avatar
      device: use the nm-shared firewalld zone in shared mode · 3e2b7235
      Beniamino Galvani authored
      When the interface is in IPv4 or IPv6 shared mode and the user didn't
      specify an explicit zone, use the nm-shared one.
      
      Note that masquerade is still done through iptables direct calls
      because at the moment it is not possible for a firewalld zone to do
      masquerade based on the input interface.
      
      The firewalld zone is needed on systems where firewalld is using the
      nftables backend and the 'iptables' binary uses the iptables API
      (instead of the nftables one). On such systems, even if the traffic is
      allowed in iptables by our direct rules, it can still be dropped in
      nftables by firewalld.
      3e2b7235
  25. 13 May, 2020 1 commit
    • Antonio Cardace's avatar
      nm-device: apply ethtool coalesce settings when activating a connection · e2be41cb
      Antonio Cardace authored
      nm-device now applies ethtool coalesce settings during stage 2 "device
      config" of the connection activation.
      
      Coalesce settings will be then restored (according to what the state
      was before the connection got activated on the device) when the
      connection is deactivated during the device cleanup.
      
      One thing to be noted is that unset coalesce settings (in the profile)
      will not be touched at all by NetworkManager so that if the NIC driver
      sets some default values these will be preserved unless specifically
      overridden by the connection profile.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1614700
      e2be41cb
  26. 12 May, 2020 1 commit
  27. 06 May, 2020 4 commits
  28. 29 Apr, 2020 1 commit
    • Thomas Haller's avatar
      device: implement "auth-request" as async operation nm_manager_device_auth_request() · fa5434fa
      Thomas Haller authored
      GObject signals only complicate the code and are less efficient.
      
      Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous
      request. Of course, fundamentally emitting a signal *is* the same as
      calling a method. However, implementing this as signal is really not
      nice nor best practice. For one, there is a (negligible) overhead emitting
      a GObject signal. But what is worse, GObject signals are not as strongly
      typed and make it harder to understand what happens.
      
      The signal had the appearance of providing some special decoupling of
      NMDevice and NMManager. Of course, in practice, they were not more
      decoupled (both forms are the same in nature), but it was harder to
      understand how they work together.
      
      Add and call a method nm_manager_device_auth_request() instead. This
      has the notion of invoking an asynchronous method. Also, never invoke
      the callback synchronously and provide a cancellable. Like every asynchronous
      operation, it *must* be cancellable, and callers should make sure to
      provide a mechanism to abort.
      
      (cherry picked from commit b5070277)
      fa5434fa