1. 07 Nov, 2014 3 commits
    • 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>