summaryrefslogtreecommitdiff
path: root/src/nm-ip6-config.c
Commit message (Collapse)AuthorAgeFilesLines
* wireguard: don't let explicit gateway override WireGuard's peer routeThomas Haller2020-04-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The profile's "ipv4.gateway" and "ipv6.gateway" has only one real purpose: to define the next hop of a static default route. Usually, when specifying a gateway in this way, the default route from other addressing methods (like DHCPv4 or IPv6 autoconf) gets ignored. If you have a WireGuard peer with "AllowedIPs=0.0.0.0/0" and "wireguard.peer-routes" enabled, NetworkManager would automatically add a route to the peer. Previously, if the user also set a gateway, that route was suppressed. That doesn't feel right. Note that configuring a gateway on a WireGuard profile is likely to be wrong to begin with. At least, unless you take otherwise care to avoid routing loops. If you take care, setting a gateway may work, but it would feel clearer to instead just add an explicit /0 manual route instead. Also, note that usually you don't need a gateway anyway. WireGuard is a Layer 3 (IP) tunnel, where the next hop is alway just the other side of the tunnel. The next hop has little effect on the routes that you configure on a WireGuard interface. What however matters is whether a default route is present or not. Also, an explicit gateway probably works badly with "ipv[46].ip4-auto-default-route", because in that case the automatism should add a /0 peer-route route in a separate routing table. The explicit gateway interferes with that too. Nonetheless, without this patch it's not obvious why the /0 peer route gets suppressed when a gateway is set. Don't allow for that, and always add the peer-route. Probably the profile's gateway setting is still wrong and causes the profile not to work. But at least, you see all routes configured, and it's clearer where the (wrong) default route to the gateway comes from. (cherry picked from commit 115291a46f52ee4adfe85264b9566d216bcb25e8)
* core: add NMIPConfigFlags for NMIPConfig flagsThomas Haller2020-04-221-0/+23
| | | | | | | | | This will be useful to set future options on the NMIPConfig. Yes, the code duplication of NMIP[46]Config is horrible. Needs to be unified in the future. (cherry picked from commit e8b86f8445cd621c21ccf87833f4c49c74c325d9)
* all: use _nm_utils_inet4_ntop() instead of nm_utils_inet4_ntop()Thomas Haller2020-01-281-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | and _nm_utils_inet6_ntop() instead of nm_utils_inet6_ntop(). nm_utils_inet4_ntop()/nm_utils_inet6_ntop() are public API of libnm. For one, that means they are only available in code that links with libnm/libnm-core. But such basic helpers should be available everywhere. Also, they accept NULL as destination buffers. We keep that behavior for potential libnm users, but internally we never want to use the static buffers. This patch needs to take care that there are no callers of _nm_utils_inet[46]_ntop() that pass NULL buffers. Also, _nm_utils_inet[46]_ntop() are inline functions and the compiler can get rid of them. We should consistently use the same variant of the helper. The only downside is that the "good" name is already taken. The leading underscore is rather ugly and inconsistent. Also, with our internal variants we can use "static array indices in function parameter declarations" next. Thereby the compiler helps to ensure that the provided buffers are of the right size.
* core: don't add prefix route for external addressesBeniamino Galvani2019-10-231-0/+2
| | | | | | | | | | | | | | | If the user adds an address manually, kernel automatically adds a prefix route for it unless the address has the NOPREFIXROUTE flag. When ip_config_merge_and_apply() gets called, NM also adds its prefix route and so we end up with two routes that differ only for the metric. This is a problem because the route added by NM is not removed if the user removes the previously added address. Also, it seems confusing to have multiple instances of the same routes. This commit skips the addition of a prefix route for addresses added manually outside of NetworkManager.
* core: track whether IP addresses are externalBeniamino Galvani2019-10-231-2/+11
| | | | | | Track whether IP addresses were added by NM or externally. In this way it becomes possible in a later commit to add prefix route only for addresses added by NM.
* all: manually drop code comments with file descriptionThomas Haller2019-10-011-2/+1
|
* all: SPDX header conversionLubomir Rintel2019-09-101-14/+1
| | | | | $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
* all: allow configuring default-routes as manual, static routesThomas Haller2019-08-131-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up until now, a default-route (with prefix length zero) could not be configured directly. The user could only set ipv4.gateway, ipv4.never-default, ipv4.route-metric and ipv4.route-table to influence the setting of the default-route (respectively for IPv6). That is a problematic limitation. For one, whether a route has prefix length zero or non-zero does not make a fundamental difference. Also, it makes it impossible to configure all the routing attributes that one can configure otherwise for static routes. For example, the default-route could not be configured as "onlink", could not have a special MTU, nor could it be placed in a dedicated routing table. Fix that by lifting the restriction. Note that "ipv4.never-default" does not apply to /0 manual routes. Likewise, the previous manners of configuring default-routes ("ipv4.gateway") don't conflict with manual default-routes. Server-side this all the pieces are already in place to accept a default-route as static routes. This was done by earlier commits like 5c299454b49b ('core: rework tracking of gateway/default-route in ip-config'). A long time ago, NMIPRoute would assert that the prefix length is positive. That was relaxed by commit a2e93f2de4ac ('libnm: allow zero prefix length for NMIPRoute'), already before 1.0.0. Using libnm from before 1.0.0 would result in assertion failures. Note that the default-route-metric-penalty based on connectivity checking applies to all /0 routes, even these static routes. Be they added due to DHCP, "ipv4.gateway", "ipv4.routes" or "wireguard.peer-routes". I wonder whether doing that unconditionally is desirable, and maybe there should be a way to opt-out/opt-in for the entire profile or even per-routes. https://bugzilla.redhat.com/show_bug.cgi?id=1714438
* core: assert for valid arguments in _addresses_sort_cmp()Thomas Haller2019-08-021-0/+3
| | | | | | | Coverity thinks that the arguments could be %NULL. Add an assertion, hoping to silence coverity. (cherry picked from commit 1b30797bc16c7e0cc2e6c5686e52aa12ef5a5425)
* core: fix mangling static IPv6 routes in nm_ip6_config_merge_setting()Thomas Haller2019-07-091-1/+1
| | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1727193 Fixes: 433d2f8659e3 ('core: merge IPv4 and IPv6 version of _nm_ip_config_merge_route_attributes()')
* core: support creating ip6-config setting with disabled methodBeniamino Galvani2019-06-111-2/+28
| | | | | Create the new setting with method=disabled if IPv6 is disabled in the sysctl.
* all: drop emacs file variables from source filesThomas Haller2019-06-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | We no longer add these. If you use Emacs, configure it yourself. Also, due to our "smart-tab" usage the editor anyway does a subpar job handling our tabs. However, on the upside every user can choose whatever tab-width he/she prefers. If "smart-tabs" are used properly (like we do), every tab-width will work. No manual changes, just ran commands: F=($(git grep -l -e '-\*-')) sed '1 { /\/\* *-\*- *[mM]ode.*\*\/$/d }' -i "${F[@]}" sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}" Check remaining lines with: git grep -e '-\*-' The ultimate purpose of this is to cleanup our files and eventually use SPDX license identifiers. For that, first get rid of the boilerplate lines.
* shared: move most of "shared/nm-utils" to "shared/nm-glib-aux"Thomas Haller2019-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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". Reasons: - 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 80db06f768e47541eae7d66ef48fbe47bf1a69ce)
* core: allow ignoring addresses when intersecting ip configsBeniamino Galvani2019-03-111-21/+42
| | | | | | | | Add a new argument to nm_ip_config_* helpers to also ignore addresses similarly to what we already do for routes. This will be used in the next commit; no change in behavior here. (cherry picked from commit 39b72572087a1243725a48d47d53131591417aec)
* nm: Fix syntax on introspection annotationsMarco Trevisan (Treviño)2019-03-071-1/+1
| | | | | | | | Various annotations were added using multiple colons, while only one has to be added or g-ir-introspect will consider them part of the description https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/94 (cherry picked from commit 73005fcf5b957a4cf7f8244da85ade0214db7606)
* 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
View Lorry Controller Status