1. 05 Sep, 2022 1 commit
    • Beniamino Galvani's avatar
      device: don't emit recheck-assume if there is a queued activation request · f2925801
      Beniamino Galvani authored
      The @dracut_NM_vlan_over_team_no_boot sometimes fails, among other
      things, because it fails to assume an indicated connection after a
      restart.
      
      That seems to happen because after the decision to activate the
      indicated connection, the device does not move from DISCONNECTED state
      quickly enough. Another assumption recheck runs in between and decides
      to generate a connection, because the assume state was already reset
      in between.
      
      First start, creates and activates b3a61b68-f744-4a4c-a513-61399c154a67
      on vlan0017:
      
        NetworkManager (version 1.41.1-30921.55767cf5.el9) is starting...
            (asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe)
        ...
        settings: update[b3a61b68-f744-4a4c-a513-61399c154a67]: adding connection "vlan0017"
            (45113870df0a4cfb/keyfile)
      
      Second start:
      
        NetworkManager (version 1.41.1-30921.55767cf5
      
      .el9) is starting...
            (after a restart, asserts:10000, boot:caf7301a-19cd-498b-b5ba-5d36ee939ffe)
      
      Assumption attempt successfully picks the right connection and thus
      proceeds to reset the assume state:
      
        manager: (vlan0017): assume: will attempt to assume matching connection 'vlan0017'
            (b3a61b68-f744-4a4c-a513-61399c154a67) (indicated)
        device[c7c5101cf0b73f5f] (vlan0017): assume-state: set guess-assume=0, connection=(null)
      
      Everything great so far, activation of the right connection is enqueued
      and the device moves away from unavailable state. However, the
      activation can't proceed immediately:
      
        device (vlan0017): state change: unmanaged -> unavailable
            (reason 'connection-assumed', sys-iface-state: 'assume')
        device (vlan0017): state change: unavailable -> disconnected
            (reason 'connection-assumed', sys-iface-state: 'assume')
        active-connection[0x55ba1162f1c0]: set device "vlan0017" [0x55ba1163c4f0]
        device[c7c5101cf0b73f5f] (vlan0017): queue activation request waiting for carrier
      
      Now another assumption attempt is done. The original assume state is
      gone, so a connection is generated:
      
        platform-linux: UDEV event: action 'add' subsys 'net' device 'vlan0017' (6); seqnum=1959
        device[c7c5101cf0b73f5f] (vlan0017): queued link change for ifindex 6
        manager: (vlan0017): assume: generated connection 'vlan0017' (57627119-8c20-4f9e-bf4d-4fc427b4a6a9)
        keyfile: commit: 57627119-8c20-4f9e-bf4d-4fc427b4a6a9 (vlan0017) added as
            "/run/NetworkManager/system-connections/vlan0017-57627119-8c20-4f9e-bf4d-4fc427b4a6a9.nmconnection"
            (nm-generated,volatile,external)
      
      I think this shouldn't have happened. We've picked the correct
      connection already and it's enqueued for activation!
      
      Change the check in nm_device_emit_recheck_assume() to also consider
      any queued activation.
      
      Fixes-test: @dracut_NM_vlan_over_team_no_boot
      
      Co-authored-by: Lubomir Rintel's avatarLubomir Rintel <lkundrak@v3.sk>
      
      !1351
      (cherry picked from commit 9eb8cbca)
      (cherry picked from commit bdaba47a)
      f2925801
  2. 31 Aug, 2022 3 commits
  3. 29 Aug, 2022 1 commit
  4. 24 Aug, 2022 1 commit
  5. 11 Aug, 2022 5 commits
  6. 05 Aug, 2022 6 commits
    • Thomas Haller's avatar
      glib-aux: merge branch 'th/random-utils' · bf0c71dd
      Thomas Haller authored
      !1323
      
      (cherry picked from commit cf141f3e)
      bf0c71dd
    • Thomas Haller's avatar
      core: block to get good random bytes for "/var/lib/NetworkManager/secret_key" · b4bc5e62
      Thomas Haller authored
      _host_id_read() is the only place where we really care to have good
      random numbers, because that is the secret key that we persist to disk.
      
      Previously, we tried only nm_random_get_bytes_full(), which is a best
      effort to get strong random numbers. If it fails to generate those,
      it would simply remember the generated key in memory and proceed, but not
      persist it to disk.
      
      nm_random_get_bytes_full() does not block waiting for good numbers.
      
      Change that. Now, first call nm_random_get_crypto_bytes(), which would
      block and try hard to get good random numbers. Only if that fails,
      fallback to nm_random_get_bytes_full() as before. The difference is of
      course only in early boot, when we might not yet have entropy. In that
      case, I think it's better for NetworkManager to block.
      
      (cherry picked from commit 67a5cf76)
      b4bc5e62
    • Thomas Haller's avatar
      glib-aux: rework random number utils · 4ca7c905
      Thomas Haller authored
      Heavily inspired by systemd ([1]).
      
      We now also have nm_random_get_bytes{,_full}() and
      nm_random_get_crypto_bytes(), like systemd's random_bytes()
      and crypto_random_bytes(), respectively.
      
      Differences:
      
      - instead of systemd's random_bytes(), our nm_random_get_bytes_full()
        also estimates whether the output is of high quality. The caller
        may find that interesting. Due to that, we will first try to call
        getrandom(GRND_NONBLOCK) before getrandom(GRND_INSECURE). That is
        reversed from systemd's random_bytes(), because we want to find
        out whether we can get good random numbers. In most cases, kernel
        should have entropy already, and it makes no difference.
      
      Otherwise, heavily rework the code. It should be easy to understand
      and correct.
      
      There is also a major bugfix here. Previously, if getrandom() failed
      with ENOSYS and we fell back to /dev/urandom, we would assume that we
      have high quality random numbers. That assumption is not warranted.
      Now instead poll on /dev/random to find out.
      
      [1] https://github.com/systemd/systemd/blob/a268e7f4021072e120a03b42660fad21e465c44e/src/basic/random-util.c#L81
      
      (cherry picked from commit d20343c9)
      4ca7c905
    • Thomas Haller's avatar
      glib-aux: add assertions to nm_utils_fd_wait_for_event() · e3722827
      Thomas Haller authored
      (cherry picked from commit e80fc43f)
      e3722827
    • Thomas Haller's avatar
      glib-aux: accept zero bytes for nm_utils_random_bytes() · b9c42c9b
      Thomas Haller authored
      As an edge case, also accept requesting zero bytes of
      randomness.
      
      (cherry picked from commit 614e050b)
      b9c42c9b
    • Thomas Haller's avatar
      glib-aux: reseed state for "bad" random bytes every time · c4630858
      Thomas Haller authored
      nm_utils_random_bytes() is supposed to give us good random number from
      kernel. It guarantees to always provide some bytes, and it has a
      boolean return value that estimates whether the bytes are good
      randomness. In practice, most callers ignore that return value, because
      what would they do about it anyway?
      
      Of course, we want to primarily use getrandom() (or "/dev/urandom"). But
      if we fail to get random bytes from them, we have a fallback path that
      tries to generate "random" bytes.
      
      It does so, by initializing a global seed from various sources, and keep
      sha256 hashing the buffer in a loop. That's certainly not efficient nor
      elegant, but we already are in a fallback path.
      
      Still, we can do slightly better. Instead of just using the global state
      and keep updating it (entirely deterministically), every time also mix in
      the results from getrandom() and a current timestamp. The idea is that if you
      have a virtual machine that gets cloned, we don't want that our global
      state keeps giving the same random numbers. In particular, because
      getrandom() might handle that case, even if it doesn't have good
      entropy.
      
      (cherry picked from commit 3c349ee1)
      c4630858
  7. 04 Aug, 2022 2 commits
  8. 26 Jul, 2022 2 commits
  9. 25 Jul, 2022 3 commits
    • Thomas Haller's avatar
      dhcp: fix EXTENDED DHCP event to accept lease for dhclient plugin · f7ced16c
      Thomas Haller authored
      n-dhcp4 only supports calling ACCEPT during the GRANTED state.
      Not during a EXTENDED event. So usually, we would not want
      to call accept in that case.
      
      And we didn't. During EXTENDED event, we would usually skip ACD (because
      it's either not enabled or we already passed ACD for the current address).
      In that case, in _nm_dhcp_client_notify() we hit the line
      
           if (client_event_type == NM_DHCP_CLIENT_EVENT_TYPE_BOUND && priv->l3cd_curr
               && nm_l3_config_data_get_num_addresses(priv->l3cd_curr, priv->config.addr_family) > 0)
               priv->l3cfg_notify.wait_dhcp_commit = TRUE;
           else
               priv->l3cfg_notify.wait_dhcp_commit = FALSE;
      
      and would not set `wait_dhpc_commit`. That means, we never called _dhcp_client_accept().
      For nettools, that doesn't really matter because calling ACCEPT during EXTENDED
      is invalid anyway. However, for dhclient that is fatal because we wouldn't reply the
      D-Bus request from nm-dhcp-helper. The helper times out after 60 seconds and dhclient
      would misbehave.
      
      We need to fix that by also calling _dhcp_client_accept() in the case when we don't
      need to wait (the EXTENDED case).
      
      However, previously _dhcp_client_accept() was rather peculiar and didn't like to be
      called in an unexpected state. Relax that. Now, when calling accept in an unexpected
      state, just do nothing and signal success. That frees the caller from the complexity
      to understand when they must/must not call accept.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=2109285
      
      Fixes: 156d8421 ('dhcp/dhclient: implement accept/decline (ACD) for dhclient plugin')
      
      !1308
      (cherry picked from commit 5077018f)
      f7ced16c
    • Ana Cabral's avatar
      rpm: make the ifcfg informational message available from RHEL 9 · 4a219f14
      Ana Cabral authored and Thomas Haller's avatar Thomas Haller committed
      (cherry picked from commit 41b58313)
      4a219f14
    • Ana Cabral's avatar
      rpm: include a warning message for network configuration on... · 74e9ec04
      Ana Cabral authored and Thomas Haller's avatar Thomas Haller committed
      rpm: include a warning message for network configuration on /etc/sysconfig/network-scripts directory
      
      NetworkManager now does not support network configuration through
      ifcfg files by default anymore, it is provided in a separated
      package:
      https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/
      
      This commits include a file in rpm packages located in ifcfg scripts
      directory, /etc/sysconfig/network-scripts/, to inform the user of
      the new location of network configuration files.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=2074020
      (cherry picked from commit 96d73626)
      74e9ec04
  10. 19 Jul, 2022 1 commit
  11. 18 Jul, 2022 4 commits
  12. 11 Jul, 2022 1 commit
  13. 04 Jul, 2022 5 commits
    • Thomas Haller's avatar
      libnm: fix timestamp in LIBNM_CLIENT_DEBUG debug logging · 29461922
      Thomas Haller authored
      Fixes: 9c01d6ca ('libnm: print timestamp in LIBNM_CLIENT_DEBUG debug logging')
      (cherry picked from commit 287a3499)
      29461922
    • Thomas Haller's avatar
      libnm: fix "parameters" argument in nm_client_dbus_call() to be optional · ce629741
      Thomas Haller authored
      It was documented to be an optional parameter. That is also in line
      with g_dbus_connection_call(), which is essentially wrapped by nm_client_dbus_call().
      
      Fixes: ce0e898f ('libnm: refactor caching of D-Bus objects in NMClient')
      (cherry picked from commit ea85f6df)
      ce629741
    • Slava Monich's avatar
      supplicant: fix a memory leak · 25f41811
      Slava Monich authored and Thomas Haller's avatar Thomas Haller committed
      ==30980== 8 bytes in 1 blocks are definitely lost in loss record 1,117 of 6,137
      ==30980==    at 0x4841C38: malloc (vg_replace_malloc.c:309)
      ==30980==    by 0x4A246C7: g_malloc (gmem.c:106)
      ==30980==    by 0x4A4A4BB: g_variant_get_strv (gvariant.c:1607)
      ==30980==    by 0x4A4CA73: g_variant_valist_get_nnp (gvariant.c:4901)
      ==30980==    by 0x4A4CA73: g_variant_valist_get_leaf (gvariant.c:5058)
      ==30980==    by 0x4A4CA73: g_variant_valist_get (gvariant.c:5239)
      ==30980==    by 0x4A4D11D: g_variant_get_va (gvariant.c:5502)
      ==30980==    by 0x4A4D1BD: g_variant_lookup (gvariant.c:989)
      ==30980==    by 0xE9389: parse_capabilities (nm-supplicant-interface.c:1241)
      ==30980==    by 0xEBF99: _properties_changed_main (nm-supplicant-interface.c:1941)
      ==30980==    by 0xEF549: _properties_changed (nm-supplicant-interface.c:2867)
      ==30980==    by 0xEF7ED: _get_all_main_cb (nm-supplicant-interface.c:2972)
      ==30980==    by 0x262057: _nm_dbus_connection_call_default_cb (nm-dbus-aux.c:70)
      ==30980==    by 0x48DB6A3: g_task_return_now (gtask.c:1215)
      ==30980==    by 0x48DBF43: g_task_return.part.3 (gtask.c:1285)
      ==30980==    by 0x4918885: g_dbus_connection_call_done (gdbusconnection.c:5765)
      ==30980==    by 0x48DB6A3: g_task_return_now (gtask.c:1215)
      ==30980==    by 0x48DB6D7: complete_in_idle_cb (gtask.c:1229)
      ==30980==    by 0x4A20981: g_main_dispatch (gmain.c:3325)
      ==30980==    by 0x4A20981: g_main_context_dispatch (gmain.c:4016)
      ==30980==    by 0x4A20BEF: g_main_context_iterate.isra.23 (gmain.c:4092)
      ==30980==    by 0x4A20E33: g_main_loop_run (gmain.c:4290)
      ==30980==    by 0x2C5C9: main (main.c:509)
      
      Fixes: cd1e0193 ('supplicant: add BIP interface capability')
      (cherry picked from commit 8c5356ce)
      25f41811
    • Beniamino Galvani's avatar
      wifi: wait supplicant to settle before renewing DHCP after roam · b3036782
      Beniamino Galvani authored
      After roaming to a different AP, if we trigger a DHCP renewal while
      the supplicant is still reauthenticating the REQUEST will be lost and
      the client will fall back to sending a DISCOVER, potentially getting a
      different address.
      
      Wait that the supplicant state settles before renewing.
      
      #1024
      !1263
      (cherry picked from commit fb4ac007)
      b3036782
    • Beniamino Galvani's avatar
      dhcp: nettools: save the lease after it gets accepted · 409546a5
      Beniamino Galvani authored and Thomas Haller's avatar Thomas Haller committed
      Currently the lease gets saved only on the extended (renewal)
      event. Also save it after it gets accepted.
      
      Fixes: 52a0fe58 ('dhcp/nettools: better track currently granted lease')
      
      !1261
      (cherry picked from commit 2807f6a8)
      409546a5
  14. 01 Jul, 2022 5 commits