1. 29 May, 2020 8 commits
    • Thomas Haller's avatar
      b4fb2a4f
    • Beniamino Galvani's avatar
      release: bump version to 1.25.2-dev · 043be769
      Beniamino Galvani authored
      043be769
    • Beniamino Galvani's avatar
      NEWS: update · 2a9c009a
      Beniamino Galvani authored
      2a9c009a
    • Thomas Haller's avatar
      NEWS: update · 268e1625
      Thomas Haller authored
      268e1625
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      device: reset original autoneg/speed/duplex setting on deactivate · 0b23ae31
      Thomas Haller authored
      The autoneg/speed ethtool settings are important. If they are wrong,
      the device might not get any carrier. Having no carrier means that
      you may be unable to activate a profile (because depending on
      configuration, carrier is required to activate a profile).
      
      Since activating profiles are the means to configure the link settings
      in NetworkManager, and activating a profile can be hampered by wrong link
      settings, it's important to reset the "correct" settings, when deactivating
      a profile.
      
      "Correct" in this case means to restore the settings that were present
      before NM changed the settings. Presumably, these are the right once.
      
      Beyond that, in the future it might make sense to support configuring
      the default link settings per device. So that NM will always restore a
      defined, configured, working state. The problem is that per-device
      settings currently are only available via NetworkManager.conf, which
      is rather inflexible.
      
      Also, when you restart NetworkManager service, it leaves the interface
      up but forgets the previous setting. That possibly could be fixed by
      persisting the previous link state in /run. However, it's not
      implemented yet.
      
      #356
      https://bugzilla.redhat.com/show_bug.cgi?id=1807171
      0b23ae31
    • 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
  2. 28 May, 2020 15 commits
  3. 27 May, 2020 7 commits
  4. 26 May, 2020 3 commits
  5. 25 May, 2020 2 commits
  6. 24 May, 2020 2 commits
  7. 23 May, 2020 1 commit
  8. 22 May, 2020 2 commits