1. 13 Jul, 2020 6 commits
  2. 11 Jul, 2020 12 commits
    • Thomas Haller's avatar
      bond: merge branch 'th/bond-normalize' · 6225ace7
      Thomas Haller authored
      !570
      
      (cherry picked from commit ecba9219)
      6225ace7
    • Thomas Haller's avatar
      tui: fix default values for bond options in nmtui · a55b5144
      Thomas Haller authored
      When configuring miimon settings, the updelay/downdelay fields with
      value zero may not be stored in the setting.
      
      For example:
      
      - have a profile with "mode=balance-rr,arp_interval=11,arp_ip_target=10.10.10.1,miimon=10"
        Switch the link monitoring mode to "MII" and press <OK>. Previously,
        the change of the link monitoring did not update the settings, and
        nothing was changed.
      
      - when loading settings, initialize all fields with the values from the
        settings, regardless whether they are currently visible or not.
        Otherwise, if you edit a profile with
        "mode=balance-rr,arp_interval=11,arp_ip_target=10.10.10.1,miimon=10"
        and switch link monitoring mode to "MII", the miimon setting was not
        initialized to 10.
      
      - accept empty bond settings, for example for updelay. In that case,
        initialize the text input to "0". Likewise, when the text entry is
        empty, set the bond option to the respective default.
      
      #488
      (cherry picked from commit 61d4bc62)
      a55b5144
    • Thomas Haller's avatar
      libnm: add _nm_setting_bond_mode_from_string() to nm-libnm-core-intern · b3775325
      Thomas Haller authored
      (cherry picked from commit a0b22b5b)
      b3775325
    • Thomas Haller's avatar
      tui: fix alternating miimon/arp_interval settings for bond options in nmtui · 131794b5
      Thomas Haller authored
      (cherry picked from commit 211d7998)
      131794b5
    • Thomas Haller's avatar
      cli: fix alternating miimon/arp_interval settings for bond options in nmcli · 9d918e55
      Thomas Haller authored
      Before 1.24, nm_setting_bond_add_option() would clear
      miimon/arp_interval settings when the respective other was set.
      
      That was no longer done, with the effect that enabling (for example)
      miimon on a bond profile that has arp_interval enabled, sets both
      conflicting options.
      
      That is not a severe problem, because the profile still validates.
      However, at runtime only one of the settings can be actually configured.
      
      Fix that, by restoring the previous behavior for the client. But note
      that this time it's implemented in the client, and not in libnm's
      nm_setting_bond_add_option().
      
      (cherry picked from commit b55578bf)
      9d918e55
    • Thomas Haller's avatar
      bond: log only skipped bond options if they are set in the profile · 0c75899d
      Thomas Haller authored
      (cherry picked from commit 3a25b3bf)
      0c75899d
    • Thomas Haller's avatar
      libnm,core: fix handling miimon and arp_interval as conflicting kernel options · 96edc84b
      Thomas Haller authored
      We use sysfs API for setting bond options. Note that the miimon and
      arp_interval settings conflict each other, and whenever setting one
      of these sysfs values, the other one gets reset. That means,
      NetworkManager needs to mediate and handle a profile which has both
      these options set.
      
      Before 1.24, the libnm API nm_setting_bond_add_option() API would mangle
      the content of the bond settings, to clear the respective other fields
      when setting miimon/arp_interval. That also had the effect that the
      settings plugins, weren't able to read such (conflicting) settings
      back from disk (but they would write them to disk). If a keyfile
      specified both miimon and arp_interval keys, then it would depend on
      their order in the keyfile which wins.
      It is wrong that a libnm property setter mangles the option in such a way,
      especially, because you still could set the NM_SETTING_BOND_OPTIONS
      property directly and bypass this. So, since 1.24, you can create
      profiles that have conflicting options.
      
      Also, we can now not start to reject such settings as invalid, because that
      would be an API break. Instead, just make sure that when one of the
      settings is set, that the other one consistently gets deactivated.
      
      Also, before 1.24 already, NMDeviceBond would mediate whether to either set
      miimon or arp_interval settings. Despite that the keyfile reader would
      mangle the settings, it would also prefer miimon over arp_interval,
      if both were set.
      
      This mechanism was broken since we switch to _bond_get_option_normalized()
      for that. As a consequence, NetworkManager would try to set both the
      conflicting options. Fix that.
      
      (cherry picked from commit 4aa46328)
      96edc84b
    • Thomas Haller's avatar
      libnm: don't fail assertion for _bond_get_option_normalized() with invalid bond mode · 491cd1d2
      Thomas Haller authored
      _bond_get_option_normalized() gets called with code paths that don't
      assume a valid options hash. That means, the bond mode might be invalid
      and we should fail an assertion.
      
      (cherry picked from commit 1543f8a1)
      491cd1d2
    • Thomas Haller's avatar
      device/bond: rework setting of arp_ip_target bond options · 45c95e93
      Thomas Haller authored
      - the arp_ip_target option in the settings might not have normalized
        IP addresses or duplicates. If there would be duplicates, setting
        them twice would fail with EINVAL. Hence, first normalize them
        and make them unique.
      
      - if what we want to set is identical to what is already set, don't
        do anything.
      
      (cherry picked from commit 6a923a5d)
      45c95e93
    • Thomas Haller's avatar
      libnm: cleanup validating bond option "arp_ip_target" · c284f3c7
      Thomas Haller authored
      We already have meta data for all bond options. For example,
      "arp_ip_target" has type NM_BOND_OPTION_TYPE_IP.
      
      Also, verify() already calls nm_setting_bond_validate_option() to validate
      the option. Doing a second validation below is redundant (and done
      inconsistently).
      
      Validate the setting only once.
      
      Also beef up the validation and use nm_utils_bond_option_arp_ip_targets_split()
      to parse the IP addresses. This now strips extra whitespace and (as
      before) removes empty entries.
      
      (cherry picked from commit e96051d7)
      c284f3c7
    • Thomas Haller's avatar
      libnm: add nm_utils_bond_option_arp_ip_targets_split() helper · 2f43cde2
      Thomas Haller authored
      Note yet used. The way how we split the option is relevant at various
      places. The code should use the same helper function.
      
      (cherry picked from commit 4ee0e8f0)
      2f43cde2
    • Thomas Haller's avatar
      shared: assert that nm_utils_strsplit_set_full() returns non-empty strv array · b5e5356a
      Thomas Haller authored
      (cherry picked from commit f78e0bf2)
      b5e5356a
  3. 10 Jul, 2020 5 commits
  4. 09 Jul, 2020 9 commits
  5. 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
  6. 07 Jul, 2020 1 commit
    • Thomas Haller's avatar
      core: fix treating route metric zero of IPv6 routes special · 2ced21c5
      Thomas Haller authored
      Userspace cannot add IPv6 routes with metric 0. Trying to do that, will
      be coerced by kernel to route metric 1024. For IPv4 this is different,
      and metric zero is commonly allowed.
      
      However, kernel itself can add IPv6 routes with metric zero:
      
        # ip -6 route show table local
        local fe80::2029:c7ff:fec9:698a dev v proto kernel metric 0 pref medium
      
      That means, we must not treat route metric zero special for most cases.
      Only, when we want to add routes (based on user configuration), we must
      coerce a route metric of zero to 1024.
      
      !563
      (cherry picked from commit 1b408e24)
      2ced21c5
  7. 06 Jul, 2020 6 commits