summaryrefslogtreecommitdiff
path: root/src/nm-ip6-config.c
Commit message (Collapse)AuthorAgeFilesLines
* all: drop unnecessary includes of <errno.h> and <string.h>Thomas Haller2019-02-121-1/+0
| | | | | "nm-macros-interal.h" already includes <errno.h> and <string.h>. No need to include it everywhere else too.
* all: don't use "static inline" in source filesThomas Haller2019-02-061-2/+2
| | | | | | | | 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.
* core: allow addresses with zero prefix lengthThomas Haller2018-12-191-1/+3
| | | | | | | | | | | | | 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, really. 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).
* all: don't use static buffer for nm_utils_inet*_ntop()Thomas Haller2018-12-191-9/+10
| | | | | | | | | | 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.
* all: cleanup GChecksum handlingThomas Haller2018-11-131-17/+7
| | | | | | | - 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.
* ip-config: add @intersect_routes argument to intersect functionsBeniamino Galvani2018-09-261-2/+11
| | | | | In some cases we want to intersect two IP configurations without considering routes.
* core: improve nm_ip_config_dump()Beniamino Galvani2018-09-261-47/+0
| | | | | | | | | Previously we had nm_ip{4,6}_config_dump() for debugging purposes, but they were inconveniently printing to stdout and so the output was not ordered in the journal. Implement a unified nm_ip_config_dump() that logs through the usual logging mechanism.
* core: handle route metric when reapplying dynamic IP methodsBeniamino Galvani2018-08-081-0/+31
| | | | | | | | | | For dynamic IP methods (DHCP, IPv4LL, WWAN) the route metric is set at activation/renewal time using the value from static configuration. To support runtime change we need to update the dynamic configuration in place and tell the DHCP client the new value to use for future renewals. https://bugzilla.redhat.com/show_bug.cgi?id=1528071
* core: use nm_gobject_notify_together() in NMIP4Config/NMIP6ConfigThomas Haller2018-08-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | 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.
* all: don't use gchar/gshort/gint/glong but C typesThomas Haller2018-07-111-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 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' \ "${FILES[@]}"
* core: reject invalid domains from ip configurationsBeniamino Galvani2018-05-141-36/+5
| | | | Reject domains containing ".." or starting with "."
* all: remove consecutive empty linesBeniamino Galvani2018-04-301-1/+0
| | | | | | | Normalize coding style by removing consecutive empty lines from C sources and headers. https://github.com/NetworkManager/NetworkManager/pull/108
* device: don't capture resolve.conf for initial device configThomas Haller2018-03-201-20/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* core: add nm_ip6_config_find_first_address() function and refactor lookup of ↵Thomas Haller2018-03-201-5/+29
| | | | | | | | | | | | code 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.
* core/dbus: rework creating numbered D-Bus export path by putting counter ↵Thomas Haller2018-03-131-1/+1
| | | | | | | | | | | | | | | into class 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.
* core/dbus: rework D-Bus implementation to use lower layer GDBusConnection APIThomas Haller2018-03-121-12/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. 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 directly. 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 useful. 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
* core: distinguish between IFA_F_SECONDARY and IFA_F_TEMPORARYThomas Haller2018-02-091-4/+4
| | | | | | | | | | | | | | | | | | 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 8b4f11927 (core: avoid IFA_F_TEMPORARY alias for IFA_F_SECONDARY).
* platform: rework nm_platform_ip6_address_sync() to fix address orderThomas Haller2018-02-091-1/+1
| | | | | | | | | | | | | 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.
* core: avoid IFA_F_TEMPORARY alias for IFA_F_SECONDARYThomas Haller2018-02-071-4/+4
| | | | | IFA_F_SECONDARY and IFA_F_TEMPORARY have the same numerical values, and are synonymous. Consistently use IFA_F_SECONDARY.
* all: get rid of a handful of unused-but-set variablesLubomir Rintel2017-12-181-14/+0
|
* core: don't use variable length arraysThomas Haller2017-12-151-4/+5
| | | | | Let's compile with -Wvla, so that G_STATIC_ASSERT() is really static. But then we cannot use variable length arrays.
* platform/trivial: s/ADDRROUTE/OBJECT/ for the cache lookupLubomir Rintel2017-12-111-7/+7
| | | | | It's going to be useful for other objects that have a type (of course) and an ifindex.
* core: add non-destructive ip config intersect functionBeniamino Galvani2017-12-061-11/+74
| | | | | Add a new function to compute the intersection between 2 IP configurations without modifying them.
* core: add nm_ipX_config_clone()Beniamino Galvani2017-12-061-0/+11
|
* core: don't reset existing routes when merging IP settingBeniamino Galvani2017-11-171-2/+0
| | | | | | | | | | | Don't reset existing routes if ipvx.ignore-auto-routes=yes: callers should already avoid adding them when not needed. Previously we would also reset the manual gateway route just added. Fixes: 5c299454b49b165f645c25fd3e083c0bb747ad91 https://bugzilla.gnome.org/show_bug.cgi?id=790423
* core: merge IPv4 and IPv6 version of _nm_ip_config_merge_route_attributes()Thomas Haller2017-11-131-60/+4
|
* core: use router preference for IPv6 routesThomas Haller2017-10-121-15/+30
| | | | | | | | | | | | | | | | | | | For routes and the default-route from NDisc, set the router preference RTA_PREF. 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. https://bugzilla.redhat.com/show_bug.cgi?id=1445417
* core: fix memory leaks in NMIP{4,6}ConfigBeniamino Galvani2017-10-101-2/+1
| | | | | Fixes: 03e1cc96a5dc3d9a9b86f60810a330332c484a94 Fixes: 9a3117f1d3095e58859efce57ea4fb41d8fb7696
* core: rework tracking of gateway/default-route in ip-configThomas Haller2017-10-101-189/+189
| | | | | | | | | | | | | | | | | | | | | | 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 origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
* core: don't track route metric in ip-configThomas Haller2017-10-091-33/+0
| | | | | | | | | | | | 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.
* core: don't track route MSS in ip-configThomas Haller2017-10-091-32/+0
| | | | | | | | | | | | | | | | | The MSS is only set for VPN connections (by merging it in the respective NMIP4Config/NMIP6Config). 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 nm_vpn_connection_ip6_config_get(). 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.
* core: use ipv6.route-table setting for other IPv6 routesThomas Haller2017-10-091-2/+6
| | | | Including device-routes, default-route, SLAAC.
* all: rework configuring route table support by adding "route-table" settingThomas Haller2017-10-091-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | 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 "ipv6.route-table".
* core: refactor parsing resolve.confThomas Haller2017-10-091-73/+12
| | | | | | | | | - 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.
* libnm,core: add TABLE attribute for routes settingsThomas Haller2017-09-261-4/+15
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1436531
* core: inject route list to delete for nm_platform_ip_route_sync()Thomas Haller2017-09-261-2/+8
| | | | | | | | | | | | | | | | | Whenever we call a platform operation that reads or writes the netlink socket, there is the possibility that the cache gets updated, as we receive netlink events. It is thus racy, if nm_platform_ip_route_sync() *first* adds routes, and then obtains a list of routes to delete. The correct approach is to determine which routes to delete first (and keep it in a list @routes_prune), and pass that list down to nm_platform_ip_route_sync(). Arguably, this doesn't yet solve every race. For example, NMDevice calls update_ext_ip_config() during ip4_config_merge_and_apply(). That is good, as it resyncs with platform. However, before calling nm_ip4_config_commit() it calls other platform operations, like _commit_mtu(). So, the race is still there.
* core: fix handling IPv6 device-route and use correct route metricThomas Haller2017-09-191-0/+92
| | | | | | | | | | | | | | | | Before commit 6698bf58bb53fb07838c52ca67293dd5352ec31c, we would rely on kernel to add the device-route for manual IPv6 routes. We broke that and now kernel would still add the device-route, however nm_platform_ip_route_sync() would delete it immediately after. That is because previously nm_platform_ip_route_sync() would ignore routes with rtm_protocol RTPRO_KERNEL. Now, it will sync and delete those too. Fix that by adding the device-route like we do it for IPv4. This also fixes an actual issue where the automatically added route always had route-metric 256. Instead, we now use the metric from ipv6.route-metric setting. Fixes: 6698bf58bb53fb07838c52ca67293dd5352ec31c
* core: workaround configuring IPv6 routes with "src" (RTA_PREFSRC)Thomas Haller2017-09-151-2/+4
| | | | | | | | | | | | | | | | | | | | | Kernel does not allow to add IPv6 routes with "src", as long as the corresponding address is still tentative (related bug rh#1457196). The workaround for this is cumbersome. First, when we fail to add such a route with "pref_src", we guess that it happend due to this issue. In that case, nm_ip6_config_commit() returns the list of routes that could not be added for the moment (but hopefully can be added later). We track this list in NMDevice, and keep trying to merge the routes back into ip6_config. In order to not try indefinitely, keep track of a timestamp when we tried to add this route for the first time. Another uglyness is that pending tentative routes don't explicitly block activation. In practice they may do, because for these routes we also have an IPv6 address that is still doing DAD, so the IP configuration is still pending due to that. https://bugzilla.redhat.com/show_bug.cgi?id=1452684
* core: track routes with source RTPROT_KERNEL (rtm_protocol) in ↵Thomas Haller2017-09-131-3/+1
| | | | | | | | | | | | | | | | NMIP4Config/NMIP6Config Let's not treat those routes special. I think this was originally done, because we relied on kernel to add the IPv4 device route, so we would ignore RTPROT_KERNEL routes and not delete them. We want to track them for various reasons: - for consistency, there is nothing special except that they might be added by kernel. - we expose the routes of NMIP4Config/NMIP6Config on D-Bus. That should include also routes such as device routes. Note, this commit changes that we now expose device routes on D-Bus too.
* core: adjust route equality for NMIP4Config/NMIP6Config to what kernel doesThomas Haller2017-09-131-2/+3
| | | | | | | | | | | | | | | | | | | For kernel, route ID compare identical according to NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID. Well, mostly. In practice, NM ignores several route properties that kernel considers part of the ID too. This leaves the possibility that kernel allows addition of two routes that compare idential for NetworkManager. Anyway, NMIP4Config/NMIP6Config should use the same equality as platform cache. Otherwise, there is the odd situation that ip-config merges routes that are treated as different by kernel. For IP addresses the ID operator already corresponded to what kernel does. There is no change for addresses. Note that NMSettingIPConfig also uses a different algorithm for comparing routes. But that doesn't really matter here, it it differed before too.
* core: fix invalid assertion in nm_ip6_config_get_num_routes().Thomas Haller2017-09-131-1/+1
| | | | Fixes: cfd1851c0067773211524c2b648330b6ee7a066c
* core: rework handling of default-routes and drop NMDefaultRouteManagerth/platform-route-pt4Thomas Haller2017-09-081-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove NMDefaultRouteManager. Instead, add the default-route to the NMIP4Config/NMIP6Config instance. This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797. We added NMDefaultRouteManager because we used the corresponding to `ip route replace` when configuring routes. That would replace default-routes on other interfaces so we needed a central manager to coordinate routes. Now, we use the corresponding of `ip route append` to configure routes, and each interface can configure routes indepdentently. In NMDevice, when creating the default-route, ignore @auto_method for external devices. We shall not touch these devices. Especially the code in NMPolicy regarding selection of the best-device seems wrong. It probably needs further adjustments in the future. Especially get_best_ip_config() should be replaced, because this distinction VPN vs. devices seems wrong to me. Thereby, remove the @ignore_never_default argument. It was added by commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's needed anymore. This brings another change. Now that we track default-routes in NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular routes. I think that makes sense, but it is a change in behavior, as previously such routes were not exposed there.
* core: support tracking default-route in NMIP4Config/NMIP6ConfigThomas Haller2017-09-081-32/+164
| | | | | | | | | | | | | | | | Default-routes are for the most part like regular routes. Add support to track them like regular routes in NMIP4Config/NMIP6Config. One thing is, sometimes we need to figure out whether an ip-config instance has a default-route. For that, keep track of the best default-route (there might be multiple) and expose it. That is the most complicated part of this patch, because there are so many places where the list of routes gets modified (replace, intersect, subtract, merge, add), and they all need to take care of updating the best default-route. In a next patch, NMDefaultRouteManager will be dropped and default-routes will be tracked by NMIP4Config/NMIP6Config.
* core: return new route from _nm_ip_config_add_obj()Thomas Haller2017-09-081-8/+26
| | | | | Later we will need the exact instance that we just added (or the previously existing one, if the new route is already tracked).
* core/trivial: rename test functions _nmtst_nm_ip*_config_*() to ↵Thomas Haller2017-09-081-4/+4
| | | | _nmtst_ip*_config_*()
* core: ignore routes from non-main table in nm_ip4_config_capture()Thomas Haller2017-09-081-1/+4
| | | | and nm_ip6_config_capture().
* core: don't loop twice over routes in nm_ip4_config_capture()Thomas Haller2017-09-081-9/+4
| | | | and nm_ip6_config_capture().
* core: return new object from _nm_ip_config_add_obj()Thomas Haller2017-09-081-7/+14
| | | | Will be used later.
* core: use _nm_ip_config_add_obj() in NMIP4Config/NMIP6ConfigThomas Haller2017-08-301-6/+7
|
* core/trivial: rename local variableThomas Haller2017-08-301-17/+17
| | | | For consistency with other places.
View Lorry Controller Status