1. 06 Mar, 2020 11 commits
    • Antonio Cardace's avatar
    • Antonio Cardace's avatar
      nmtui: only set 'mode' and enable 'miimon' when setting up a new connection · 40ea0335
      Antonio Cardace authored
      When creating a new connection before the user gets the chance to modify
      the bond options let's just initialize 'mode' and 'miimon' (with related
      'updelay' and 'downdelay').
      Initializing also 'arp_interval', 'arp_ip_target' and 'primary' doesn't
      make much sense as by default they're disabled or contain empty values.
    • Antonio Cardace's avatar
      nm-setting-bond: add API to libnm to get the normalized bond option value · b868fee9
      Antonio Cardace authored
      Add 'nm_setting_bond_get_option_normalized()', the purpose of this API
      is to retrieve a bond option normalized value which is the option that
      NetworkManager will actually apply to the bond when activating the
      connection, this takes into account default values for some options that
      NM assumes.
      For example, if you create a connection:
      $ nmcli c add type bond con-name nm-bond ifname bond0 bond.options mode=0
      Calling 'nm_setting_bond_get_option_normalized(s_bond, "miimon")' would
      return "100" as even if not specified NetworkManager enables miimon for
      bond connections.
      Another example:
      $ nmcli c add type bond con-name nm-bond ifname bond0 bond.options mode=0,arp_interval=100
      Calling 'nm_setting_bond_get_option_normalized(s_bond, "miimon")' would
      return NULL in this case because NetworkManager disables miimon if
      'arp_interval' is set explicitly but 'miimon' is not.
    • Antonio Cardace's avatar
      bond: bond options logic rework · 9bd07336
      Antonio Cardace authored
      Add '_nm_setting_bond_get_option_or_default()' and move all the custom
      policies applied by NM for bond options in there.
      One such example of a custom policy is to set 'miimon' to 0 (instead of its
      default value of 100) if 'arp_interval' is explicitly enabled
      and 'miimon' is not.
      This means removing every piece of logic from
      nm_setting_bond_add_option() which used to clear out 'arp_interval' and
      'arp_ip_target' if 'miimon' was set or clear out 'miimon' along with
      'downdelay', 'updelay' and 'miimon' if 'arp_interval' was set.
      This behaviour is a bug since the kernel allow setting any combination
      of this options for bonds and NetworkManager should not limit the user
      to do so.
      Also use 'set_bond_attr_or_default()' instead of 'set_bond_attr()' as
      the former calls '_nm_setting_bond_get_option_or_default()' to implement
      the right logic to retrieve bond options according to current bond
    • Antonio Cardace's avatar
      nm-setting-bond: let 'miimon' and 'arp_interval' coexist for verify() · 57bdf680
      Antonio Cardace authored
      Fix 'miimon' and 'arp_interval' validation, they can both be set indeed,
      the kernel does not impose this limitation, nevertheless is sensible to
      keep the defaults as previously (miimon=100, arp_interval=0).
      Also add unit test.
    • Antonio Cardace's avatar
      nm-setting-bond: if unset consider bond options with default values for validation · c07f3b51
      Antonio Cardace authored
      Doing 'verify()' with options such as 'miimon' and 'num_grat_arp' set to
      arbitrary values it's not consistent with what NetworkManager does to
      bond options when activating the bond through 'apply_bonding_config()'
      (at a later stage) because the said values do not
      correspond to what the default values for those options are.
      This leads to an inconsistency with the 'miimon' parameter for example,
      where 'verify()' is done while assuming it's 0 if not set but its
      default value is actually 100.
      Fixes: 8775c25c ('libnm: verify bond option in defined order')
    • Thomas Haller's avatar
      ifcfg-rh: use binary search for converting string to ethtool ID · d482eec6
      Thomas Haller authored
      Don't do a linear search through all names, but use binary search.
      Upside: calling nms_ifcfg_rh_utils_get_ethtool_by_name() in a loop
      (once over all 60 names) is 75% faster.
      Downside: when adding a new feature, we have yet another line that we
      need to add. Previously, adding a new feature required adding 7 lines,
      not it is 8. But we didn't add a single feature since this was added,
      so that happens very seldom.
      Possible downside: is this code harder to read? Now we track both how to
      convert the ID to name and back. This is redundant (and thus harder to
      maintain). But it's really just one extra line per feature, for which there
      is a unit test. So, when adding a new NMEthtoolID it would be pretty
      hard to mess this up, because of all the tests and assertions.
      So, maybe it's slightly harder to read. On the other hand, it unifies
      handling for ethtool and kernel names, and the code has less logic
      and is more descriptive. I don't think this is actually harder to maintain
      and it should be easy to see that it is correct (readability).
    • Thomas Haller's avatar
    • Thomas Haller's avatar
    • Thomas Haller's avatar
    • Auke-Jan Kok's avatar
      man: show example for `nmcli device wifi connect` in nmcli-example manual · 425293b1
      Auke-Jan Kok authored and Thomas Haller's avatar Thomas Haller committed
      Add the only important example that this file should have
      All other examples are nice. But when you install a console-only
      machine and read the NM man pages, you are none the wiser, because
      something as simple like this isn't covered in the man pages.
      I've seen other users complain about it, and I've torn my hair out
      over this several times.
      [thaller@redhat.com: changed subject line of patch]
  2. 04 Mar, 2020 8 commits
  3. 03 Mar, 2020 2 commits
    • Thomas Haller's avatar
      dhcp: clean source on dispatch failure (fix leak) · 05493511
      Thomas Haller authored
      The GSource must also be unrefed. Also, first clear the field
      before invoking callbacks to the upper layers.
      Fixes: 843d696e ('dhcp: clean source on dispatch failure')
    • Beniamino Galvani's avatar
      dhcp: clean source on dispatch failure · 843d696e
      Beniamino Galvani authored
      Fix the following warning:
       NetworkManager[1524461]: Source ID 3844 was not found when attempting to remove it
       g_logv (log_domain=0x7f2816fa676e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffe697374d0) at gmessages.c:1391
       g_log (log_domain=log_domain@entry=0x7f2816fa676e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7f2816fae240 "Source ID %u was not found when attempting to remove it") at gmessages.c:1432
       g_source_remove (tag=519) at gmain.c:2352
       nm_clear_g_source (id=<optimized out>) at ./shared/nm-glib-aux/nm-macros-internal.h:1198
       dispose (object=0x55f7289b1ca0) at src/dhcp/nm-dhcp-nettools.c:1433
       g_object_unref (_object=<optimized out>) at gobject.c:3303
       g_object_unref (_object=0x55f7289b1ca0) at gobject.c:3232
       dhcp4_cleanup (self=self@entry=0x55f728af3b20, cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE, release=release@entry=0) at src/devices/nm-device.c:7565
      Fixes: 45521b1b ('dhcp: nettools: move to failed state if event dispatch fails')
  4. 02 Mar, 2020 4 commits
  5. 28 Feb, 2020 2 commits
  6. 26 Feb, 2020 13 commits