1. 05 Sep, 2017 1 commit
  2. 24 Aug, 2017 2 commits
    • Thomas Haller's avatar
      platform: add option to suppress error message from nm_platform_ip_route_add() · 8f65f96a
      Thomas Haller authored
      When an error happens, we want to print a better message.
      Avoid duplicate error messages by adding a flag to suppress
      logging in the lower layer.
      8f65f96a
    • Thomas Haller's avatar
      platform: return failure reason from route-add and return only netlink response · 774c8a81
      Thomas Haller authored
      Let nm_platform_ip_route_add() and friends return an NMPlatformError
      failure reason.
      
      Also, do_add_addrroute() did not return the response from kernel.
      Instead, it determined success/failure based on the presence of the
      object in the cache. That is racy and does not allow to give a failure
      reason from kernel.
      
      Instead, determine success solely based on the netlink reply from
      kernel. The received errno shall be authorative, there is no need
      to second guess the response.
      
      There is a problem that netlink is not a reliable protocol. In case
      of receive buffer overflow, the response is lost and we don't know
      whether the command succeeded (it likely did). It's unclear how to fix
      that, but for now just return "unspecified" error. We probably avoid
      that already by having a huge buffer size.
      
      Also, downgrade the error message to <warn> level. <error> is really
      for bugs only.
      774c8a81
  3. 23 Aug, 2017 1 commit
  4. 12 Aug, 2017 2 commits
    • Thomas Haller's avatar
      platform: fix cache to use kernel's notion for equality of routes · cdd8c657
      Thomas Haller authored
      Until now, NetworkManager's platform cache for routes used the quadruple
      network/plen,metric,ifindex for equaliy. That is not kernel's
      understanding of how routes behave. For example, with `ip route append`
      you can add two IPv4 routes that only differ by their gateway. To
      the previous form of platform cache, these two routes would wrongly
      look identical, as the cache could not contain both routes. This also
      easily leads to cache-inconsistencies.
      
      Now that we have NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID, fix the route's
      compare operator to match kernel's.
      
      Well, not entirely. Kernel understands more properties for routes then
      NetworkManager. Some of these properties may also be part of the ID according
      to kernel. To NetworkManager such routes would still look identical as
      they only differ in a property that is not understood. This can still
      cause cache-inconsistencies. The only fix here is to add support for
      all these properties in NetworkManager as well. However, it's less serious,
      because with this commit we support several of the more important properties.
      See also the related bug rh#1337855 for kernel.
      
      Another difficulty is that `ip route replace` and `ip route change`
      changes an existing route. The replaced route has the same
      NM_PLATFORM_IP_ROUTE_CMP_TYPE_WEAK_ID, but differ in the actual
      NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID:
      
          # ip -d -4 route show dev v
          # ip monitor route &
          # ip route add 192.168.5.0/24 dev v
          192.168.5.0/24 dev v scope link
          # ip route change 192.168.5.0/24 dev v scope 10
          192.168.5.0/24 dev v scope 10
          # ip -d -4 route show dev v
          unicast 192.168.5.0/24 proto boot scope 10
      
      Note that we only got one RTM_NEWROUTE message, although from NMPCache's
      point of view, a new route (with a particular ID) was added and another
      route (with a different ID) was deleted. The cumbersome workaround is,
      to keep an ordered list of the routes, and figure out which route was
      replaced in response to an RTM_NEWROUTE. In absence of bugs, this should
      work fine. However, as we only rely on events, we might wrongly
      introduce a cache-inconsistancy as well. See the related bug rh#1337860.
      
      Also drop nm_platform_ip4_route_get() and the like. The ID of routes
      is complex, so it makes little sense to look up a route directly.
      cdd8c657
    • Thomas Haller's avatar
      platform: preserve order of objects during dump · 94c02545
      Thomas Haller authored
      NMPCache can preserve the order of the objects. Until now, the order
      was however arbitrary. Soon we will require to preserve the order of
      routes.
      
      During a dump, force appending new objects at the end. That ensures,
      correct ordering during the dump.
      
      Note that we track objects in several distrinct indexes. Those partition the
      set of all objects. Outside a dump when receiving events about new objects (e.g.
      RTM_NEWROUTE), it is very unclear at which place the new object should be sorted.
      It is especially unclear, as an object might move from one partition (of
      an index) to another.
      In general, a deterministic order will only be useful in one particular
      instance: the NMP_CACHE_ID_TYPE_ROUTES_BY_DESTINATION index for routes.
      In this case, we will ensure a particular order of the routes.
      94c02545
  5. 03 Aug, 2017 1 commit
    • Thomas Haller's avatar
      platform: extend API for adding routes · d373855e
      Thomas Haller authored
      Via the flags of the RTM_NEWROUTE netlink message, kernel and iproute2
      support various variants to add a route.
      
       - ip route add
       - ip route change
       - ip route replace
       - ip route prepend
       - ip route append
       - ip route test
      
      Previously, our nm_platform_ip4_route_add() function was basically
      `ip route replace`. In the future, we should rather user `ip route
      append` instead.
      
      Anyway, expose the netlink message flags in the API. This allows to
      use the various forms, and makes it also more apparent to the user that
      they even exist.
      d373855e
  6. 25 Jul, 2017 1 commit
    • Thomas Haller's avatar
      platform: pass full route object to platform delete function · 2861c591
      Thomas Haller authored
      Contrary to addresses, routes have no ID. When deleting a route,
      you cannot just specify certain properties like network/plen,metric.
      
      Well, actually you can specify only certain properties, but then kernel
      will treat unspecified properties as wildcard and delete the first matching
      route. That is not something we want, because we need to be in control which
      exact route shall be deleted.
      
      Also, rtm_tos *must* match. Even if we like the wildcard behavior,
      we would need to pass TOS to nm_platform_ip4_route_delete() to be
      able to delete routes with non-zero TOS. So, while certain properties
      may be omitted, some must not. See how test_ip4_route_options() was
      broken.
      
      For NetworkManager it only makes ever sense to call delete on a route,
      if the route is already fully known. Which means, we only delete routes
      that we have already in the platform cache (otherwise, how would we know
      that there is something to delete). Because of that, no longer have separate
      IPv4 and IPv6 functions. Instead, have nm_platform_ip_route_delete() which
      accepts a full NMPObject from the platform cache.
      
      The code in core doesn't jet make use of this new functionality. It will
      in the future.
      
      At least, it fixes deleting routes with differing TOS.
      2861c591
  7. 05 Jul, 2017 4 commits
    • Thomas Haller's avatar
      platform: move link accessors to NMPlatform base class · ac60b0ce
      Thomas Haller authored
      and refactor NMFakePlatform to also track links via NMPCache.
      
      For one, now NMFakePlatform also tests NMPCache, increasing the
      coverage of what we care about.
      
      Also, all our NMPlatform implementations now use NMPObject and NMPCache.
      That means, we can expose those as part of the public API. Which is
      great, because callers can keep a reference to the NMPObject object
      and make use of generic functions like nmp_object_to_string().
      ac60b0ce
    • Thomas Haller's avatar
      platform: refactor fake platform to use NMPCache for addresses · 71cf60e8
      Thomas Haller authored
      And move some code from NMLinuxPlatform to NMPlatform, where it belongs.
      
      The advantage is that we reuse (and test!) the NMPCache implementation for
      tracking addresses.
      
      Also, we now always expose proper NMPObjects from both linux and fake
      platform.
      
      For example,
      
        obj = NMP_OBJECT_UP_CAST (nm_platform_ip4_address_get (...));
      
      will work as expected. Also, the caller is now by NMPlatform API
      allowed to take and keep a reference to the returned objects.
      71cf60e8
    • Thomas Haller's avatar
      platform: drop separate index for visible objects · 17f02318
      Thomas Haller authored
      Routes and addresses don't implement cmd_obj_is_visible(),
      hence they are always visible, and NMP_CACHE_ID_TYPE_OBJECT_TYPE_VISIBLE_ONLY
      is identical to NMP_CACHE_ID_TYPE_OBJECT_TYPE.
      
      Only link objects can be alive but invisible. Still, drop the index
      for looking up visible links entirely. Let callers do the filtering,
      if they care.
      17f02318
    • Thomas Haller's avatar
      platform: track routes in NMFakePlatform via NMPCache · c9cd6d99
      Thomas Haller authored
      NMPlatform's cache should be directly accessible to the users,
      at least the NMPLookup part and the fact that the cache contains
      ref-counted, immutable NMPObjects.
      
      This allows users to inspect the cache with zero overhead. Meaning,
      they can obtain an NMDedupMultiHeadEntry and iterate the objects
      themself. It also means, the are free to take and keep references
      of the NMPObject instances (of course, without modifying them!).
      
      NMFakePlatform will use the very same cache. The fake platform should
      only differ when modifying the objects.
      
      Another reason why this makes sense is because NMFakePlatform is for one
      a test-stup but also tests behavior of platform itself. Using a separate
      internal implementation for the caching is a pointless excecise, because
      only the real NMPCache's implementation really matters for production.
      So, either NMFakePlatform behaves idential, or it is buggy. Reuse it.
      
      Port fake platform's tracking of routes to NMPCache and move duplicate
      code from NMLinuxPlatform to the base class.
      
      This commit only ports IP routes, eventually also addresses and links
      should be tracked via the NMPCache instance.
      c9cd6d99
  8. 27 May, 2017 2 commits
  9. 18 Apr, 2017 4 commits
    • Beniamino Galvani's avatar
      platform: detect SR-IOV support and allow changing the number of VFs · 2511e27e
      Beniamino Galvani authored
      (cherry picked from commit 0a7694cf)
      2511e27e
    • Beniamino Galvani's avatar
    • Thomas Haller's avatar
      core: add NMNetns to bundle platform and route managers · d37b9d79
      Thomas Haller authored
      NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons
      instances. Users of those are for example NMDevice, which registers
      to GObject signals of both NMPlatform and NMRouteManager.
      
      Hence, as NMDevice:dispose() disconnects the signal handlers, it must
      ensure that those singleton instances live longer then the NMDevice
      instance. That is usually accomplished by having users of singleton
      instances own a reference to those instances.
      For NMDevice that effectively means that it shall own a reference to
      several singletons.
      
      NMPlatform, NMRouteManager, and NMDefaultRouteManager are all
      per-namespace. In general it doesn't make sense to have more then
      one instances of these per name space. Nnote that currently we don't
      support multiple namespaces yet. If we will ever support multiple
      namespaces, then a NMDevice would have a reference to all of these
      manager instances. Hence, introduce a new class NMNetns which bundles
      them together.
      
      (cherry picked from commit 0af2f5c2)
      d37b9d79
    • Thomas Haller's avatar
      core: add NMNetns to bundle platform and route managers · 0af2f5c2
      Thomas Haller authored
      NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons
      instances. Users of those are for example NMDevice, which registers
      to GObject signals of both NMPlatform and NMRouteManager.
      
      Hence, as NMDevice:dispose() disconnects the signal handlers, it must
      ensure that those singleton instances live longer then the NMDevice
      instance. That is usually accomplished by having users of singleton
      instances own a reference to those instances.
      For NMDevice that effectively means that it shall own a reference to
      several singletons.
      
      NMPlatform, NMRouteManager, and NMDefaultRouteManager are all
      per-namespace. In general it doesn't make sense to have more then
      one instances of these per name space. Nnote that currently we don't
      support multiple namespaces yet. If we will ever support multiple
      namespaces, then a NMDevice would have a reference to all of these
      manager instances. Hence, introduce a new class NMNetns which bundles
      them together.
      0af2f5c2
  10. 24 Mar, 2017 1 commit
  11. 06 Mar, 2017 2 commits
  12. 13 Dec, 2016 1 commit
  13. 22 Oct, 2016 1 commit
  14. 04 Oct, 2016 1 commit
    • Thomas Haller's avatar
      core: refactor private data in "src" · 4d37f7a1
      Thomas Haller authored
      - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere.
      
      - reorder statements, to have GObject related functions (init, dispose,
        constructed) at the bottom of each file and in a consistent order w.r.t.
        each other.
      
      - unify whitespaces in signal and properties declarations.
      
      - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify()
      
      - drop unused signal slots in class structures
      
      - drop unused header files for device factories
      4d37f7a1
  15. 03 Oct, 2016 1 commit
  16. 05 Jul, 2016 1 commit
    • Thomas Haller's avatar
      core: don't warn when setting address of non-existing link · f9852821
      Thomas Haller authored
      Trying to set a property on a device that does not exist is not something
      necessarily wrong. Don't print error/warning messages.
      
          <trace> [1467707267.2887] device[0x55a74adbdaf0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, unmanage)...
          <debug> [1467707267.2887] platform: link: setting '(null)' (2) hardware address
          <debug> [1467707267.2887] platform-linux: link: change 2: address: 68:F7:28:61:68:F7 (6 bytes)
          <debug> [1467707267.2887] platform-linux: do-request-link: 2
          <debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 226
          <debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 227
          <error> [1467707267.2888] platform-linux: do-change-link[2]: failure changing link: failure 19 (No such device)
          <warn>  [1467707267.2888] device (enp0s25): set-hw-addr: failed to reset MAC address to 68:F7:28:61:68:F7 (unmanage)
      f9852821
  17. 17 May, 2016 1 commit
  18. 28 Apr, 2016 2 commits
    • Thomas Haller's avatar
      platform: extend NMIPConfigSource to preserve the rtm_protocol field · 4c2410bc
      Thomas Haller authored
      For addresses (NMPlatformIPAddress) the @addr_source field is ignored
      on a platform level. That is, all addresses inside the platform cache
      have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason,
      the source should not be a part of the NMPlatformIPAddress structure, but
      it is convenient for users to piggy back the source inside the platform
      address structure.
      
      For routes, the source is stored in NMPlatformIPRoute's @rt_source
      field. When adding a route to kernel, we set the @rtm_protocol of the
      route depending on the source. However, we want to map different source
      values to the same protocol value.
      
      On the other hand, when kernel sends us a route that gets put inside
      the cache, we must preserve the protocol value and must not map
      different protocol values to the same source.
      The reason is, that a user can add two routes that only differ by
      @rtm_protocol. In that sense, the @rtm_protocol fields is part of the
      unique ID of a kernel route, and thus different values must map to
      different sources.
      
      Fix this, by extending the range of NMIPConfigSource to contain
      a range of protocol fields.
      4c2410bc
    • Thomas Haller's avatar
      core/trivial: rename "source" field of addresses and routes · 6bf02235
      Thomas Haller authored
      The "source" field of NMPlatformIPRoute (now "rt_source") maps to the
      protocol field of the route. The source of NMPlatformIPAddress (now
      "addr_source") has no direct equivalent in the kernel.
      
      As their use is different, they should have different names. Also,
      the name "source" is used all over the place. Hence give the fields
      a more distinct name.
      6bf02235
  19. 20 Apr, 2016 2 commits
  20. 11 Apr, 2016 2 commits
  21. 01 Mar, 2016 2 commits
    • Thomas Haller's avatar
      platform: add flags argument to nm_platform_ip4_address_add() · 684e80b5
      Thomas Haller authored
      The argument is still always unset. We will need it later to set
      IFA_F_NOPREFIXROUTE.
      684e80b5
    • Thomas Haller's avatar
      core: split "nm-core-utils.h" out of "NetworkManagerUtils.h" · adb56d13
      Thomas Haller authored
      "NetworkManagerUtils.h" contains a bunch of helper tools for core
      daemon ("src/").
      
      Unfortunately, it has dependencies to other parts of core,
      such as "nm-device.h" and "nm-platform.h". Split out a part
      of tools that are independent so that they can be used without
      dragging in other dependencies.
      
      "nm-core-utils.h" should only use libnm-core, "nm-logging.h"
      and shared.
      
      "NetworkManagerUtils.h" should provide all "nm-core-utils.h" and
      possibly other utilities that have larger dependencies.
      adb56d13
  22. 29 Feb, 2016 3 commits
  23. 19 Feb, 2016 1 commit
    • Thomas Haller's avatar
      all: cleanup includes and let "nm-default.h" include "config.h" · 8bace23b
      Thomas Haller authored
      - All internal source files (except "examples", which are not internal)
        should include "config.h" first. As also all internal source
        files should include "nm-default.h", let "config.h" be included
        by "nm-default.h" and include "nm-default.h" as first in every
        source file.
        We already wanted to include "nm-default.h" before other headers
        because it might contains some fixes (like "nm-glib.h" compatibility)
        that is required first.
      
      - After including "nm-default.h", we optinally allow for including the
        corresponding header file for the source file at hand. The idea
        is to ensure that each header file is self contained.
      
      - Don't include "config.h" or "nm-default.h" in any header file
        (except "nm-sd-adapt.h"). Public headers anyway must not include
        these headers, and internal headers are never included after
        "nm-default.h", as of the first previous point.
      
      - Include all internal headers with quotes instead of angle brackets.
        In practice it doesn't matter, because in our public headers we must
        include other headers with angle brackets. As we use our public
        headers also to compile our interal source files, effectively the
        result must be the same. Still do it for consistency.
      
      - Except for <config.h> itself. Include it with angle brackets as suggested by
        https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
      8bace23b
  24. 29 Jan, 2016 1 commit
    • Lubomir Rintel's avatar
      fake-platform: check link_get return · 9b851798
      Lubomir Rintel authored
      Can not fail no fake platform, but makes Coverity worried:
      
      CID 59381 (#1 of 1): Dereference null return value (NULL_RETURNS)
      6.  dereference: Dereferencing a null pointer device.
      9b851798