1. 12 Jan, 2015 1 commit
  2. 25 Nov, 2014 1 commit
  3. 19 Nov, 2014 11 commits
  4. 13 Nov, 2014 1 commit
    • Dan Winship's avatar
      all: consistently include config.h · 3bfb163a
      Dan Winship authored
      config.h should be included from every .c file, and it should be
      included before any other include. Fix that.
      (As a side effect of how I did this, this also changes us to
      consistently use "config.h" rather than <config.h>. To the extent that
      it matters [which is not much], quotes are more correct anyway, since
      we're talking about a file in our own build tree, not a system
  5. 11 Nov, 2014 1 commit
  6. 10 Nov, 2014 1 commit
  7. 07 Nov, 2014 9 commits
    • Thomas Haller's avatar
      policy: fix get_best_device() to return only active devices from the list · 065a3240
      Thomas Haller authored
      This fixes an assertion during shutdown. NMManager:dispose()
      calls remove_device(), which eventually hit the assertion
      in nm_default_route_manager_ip4_get_best_device().
      Remove the assertion, but also make sure that the function only
      returns devices from the provided list. It is counter intuitive,
      that the function might return devices that are not in the provided
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
    • Thomas Haller's avatar
      policy: return best config based on the internal sorting of NMDefaultRouteManager · 6e409ef9
      Thomas Haller authored
      Now that both VPN and devices are managed (and ordered) by
      NMDefaultRouteManager, refactor get_best_config() to use the
      priority accordingly.
      Before, we would first iterate over all VPN connections and
      returning the best one. Only if no suitable VPN connection
      was found, a best device would be returned.
      Modify get_best_config() to treat VPN and device the same and
      return the best one based on the route metric.
      With this change, get_best_config() gives consistent results
      together with get_best_device(). Also, you can configure
      that a device gets a higher priority then a VPN.
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
    • Thomas Haller's avatar
      policy: improve get_best_device() to strictly adhering the sort order of the entries · f22c72d2
      Thomas Haller authored
      get_best_device() has two different modes depending on the @fully_activated argument.
      If @fully_activated, it only considers devices that are considered as active.
      Otherwise, it returns the best activating device (if that device is expected
      to be better then any of the already activated devices).
      Before, the check whether an activated device is considered best device
      also involved looking at the device state. This redundancy was harmful
      because part of NMDefaultRouteManager considered a device as fully activated,
      but get_best_device() might not return them.
      Split get_best_device() in two parts. The one part _ipx_get_best_activating_device()
      now checks for still activating devices. When inspecting devices with
      an entry, those devices are weighted according to _ipx_get_best_device().
      That means that both functions now give a consistent result.
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      policy: move get_best_config() function to nm-default-route-manager · ff40ccf8
      Thomas Haller authored
      No functional change, only refactoring by moving and combining the code.
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
    • Thomas Haller's avatar
      policy: track default route for VPN in NMDefaultRouteManager · a39a3ae4
      Thomas Haller authored
      Extend NMDefaultRouteManager to track NMVpnConnection beside
      NMDevice. That way, all default routes are managed by
      For VPN connections the manager also tracks connections that are
      set never_default. That is useful because NMPolicy still uses VPNs
      without default route to setup DNS. Hence, NMDefaultRouteManager
      trackes those connections to have the relative priority of the
      Interestingly, that means that for VPNs that are ipv4.never-default,
      ipv4.route-metric still has an effect in determining relative priorities
      for DNS configuration.
      This commit only adds the parts to track the default route. NMPolicy
      still sets the route as before.
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
    • Thomas Haller's avatar
      policy: better sync get_best_device() with NMDefaultRouteManager · a94605f9
      Thomas Haller authored
      NMDefaultRouteManager has a sorted list of routes. Change get_best_device()
      to better consider that list when choosing a best device.
      Always prefer the priority as reported from entry->effective_metric
      if the device is registered to have a default route. Before for
      !fully_activated, we choose the metric based on
      Add more checks in case of equal priority. For @fully_activated,
      always prefer the device that is sorted by NMDefaultRouteManager.
      For non @fully_activated, prefer the device with an entry.
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
    • Thomas Haller's avatar
      policy: move get_best_device() function to nm-default-route-manager · 0fc47f3b
      Thomas Haller authored
      No functional change, only refactoring by moving and combining the code.
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
    • Thomas Haller's avatar
      policy: add manager for default routes and support multiple default routes · e8824f6a
      Thomas Haller authored
      Up to now, NMPolicy would iterate over all devices to find the "best"
      device and assign the default route to that device.
      A better approach is to add a default route to *all* devices that
      are never-default=no. The relative priority is choosen according to
      the route metrics.
      If two devices receive the same metric, we want to prefer the device
      that activates first. That way, the default route sticks to the same
      device until a better device activates or the device deactivates.
      Hence, the order of activation is imporant in this case (as it is
      already now).
      Also, if several devices have identical metrics, increment their
      metrics so that every metric is unique.
      This makes the routing deterministic according to what we choose as best
      A special case is assumed devices. In this case we cannot adjust the metric
      in face of equal metrics.
      Add a new singleton class NMDefaultRouteManager that has a list of all
      devices and their default routes. The manager will order the devices by
      their priority and configure the routes using platform.
      Also update the metric for VPN connections. Later we will track VPN
      routes also via NMDefaultRouteManager. For now, fix the VPN metric because
      otherwise VPNs would always get metric 1024 (which is usually much larger then the
      device metrics).
      https://bugzilla.gnome.org/show_bug.cgi?id=735512Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>