summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* core: rework handling of default-routes and drop NMDefaultRouteManagerth/platform-route-pt4Thomas Haller2017-09-0812-1977/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-087-69/+439
| | | | | | | | | | | | | | | | 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-0811-54/+95
| | | | | 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-088-50/+50
| | | | _nmtst_ip*_config_*()
* platform: delete routes after adding in nm_platform_ip_route_sync()Thomas Haller2017-09-081-60/+46
| | | | | | | | | | | | | | | | | Previously, we would first delete routes that are not to be added, before adding the new ones. This has the advantage, that even if delete removes the wrong route, add would restore the expected state. This tries to workaround the fact that RTM_DELROUTE allows for wild-card fields, and might delete the wrong route. However, for example when bumping the route metric after connectivty check (removing the default-route with metric 20100 and adding the one with metric 100), there is a short moment when there is no default-route. To avoid that, don't do delete-then-add, but add-then-delete.
* core: ignore routes from non-main table in nm_ip4_config_capture()Thomas Haller2017-09-082-2/+8
| | | | and nm_ip6_config_capture().
* core: don't loop twice over routes in nm_ip4_config_capture()Thomas Haller2017-09-082-17/+8
| | | | and nm_ip6_config_capture().
* core: add nm_utils_connection_has_default_route()Thomas Haller2017-09-085-67/+56
| | | | Taken from "src/nm-default-route-manager.c".
* device: expose nm_device_get_ip_route_metric() functionThomas Haller2017-09-082-22/+21
| | | | Will be used later.
* core: nm_utils_ip_route_metric_normalize() utilThomas Haller2017-09-082-4/+7
| | | | | Functions that take and addr_family argument are just nicer to use at places where we treat IPv4 and IPv6 generically.
* platform: add nm_clear_nmp_object() utilThomas Haller2017-09-081-0/+15
|
* core: return new object from _nm_ip_config_add_obj()Thomas Haller2017-09-083-15/+33
| | | | Will be used later.
* core: use _nm_ip_config_add_obj() in nm_ip4_config_replace() for routesThomas Haller2017-09-081-6/+7
| | | | | | | | Avoid calling nm_dedup_multi_index_add() directly, like we do for all other places. Instead, call the wrapper _nm_ip_config_add_obj() which does some pre-precessing. In practice, the result is exactly the same (at the moment). But there should by only one way to add the route.
* core/tests: add test for nm_ip6_config_replace()Thomas Haller2017-09-081-0/+67
|
* platform/trivial: add code commentsThomas Haller2017-09-082-1/+8
|
* policy: take reference to best_device/activating_deviceThomas Haller2017-09-081-21/+17
| | | | | | | | Don't rely on manager keeping them alive long enough. E.g. get-best-device() is used when resetting the best device, however, it accesses the current device (hence, it relies on manager removing the device from the list, but keeping it alive long enough).
* policy: cleanup setting default_device/activating_deviceThomas Haller2017-09-081-32/+32
| | | | | - _LOGt() whenever the properties change. - some minor refactoring
* policy: don't re-lookup the best device during update_system_hostname()Thomas Haller2017-09-081-18/+12
| | | | | | | | | We already track the best device as priv->default_device4 / priv->default_device6. Don't try to look it up again. If the cached values from @priv are invalid/outdated, that should be fixed instead. This was already introduced by commit 773c006a4c9d3162e9b371762dc59fd5948e4b43. But I don't think it should be done.
* policy: always check for hostname from DHCPv6 in update_system_hostname()Thomas Haller2017-09-081-1/+3
| | | | | There is no reason for if-else-if. If DHCPv4 doesn't provide a hostname (but we are doing DHCP), just check for DHCPv6.
* policy: refactor setting hostname from DHCP in update_system_hostname()Thomas Haller2017-09-081-18/+14
|
* dns: use 127.0.0.53 address in /etc/resolv.conf with systemd-resolvedThomas Haller2017-09-071-2/+9
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=787378
* ifnet: ensure an error is always returned when add failsBeniamino Galvani2017-09-071-2/+7
| | | | | There are many places where the function can fail without returning an error, leading to a crash. Fix this.
* vpn: only rely on `ip route get` to resolve route to external VPN gatewayThomas Haller2017-09-071-43/+23
| | | | | | | | | | Until recently, we would only consier the IP config of the parent device to determine the route to the external VPN gateway. We changed that, to additionally improve the guess by letting kernel resolve the route. Now, drop checking the parent's config entirely. The only thing that matters is the here and now runtime configuraion on the parent device. And for that we ask kernel to resolve the route.
* vpn: improve resolving route to external VPN gateway by restricting oifThomas Haller2017-09-071-8/+34
| | | | | | | | | | | | | Previously, we would try to resolve the route in general (unrestricted to a certain ifindex), and reject it the result wasn't on the parent device. Now, use the oif argument, and resolve the route only on the parent device. The problem is that kernel would pretend that the destination is onlink, if there is no route to it. Hence, hack around that by only accepting an onlink route, if the VPN gateway itself is site-local. Yes, there are scenarios where this will still lead to a wrong guess. See related bug rh#1489343 for kernel.
* platform: add oif argument to nm_platform_ip_route_get()Thomas Haller2017-09-075-2/+20
| | | | Analog to `ip route get $DST oif $IFACE`.
* vpn: apply parent config in nm_vpn_connection_apply_config() firstThomas Haller2017-09-071-2/+2
| | | | | | | | | In practice, it shouldn't matter much, because NM may frequently reapply the IP config. Hence, it anyway must cope with the fact that IP config from a previous iteration is already applied on the VPN device, before applying it to the parent device. Anyway, it makes a bit more sense to apply it first the the parent device.
* vpn: fix ifindex of parent IP config in apply_parent_device_config()Thomas Haller2017-09-072-25/+26
| | | | | | | | | | | | | | | When creating the NMIP4Config/NMIP6Config instance, we must always use the right ifindex. That is the ifindex, on which we want to apply the config. It also means, that for device-based VPNs (those with priv->ip_ifindex set, like OpenVPN), the parent's config must have the ip-ifindex of the parent device. Not of the VPN's device. One effect of this bug is that in add_ip4_vpn_gateway_route() we resolve the route to the external gateway and only accept it if it's on the parent device. But since the ifindex of the config was wrong, we would accept route on the wrong interface. https://bugzilla.gnome.org/show_bug.cgi?id=787370
* platform: refetch IPv6 address if still present after deletionBeniamino Galvani2017-09-071-2/+13
| | | | | | | | | | | | | | | | | | | | After commit 5a69b27a64a0 ("platform: let platform operations only consider kernel response") the platform only relies on kernel messages and doesn't check if a deleted object is gone from the cache. For IPv6 addresses it can happen that the RTM_DELADDR comes after the ack, and this causes random failures in test /address/ipv6/general-2: [10.8009] platform: address: deleting IPv6 address 2001:db8:a:b:1:2:3:4/64, ifindex 12 dev nm-test-device [10.8009] platform-linux: delayed-action: schedule wait-for-nl-response (seq 55, timeout in 0.199999680, response-type 0) [10.8009] platform-linux: delayed-action: handle wait-for-nl-response (any) [10.8009] platform-linux: netlink: recvmsg: new message (2), flags 0x0100, seq 55 [10.8009] platform-linux: delayed-action: complete wait-for-nl-response (seq 55, timeout in 0.199980533, response-type 0, success) [10.8009] platform-linux: do-delete-ip6-address[12: 2001:db8:a:b:1:2:3:4]: success ** NetworkManager:ERROR:src/platform/tests/test-common.c:1127:_ip_address_del: assertion failed: (external_command) Use the same workaround in place for the addition of IPv6 addresses, i.e. refetch the object if the address is still present after the ack.
* platform: fix coding style (missing braces)Beniamino Galvani2017-09-071-1/+2
|
* all: use _nm_utils_ip4_*() utils functionsThomas Haller2017-09-0512-21/+21
|
* ifcfg-rh/tests: test backward compatibility reading routes with "via (null)"Thomas Haller2017-09-052-1/+9
| | | | | | | | | Due to a bug, NetworkManager used to write device routes with "via (null)". That was fixed in commit af8aac9b544cb64df3b77a413dfded23e976d1b0 and bug rh#1452648. Add a unit test to ensure we keep accepting such (invalid) routes that NetworkManager once wrote.
* core: don't require manageable device in unmanaged_to_disconnected()Thomas Haller2017-09-041-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | It seems the assert there is too strict. I don't really understand why it fails, but I also don't see why the assert is supposed to hold. Just return in case the device is unmanagable at this point. The activation shall fail later. Traceback from a test build of commit a7aca2ab08abcc5bee02f0f6f9ffe899919f4234: #0 0x00007fdb28ffb643 in g_logv (log_domain=0x7fdb2b584cc9 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff10630200) at gmessages.c:1086 #1 0x00007fdb28ffb7bf in g_log (log_domain=log_domain@entry=0x7fdb2b584cc9 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7fdb29069190 "%s: assertion '%s' failed") at gmessages.c:1119 #2 0x00007fdb28ffb7f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7fdb2b584cc9 "NetworkManager", pretty_function=pretty_function@entry=0x7fdb2b54fee0 <__func__.38922> "unmanaged_to_disconnected", expression=expression@entry=0x7fdb2b54d450 "nm_device_get_managed (device, FALSE)") at gmessages.c:1128 #3 0x00007fdb2b36e05b in unmanaged_to_disconnected (device=device@entry=0x7fdb2d2384f0 [NMDeviceVlan]) at src/nm-manager.c:3201 #4 0x00007fdb2b37eb3a in _internal_activate_generic (error=0x7fff106303d0, active=0x7fdb2d1d4550 [NMActRequest], self=0x0) at src/nm-manager.c:3430 #5 0x00007fdb2b37eb3a in _internal_activate_generic (self=self@entry=0x7fdb2d02b090 [NMManager], active=active@entry=0x7fdb2d1d4550 [NMActRequest], error=error@entry=0x7fff10630450) at src/nm-manager.c:3458 #6 0x00007fdb2b37fe90 in _activation_auth_done (active=0x7fdb2d1d4550 [NMActRequest], success=1, error_desc=0x0, user_data1=0x7fdb2d02b090, user_data2=0x7fdb0800bec0) at src/nm-manager.c:3866 #7 0x00007fdb2b4cc9d7 in auth_done (chain=0x7fdb2d17de30, error=0x0, unused=<optimized out>, user_data=<optimized out>) at src/nm-active-connection.c:929 #8 0x00007fdb2b4d6884 in auth_chain_finish (user_data=0x7fdb2d17de30) at src/nm-auth-utils.c:92 #9 0x00007fdb28ff4d7a in g_main_context_dispatch (context=0x7fdb2cff2e00) at gmain.c:3152 #10 0x00007fdb28ff4d7a in g_main_context_dispatch (context=context@entry=0x7fdb2cff2e00) at gmain.c:3767 #11 0x00007fdb28ff50b8 in g_main_context_iterate (context=0x7fdb2cff2e00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838 #12 0x00007fdb28ff538a in g_main_loop_run (loop=0x7fdb2cff2ec0) at gmain.c:4032 #13 0x00007fdb2b349ed7 in main (argc=1, argv=0x7fff106307a8) at src/main.c:438 https://bugzilla.redhat.com/show_bug.cgi?id=1478911
* device: extend wait time for carrier after MTU changeThomas Haller2017-09-041-3/+24
| | | | | | | Especially during an MTU change, the driver might need longer to bring back carrier. In this case, extend the wait time. https://bugzilla.redhat.com/show_bug.cgi?id=1487702
* systemd: merge branch systemd into masterThomas Haller2017-09-046-11/+82
|\ | | | | | | | | Seems there is nothing relevant really. Just do our regular resync to keep the diff to upstream systemd small.
| * systemd: update code from upstream (2017-09-04)Thomas Haller2017-09-046-11/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a direct dump from systemd git on 2017-09-04, git commit c792ec2e3512a672881fc847ff432e26b641c9c9. ====== SYSTEMD_DIR=../systemd COMMIT=c792ec2e3512a672881fc847ff432e26b641c9c9 ( cd "$SYSTEMD_DIR" git checkout "$COMMIT" git reset --hard git clean -fdx ) git ls-files :/src/systemd/src/ | xargs -d '\n' rm -f nm_copy_sd() { mkdir -p "./src/systemd/$(dirname "$1")" cp "$SYSTEMD_DIR/$1" "./src/systemd/$1" } nm_copy_sd "src/basic/alloc-util.c" nm_copy_sd "src/basic/alloc-util.h" nm_copy_sd "src/basic/async.h" nm_copy_sd "src/basic/escape.c" nm_copy_sd "src/basic/escape.h" nm_copy_sd "src/basic/ether-addr-util.c" nm_copy_sd "src/basic/ether-addr-util.h" nm_copy_sd "src/basic/extract-word.c" nm_copy_sd "src/basic/extract-word.h" nm_copy_sd "src/basic/fileio.c" nm_copy_sd "src/basic/fileio.h" nm_copy_sd "src/basic/fd-util.c" nm_copy_sd "src/basic/fd-util.h" nm_copy_sd "src/basic/fs-util.c" nm_copy_sd "src/basic/fs-util.h" nm_copy_sd "src/basic/hash-funcs.c" nm_copy_sd "src/basic/hash-funcs.h" nm_copy_sd "src/basic/hashmap.c" nm_copy_sd "src/basic/hashmap.h" nm_copy_sd "src/basic/hexdecoct.c" nm_copy_sd "src/basic/hexdecoct.h" nm_copy_sd "src/basic/hostname-util.c" nm_copy_sd "src/basic/hostname-util.h" nm_copy_sd "src/basic/in-addr-util.c" nm_copy_sd "src/basic/in-addr-util.h" nm_copy_sd "src/basic/io-util.c" nm_copy_sd "src/basic/io-util.h" nm_copy_sd "src/basic/list.h" nm_copy_sd "src/basic/log.h" nm_copy_sd "src/basic/macro.h" nm_copy_sd "src/basic/mempool.h" nm_copy_sd "src/basic/mempool.c" nm_copy_sd "src/basic/parse-util.c" nm_copy_sd "src/basic/parse-util.h" nm_copy_sd "src/basic/path-util.c" nm_copy_sd "src/basic/path-util.h" nm_copy_sd "src/basic/prioq.h" nm_copy_sd "src/basic/prioq.c" nm_copy_sd "src/basic/process-util.h" nm_copy_sd "src/basic/process-util.c" nm_copy_sd "src/basic/random-util.c" nm_copy_sd "src/basic/random-util.h" nm_copy_sd "src/basic/refcnt.h" nm_copy_sd "src/basic/set.h" nm_copy_sd "src/basic/signal-util.h" nm_copy_sd "src/basic/siphash24.c" nm_copy_sd "src/basic/siphash24.h" nm_copy_sd "src/basic/socket-util.c" nm_copy_sd "src/basic/socket-util.h" nm_copy_sd "src/basic/sparse-endian.h" nm_copy_sd "src/basic/stdio-util.h" nm_copy_sd "src/basic/string-table.c" nm_copy_sd "src/basic/string-table.h" nm_copy_sd "src/basic/string-util.c" nm_copy_sd "src/basic/string-util.h" nm_copy_sd "src/basic/strv.c" nm_copy_sd "src/basic/strv.h" nm_copy_sd "src/basic/time-util.c" nm_copy_sd "src/basic/time-util.h" nm_copy_sd "src/basic/umask-util.h" nm_copy_sd "src/basic/unaligned.h" nm_copy_sd "src/basic/utf8.c" nm_copy_sd "src/basic/utf8.h" nm_copy_sd "src/basic/util.c" nm_copy_sd "src/basic/util.h" nm_copy_sd "src/libsystemd-network/arp-util.c" nm_copy_sd "src/libsystemd-network/arp-util.h" nm_copy_sd "src/libsystemd-network/dhcp6-internal.h" nm_copy_sd "src/libsystemd-network/dhcp6-lease-internal.h" nm_copy_sd "src/libsystemd-network/dhcp6-network.c" nm_copy_sd "src/libsystemd-network/dhcp6-option.c" nm_copy_sd "src/libsystemd-network/dhcp6-protocol.h" nm_copy_sd "src/libsystemd-network/dhcp-identifier.c" nm_copy_sd "src/libsystemd-network/dhcp-identifier.h" nm_copy_sd "src/libsystemd-network/dhcp-internal.h" nm_copy_sd "src/libsystemd-network/dhcp-lease-internal.h" nm_copy_sd "src/libsystemd-network/dhcp-network.c" nm_copy_sd "src/libsystemd-network/dhcp-option.c" nm_copy_sd "src/libsystemd-network/dhcp-packet.c" nm_copy_sd "src/libsystemd-network/dhcp-protocol.h" nm_copy_sd "src/libsystemd-network/lldp-internal.h" nm_copy_sd "src/libsystemd-network/lldp-neighbor.c" nm_copy_sd "src/libsystemd-network/lldp-neighbor.h" nm_copy_sd "src/libsystemd-network/lldp-network.c" nm_copy_sd "src/libsystemd-network/lldp-network.h" nm_copy_sd "src/libsystemd-network/network-internal.c" nm_copy_sd "src/libsystemd-network/network-internal.h" nm_copy_sd "src/libsystemd-network/sd-dhcp6-client.c" nm_copy_sd "src/libsystemd-network/sd-dhcp6-lease.c" nm_copy_sd "src/libsystemd-network/sd-dhcp-client.c" nm_copy_sd "src/libsystemd-network/sd-dhcp-lease.c" nm_copy_sd "src/libsystemd-network/sd-ipv4ll.c" nm_copy_sd "src/libsystemd-network/sd-ipv4acd.c" nm_copy_sd "src/libsystemd-network/sd-lldp.c" nm_copy_sd "src/libsystemd/sd-event/sd-event.c" nm_copy_sd "src/libsystemd/sd-id128/id128-util.c" nm_copy_sd "src/libsystemd/sd-id128/id128-util.h" nm_copy_sd "src/libsystemd/sd-id128/sd-id128.c" nm_copy_sd "src/shared/dns-domain.c" nm_copy_sd "src/shared/dns-domain.h" nm_copy_sd "src/systemd/_sd-common.h" nm_copy_sd "src/systemd/sd-dhcp6-client.h" nm_copy_sd "src/systemd/sd-dhcp6-lease.h" nm_copy_sd "src/systemd/sd-dhcp-client.h" nm_copy_sd "src/systemd/sd-dhcp-lease.h" nm_copy_sd "src/systemd/sd-event.h" nm_copy_sd "src/systemd/sd-ndisc.h" nm_copy_sd "src/systemd/sd-id128.h" nm_copy_sd "src/systemd/sd-ipv4acd.h" nm_copy_sd "src/systemd/sd-ipv4ll.h" nm_copy_sd "src/systemd/sd-lldp.h"
* | platform: fix deleting routes in nm_platform_ip_route_sync()Thomas Haller2017-09-021-3/+3
| | | | | | | | | | | | | | The condition was wrong resulting in sync() not deleting route when it should. Fixes: f0de7d347f3663c6706b05d462adb2f144f78ab3
* | device: don't release external slaves on state changeBeniamino Galvani2017-09-021-1/+5
| | | | | | | | | | | | | | | | If the slave is 'external' we should never touch it, in particular we should not release the link from its master; we only have to remove it from master's list. https://bugzilla.redhat.com/show_bug.cgi?id=1442361
* | device: don't promote slave devices to managedBeniamino Galvani2017-09-021-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, if a master device had internal state 'managed', we would promote the slave to 'managed' as well. However, - if the slave is 'external', it should stay as is because we don't want to start managing it - if the slave is 'assumed', it will become managed when the activation succeeds, so it's not necessary to do it here Fixes: 850c977953e4de3c8bbee64a3d2e8726c971761c
* | core: ignore host-routes routes when matching generated connectionThomas Haller2017-09-011-13/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we generate the connection in nm_device_generate_connection(), we add all routes that have rt_source (roundtrip(NM_IP_CONFIG_SOURCE_USER)). Especially since commit e470e1392242a088573c4fc317b7b5ffaca4df19, this includes automatically added host-routes to the gateway, added by ip4_config_merge_and_apply(). Later, during nm_utils_match_connection() this route most not prevent matching. Either nm_device_generate_connection() should not add it, or nm_utils_match_connection() should ignore it. I think adjusting the matching is better, because ip-configs are used for several things, including exposing routes on D-Bus. We don't want to hide this route on D-Bus. Fixes: e470e1392242a088573c4fc317b7b5ffaca4df19 https://bugzilla.redhat.com/show_bug.cgi?id=1487384
* | team: wait that existing instance is killed before starting teamd againBeniamino Galvani2017-09-011-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | teamd uses a PID file to guarantee a single instance is running for each device. If we spawn a new teamd process without waiting the termination of the existing one, the new process can fail: <debug> [1486191713.2530] kill child process 'teamd' (2676): wait for process to terminate after sending SIGTERM (15) (send SIGKILL in 2000 milliseconds)... ... <debug> [1486191713.2539] device[0x7f737f5d7c40] (team1): running: /usr/bin/teamd -o -n -U -D -N -t team1 -c {"runner": {"name": "activebackup"}} -gg Using team device "team1". Using PID file "/var/run/teamd/team1.pid" This program is not intended to be run as root. Daemon already running on PID 2676. Failed: File exists To avoid this, keep track that a kill is in progress and postpone the start of teamd. https://bugzilla.redhat.com/show_bug.cgi?id=1415641
* | platform: ignore RTM_*LINK messages for unknown ifi_family (AF_BRIDGE)Thomas Haller2017-08-311-16/+3
| | | | | | | | | | | | | | | | | | | | | | When unenslaving an interface from a bridge, kernel sends a RTM_DELLINK message with ifi_family AF_BRIDGE. We only care about regular RTM_DELLINK/RTM_NEWLINK messages, ignore all but ifi_family AF_UNSPEC. There is also test_nl_bugs_spuroius_dellink(), added in commit 8a87a918130e959f78b5f00db14591b604a07505 for related bug rh#1302037. The workaround was masking a bug in NetworkManager (to not ignore AF_BRIDGE messages) and can now be removed as well.
* | settings: ensure the keyfile storage directory actually existsIkey Doherty2017-08-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | When first trying to write out the connections we need to ensure that the keyfile directory exists, as the /etc/ tree may be either stateless or reset initially. Creating the directory on demand ensures that we have a chance for our writes to actually work. [lkundrak@v3.sk: dropped a comment for what seems obvious, minor style fixes]
* | core: fix clearing dirty flag in _nm_ip_config_add_obj()Thomas Haller2017-08-311-2/+6
| | | | | | | | | | | | | | | | | | We rely on clearing the dirty flag. For example in nm_ip4_config_replace(), we first mark all entries dirty, then force-append the ones we keep, and finally remove the ones that are still dirty. Since _nm_ip_config_add_obj() short-cuts nm_dedup_multi_index_add_full(), it must clear the dirty flag on its own.
* | core: workaround compiler waring in for-each macros for ↵Thomas Haller2017-08-312-12/+12
| | | | | | | | | | | | | | | | NMIP4Config/NMIP6Config (again) Compiler wouldn't recognize that the @route/@address argument is always initialized. The right workaround seems to let the next() functions always set the value.
* | core: avoid compiler warning in nm_ip_config_iter_ip4_address_for_each() macroThomas Haller2017-08-302-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | In file included from src/nm-ip6-config.c:24:0: src/nm-ip6-config.c: In function ‘nm_ip6_config_create_setting’: src/nm-ip6-config.c:734:62: error: the address of ‘address’ will always evaluate as ‘true’ [-Werror=address] nm_ip_config_iter_ip6_address_for_each (&ipconf_iter, self, &address) { ^ src/nm-ip6-config.h:60:17: note: in definition of macro ‘nm_ip_config_iter_ip6_address_for_each’ for (({ if (address) { *(((const NMPlatformIP6Address **) address)) = NULL; } }), nm_ip_config_iter_ip6_address_init ((iter), (self)); \ ^ Fixes: 6e9aa9402a67bab563320fb0b37df242df15214c
* | core: use _nm_ip_config_add_obj() in NMIP4Config/NMIP6ConfigThomas Haller2017-08-302-19/+21
| |
* | core: allow NULL argument to nm-ip-config's for-each macrosThomas Haller2017-08-302-16/+8
| | | | | | | | | | Allow omitting the platform output argument. One can use the iterator to access the current entry.
* | core: fix emitting changed notification during nm_ip4_config_intersect()Thomas Haller2017-08-301-0/+9
| |
* | core/trivial: rename local variableThomas Haller2017-08-302-33/+33
| | | | | | | | For consistency with other places.
* | default-route: skip addition when the route already existsBeniamino Galvani2017-08-291-10/+60
| | | | | | | | | | | | | | Re-adding the default route has side-effects, as it also prunes the cloned routes from the kernel FIB. https://bugzilla.redhat.com/show_bug.cgi?id=1470930
View Lorry Controller Status