summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* core: rework tracking of gateway/default-route in ip-configth/policy-routing-pt2-rh1436531Thomas Haller2017-10-0934-895/+1100
| | | | | | | | | | | | | | | | | | | | | | 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-094-68/+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-097-92/+8
| | | | | | | | | | | | | | | | | 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-095-7/+24
| | | | Including device-routes, default-route, SLAAC.
* core: use ipv4.route-table setting for other IPv4 routesThomas Haller2017-10-0917-20/+94
| | | | Including device-routes, default-route, DHCPv4, IPv4LL.
* all: rework configuring route table support by adding "route-table" settingThomas Haller2017-10-0922-179/+274
| | | | | | | | | | | | | | | | | | | | | | | | | 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".
* dns: merge IPv4 and IPv6 implementation for update_add_ip_config()Thomas Haller2017-10-091-57/+54
| | | | | | How nice would it be to have a NMIPConfig class that is agnostic for IPv4 and IPv6. Another small step, in unifying v4 and v6.
* shared: add nm_utils_addr_family_to_size()Thomas Haller2017-10-091-0/+10
|
* core: refactor parsing resolve.confThomas Haller2017-10-097-257/+137
| | | | | | | | | - 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.
* shared: add nm_strstrip_avoid_copy()Thomas Haller2017-10-091-0/+27
|
* platform: mark static nla_policy variables as constThomas Haller2017-10-092-26/+68
| | | | | | | | | | | | These static variables really never be modified. Mark them as const, which allows the linker to mark them as read-only. The problem is libnl3's API, which has these parameters not as const. Add a workaround for that. Clearly libnl3 is not gonna modify the policy, that the API was fixed too [1] [1] https://github.com/thom311/libnl/commit/b4802a17a7655bfeee3e9c06e649d30b96dbad3b
* wwan: fix uninitialized variable in ofono's context_property_changed()Thomas Haller2017-10-091-7/+6
|
* dhcp: set @was_active on ipv6 when assuming a device with dhcp ipv6 confFrancesco Giudici2017-10-061-1/+1
| | | | | | Due to a typo the flag was set on ipv4 Fixes: ddfeed4530bb0ade4249025930da4f0456026d9f
* platform: treat dsa devices as regular wired ethernetLubomir Rintel2017-10-061-0/+4
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1371289
* device: reword logging line about device's state changeThomas Haller2017-10-061-2/+2
| | | | | | | | | | | | The line device (wlan0): state change: ip-config -> ip-check (reason none, internal state managed) prints the sys-iface-state, which is at other places logged with device[0x55914506ed70] (wlan0): sys-iface-state: external -> managed For consistency, name the same parameter the same.
* all: merge branch 'th/policy-routing-pt2-rh1436531' (part 1)Thomas Haller2017-10-0623-294/+455
|\ | | | | | | | | | | | | Merge an early part of the branch, with independent cleanups and refactoring. https://bugzilla.redhat.com/show_bug.cgi?id=1436531
| * dhcp/trivial: rename "priority" variables to "route_metric" in DHCP codeThomas Haller2017-10-069-49/+46
| | | | | | | | | | | | | | | | The name "priority" is well established for routes (e.g. kernel's RTA_PRIORITY netlink attribute). However, we call it at most places "metric" or "route_metric". Rename it, not to use two different names for the same thing.
| * device: factor out config argument to ip4_config_merge_and_apply()Thomas Haller2017-10-061-18/+17
| |
| * device: refactor function nm_device_get_priority() / _get_route_metric_default()Thomas Haller2017-10-062-15/+4
| | | | | | | | | | | | | | The name nm_device_get_priority() is misleading. Nowadays it's only used for the default route metric, and nothing else. Rename it, and make it static.
| * device/trivial: rename nm_device_get_ip_route_metric() to ↵Thomas Haller2017-10-065-25/+25
| | | | | | | | | | | | nm_device_get_route_metric() Brevity!
| * device: remove wrappers for nm_device_get_ip_route_metric()Thomas Haller2017-10-064-33/+21
| |
| * wwan: replace utils function ip4_string_to_num() with ↵Thomas Haller2017-10-062-40/+14
| | | | | | | | | | | | | | | | | | | | | | nm_utils_parse_inaddr_bin() One might already question the existance of nm_utils_parse_inaddr_bin(), because it only wraps inet_pton(), which by itself isn't terrible API. The reason nm_utils_parse_inaddr_bin() exists, is to mirror to nm_utils_parse_inaddr() function, which has additional functionality on top of inet_pton(). But we shouldn't have more then one wrapper for inet_pton().
| * shared: guarantee output argument of nm_utils_parse_inaddr_bin() is only set ↵Thomas Haller2017-10-061-1/+18
| | | | | | | | | | | | | | | | on success The documentation of inet_pton() is not clear about what happens when parsing fails. Guarantee that the output is only modified on success.
| * shared: pass addr_family as first argument to nm_utils_parse_inaddr*()Thomas Haller2017-10-065-69/+69
| | | | | | | | | | | | | | The addr_family should be the first argument. It mirrors inet_pton() and is just nicer. Also, rename the argument from "family" to "addr_family".
| * wwan: add FIXME comment about broken ofono supportThomas Haller2017-10-061-0/+3
| |
| * wwan: make idle action for stage3-ip-config cancellableThomas Haller2017-10-061-6/+17
| |
| * wwan: use logging macro in nm-modem.cThomas Haller2017-10-061-60/+86
| | | | | | | | | | | | | | | | | | For some logging lines this changes the domain from LOGD_PPP or LOGD_MB|LOGD_IP4 to LOGD_MB. Also, it changes the format of the prefix, and adds a prefix for some logging lines that didn't have one previously.
| * shared: add nm_strquote() utilThomas Haller2017-10-063-0/+157
|/ | | | | | | | | We already have nm_strquote_a(). That is useful, but uses alloca(), hence it is ill suited to be called from a macro, inside a loop, or from a function that should be inlined. Instead, add nm_strquote() that has the same purpose but writes to a provided string buffer.
* core: avoid compiler warnings related to cleanup attributeThomas Haller2017-10-052-2/+2
| | | | | | | | | gcc doesn't consider variables with cleanup attribute as unused. clang does, and warns about them. In one case, clang is right, in the other one the warning is bogus. Fix both.
* device: fix handling NM_UNMANAGED_USER_CONF in _get_managed_by_flags()Thomas Haller2017-10-051-2/+2
| | | | | | | | | | Found by clang warning: src/devices/nm-device.c:11370:14: error: use of logical '||' with constant operand [-Werror,-Wconstant-logical-operand] || NM_UNMANAGED_USER_UDEV ^ ~~~~~~~~~~~~~~~~~~~~~~ Fixes: 5778bc6a34f2291d68247695119f2170bc3bf8b3
* core: merge branch 'th/activation-state-flags-rh1454883'Thomas Haller2017-10-0512-152/+394
|\ | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1454883
| * core: add NMActivationStateFlags "master-has-slaves"Thomas Haller2017-10-053-0/+13
| |
| * core: add NMActivationStateFlags "layer2-ready", "ip4-ready", and "ip6-ready"Thomas Haller2017-10-053-0/+42
| |
| * core: add NMActivationStateFlags "is-master" and "is-slave"Thomas Haller2017-10-052-0/+26
| |
| * libnm: add NMActivationStateFlagsThomas Haller2017-10-057-0/+122
| | | | | | | | | | | | No flags yet implemented. https://bugzilla.redhat.com/show_bug.cgi?id=1454883
| * core: refactor setting applied-connection in NMActiveConnectionThomas Haller2017-10-051-7/+37
| | | | | | | | Introduce a set-function, will be used later.
| * shared: move utils NM_UTILS_ENUM2STR*, NM_UTILS_FLAGS2STR*, and ↵Thomas Haller2017-10-054-147/+151
| | | | | | | | | | | | | | | | nm_utils_to_string_buffer_init() These are just simple utility functions, not tied to NetworkManager core. Move them to shared/nm-utils, so that they may be reused otherwise.
| * core/utils: extend nm_utils_flags2str() for multi-value flags and name for zeroThomas Haller2017-10-051-3/+9
| | | | | | | | | | | | | | | | | | | | Allow passing a pretty name for the zero flag 0, like "none". Also, don't require flags to be power-of-two. Instead, allow names for multiple flags. For example an "all" name. By specifying multi-value flags first, their nick will be supersede the more specific flags. Probably it doesn't make sense in usual cases, but nm_utils_flags2str() should prevent such use.
| * core: minor cleanup of _NMLOG() macro in "src/nm-active-connection.c"Thomas Haller2017-10-051-4/+3
|/
* device: fix frozen notify signals on unrealize error pathBeniamino Galvani2017-10-041-1/+1
| | | | | | | | | If unrealize() failed we returned without thawing notify signals. Fix this by moving g_object_freeze_notify() after the unrealization/deletion but before the properties are reset in unrealize_notify(). Fixes: a93807c288743f499362f7edfe0674020762811c
* core: cleanup autoconnect retry handling (fix settings-docs.c)Thomas Haller2017-10-041-1/+1
| | | | Fixes: cfb14ce17e77916d8998d444a05cdea726723240
* core: cleanup autoconnect retry handlingThomas Haller2017-10-046-12/+19
| | | | | | | | - clearify in the manual page that setting retry to 1 means to try once, without retry. - log the initially set retry value in nm_settings_connection_get_autoconnect_retries(). - use nm_settings_connection_get_autoconnect_retries() in nm_settings_connection_can_autoconnect().
* dhcp: cleanup handling method-call in DHCP listenerThomas Haller2017-10-041-29/+32
| | | | | | Split out a separate function _method_call_handle(). That way we can get rid of the "goto out" and use cleanup attribute to manage resources inside _method_call_handle().
* libnm,keyfile: merge branch 'th/libnm-keyfile-route-metric'Thomas Haller2017-10-043-45/+57
|\
| * keyfile: fix reading/writing route metric zeroThomas Haller2017-10-043-14/+19
| | | | | | | | | | | | | | Zero is a valid route metric and distinct from -1, which means unspecified. Fix reader and writer. Fixes: e374923bbe4a9f608644756f749b9bae9aa5f349
| * keyfile: cleanup error argument for read_field()Thomas Haller2017-10-041-25/+33
| | | | | | | | | | | | | | | | | | | | | | Rename @error to @out_err_str, because @error is usually used for GError output arguments. Also, make the string variables "const char *". Use nm_assert() in read_field(), because it is a static function with only four call sites. It's easily verified that the assertion holds, so no need for a run-time check in production builds.
| * keyfile: minor cleanup in get_one_int() to use _nm_utils_ascii_str_to_int64()Thomas Haller2017-10-041-6/+5
|/
* contrib/scripts: fix coloring for platform messages in NM-log for old logsThomas Haller2017-10-031-1/+1
| | | | | | | | Older logfiles contain platform: route: adding or updating IPv4 route: 10.1.0 Hightlight that too.
* libnm: update property in the manager after connectivity checkBeniamino Galvani2017-10-031-3/+17
| | | | | | | | | | | | | | Currently, after a client performs a connectivity check it cannot access the up-to-date value of the manager.connectivity property right away, but it must wait that the queued PropertiesChanged signal is processed, which is cumbersome. Arguably, clients already receive the new connectivity value as the result of the connectivity check call, so they don't have to read it from the object; however it would be better if the right value of the object property was available immediately as well. https://bugzilla.gnome.org/show_bug.cgi?id=784629
* core: cleanup handling addr_family in NMDeviceThomas Haller2017-10-022-51/+71
| | | | | | | | - use nm_utils_addr_family_to_char(). It asserts that the input argument is either AF_INET or AF_INET6. - rename variable @family to @addr_family for consistency. - when logging addr_family for activation-stage, use v4 or v6 instead of numeric AF_INET/AF_INET6.
View Lorry Controller Status