summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* core: don't suppress host route to gateway in ip-config caputureth/platform-route-pt3Thomas Haller2017-08-242-19/+10
| | | | | | | | | | Why would we do this? The route is there, so, add it. This revises commit 4fba2260f3e14a13f37499bd46ffcb220fdc5a4c which added this check for matching generated connections. I don't think this is still necessary, and if it is, then the matching should be relaxed instead. It's bad to hide routes from NMIP4Config/NMIP6Config, because those routes are also exported via D-Bus.
* platform: add support for routing tables to platform cacheThomas Haller2017-08-248-15/+74
| | | | | The upper layers still ignore all routes outside the main table. For now, just add support to NMPlatform.
* platform: report error when configuring manual routeThomas Haller2017-08-241-6/+59
| | | | | | | | | | | Rework to use nm_platform_ip_route_sync() broke to fail activation when we were unable to configure a route. Fix it. As before, we only do this for routes that are configured manually by the user. Invalid routes from DHCP do not break activation. Also, improve logging to give a hint what's wrong.
* platform: add option to suppress error message from nm_platform_ip_route_add()Thomas Haller2017-08-244-9/+29
| | | | | | When an error happens, we want to print a better message. Avoid duplicate error messages by adding a flag to suppress logging in the lower layer.
* platform: pass string buffer to nm_platform_error_to_string() and print ↵Thomas Haller2017-08-2414-31/+62
| | | | | | | | | | numeric errno Change the output of nm_platform_error_to_string() to print the numeric value. Also, accept a string buffer instead of using an alloca() allocated buffer. There is still a macro to provide the previous functionality, but it was ill-suited to call from inside a loop.
* platform: assert for namespace in nm_platform_cache_update_emit_signal()Thomas Haller2017-08-241-0/+4
|
* platform: let platform operations only consider kernel responseThomas Haller2017-08-241-38/+11
| | | | | | | Also downgrade <error> logging messages to <warn>. An external condition should never be able to trigger an <error>, and clearly there is always a external race that can cause a netlink command to fail.
* platform: return failure reason from route-add and return only netlink responseThomas Haller2017-08-247-51/+60
| | | | | | | | | | | | | | | | | | | | | | | Let nm_platform_ip_route_add() and friends return an NMPlatformError failure reason. Also, do_add_addrroute() did not return the response from kernel. Instead, it determined success/failure based on the presence of the object in the cache. That is racy and does not allow to give a failure reason from kernel. Instead, determine success solely based on the netlink reply from kernel. The received errno shall be authorative, there is no need to second guess the response. There is a problem that netlink is not a reliable protocol. In case of receive buffer overflow, the response is lost and we don't know whether the command succeeded (it likely did). It's unclear how to fix that, but for now just return "unspecified" error. We probably avoid that already by having a huge buffer size. Also, downgrade the error message to <warn> level. <error> is really for bugs only.
* vpn: resolve route to external VPN gateway from kernelThomas Haller2017-08-241-43/+86
| | | | | | | | | | | | | | | | | | When activating a route, we commonly need to add a route to the external VPN gateway, so that the (encrypted) data is not sent over the VPN itself. Currently, our VPN connections are rather strongly tied to their parent device. Maybe the shouldn't be, as VPN may happily support changing the route from one device/IP address to another. Anyway, our previous way to determine the gateway for the route was not great. Instead, ask kernel how to reach the gateway via (something like) `ip route get`. If kernel would route the packets to the gateway via our parent device, we take that gateway. If not, we keep our previous heuristic (which is probably wrong in this case).
* platform: add nm_platform_ip_route_get() for route-lookupThomas Haller2017-08-244-34/+361
| | | | | | | | | | | | Inspired from iproute2. As such, don't use libnl3's "struct nl_msg", but add _nl_addattr_l() and use a stack-allocated "struct nlmsghdr". With this, we are closer to the raw netlink API. It really is simple enough. The complicated part of the patch is that we re-use the existing netlink socket for events. Hence, we must process the socket via our common event_handler_recvmsgs(). That also means, that we get the netlink response a few layers down the stack and have to return the result via DelayedActionWaitForNlResponseData.
* platform: use IFA_F_NOPREFIXROUTE flag for IPv4 addressesThomas Haller2017-08-241-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | For IPv6 addresses we use IFA_F_NOPREFIXROUTE for a long time. If we detect that kernel does not support the flag (for IPv6), we add addresses as /128 to prevent kernel from adding an onlink route. We add IPv6 device routes explicitly, whenever needed according to the onlink RA flag. For IPv4, we also don't want the route added by kernel. The reason is that is has an undesired metric of zero. However, usually we want the route to have a different metric. The complicated part is that kernel does not add the route immediately but sometimes later. For that we have nm_platform_ip4_dev_route_blacklist_set() (previously that was nm_route_manager_ip4_route_register_device_route_purge_list()). It watches the interface and when a registered device route shows up, it deletes it. The better solution is to use the IFA_F_NOPREFIXROUTE flag to prevent the creation of the route in the first place. It was added for IPv4 to kernel in commit 7b1311807f3d3eb8bef3ccc53127838b3bea3771, October 2015. Contrary to IPv6, we cannot (easily) detect whether kernel supports IFA_F_NOPREFIXROUTE for IPv4 routes. Hence keep nm_platform_ip4_dev_route_blacklist_set() for older kernels.
* core: cleanup setting ifa_flags in ndisc_config_changed()Thomas Haller2017-08-242-42/+37
| | | | | | Some refactoring and one change: If we don't have system-support, don't set IFA_F_MANAGETEMPADDR.
* core: move setting NDisc addresses/routes to NMIP6ConfigThomas Haller2017-08-245-85/+140
| | | | | | | | | | | | Add an utility function for resetting addresses/routes of NMIP6Config from NMNDisc data. For one, this de-duplicates code in device and nm-iface-helper. Also, we no longer first reset (delete) all addresses and add them anew. Instead, we first mark all entries as dirty for deletion, merge (append) the new entires, and delete the remaining dirty entires. This saves a extra work, in the expected case where NMIP6Config already contains several of the new entries.
* all,trivial: include kernel versions and release dates in commentsLubomir Rintel2017-08-243-8/+12
| | | | | | This will make us stop worry how relevant are chunks of compat code with older kernels when deciding whether it's worth supporting/testing them. As if we actually were testing old kernels.
* platform: cleanup detecting kernel support for IFA_FLAGS and IPv6LLThomas Haller2017-08-242-45/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | - cache the result in NMPlatformPrivate. No need to call the virtual function every time. The result is not ever going to change. - if we are unable to detect support, assume support. Those features were added quite a while ago to kernel, we should default to "support". Note, that we detect support based on the presence of the absence of certain netlink flags. That means, we will still detect no support. The only moment when we actually use the fallback value, is when we didn't encounter an RTM_NEWADDR or AF_INET6-IFLA_AF_SPEC message yet, which would be very unusual, because we fill the cache initially and usually will have some addresses there. - for no strong reason, track "undetected" as numerical value zero, and "support"/"no-support" as 1/-1. We already did that previously for _support_user_ipv6ll, so this just unifies the implementations. The minor reason is that this puts @_support_user_ipv6ll to the BSS section and allows us to omit initializing priv->check_support_user_ipv6ll_cached in platforms constructor. - detect _support_kernel_extended_ifa_flags also based on IPv4 RTM_NEWADDR messages. Originally, extended flags were added for IPv6, and later to IPv4 as well. Once we see an IPv4 message with IFA_FLAGS, we know we have support.
* platform/trivial: move codeThomas Haller2017-08-241-42/+44
|
* platform: add non-exclusive routes and drop route-managerThomas Haller2017-08-2419-2670/+770
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we would add exclusive routes via netlink message flags NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`. Using that form of RTM_NEWROUTE message, we could only add a certain route with a certain network/plen,metric triple once. That was already hugely inconvenient, because - when configuring routes, multiple (managed) interfaces may get conflicting routes (multihoming). Only one of the routes can be actually configured using `ip route replace`, so we need to track routes that are currently shadowed. - when configuring routes, we might replace externally configured routes on unmanaged interfaces. We should not interfere with such routes. That was worked around by having NMRouteManager (and NMDefaultRouteManager). NMRouteManager would keep a list of the routes which NetworkManager would like to configure, even if momentarily being unable to do so due to conflicting routes. This worked mostly well but was complicated. It involved bumping metrics to avoid conflicts for device routes, as we might require them for gateway routes. Drop that now. Instead, use the corresponding of `ip route append` to configure routes. This allows NetworkManager to confiure (almost) all routes that we care. Especially, it can configure all routes on a managed interface, without replacing/interfering with routes on other interfaces. Hence, NMRouteManager becomes obsolete. It practice it is a bit more complicated because: - when adding an IPv4 address, kernel will automatically create a device route for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4 addresses yet (and we don't require such a kernel yet), we still need functionality similar to nm_route_manager_ip4_route_register_device_route_purge_list(). This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set(). - trying to configure an IPv6 route with a source address will be rejected by kernel as long as the address is tentative (see related bug rh#1457196). Preferably, NMDevice would keep the list of routes which should be configured, while kernel would have the list of what actually is configured. There is a feed-back loop where both affect each other (for example, when externally deleting a route, NMDevice must forget about it too). Previously, NMRouteManager would have the task of remembering all routes which we currently want to configure, but cannot due to conflicting routes. We get rid of that, because now we configure non-exclusive routes. We however still will need to remember IPv6 routes with a source address, that currently cannot be configured yet. Hence, we will need to keep track of routes that currently cannot be configured, but later may be. That is still not done yet, as NMRouteManager didn't handle this correctly either.
* platform: fix handling rt_scope of IPv4 routeThomas Haller2017-08-241-9/+34
| | | | | | | | | | | | | | | | | | | Kernel does not allow to add an IPv4 route with rt_scope RT_SCOPE_NOWHERE (255). It would fail with EINVAL. While adding a route, we coerce/normalize the scope in nm_platform_ip_route_normalize(). However, that should only be done, if the scope is not explicitly set already. Otherwise, leave it unchanged. nm_platform_ip_route_normalize() is related to the compare functions. Several compare modes do a fuzzy comparison, and they should compare equal as if they would be normalized. Hence, we must do the same normalization there. One pecularity in NetworkManager is that we track scope as it's inverse. The reason is to have a default value of zero meaning RT_SCOPE_NOWHERE. Hence "scope_inv".
* platform: add and use nm_platform_ip_route_normalize()Thomas Haller2017-08-234-21/+44
| | | | | Adding a route to kernel may coerce/mangle some properties. Add a function nm_platform_ip_route_normalize() to simulate these changes.
* platform: cleanup and renaming of nm_platform_address_flush() functionThomas Haller2017-08-235-7/+20
| | | | | | | | | | | | Rename to nm_platform_ip_address_flush(), it's more consistent with naming for other platform functions. Also, pass an address family argument. Sometimes I feel an option makes it clearer what the function does. Otherwise, from the name it's not clear which address families are affected. As an API, it feels more correct to me. We soon also get a nm_platform_ip_route_flush() function, which will look similar.
* platform: add typedef for NMPObjectPredicateFunc function pointerThomas Haller2017-08-233-4/+7
| | | | Otherwise, casting a function pointer is cumbersome.
* core: consistently use _nm_ip_config_add_obj() when adding route/address to ↵Thomas Haller2017-08-233-67/+92
| | | | | | | | | | ip-config _nm_ip_config_add_obj() does some additional checking, like setting the ifindex. We shall not bypass this also during bulk-update (replace). Add options @merge and @append_force to make _nm_ip_config_add_obj() suitable in those cases too, and use it.
* core: merge code block in nm_ip4_config_commit() by un-indentingThomas Haller2017-08-232-68/+62
|
* platform: add nm_platform_ip_route_add() functionThomas Haller2017-08-232-20/+45
|
* platform/trivial: move codeThomas Haller2017-08-231-18/+18
| | | | | Trivial code (like this which only depends on an enum defined in a header file) should go first, so that the complex stuff is close together.
* platform: fix constness of argument for nm_platform_lookup_all()Thomas Haller2017-08-232-4/+4
| | | | ... and nm_platform_lookup_entry().
* platform: fix handling rt_source/rtprot when comparing routesThomas Haller2017-08-231-6/+17
| | | | | | | | | | | | In several cases, does the route compare function a fuzzy match, to get the result as what would happen if you add that route to kernel. The rt_source enum contains some NetworkManager specific values which are mapped to a certain rtm_protocol value. Especially, when adding a route to kernel, the resulting value will be coerced (and end up being different). We must take this coercion into account.
* platform: fix loose comparison for metric of IPv6 routesThomas Haller2017-08-231-4/+10
| | | | | | For IPv6 routes, a metric of zero is identical to a metric of 1024. Unless we do NM_PLATFORM_IP_ROUTE_CMP_TYPE_FULL, compare them as equal.
* platform: use _Generic() for NM_PLATFORM_IP_ROUTE_IS_DEFAULT() macroThomas Haller2017-08-231-0/+15
| | | | Avoid the plain cast and use _Generic() to check the type of @route argument.
* shared: return deleted object from nm_dedup_multi_index_remove_obj()Thomas Haller2017-08-234-11/+29
| | | | | | | | | | For completeness of the API. remove_obj() is basically a shortcut of nm_dedup_multi_index_lookup_obj() combined with nm_dedup_multi_index_remove_entry(). As such, it is useful to return the actually deleted object. Note that the lookup needle @obj is not necessarily the same instance as the one that will be removed, it's only an instance that compares equal according to the index's equality operator.
* shared: indicate changes when only reordering happens during ↵Thomas Haller2017-08-231-1/+7
| | | | | | | | | | nm_dedup_multi_index_add() The return value shall indicate whether the add-call changed anything. Reordering shall count as a change too. On the other hand, clearing the dirty flag of the entry does not count as a change.
* shared: add nm_g_slice_free_fcn() utilThomas Haller2017-08-232-0/+68
| | | | | Useful, when you need a GDestroyNotify function for g_slice_free() of a certain type.
* core/trivial: indentation in src/devices/nm-device-ip-tunnel.cThomas Haller2017-08-231-8/+8
|
* core: fix crash in nm_ip4_config_address_exists()Thomas Haller2017-08-231-1/+1
| | | | Fixes: 22edeb5b691befd796c534cf71901b32f0b7945b
* clients: don't default Bluetooth to the PANU profileLubomir Rintel2017-08-231-11/+0
| | | | | | | | | | No reason to, the other types are no less likely. Quite the contrary, if the user specifies a GSM APN we're sure to use a DUN profile. $ ./clients/cli/nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 apn internet $ nmcli c show bluetooth-1 |grep bluetooth.type bluetooth.type: panu ^^^^ not cool
* core: infer the bluetooth type from the presence of the supplemental settingsLubomir Rintel2017-08-233-23/+89
| | | | | | | | | | | | | | | | | | When the user sets a GSM or CDMA setting along with a Bluetooth setting we know we're dealing with a DUN profile. No need to ask. [thaller@redhat.com: verify() and normalize() must strongly agree whether a connection is normalizable, and now to do it. That is, after verify() determines the connection is normalizable, normalize() must fix it as anticipated. The reason is, we only want to modify the connection, if we are able to create a valid result. Hence, after normalize() it *must* verify(). Try to simplify that by moving the logic of fixing the bt-type to a common place _nm_connection_detect_bluetooth_type().] Co-Authored-By: Thomas Haller <thaller@redhat.com>
* clients: allow GSM and CDMA for Bluetooth connectionsLubomir Rintel2017-08-231-0/+2
| | | | | | | | | | | | | | | | | | | | | Unbreaks Bluetooth DUN. Probably broken with the nm-meta-setting-desc refactor, hence the Fixes tag. I didn't actually check. $ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm Error: 'apn' argument is required. $ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm apn internet Error: invalid <setting>.<property> 'apn'. $ This is where it starts to get sad ^ $ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm gsm.apn internet Error: invalid or not allowed setting 'gsm': 'gsm' not among [connection, bluetooth, bridge, ipv4, ipv6, proxy]. $ This is where it gets obvious what went wrong ^ Fixes: b5c8622ad3e8eb34143e5023cdf784da741f338c
* device: skip creating VLAN devices if parent device is not ready yetFrancesco Giudici2017-08-221-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | do a check on parent ifindex before calling "nm_device_supports_vlans" otherwise if the parent device is a software device and its ifindex member has not been updated yet we will trigger the g_return_if_fail statement in "nmp_cache_lookup_entry_link". This has been osserved in NetworkManager CI test suite, on NetworkManager boot, during the creation of a vlan on top of a bond interface. CI test: vlan_update_mac_from_bond [...] <info> [1503323670.0229] manager: (bond0): new Bond device (/org/freedesktop/NetworkManager/Devices/23) <debug> [1503323670.0231] device[0x555555c3e320] (vlan10): constructed (NMDeviceVlan) <debug> [1503323670.0231] manager: (vlan-vlan10) create virtual device vlan10 <debug> [1503323670.0231] device[0x555555c3e320] (vlan10): unmanaged: flags set to [platform-init,!sleeping=0x10/0x11/unmanaged/unrealized], set-managed [sleeping=0x1]) <trace> [1503323670.0235] exported-object[0x555555c3e320]: export: "/org/freedesktop/NetworkManager/Devices/24" <trace> [1503323670.0235] properties-changed[0x555555c3e320]: ignoring notification for prop g-object-path on type NMDeviceVlan <trace> [1503323670.0236] properties-changed[0x555555c3e320]: ignoring notification for prop path on type NMDeviceVlan <info> [1503323670.0237] manager: (vlan10): new VLAN device (/org/freedesktop/NetworkManager/Devices/24) <debug> [1503323670.0239] device[0x555555c3e320] (vlan10): create (is nm-owned) Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x5555557c39a9 "NetworkManager", log_level= G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffdef0) at gmessages.c:1086 1086 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 0x00007ffff5ce3643 in g_logv (log_domain=0x5555557c39a9 "NetworkManager", log_level= G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffdef0) at gmessages.c:1086 #1 0x00007ffff5ce37bf in g_log (log_domain=log_domain@entry=0x5555557c39a9 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff5d51190 "%s: assertion '%s' failed") at gmessages.c:1119 #2 0x00007ffff5ce37f9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x5555557c39a9 "NetworkManager", pretty_function=pretty_function@entry=0x5555557b2a20 <__func__.32407> "nmp_cache_lookup_entry_link", expression=expression@entry=0x5555557b1037 "ifindex > 0") at gmessages.c:1128 #3 0x000055555566688a in nmp_cache_lookup_entry_link (cache=0x555555a780f0, ifindex=<optimized out>) at src/platform/nmp-object.c:1449 #4 0x00005555556668f9 in nmp_cache_lookup_link (cache=<optimized out>, ifindex=ifindex@entry=0) at src/platform/nmp-object.c:1464 #5 0x00005555556515e9 in nm_platform_link_get_obj (self=self@entry=0x555555a88880 [NMLinuxPlatform], ifindex=ifindex@entry=0, visible_only=visible_only@entry=1) at src/platform/nm-platform.c:618 #6 0x0000555555633e91 in link_supports_vlans (platform=0x555555a88880 [NMLinuxPlatform], ifindex=0) at src/platform/nm-linux-platform.c:4482 #7 0x00005555556d6d41 in create_and_realize (device=0x555555c3e320 [NMDeviceVlan], connection=0x7fffdc007890, parent=0x555555c33560 [NMDeviceBond], out_plink=0x7fffffffe1f8, error=0x7fffffffe358) at src/devices/nm-device-vlan.c:239 #8 0x00005555556b934c in nm_device_create_and_realize (self=self@entry=0x555555c3e320 [NMDeviceVlan], connection=connection@entry=0x7fffdc007890, parent=0x555555c33560 [NMDeviceBond], error=error@entry=0x7fffffffe358) at src/devices/nm-device.c:2946 #9 0x00005555555b84c7 in connection_changed (connection=0x7fffdc007890, self=0x555555ab1070 [NMManager]) at src/nm-manager.c:1381 #10 0x00005555555b84c7 in connection_changed (self=0x555555ab1070 [NMManager], connection=0x7fffdc007890) at src/nm-manager.c:1431 #11 0x00005555555b9130 in retry_connections_for_parent_device (self=self@entry=0x555555ab1070 [NMManager], device=device@entry=0x555555c33560 [NMDeviceBond]) at src/nm-manager.c:1416 #12 0x00005555555b95c7 in add_device (self=self@entry=0x555555ab1070 [NMManager], device=device@entry=0x555555c33560 [NMDeviceBond], error=error@entry=0x7fffffffe598) at src/nm-manager.c:2238 #13 0x00005555555b83e1 in connection_changed (connection=0x7fffdc007b30, self=0x555555ab1070 [NMManager]) at src/nm-manager.c:1352 #14 0x00005555555b83e1 in connection_changed (self=0x555555ab1070 [NMManager], connection=0x7fffdc007b30) at src/nm-manager.c:1431 #15 0x00005555555be25b in nm_manager_start (self=0x555555ab1070 [NMManager], error=error@entry=0x7fffffffe720) at src/nm-manager.c:5202 #16 0x0000555555586b13 in main (argc=1, argv=0x7fffffffe888) at src/main.c:413
* libnm/build: un-export wrong symbols for nm-manager.hThomas Haller2017-08-211-3/+0
| | | | | | | libnm/nm-manager.h is a private header file. It's symbols should not be exported. Fixes: 75aa3ea19451ba88942dd12d5ca0019518d6e747
* config: write connectivity=true to internal state fileThomas Haller2017-08-211-4/+2
| | | | | | | The internal state file is supposed to overwrite the files from /etc. Hence, we must also explicitly enable connectivity checking, when the user wishes to do so. Otherwise, if /etc contains connectivity=false, the setting cannot be overruled via D-Bus.
* config/tests: remove test artifact after test_config_connectivity_check()Thomas Haller2017-08-181-0/+2
| | | | Fixes: 9a58ee0705a5db75ce763eb2b24aec3f2c2028cb
* platform: fix updating object in nmp_cache_update_netlink_route()Thomas Haller2017-08-181-3/+6
| | | | | | | | | | _idxcache_update() may remove @entry_old or it may update @entry_old in-place. We must assign @out_obj_old before and not touch @entry_old after _idxcache_update(). Fixes: cdd8c6579919e542fb643a2070bb7ea49faef694
* libnm/connectivity: fix exporting new connectivity ABI in linker version scriptThomas Haller2017-08-171-0/+6
| | | | Fixes: 0480dae7492adfea5fb8f60b366a22cdd7df4927
* connectivity: merge branch 'connectivity-enable-dbus-bgo785117'Thomas Haller2017-08-1716-4/+362
|\ | | | | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=785117 https://github.com/NetworkManager/NetworkManager/pull/23 https://mail.gnome.org/archives/networkmanager-list/2017-July/msg00035.html
| * cli: show new enable-disable-connectivity-check permissionThomas Haller2017-08-171-0/+2
| |
| * libnm: add gtk-doc Since markers for new API and missing enum documentationThomas Haller2017-08-173-0/+22
| |
| * client: expose connectivity-check-{available,enabled} propertiesJames Henstridge2017-08-174-1/+168
| | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=785117
| * manager: add connectivity-check-{available,enabled} properties.James Henstridge2017-08-175-0/+67
| | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=785117
| * config: add an API to disable connectivity check via internal config file.James Henstridge2017-08-176-3/+103
|/ | | | https://bugzilla.gnome.org/show_bug.cgi?id=785117
* platform: merge branch 'th/platform-route-pt2'Thomas Haller2017-08-1219-605/+1380
|\ | | | | | | | | | | | | | | | | | | | | | | Fix the platform cache for routes, to be able to track routes like they can be added to kernel. Basically, the previous notion of the identifier for routes (ifindex,network/plen,metric) was not what kernel does. NMRouteManager and other code outside of platform is still oblivious to this change. That has to be addressed in future commits. https://github.com/NetworkManager/NetworkManager/pull/24
View Lorry Controller Status