1. 18 Dec, 2017 26 commits
  2. 16 Dec, 2017 2 commits
    • Inigo Martínez's avatar
      build: Merge no introspection headers with public headers · e2562d2b
      Inigo Martínez authored
      There are three headers `nm-secret-agent-old.h`,
      `nm-vpn-plugin-old.h`, and `nm-vpn-service-plugin.h`, which are
      named as no introspection headers. However, these files also
      join to the rest headers to generate introspection data.
      
      This patch merges those no introspection headers with the public
      headers.
      e2562d2b
    • Inigo Martínez's avatar
      build: Make generate-plugin-docs.pl independent of autotools · 28914f6a
      Inigo Martínez authored
      `generate-plugin-docs.pl` script which is used to parse
      `nm-setting-c*.c` files depends on autotools. This is because it
      parses the `Makefile.am` in order to figure out the setting files
      it needs to parse.
      
      This patch makes the script independent of autotools by passing
      the necessary setting files by command line instead of parsing the
      `Makefile.am` file. It also changes the autotools' and meson's
      accordingly.
      28914f6a
  3. 15 Dec, 2017 12 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      build: add "-Wvla" to warn about uses of variable-length arrays · 9c3402aa
      Thomas Haller authored
      We don't use them, so add a compiler warning about their use.
      I think they are annoying, because sizeof(x) and typeof(x) might
      evaluate at runtime. Especially the typeof() extension is useful
      for macros, but behaves badly with variable-length arrays due to
      running code at runtime.
      
      But the worst is, G_STATIC_ASSERT() is implemented by declaring
      an array of negative length. Usually, the checked condition should
      be a compile time constant, but with VLAs the compiler would not evaluate
      the static-assert at compile time and instead accept it silently. It's easy
      to mess up static asserts to wrongly have a non-constant condition,
      especially when the static-assert is used inside a macro.
      
      Just say no.
      9c3402aa
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      tests: fix invalid static-asserts with non-const expression · 08d41ada
      Thomas Haller authored
      The expression is not const. Use a run-time assert instead
      08d41ada
    • Thomas Haller's avatar
      core: don't use variable length arrays · ea1f77f9
      Thomas Haller authored
      Let's compile with -Wvla, so that G_STATIC_ASSERT() is really
      static. But then we cannot use variable length arrays.
      ea1f77f9
    • Thomas Haller's avatar
      all: don't use NM_FLAGS_HAS() with non-constant argument · c696a226
      Thomas Haller authored
      NM_FLAGS_HAS() uses a static-assert that the second argument is a
      single flag (power of two). With a single flag, NM_FLAGS_HAS(),
      NM_FLAGS_ANY() and NM_FLAGS_ALL() are all identical.
      
      The second argument must be a compile time constant, and if that is
      not the case, one must not use NM_FLAGS_HAS().
      
      Use NM_FLAGS_ANY() in these cases.
      c696a226
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      device: generate unique default route-metrics per interface · 6a32c64d
      Thomas Haller authored
      In the past we had NMDefaultRouteManager which would coordinate adding
      the default-route with identical metrics. That especially happened, when
      activating two devices of the same type, without explicitly specifying
      ipv4.route-metric. For example, with ethernet devices, the routes on
      both interfaces would get a metric of 100.
      
      Coordinating routes was especially necessary, because we added
      routes with NLM_F_EXCL flag, akin to `ip route replace`. We not
      only had to avoid that activating two devices in NetworkManager would
      result in a fight over the default-route, but more importently
      to preserve externally added default-routes on unmanaged interfaces.
      
      NMDefaultRouteManager would ensure that in case of duplicate
      metrics, that the device that activated first would keep the
      best default-route. It would do so by bumping the metric
      of the second device to find a unused metric. The bumping itself
      was not very important -- MDefaultRouteManager could also just not
      configure any default-routes that show up as second, the result
      would be quite similar. More important was to keep the best
      default-route on the first activating device until the device
      deactivates or a device activates that really has a better
      default-route..
      
      Likewise, NMRouteManager would globally manage non-default-routes.
      It would not do any bumping of metrics, but it would also ensure that the routes
      of the device that activates first are not overwritten by a device activating
      later.
      
      However, the `ip route replace` approach has downsides, especially
      that it messes with routes on other interfaces, interfaces that are
      possibly not managed by NetworkManager. Another downside is, that
      binding a socket to an interface might not result in correct
      routes, because the route might just not be there (in case of
      NMRouteManager, which wouldn't configure duplicate routes by bumping
      their metric).
      
      Since commit 77ec3027 we would no longer
      use NLM_F_EXCL, but add routes akin to `ip route append`. When
      activating for example two ethernet devices with no explict route
      metric configuration, there are two routes like
      
         default via 10.16.122.254 dev eth0 proto dhcp metric 100
         default via 192.168.100.1 dev eth1 proto dhcp metric 100
      
      This does not only affect default routes. In case of a multi-homing
      setup you'd get
      
        192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100
        192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100
      
      but it's visible the most for default-routes.
      
      Note that we would append the routes that are activated later, as the order
      of `ip route show` confirms. One might hence expect, that kernel selects
      a route based on the order in the routing tables. However, that isn't
      the case, and activating the second interface will non-deterministically
      re-route traffic via the new interface. That will interfere badly with
      with NAT, stateful firewalls, and existing connections (like TCP).
      
      The solution is to have NMManager keep a global index of the default route-metrics
      currently in use. So, instead of determining the default-route metric based solely
      on the device-type, we now in addition generate default metrics that do not
      overlap. For example, if you activate eth0 first, it gets route-metric 100,
      and if you then activate eth1, it gets 101. Note that if you deactivate
      and re-activate eth0, then it will get route-metric 102, because the
      best route should stick on eth1 (which reserves the range 100 to 101).
      
      Note that when a connection explititly selects a particular metric, then that
      choice is honored (contrary to NMDefaultRouteManager which was more concerned
      with avoiding conflicts, then keeping the exact metric).
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1505893
      6a32c64d
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      core: cache device state in NMConfig and load all at once · ea08df92
      Thomas Haller authored
      NMManager will need to know the state of all device at once.
      Hence, load it once and cache it in NMConfig.
      
      Note that this wastes a bit of memory in the order of
      O(number-of-interfaces). But each device state entry is
      rather small, and we always consume memory in the order
      of O(number-of-interfaces).
      ea08df92
    • Thomas Haller's avatar
      3f38b765