1. 13 Mar, 2019 16 commits
    • Thomas Haller's avatar
      platform: add NMPRulesManager for syncing routing rules · b8398b9e
      Thomas Haller authored
      Routing rules are unlike addresses or routes not tied to an interface.
      NetworkManager thinks in terms of connection profiles. That works well
      for addresses and routes, as one profile configures addresses and routes
      for one device. For example, when activating a profile on a device, the
      configuration does not interfere with the addresses/routes of other
      devices. That is not the case for routing rules, which are global, netns-wide
      entities.
      
      When one connection profile specifies rules, then this per-device configuration
      must be merged with the global configuration. And when a device disconnects later,
      the rules must be removed.
      
      Add a new NMPRulesManager API to track/untrack routing rules. Devices can
      register/add there the routing rules they require. And the sync method will
      apply the configuration. This is be implemented on top of NMPlatform's
      caching API.
      b8398b9e
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      9992ac1c
    • Thomas Haller's avatar
      platform: add support for routing-rule objects and cache them in platform · 9934a6a0
      Thomas Haller authored
      Add and implement NMPlatformRoutingRule types and let the platform cache
      handle rules.
      
      Rules are special in two ways:
      
      - they don't have an ifindex. That makes them different from all other
        currently existing NMPlatform* types, which have an "ifindex" field and
        "implement" NMPlatformObjWithIfindex.
      
      - they have an address family, but contrary to addresses and routes, there
        is only one NMPlatformRoutingRule object to handle both address
        families.
      
      Both of these points require some special considerations.
      
      Kernel treats routing-rules quite similar to routes. That is, kernel
      allows to add different rules/routes, as long as they differ in certain
      fields. These "fields" make up the identity of the rules/routes. But
      in practice, it's not defined which fields contribute to the identity
      of these objects. That makes using the netlink API very hard. For
      example, when kernel gains support for a new attribute which
      NetworkManager does not know yet, then users can add two rules/routes
      that look the same to NetworkManager. That can easily result in cache
      inconsistencies.
      
      Another problem is, that older kernel versions may not yet support all
      fields, which NetworkManager (and newer kernels) considers for identity.
      The older kernel will not simply reject netlink messages with these unknown
      keys, instead it will proceed adding the route/rule without it. That means,
      the added route/rule will have a different identity than what NetworkManager
      intended to add.
      9934a6a0
    • Thomas Haller's avatar
      platform: separate the refresh-type from the object type · b9ee40b8
      Thomas Haller authored
      Currently, there is a directy one to one relation between
      
       - DELAYED_ACTION_TYPE_REFRESH_ALL_*
      
       - REFRESH_ALL_TYPE_*
      
       - NMP_OBJECT_TYPE_*
      
      For IP addresses, routes and routing policy rules, when we request
      a refresh-all (NLM_F_DUMP), we want to specify the address family.
      
      For addresses and routes that is currently solved by having two
      sets of NMPObject types, for each address family one.
      
      I think that is cumbersome because the implementations of both address
      families are quite similar. By implementing both families as different
      object types, we have a lot of duplicate code and it's hard to see where
      the families actually differ. It would be better to have only one NMPObject
      type, but then when we "refresh-all" such types, we still want to be able
      to dump all (AF_UNSPEC) or only a particular address family (AF_INET, AF_INET6).
      
      Decouple REFRESH_ALL_TYPE_* from NMP_OBJECT_TYPE_* to make that
      possible.
      b9ee40b8
    • Thomas Haller's avatar
      platform/trivial: rename enum DELAYED_ACTION_IDX_REFRESH_ALL_* to REFRESH_ALL_TYPE_* · 0a2a8617
      Thomas Haller authored
      While these numbers are strongly related to DELAYED_ACTION_TYPE_REFRESH_ALL_*,
      they differ in their meaning.
      
      These are the refresh-all-types that we support. While some of the delayed-actions
      are indeed for refresh-all, they are not the same thing.
      
      Rename the enum.
      0a2a8617
    • Thomas Haller's avatar
      platform: drop unused nm_platform_refresh_all() · 7c5ad2d9
      Thomas Haller authored
      The function is unused. It would require redesign to work with
      future changes, and since it's unused, just drop it.
      
      The long reasoning is:
      
          Currently, a refresh-all is tied to an NMPObjectType. However, with
          NMPObjectRoutingRule (for policy-routing-rules) that will no longer
          be the case.
      
          That is because NMPObjectRoutingRule will be one object type for
          AF_INET and AF_INET6. Contrary to IPv4 addresses and routes, where
          there are two sets of NMPObject types.
      
          The reason is, that it's preferable to treat IPv4 and IPv6 objects
          similarly, that is: as the same type with an address family property.
      
          That also follows netlink, which uses RTM_GET* messages for both
          address families, and the address family is expressed inside the
          message.
      
          But then an API like nm_platform_refresh_all() makes little sense,
          it would require at least an addr_family argument. But since the
          API is unused, just drop it.
      7c5ad2d9
    • Thomas Haller's avatar
      platform: suppress unnecessary logging in do_request_all_no_delayed_actions() · bbfb8a9b
      Thomas Haller authored
      When we refresh all links, we clear all flags to refresh a specific
      link. However, only log a message if there was anything to clear.
      bbfb8a9b
    • Thomas Haller's avatar
      platform: add NULL check in inline nmp_object_unref() function · 2c37a3fb
      Thomas Haller authored
      This allows the compiler to see that this function does nothing for %NULL.
      That is not so unusual, as we use nm_auto_nmpobj to free objects. Often
      the compiler can see that these pointers are %NULL.
      2c37a3fb
    • Thomas Haller's avatar
      platform: add NMPlatformObjWithIfindex helper structure for handling NMPObject types · ac4a1deb
      Thomas Haller authored
      Until now, all implemented NMPObject types have an ifindex field (from
      links, addresses, routes, qdisc to tfilter).
      
      The NMPObject structure contains a union of all available types, that
      makes it easier to down-case from an NMPObject pointer to the actual
      content.
      
      The "object" field of NMPObject of type NMPlatformObject is the lowest
      common denominator.
      
      We will add NMPlatformRoutingRules (for policy routing rules). That type
      won't have an ifindex field.
      
      Hence, drop the "ifindex" field from NMPlatformObject type. But also add
      a new type NMPlatformObjWithIfindex, that can represent all types that
      have an ifindex.
      ac4a1deb
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      platform: drop unnecessary casts from NMP_OBJECT_CAST_*() macros · 8f3724a6
      Thomas Haller authored
      It's wrong to cast here. The caller must always provide an
      NMPObject pointer.
      8f3724a6
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      shared: add nm_hash_obfuscate_ptr() helper · 237a1723
      Thomas Haller authored
      237a1723
    • Thomas Haller's avatar
      shared: add c_list_length_is() helper · 83fa4aaf
      Thomas Haller authored
      83fa4aaf
    • Thomas Haller's avatar
      contrib: set shift for less in NM-log · bfd6d608
      Thomas Haller authored
      bfd6d608
  2. 12 Mar, 2019 1 commit
  3. 11 Mar, 2019 3 commits
  4. 09 Mar, 2019 5 commits
  5. 08 Mar, 2019 1 commit
  6. 07 Mar, 2019 14 commits
    • Frédéric Danis's avatar
      tests: Fix variant_from_dbus() for arrays of UInt32 · 9a71d7d2
      Frédéric Danis authored
      Using test-networkmanager-servic.py, I get the following error when
      trying to add manual config with a dns address:
      
          Error: g-io-error-quark: Traceback (most recent call last):
            File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 707, in _message_cb
              retval = candidate_method(self, *args, **keywords)
            File "tools/test-networkmanager-service.py", line 1727, in AddConnection
              return self.add_connection(con_hash)
            File "tools/test-networkmanager-service.py", line 1731, in add_connection
              con_inst = Connection(self.c_counter, con_hash, do_verify_strict)
            File "tools/test-networkmanager-service.py", line 1601, in __init__
              NmUtil.con_hash_verify(con_hash, do_verify_strict=do_verify_strict)
            File "tools/test-networkmanager-service.py", line 497, in con_hash_verify
              BusErr.raise_nmerror(e)
            File "tools/test-networkmanager-service.py", line 419, in raise_nmerror
              raise e
          Exception: Unsupported value ipv4.dns = dbus.Array([dbus.UInt32(168430090L), dbus.UInt32(218893066L)], signature=dbus.Signature('u'), variant_level=1) (Cannot convert array element to type 'u': Must be number, not Variant)
      
      https://mail.gnome.org/archives/networkmanager-list/2019-March/msg00013.html
      9a71d7d2
    • Thomas Haller's avatar
      7dd44d6d
    • Thomas Haller's avatar
    • Benjamin Berg's avatar
      libnm: Fix reporting of unknown device types · a6a185ba
      Benjamin Berg authored
      nm_device_get_device_type would report the device type as it was send on
      DBus, while fetching the property would mean that only a known device
      types is reported.
      
      Make both results consistent by coercing in nm_device_get_device_type
      rather than when setting the property.
      a6a185ba
    • Benjamin Berg's avatar
      core,wifi-p2p: Fix Wi-Fi P2P device type · 8d9365a9
      Benjamin Berg authored
      The device type was set to the GType rather than a new value in the
      NMDeviceType enum.
      
      Add the corresponding enum entry, fix the device type and set the
      routing priority to the same value as generic devices.
      8d9365a9
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      3990c92f
    • Lubomir Rintel's avatar
      clients/tests: add wireguard import tests · c152ca37
      Lubomir Rintel authored
      c152ca37
    • Thomas Haller's avatar
      cli/wireguard: add import functionality for WireGuard · a3a8583c
      Thomas Haller authored
      Support importing ".conf" files as `wg-quick up` supports it.
      
      `wg-quick` parses several options under "[Interface]" and
      passes the remainder to `wg setconf`.
      
      The PreUp/PreDown/PostUp/PostDown options are of course not supported.
      
      "Table" for the moment behaves different.
      a3a8583c
    • Thomas Haller's avatar
      libnm: rename and expose nm_utils_base64secret_decode() in libnm · e46ba018
      Thomas Haller authored
      A NetworkManager client requires an API to validate and decode
      a base64 secret -- like it is used by WireGuard. If we don't have
      this as part of the API, it's inconvenient. Expose it.
      
      Rename it from _nm_utils_wireguard_decode_key(), to give it a more
      general name.
      
      Also, rename _nm_utils_wireguard_normalize_key() to
      nm_utils_base64secret_normalize(). But this one we keep as internal
      API. The user will care more about validating and decoding the base64
      key. To convert the key back to base64, we don't need a public API in
      libnm.
      
      This is another ABI change since 1.16-rc1.
      e46ba018
    • Thomas Haller's avatar
      libnm: fix return value for nm_wireguard_peer_append_allowed_ip() · f3ac8c6f
      Thomas Haller authored
      According to documentation, this returns a boolean indicating whether
      the value is valid. Previously, it was indicating whether the instance
      was modified.
      
      Together with the @accept_invalid argument, both behaviors make some
      sense. Change it, because that is also how the other setters behave.
      f3ac8c6f
    • Thomas Haller's avatar
      libnm: change nm_wireguard_peer_set_endpoint() API to allow validation · 8ae9aa24
      Thomas Haller authored
      This is an API break since 1.16-rc1.
      
      Similar to previous commit.
      8ae9aa24
    • Thomas Haller's avatar
      libnm: change nm_wireguard_peer_set_public_key() API to allow validation · 79626539
      Thomas Haller authored
      This is an API break since 1.16-rc1.
      
      Similar to previous commit.
      79626539
    • Thomas Haller's avatar
      libnm: change nm_wireguard_peer_set_preshared_key() API to allow validation · d7bc1750
      Thomas Haller authored
      This is an API break since 1.16-rc1.
      
      The functions like _nm_utils_wireguard_decode_key() are internal API
      and not accessible to a libnm user. Maybe this should be public API,
      but for now it is not.
      
      That makes it cumbersome for a client to validate the setting. The client
      could only reimplement the validation (bad) or go ahead and set invalid
      value.
      
      When setting an invalid value, the user can afterwards detect it via
      nm_wireguard_peer_is_valid(), but at that point, it's not clear which
      exact property is invalid.
      
      First I wanted to keep the API conservative and not promissing too much.
      For example, not promising to do any validation when setting the key.
      However, libnm indeed validates the key at the time of setting it
      instead of doing lazy validation later. This makes sense, so we can
      keep this promise and just expose the validation result to the caller.
      
      Another downside of this is that the API just got more complicated.
      But it not provides a validation API, that we previously did not have.
      d7bc1750