1. 05 Oct, 2017 2 commits
  2. 04 Oct, 2017 8 commits
  3. 03 Oct, 2017 2 commits
  4. 02 Oct, 2017 3 commits
  5. 29 Sep, 2017 11 commits
  6. 28 Sep, 2017 9 commits
  7. 27 Sep, 2017 5 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      libnm: add nm_ip_route_equal_full() function · f83e6b97
      Thomas Haller authored
      Expose previously internal function nm_ip_route_equal_full(). It's
      just useful API.
      
      However, add a @cmp_flags argument, so that in the future we could
      extend it.
      f83e6b97
    • Thomas Haller's avatar
      libnm: don't skip routes in nm_setting_ip_config_add_route() that only differ by attributes · f05ebc42
      Thomas Haller authored
      For kernel and NetworkManager's core, route identity is a complicated topic
      (see NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID). For example, a route
      without explity table is treated identical to "table 254" or "table 0".
      
      It would be complicated to have nm_setting_ip_config_add_route()
      implement that logic, especially since libnm offers not public API
      to expose kernel's logic.
      
      However, previously nm_setting_ip_config_add_route() would only consider
      dest/prefix,next_hop,metric when comparing for equality. Hence, with
      
        nmcli connection modify "$CON" +ipv4.routes '192.168.5.0/24'
        nmcli connection modify "$CON" +ipv4.routes '192.168.5.0/24 table=42'
      
      the second route was not actually added, although it is a very different
      route. Fix that, and consider attributes too. Note that this allows the user
      to add two routes that look different to libnm, but are actually idential:
      
        nmcli connection modify "$CON" +ipv4.routes '192.168.5.0/24'
        nmcli connection modify "$CON" +ipv4.routes '192.168.5.0/24 table=254'
      
      In the above example, the route instances look different, but
      sementically they are both the same route in the main table (254).
      
      This also allows the user to add routes that are semantically different, but
      are treated as the same route by kernel:
      
        nmcli connection modify "$CON" +ipv6.routes 'a:b:c::/120'
        nmcli connection modify "$CON" +ipv6.routes 'a:b:c::/120 mtu=600'
      
      I think libnm should allow to add routes as long as they look different
      to libnm. Regardless how kernel and NetworkManager-core thinks about
      route identity.
      
      This changes API of nm_setting_ip_config_add_route(). However, I think
      the previous behavior was just broken.
      
      Same for nm_setting_ip_config_remove_route_by_value().
      f05ebc42
    • Thomas Haller's avatar
      libnm: make index variable i unsigned for iterating array · d06c46b8
      Thomas Haller authored
      GArray's and GPtrArray's plen argument is unsigned. The index variable
      to iterate the list, should not have a smaller range (or different data type).
      
      Also, assert against negative idx argument.
      d06c46b8
    • Thomas Haller's avatar
      contrib/rpm: enable "NetworkManager-wait-online.service" on package upgrade · 513d0c22
      Thomas Haller authored
      Since commit d61eaf25 ("service: don't
      install dependency for "NetworkManager-wait-online.service" to
      "network-online.target.wants") we no longer install NM-w-o.service
      in "network-online.target.wants" directory.
      
      Obviously, for previous RPM versions NM-w-o.service was always enabled.
      For current versions, it depends now on the preset. Most importantly,
      this allows the user to disable the service, without masking it.
      Previously NM-w-o.service was always implicitly enabled.
      
      But presets are not applied during package upgrade, so it means that
      after upgrade the service will be disabled. Hack around that via an RPM
      scriptlet.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1455704
      513d0c22