1. 23 Aug, 2019 7 commits
    • Beniamino Galvani's avatar
      wifi: support WPA2 ad-hoc (ibss-rsn) · cc201246
      Beniamino Galvani authored
      If the device supports it, allow usage of WPA2 in ad-hoc networks.
      Based-on-patch-by: default avatarNicolas Cavallari <cavallar@lri.fr>
      
      #184
      cc201246
    • Beniamino Galvani's avatar
      wifi: drop support for wpa-none key-mgmt · f81b99a7
      Beniamino Galvani authored
      NM didn't support wpa-none for years because kernel drivers used to be
      broken. Note that it wasn't even possible to *add* a connection with
      wpa-none because it was rejected in nm_settings_add_connection_dbus().
      Given that wpa-none is also deprecated in wpa_supplicant and is
      considered insecure, drop altogether any reference to it.
      f81b99a7
    • Beniamino Galvani's avatar
      wifi: expose IBSS_RSN capability · f0e8041d
      Beniamino Galvani authored
      The new capability indicates whether the device supports WPA2/RSN in
      an IBSS (ad-hoc) network.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=757823
      f0e8041d
    • Thomas Haller's avatar
      bluetooth: fix leak in get_managed_objects_cb() · 25571bb6
      Thomas Haller authored
      Fixes: 1ae5d533 ('bluez: add support for BlueZ 5')
      25571bb6
    • Thomas Haller's avatar
      shared/hash: implement nm_hash_obfuscate_ptr() as inline function instead of macro · a63f9aad
      Thomas Haller authored
      There is really no reason for this to be a macro. Our hash-related
      helpers (like nm_hash_update_val()) are macros because they do some
      shenigans to accept arguments of different (compile-time) types. But
      the arguments for nm_hash_obfuscate_ptr() are well known and expected
      of a certain form.
      
      Note that with "-O2" some quick testing shows that the compiler no
      longer inlines the function. But I guess that's fine, probably the
      compiler knows best anyway.
      a63f9aad
    • Thomas Haller's avatar
      core/logging: don't log plain pointer value from nm_log_ptr() · aa100d89
      Thomas Haller authored
      Logging pointer values might reveal information that can be used to defeat
      ASLR. We should avoid that.
      
      On the other hand, it's useful to tag a logging message with the pointer
      value of the "source" of the message. It helps to correlate messages and
      search for relevant messages in the log.
      
      As a compromise, use NM_HASH_OBFUSCATE_PTR(), like we do at several places
      already. For example, we also log
      
        <debug> [1566550899.7901] setup NMPlatform singleton (29a6af9867f2e5d0)
      
      This obfuscated value is a 64 bit unsigned integer with the siphash24
      hash of the raw value with a randomized seed. Of course, contrary to the
      pointer value, there is a tiny chance that two different pointers hash
      to the same identifier. However, that seems unlikely enough to be of no
      concern. Note that this pointer value is only logged to aid debugging.
      It is sufficiently unlikely that this causes confusion.
      
      One other downside of printed the obfuscated value, is that you can no
      longer read the pointer from the log and use it in gdb directly. That
      might be sometimes convenient, but making this impossible is kinda the
      purpose of this change.
      
      As such, nm_log_ptr() becomes a bit of a misnomer. But not too bad, it
      still is a good name. For example, if we wanted we could redefine the
      NM_HASH_OBFUSCATE_PTR* macros when building "--with-more-asserts".
      aa100d89
    • Lubomir Rintel's avatar
      contrib/rpm: install our dispatcher scripts into /usr/lib/NetworkManager · 505208a4
      Lubomir Rintel authored
      That's where they always should have been.
      505208a4
  2. 22 Aug, 2019 4 commits
  3. 21 Aug, 2019 1 commit
  4. 20 Aug, 2019 3 commits
    • Thomas Haller's avatar
      wifi: detect FT support per interface and avoid enabling it · 2f8a4e90
      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.
      2f8a4e90
    • Thomas Haller's avatar
      cli: cleanup unique_master_iface_ifname() · 0e1748af
      Thomas Haller authored
      - use appropriate types for integer variables
      
      - rework the confusing loop which would reset the loop-counter
        to start again.
      0e1748af
    • Thomas Haller's avatar
      e1ec22f7
  5. 16 Aug, 2019 9 commits
  6. 15 Aug, 2019 4 commits
  7. 13 Aug, 2019 10 commits
    • Thomas Haller's avatar
      cli: don't require "ifname" when adding connection · 02e5a8d1
      Thomas Haller authored
        $ nmcli connection add type ethernet con-name t autoconnect no
        Error: ifname argument is required.
      
      This reverts commit a91eafdf ('cli: 'con add': make ifname mandatory
      (except bond,bridge,vlan) (bgo #698113)'). Apparently ifname argument was
      required to avoid confusion (unexpected behavior). But I don't agree
      that is an issue, it's just annoying. Often you really have just one
      ethernet or Wi-Fi device, so this does not seem helpful.
      
      !222
      02e5a8d1
    • Thomas Haller's avatar
      2c517691
    • Thomas Haller's avatar
      all: allow configuring default-routes as manual, static routes · c167e014
      Thomas Haller authored
      Up until now, a default-route (with prefix length zero) could not
      be configured directly. The user could only set ipv4.gateway,
      ipv4.never-default, ipv4.route-metric and ipv4.route-table to influence
      the setting of the default-route (respectively for IPv6).
      
      That is a problematic limitation. For one, whether a route has prefix
      length zero or non-zero does not make a fundamental difference. Also,
      it makes it impossible to configure all the routing attributes that one can
      configure otherwise for static routes. For example, the default-route could
      not be configured as "onlink", could not have a special MTU, nor could it be
      placed in a dedicated routing table.
      
      Fix that by lifting the restriction. Note that "ipv4.never-default" does
      not apply to /0 manual routes. Likewise, the previous manners of
      configuring default-routes ("ipv4.gateway") don't conflict with manual
      default-routes.
      
      Server-side this all the pieces are already in place to accept a default-route
      as static routes. This was done by earlier commits like 5c299454
      ('core: rework tracking of gateway/default-route in ip-config').
      
      A long time ago, NMIPRoute would assert that the prefix length is
      positive. That was relaxed by commit a2e93f2d ('libnm: allow zero
      prefix length for NMIPRoute'), already before 1.0.0. Using libnm from
      before 1.0.0 would result in assertion failures.
      
      Note that the default-route-metric-penalty based on connectivity
      checking applies to all /0 routes, even these static routes. Be they
      added due to DHCP, "ipv4.gateway", "ipv4.routes" or "wireguard.peer-routes".
      I wonder whether doing that unconditionally is desirable, and maybe
      there should be a way to opt-out/opt-in for the entire profile or even
      per-routes.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1714438
      c167e014
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      libnm: set errno in nm_key_file_get_boolean() to distinguish between missing key and error · cc7b2cde
      Thomas Haller authored
      This is also what nm_keyfile_plugin_kf_get_int64() does. It's useful to
      know whether a value was missing or invalid.
      cc7b2cde
    • Thomas Haller's avatar
      1533a3e5
    • Thomas Haller's avatar
      dhcp: minor refactoring to switch default IPv4 DHCP plugin to "nettools" with one-line change · 75503c85
      Thomas Haller authored
      Minor refactoring so that there is only a one-line change necessary to
      flip the implementation of the "internal" DHCP plugin for IPv4 from
      "systemd" to "nettools".
      
      We don't do that yet, because there are still some issues (e.g. the
      lease is not persisted for nettools plugin). Eventually we want to
      switch, so prepare the code to be almost there.
      75503c85
    • Thomas Haller's avatar
      dhcp: make "systemd" DHCP plugin configurable · b53e2614
      Thomas Haller authored
      We have the "internal" DHCP plugin. That's our preferred plugin,
      and eventually we may drop all other plugins.
      
      Currently, the "internal" plugin is based on code from systemd-networkd
      and implemented in "src/dhcp/nm-dhcp-systemd.c". As this code is forked
      we eventually want to switch to nettools' n-dhcp4 library (for IPv4).
      For that reason we already have "src/dhcp/nm-dhcp-nettools.c".
      
      Note that "nettools" can be configured as a DHCP plugin, but this configuration
      is only experimental and for testing. There is never supposed to be a
      "nettools" plugin, but eventually the "internal" plugin will switch
      implementation.
      
      We don't want to replace systemd-based implementation right away. Not until
      we are sure that nettools works well. For that reason we keep them
      both in parallel for a while.
      
      This commit makes "systemd" DHCP plugin explicitly configurable
      in NetworkManager.conf. Like "nettools" this is an undocumented option,
      only for testing.
      
      If you choose "internal" (the default), you get one of the
      implementations (currently the "systemd" one). But by selecting
      "systemd" or "nettools" explicitly, you can select the exact plugin.
      b53e2614
    • Thomas Haller's avatar
      8d8cc0da
    • Thomas Haller's avatar
      dhcp: cleanup selecting GType from DHCP client factory · b32cf718
      Thomas Haller authored
      Instead of returning a client-factory, return the GType right
      away.
      b32cf718
  8. 12 Aug, 2019 2 commits