delta/NetworkManager.git/src/tests, branch th/cli-strsplit

core: add nm_ipX_config_clone()

2017-12-06T08:53:18+00:00

device: add "indicated" argument to nm_utils_match_connection()

2017-11-30T13:47:49+00:00

The matching works fuzzy and is not reliable. That is why we store
which connection should be assumed after restart in the state file
of NetworkManager.

In that case, we don't need to do a full check (with the possibility
of a false-reject). Just check for the minimum required properties:
the type and slave-type.

Yes, if the user modifies the connection while restarting NM, then
we might wrongly assume a connection that no longer would match.
But NM should not read minds, it should do as indicated.

all: use nm_direct_hash() instead of g_direct_hash()

2017-11-16T10:49:52+00:00

We also do this for libnm, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.

all: use nm_close() instead of close()

2017-11-14T14:10:42+00:00

core: use NM_CONSTCAST() for NM_IP_CONFIG_CAST()

2017-11-13T10:35:44+00:00

core: fix build without connectivity check

2017-11-12T09:33:32+00:00

Fixes: 4dd30b784c53e9b61b6e3a2b2e135f589747fc06

https://bugzilla.gnome.org/show_bug.cgi?id=790222

core: add nm_utils_sysctl_ip_conf_is_path() util

2017-10-24T14:05:40+00:00

core: rework tracking of gateway/default-route in ip-config

2017-10-10T06:46:47+00:00

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 MSS in ip-config

2017-10-09T20:06:25+00:00

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: refactor parsing resolve.conf

2017-10-09T20:05:35+00:00

- 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.