1. 18 Apr, 2019 1 commit
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · d984b2ce
      Thomas Haller authored
      From the files under "shared/nm-utils" we build an internal library
      that provides glib-based helper utilities.
      Move the files of that basic library to a new subdirectory
      "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
      to "libnm-glib-aux.la".
       - the name "utils" is overused in our code-base. Everything's an
         "utils". Give this thing a more distinct name.
       - there were additional files under "shared/nm-utils", which are not
         part of this internal library "libnm-utils-base.la". All the files
         that are part of this library should be together in the same
         directory, but files that are not, should not be there.
       - the new name should better convey what this library is and what is isn't:
         it's a set of utilities and helper functions that extend glib with
         funcitonality that we commonly need.
      There are still some files left under "shared/nm-utils". They have less
      a unifying propose to be in their own directory, so I leave them there
      for now. But at least they are separate from "shared/nm-glib-aux",
      which has a very clear purpose.
      (cherry picked from commit 80db06f7)
  2. 11 Mar, 2019 1 commit
  3. 09 Mar, 2019 1 commit
  4. 07 Mar, 2019 2 commits
  5. 12 Feb, 2019 1 commit
  6. 06 Feb, 2019 1 commit
    • Thomas Haller's avatar
      all: don't use "static inline" in source files · d25ed082
      Thomas Haller authored
      For static functions inside a module, the compiler determines on its own
      whether to inline the function.
      Also, "inline" was used at some places that don't immediatly look like
      candidates for inlining. It was most likely a copy&paste error.
  7. 19 Dec, 2018 2 commits
    • Thomas Haller's avatar
      core: allow addresses with zero prefix length · 3102b49f
      Thomas Haller authored
      There is really no problem here, allow it.
      Previously we would assert against a non-zero prefix length.
      But I am not sure that all callers really ensured that this
      couldn't happen. Anyway, there is no problem we such addresses,
      Only we need to make sure that nm_ip4_config_add_dependent_routes()
      and nm_ip6_config_add_dependent_routes() don't add prefix routes for
      such addresses (which is the case now).
    • Thomas Haller's avatar
      all: don't use static buffer for nm_utils_inet*_ntop() · a51c09dc
      Thomas Haller authored
      While nm_utils_inet*_ntop() accepts a %NULL buffer to fallback
      to a static buffer, don't do that.
      I find the possibility of using a static buffer here error prone
      and something that should be avoided. There is of course the downside,
      that in some cases it requires an additional line of code to allocate
      the buffer on the stack as auto-variable.
  8. 13 Nov, 2018 1 commit
    • Thomas Haller's avatar
      all: cleanup GChecksum handling · eb9f950a
      Thomas Haller authored
      - prefer nm_auto_free_checksum over explicit free.
      - use nm_utils_checksum_get_digest*().
      - prefer defines for digest length.
      - assume g_checksum_new() cannot fail.
  9. 26 Sep, 2018 2 commits
  10. 08 Aug, 2018 1 commit
  11. 01 Aug, 2018 1 commit
    • Thomas Haller's avatar
      core: use nm_gobject_notify_together() in NMIP4Config/NMIP6Config · 62a4f265
      Thomas Haller authored
      nm_gobject_notify_together() freezes the notifications to emit both
      notification signals together. That matters for NMDBusObject base
      class, which hooks into dispatch_properties_changed() to emit a combined
      "PropertiesChanged" signal.
      Note, that during calls like nm_ip4_config_replace(), we already
      froze/thawed the notifications. So, this change adds unnecessary
      freeze/thaw calls, because signal emition is already frozen.
      That is a bit ugly, because g_object_freeze_notify() is more heavy
      than I'd wish it would be.
      Anyway, for other places, like nm_ip4_config_reset_routes() that is
      not the case. And correctness trumps performance.
      Ultimately, the issue there is that we use NMIP4Config / NMIP6Config
      both to track internal configuration, and to expose it on D-Bus.
      The majority of created NMIP4Config / NMIP6Config instances won't get
      exported, and but still pay an unnecessary overhead. The proper solution
      to minimize the overhead would be, to separate these uses.
  12. 11 Jul, 2018 1 commit
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      We commonly don't use the glib typedefs for char/short/int/long,
      but their C types directly.
          $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
      One could argue that using the glib typedefs is preferable in
      public API (of our glib based libnm library) or where it clearly
      is related to glib, like during
        g_object_set (obj, PROPERTY, (gint) value, NULL);
      However, that argument does not seem strong, because in practice we don't
      follow that argument today, and seldomly use the glib typedefs.
      Also, the style guide for this would be hard to formalize, because
      "using them where clearly related to a glib" is a very loose suggestion.
      Also note that glib typedefs will always just be typedefs of the
      underlying C types. There is no danger of glib changing the meaning
      of these typedefs (because that would be a major API break of glib).
      A simple style guide is instead: don't use these typedefs.
      No manual actions, I only ran the bash script:
        FILES=($(git ls-files '*.[hc]'))
        sed -i \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
  13. 14 May, 2018 1 commit
  14. 30 Apr, 2018 1 commit
  15. 20 Mar, 2018 2 commits
    • Thomas Haller's avatar
      device: don't capture resolve.conf for initial device config · 454195c0
      Thomas Haller authored
      This was called by via
        - manager:recheck_assume_connection()
          - manager:get_existing_connection()
            - nm_device_capture_initial_config()
              - update_ext_ip_config(initial=TRUE)
      and would parse resolv.conf, and try to fill the device IP config
      with nameservers and dns-options.
      But why? It would only have effect if NM was started with
      nm_dns_manager_get_resolv_conf_explicit(), but is that really sensible?
      And it would only take effect on devices that have a default route.
      And for what is this information even used?
      Let's not do it this way. If we need this information for assuming or
      external sys-iface mode, then it should be explicitly loaded at the
      appropriate moment.
      For now, drop it and see what breaks. Then we can fix it properly. If
      it even matters.
    • Thomas Haller's avatar
      core: add nm_ip6_config_find_first_address() function and refactor lookup of code · 945339cb
      Thomas Haller authored
      Instead have one particular nm_ip6_config_get_address_first_nontentative() function,
      make it more extendable. Now, we pass a match-type argument, which can control which
      element to search.
      This patch has no change in behavior, but it already makes clear, that
      nm_ip6_config_get_address_first_nontentative() was buggy, because it would
      also return addresses that failed DAD.
  16. 13 Mar, 2018 1 commit
    • Thomas Haller's avatar
      core/dbus: rework creating numbered D-Bus export path by putting counter into class · 57ab9fd6
      Thomas Haller authored
      I dislike the static hash table to cache the integer counter for
      numbered paths. Let's instead cache the counter at the class instance
      itself -- since the class contains the information how the export
      path should be exported.
      However, we cannot use a plain integer field inside the class structure,
      because the class is copied between derived classes. For example,
      NMDeviceEthernet and NMDeviceBridge both get a copy of the NMDeviceClass
      instance. Hence, the class doesn't contain the counter directly, but
      a pointer to one counter that can be shared between sibling classes.
  17. 12 Mar, 2018 1 commit
    • Thomas Haller's avatar
      core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API · 297d4985
      Thomas Haller authored
      Previously, we used the generated GDBusInterfaceSkeleton types and glued
      them via the NMExportedObject base class to our NM types. We also used
      Don't do that anymore. The resulting code was more complicated despite (or
      because?) using generated classes. It was hard to understand, complex, had
      ordering-issues, and had a runtime and memory overhead.
      This patch refactors this entirely and uses the lower layer API GDBusConnection
      directly. It replaces the generated code, GDBusInterfaceSkeleton, and
      GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager
      and static descriptor instances of type GDBusInterfaceInfo.
      This adds a net plus of more then 1300 lines of hand written code. I claim
      that this implementation is easier to understand. Note that previously we
      also required extensive and complex glue code to bind our objects to the
      generated skeleton objects. Instead, now glue our objects directly to
      GDBusConnection. The result is more immediate and gets rid of layers of
      code in between.
      Now that the D-Bus glue us more under our control, we can address issus and
      bottlenecks better, instead of adding code to bend the generated skeletons
      to our needs.
      Note that the current implementation now only supports one D-Bus connection.
      That was effectively the case already, although there were places (and still are)
      where the code pretends it could also support connections from a private socket.
      We dropped private socket support mainly because it was unused, untested and
      buggy, but also because GDBusObjectManagerServer could not export the same
      objects on multiple connections. Now, it would be rather straight forward to
      fix that and re-introduce ObjectManager on each private connection. But this
      commit doesn't do that yet, and the new code intentionally supports only one
      D-Bus connection.
      Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start()
      succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to
      connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough
      for the moment. It could be easily extended later, for example with polling whether the
      system bus appears (like was done previously). Also, restart of D-Bus daemon isn't
      supported either -- just like before.
      Note how NMDBusManager now implements the ObjectManager D-Bus interface
      Also, this fixes race issues in the server, by no longer delaying
      PropertiesChanged signals. NMExportedObject would collect changed
      properties and send the signal out in idle_emit_properties_changed()
      on idle. This messes up the ordering of change events w.r.t. other
      signals and events on the bus. Note that not only NMExportedObject
      messed up the ordering. Also the generated code would hook into
      notify() and process change events in and idle handle, exhibiting the
      same ordering issue too.
      No longer do that. PropertiesChanged signals will be sent right away
      by hooking into dispatch_properties_changed(). This means, changing
      a property in quick succession will no longer be combined and is
      guaranteed to emit signals for each individual state. Quite possibly
      we emit now more PropertiesChanged signals then before.
      However, we are now able to group a set of changes by using standard
      g_object_freeze_notify()/g_object_thaw_notify(). We probably should
      make more use of that.
      Also, now that our signals are all handled in the right order, we
      might find places where we still emit them in the wrong order. But that
      is then due to the order in which our GObjects emit signals, not due
      to an ill behavior of the D-Bus glue. Possibly we need to identify
      such ordering issues and fix them.
      Numbers (for contrib/rpm --without debug on x86_64):
      - the patch changes the code size of NetworkManager by
        - 2809360 bytes
        + 2537528 bytes (-9.7%)
      - Runtime measurements are harder because there is a large variance
        during testing. In other words, the numbers are not reproducible.
        Currently, the implementation performs no caching of GVariants at all,
        but it would be rather simple to add it, if that turns out to be
        Anyway, without strong claim, it seems that the new form tends to
        perform slightly better. That would be no surprise.
        $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .;  done)
        - real    1m39.355s
        + real    1m37.432s
        $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done)
        - real    0m26.843s
        + real    0m25.281s
      - Regarding RSS size, just looking at the processes in similar
        conditions, doesn't give a large difference. On my system they
        consume about 19MB RSS. It seems that the new version has a
        slightly smaller RSS size.
        - 19356 RSS
        + 18660 RSS
  18. 09 Feb, 2018 2 commits
    • Thomas Haller's avatar
      core: distinguish between IFA_F_SECONDARY and IFA_F_TEMPORARY · 3e9e51f1
      Thomas Haller authored
      While the numerical values of IFA_F_SECONDARY and IFA_F_TEMPORARY
      are identical, their meaning is not.
      IFA_F_SECONDARY is only relevant for IPv4 addresses, while
      IFA_F_TEMPORARY is only relevant for IPv6 addresses.
      IFA_F_TEMPORARY is automatically set by kernel for the addresses
      that it generates as part of IFA_F_MANAGETEMPADDR. It cannot be
      actively set by user-space.
      IFA_F_SECONDARY is automatically set by kernel depending on the order
      in which the addresses for the same subnet are added.
      This essentially reverts 8b4f1192 (core: avoid IFA_F_TEMPORARY alias for
    • Thomas Haller's avatar
      platform: rework nm_platform_ip6_address_sync() to fix address order · 7e208c1d
      Thomas Haller authored
      We want to add addresses in a particular order so that source address
      selection works.
      Note that @known_addresses contains the desired addresses in order of
      least-important first, while @plat_addresses contains them in opposite
      order. Previously, this inverted order was not considered, and we
      essentially ended up removing and re-adding all addresses every time.
      Fix that. While at it, get rid of the O(n^2) runtime complexity, and
      make it O(n) by iterating both lists simultaneously.
  19. 07 Feb, 2018 1 commit
  20. 18 Dec, 2017 1 commit
  21. 15 Dec, 2017 1 commit
  22. 11 Dec, 2017 1 commit
  23. 06 Dec, 2017 2 commits
  24. 17 Nov, 2017 1 commit
  25. 13 Nov, 2017 1 commit
  26. 12 Oct, 2017 1 commit
    • Thomas Haller's avatar
      core: use router preference for IPv6 routes · 032b4e43
      Thomas Haller authored
      For routes and the default-route from NDisc, set the router preference
      Also, previously, we would only configure one IPv6 default-route. That by itself
      was not really a problem, as long as NetworkManager would always make sure that
      it configured the route to the ~best~ router.
      Actually, NM should have done that already. It keeps the list of gateways
      sorted, and prefers them according to their preference. But maybe
      it didn't, so we have bug rh#1445417 (??).
      Change that by configuring a default-route for all gateways, with
      appropriate router prefrence. In case, kernel doesn't support RTA_PREF
      yet, only configure all routes that share the same maxiumum preference.
  27. 10 Oct, 2017 2 commits
    • Beniamino Galvani's avatar
      core: fix memory leaks in NMIP{4,6}Config · 31ad3dbc
      Beniamino Galvani authored
      Fixes: 03e1cc96
      Fixes: 9a3117f1
    • Thomas Haller's avatar
      core: rework tracking of gateway/default-route in ip-config · 5c299454
      Thomas Haller authored
      Instead of having 3 properties @gateway, @never_default and @has_gateway
      on NMIP4Config/NMIP6Config that determine the default-route, track the
      default-route as a regular route.
      The gateway setting is the configuration knob for the default-route.
      Since an NMIP4Config/NMIP6Config instance only has one gateway property,
      it cannot track more then one default-routes (see related bug rh#1445417).
      Especially with policy routing, it might be interesting to configure a
      default-route in multiple tables.
      Also, later it might be interesting to allow adding default-routes as
      regular static routes in a connection, so that the user can configure additional
      route parameters for the default-route or add default-routes in multiple tables.
      With this patch, default-routes now have a rt_source property according to their
      Also, the previous commits of this branch broke handling of the
      default-route :) . That should be working now again.
  28. 09 Oct, 2017 5 commits
    • Thomas Haller's avatar
      core: don't track route metric in ip-config · 2bdfc092
      Thomas Haller authored
      It's not needed. Whenever we add a route, we pass in the
      route metric (for example, based on the device's configuration).
      No need to merge and track it into the NMIP4Config/NMIP6Config.
      The metric was only used in nm_ip4_config_create_setting()
      and nm_ip6_config_create_setting(). In fact it's wrong to do
      that, because it means we first capture some settings, and guess
      the configured route metric. But we cannot do that. Our best
      guess what a configured setting might be is -1.
    • Thomas Haller's avatar
      core: don't track route MSS in ip-config · 9003dae6
      Thomas Haller authored
      The MSS is only set for VPN connections (by merging it in the respective
      It is also only used when setting the MSS of the default route.
      Don't track that property in NMIP4Config/NMIP6Config, instead, set the
      mss of the route directly in nm_vpn_connection_ip4_config_get() and
      There is a potential change in behavior here: NMDevice also consisdered
      the MSS for the default route, but that would only be set if the MSS
      gets merged from an vpn-ip-config. Which at most is the case for
      iterface-less VPN types (libreswan). But even in that case, it doesn't
      seem right to me to use the VPN's MSS for the device's default-route.
    • Thomas Haller's avatar
      core: use ipv6.route-table setting for other IPv6 routes · 2e146148
      Thomas Haller authored
      Including device-routes, default-route, SLAAC.
    • Thomas Haller's avatar
      all: rework configuring route table support by adding "route-table" setting · cc1ee1d2
      Thomas Haller authored
      We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
      behavior for users that configured policy routing outside of NetworkManager,
      for example, via a dispatcher script. Users had to explicitly opt-in
      for NetworkManager to fully manage all routing tables.
      These settings were awkward. Replace them with new settings "ipv4.route-table"
      and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
      development branch by removing recently added API.
      As before, a connection will have no route-table set by default. This
      has the meaning that policy-routing is not enabled and only the main table
      will be fully synced. Once the user sets a table, we recognize that and
      NetworkManager manages all routing tables.
      The new route-table setting has other important uses: analog to
      "ipv4.route-metric", it is the default that applies to all routes.
      Currently it only works for static routes, not DHCP, SLAAC,
      default-route, etc. That will be implemented later.
      For static routes, each route still can explicitly set a table, and
      overwrite the per-connection setting in "ipv4.route-table" and
    • Thomas Haller's avatar
      core: refactor parsing resolve.conf · 8f1ef161
      Thomas Haller authored
      - merge the IPv4 and IPv6 implementations. They are for the most
        part identical. Also, they are independent of NMIP4Config/NMIP6Config.
      - parse the entire file at once. Don't parse it twice, once for the
        name servers and once for the options. This also avoids loading
        /etc/resolv.conf twice, as it would be done before.
  29. 26 Sep, 2017 1 commit