1. 18 Sep, 2019 3 commits
  2. 16 Sep, 2019 1 commit
  3. 13 Sep, 2019 1 commit
  4. 07 Sep, 2019 4 commits
  5. 06 Sep, 2019 1 commit
  6. 05 Sep, 2019 6 commits
  7. 03 Sep, 2019 6 commits
  8. 02 Sep, 2019 1 commit
    • Thomas Haller's avatar
      keyfile: reorder printing empty [wireguard] section with peers and fix test failure · 18dfbeef
      Thomas Haller authored
      We want to print the [wireguard] section before printing sections of the
      peers. It just looks nicer.
      This also fixes a test failure:
        /libnm/settings/roundtrip-conversion/wireguard/2: **
        test:ERROR:./shared/nm-utils/nm-test-utils.h:2254:nmtst_keyfile_assert_data: assertion failed (d1 == data): ("[connection]\nid=roundtrip-conversion-2\nuuid=63376701-b61e-4318-bf7e-664a1c1eeaab\ntype=wireguard\ninterface-name=ifname2\npermissions=\n\n[wireguard-peer.uoGoXWWRxJvu4jDva8pPGA4nxau8B33S+YR+MfPFjxc=]\nendpoint=\npreshared-key-flags=2\n\n[wireguard-peer.BED73rH9j3OCHYAeXNrW5y5oia/Ngj+M04e9sG7DQOo=]\nendpoint=\npreshared-key-flags=1\npersistent-keepalive=5070\nallowed-ips=;;a:b:c::e4:13/128;;a:b:c::1b:df/128;a:b:c::b0:84/128;;\n\n[wireguard]\n\n[ipv4]\ndns-search=\nmethod=disabled\n\n[ipv6]\naddr-gen-mode=stable-privacy\ndns-search=\nmethod=ignore\n\n[proxy]\n" == "[connection]\nid=roundtrip-conversion-2\nuuid=63376701-b61e-4318-bf7e-664a1c1eeaab\ntype=wireguard\ninterface-name=ifname2\npermissions=\n\n[wireguard]\n\n[wireguard-peer.uoGoXWWRxJvu4jDva8pPGA4nxau8B33S+YR+MfPFjxc=]\nendpoint=\npreshared-key-flags=2\n\n[wireguard-peer.BED73rH9j3OCHYAeXNrW5y5oia/Ngj+M04e9sG7DQOo=]\nendpoint=\npreshared-key-flags=1\npersistent-keepalive=5070\nallowed-ips=;;a:b:c::e4:13/128;;a:b:c::1b:df/128;a:b:c::b0:84/128;;\n\n[ipv4]\ndns-search=\nmethod=disabled\n\n[ipv6]\naddr-gen-mode=stable-privacy\ndns-search=\nmethod=ignore\n\n[proxy]\n")
      Fixes: ddd148e0 ('keyfile: let keyfile writer serialize setting with all default values')
      (cherry picked from commit 576a1289)
  9. 29 Aug, 2019 1 commit
  10. 28 Aug, 2019 2 commits
  11. 27 Aug, 2019 9 commits
    • Thomas Haller's avatar
      acd: fix memleak in acd_event() · faf12086
      Thomas Haller authored
      Only happens with debug logging enabled. So, not a large problem.
      Found by Coverity.
      Fixes: d9a4b59c ('acd: adapt NM code and build options')
      (cherry picked from commit 0300c182)
    • Thomas Haller's avatar
      contrib/rpm: explicitly set runstatedir to "/run" when building release tarball · ceb1ba69
      Thomas Haller authored
      Nowadays, we should prefer "/run" over "/var/run". When not specifying
      during ./configure, autotools however still defaults to "/var/run".
      This default is also visible in the pre-generated documenation, for
      example `man NetworkManager.conf` says
        Unless the symlink points to the internal file /run/NetworkManager/resolv.conf,
        in which case the ...
      (cherry picked from commit 081b16cd)
    • Thomas Haller's avatar
      keyfile: merge branch 'th/keyfile-fix-empty-settings' · c6584278
      Thomas Haller authored
      (cherry picked from commit 01ef7c40)
    • Thomas Haller's avatar
      keyfile: let keyfile writer serialize setting with all default values · aca5b672
      Thomas Haller authored
      It's important whether a setting is present or not. Keyfile writer
      omits properties that have a default value, that means, if the setting
      has all-default values, it would be dropped. For [proxy] that doesn't
      really matter, because we tend to normalize it back. For some settings
      it matters:
        $ nmcli connection add type bluetooth con-name bt autoconnect no bluetooth.type dun bluetooth.bdaddr aa:bb:cc:dd:ee:ff gsm.apn a
        Connection 'bt' (652cabd8-d350-4246-a6f3-3dc17eeb028f) successfully added.
        $ nmcli connection modify bt gsm.apn ''
      When storing this to keyfile, the [gsm] section was dropped
      (server-side) and we fail an nm_assert() (omitted from the example
      output below).
        <error> [1566732645.9845] BUG: failure to normalized profile that we just wrote to disk: bluetooth: 'dun' connection requires 'gsm' or 'cdma' setting
        <trace> [1566732645.9846] keyfile: commit: "/etc/NetworkManager/system-connections/bt.nmconnection": profile 652cabd8-d350-4246-a6f3-3dc17eeb028f (bt) written
        <trace> [1566732645.9846] settings: update[652cabd8-d350-4246-a6f3-3dc17eeb028f]: update-from-dbus: update profile "bt"
        <trace> [1566732645.9849] settings: storage[652cabd8-d350-4246-a6f3-3dc17eeb028f,3e504752a4a78fb3/keyfile]: change event with connection "bt" (file "/etc/NetworkManager/system-connections/>
        <trace> [1566732645.9849] settings: update[652cabd8-d350-4246-a6f3-3dc17eeb028f]: updating connection "bt" (3e504752a4a78fb3/keyfile)
        <debug> [1566732645.9857] ++ connection 'update connection' (0x7f7918003340/NMSimpleConnection/"bluetooth" < 0x55e1c52480e0/NMSimpleConnection/"bluetooth") [/org/freedesktop/NetworkManager>
        <debug> [1566732645.9857] ++ gsm                       [ 0x55e1c5276f80 < 0x55e1c53205f0 ]
        <debug> [1566732645.9858] ++ gsm.apn                   < 'a'
      Of course, after reload the connection on disk is no loner valid.
      Keyfile writer wrote an invalid setting.
        # nmcli connection reload
        <warn>  [1566732775.4920] keyfile: load: "/etc/NetworkManager/system-connections/bt.nmconnection": failed to load connection: invalid connection: bluetooth: 'dun' connection requires 'gsm' or 'cdma' setting
        <trace> [1566732775.5432] settings: update[652cabd8-d350-4246-a6f3-3dc17eeb028f]: delete connection "bt" (3e504752a4a78fb3/keyfile)
        <debug> [1566732775.5434] Deleting secrets for connection /org/freedesktop/NetworkManager/Settings (bt)
        <trace> [1566732775.5436] dbus-object[9a402fbe14c8d975]: unexport: "/org/freedesktop/NetworkManager/Settings/55"
      (cherry picked from commit ddd148e0)
    • Thomas Haller's avatar
      keyfile: refactor _parse_info_find() to get ParseInfoSetting · 3ea2337f
      Thomas Haller authored
      I thought I would need this, but ended up not using it.
      Anyway, it makes sense in general that the function can lookup
      all relevant information, so merge it.
      (cherry picked from commit e6eb01c1)
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      settings/keyfile: check whether profile can be re-read before writing to disk and fail · 22800c04
      Thomas Haller authored
      First of all, keyfile writer (and reader) are supposed to be able to store
      every profile to disk and re-read a valid profile back. Note that the profile
      might be modified in the process, for example, blob certificates are written
      to a file. So, the result might no be exactly the same, but it must still be
      valid (and should only diverge in expected ways from the original, like mangled
      Previously, we would re-read the profile after writing to disk. If that failed,
      we would only fail an assertion but otherwise proceeed. It is a bug
      after all. However, it's bad to check only after writing to file,
      because it results in a unreadable profile on disk, and in the first
      moment it appears that noting went wrong. Instead, we should fail early.
      Note that nms_keyfile_reader_from_keyfile() must entirely operate on the in-memory
      representation of the keyfile. It must not actually access any files on disk. Hence,
      moving this check before writing the profile must work. Otherwise, that would be
      a separate bug. Actually, keyfile reader and writer violate this. I
      added FIXME comments for that. But it doesn't interfere with this
      (cherry picked from commit 3b8aab29)
    • Thomas Haller's avatar
      settings/keyfile: log reason why re-read connection cannot be normalized · d92ec1d4
      Thomas Haller authored
      It's a bug either way, but let's log what exactly went wrong.
      (cherry picked from commit 1c2c7d3c)
    • Thomas Haller's avatar
      shared/tests: add nmtst_keyfile_get_num_keys() helper · 2958d042
      Thomas Haller authored
      (cherry picked from commit a2658923)
  12. 24 Aug, 2019 1 commit
  13. 23 Aug, 2019 2 commits
  14. 20 Aug, 2019 1 commit
    • Thomas Haller's avatar
      wifi: detect FT support per interface and avoid enabling it · b82f2d97
      Thomas Haller authored
      Previously we only cared whether supplicant is build with support for
      FT. In that case we would pass FT-PSK to supplicant, like
        Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK'
      Supplicant would then always try FT with preference, regardless whether
      the interface/driver support it. That results in a failure to associate, if
      the driver does not support it.
        NetworkManager[1356]: <info>  [1566296144.9940] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK'
        wpa_supplicant[1348]: wlan0: WPA: AP key_mgmt 0x42 network profile key_mgmt 0x142; available key_mgmt 0x42
        wpa_supplicant[1348]: wlan0: WPA: using KEY_MGMT FT/PSK
        wpa_supplicant[1348]:   * akm=0xfac04
        kernel: ERROR @wl_set_key_mgmt :
        kernel: invalid cipher group (1027076)
      Since we pass a list of acceptable "key_mgmt" options to supplicant,
      FT-PSK should not be used when supplicant knows it's not supported.
      That is a supplicant bug.
      Regardless, work around it by checking the per-interface capability, and
      avoid it if support is apparently not present.
      (cherry picked from commit 2f8a4e90)
  15. 16 Aug, 2019 1 commit