We don't really know which version it's going to be -- and thus if we're going
to actually need it (version 5), or not (version 4). It's going to be decided
at configure time.
Also, drop the bogus Fedora 19 conditionals; Fedora < 20 has ModemManager that's
too old for the WWAN code anyway.
(cherry picked from commit db44539912)
NetworkManager uses wpa_supplicant, which in turn calls OpenSSL for verifying
certificates. wpa_supplicant calls
SSL_CTX_load_verify_locations(ctx, CAfile, CApath)
using its ca_cert and ca_path options as CAfile and CApath parameters.
We have a configure time option with_system_ca_path to override ca_path.
However, it doesn't work when a system (like Fedora) only uses bundled PEM
certificates instead of a directory with hashed certificates ([1], [2]).
So this commit allows setting --with_system_ca_path to a file name (the
trusted certificate bundle). Then the name is used to populate wpa_supplicant's
ca_cert instead of ca_path.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1053882
[2] https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/https://bugzilla.redhat.com/show_bug.cgi?id=1236548
(cherry picked from commit 640eb8f284)
priv->iface could change in device_link_changed() which reacts on platform link
changes caused by nm_platform_link_set_user_ipv6ll_enabled(). (The variable could
change between obtaining and using its value, because emitting a glib signal runs
callbacks synchronously).
Actually, the problem is already fixed by commit 04caae735f.
But still this is better.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1224366
(cherry picked from commit bb1692707f)
Kernel does not allow to add the same route (as determined by network/plen,metric)
on two different interfaces (ifindex). In case of conflict, NMRouteManager used to
ignore any but the firstly added route.
On the other hand, we cannot add a gateway-route, if there is no direct
route to the gateway. Hence, skipping duplicate routes can mean that we
skip a direct route what was necessary to add another gateway-route,
which then leads to a failure to add that route.
This also applies to IPv4 device routes that since recently are managed
by NMRouteManager.
For example, say you connect two interfaces to the same IP subnet.
The route-metric can conflict if the interfaces are of the same type
or if the user explicitly configured a conflict.
In case of conflicts, NMRouteManager would only configure the first
appearing route and skip the shadowed route on the second interface.
Now we cannot configure gateway-routes on the second interface because
the gateway is unreachable.
There are many scenarios where this issue can happen, especially with
default-routes and user-configured-routes.
For example with default-routes, ip4_config_merge_and_apply() would check
if the default-gateway requires an explict route and possibly add it.
But then NMRouteManager might not add the route because it is shadowed
by a route on an other interface.
This patch solves the issue by having NMRouteManager configure shadowed
routes too, similar to what NMDefaultRouteManager does.
It does that by searching for an unused, non-conflicting, higher metric
for the route, i.e. bump the metric by 1 until we can add it without
conflict.
Also note that NMRouteManager still ensures that for conflicting routes
the best route sticks to the interface that configured it first. That
means if you later add the conflicting route on another interface, it
will be added with higher metric and the data is still routed along the
first interface.
(cherry picked from commit f5c087c8e9)
Early part of fixes and improvements to NMConfig.
This is mostly refactoring and adding of new utility functions.
But it also fixes the way how to parse configuration options from
"NetworkManager.conf" keyfile. So this brings behavioral changes
in the way how we parse the configuration. But unless the user had
unusual configurations (whitespaces, backslash escapes), there should
be no visible changes.
https://bugzilla.gnome.org/show_bug.cgi?id=750558
(cherry picked from commit 65753dbc13)
It is wrong to blindly merge keys that have an 'option+' or 'option-'.
Merging options is only possibly when we understand what the option
means and how to merge it.
No longer handle every setting but only those that are explicitly known
to be string-lists (or device-specs).
(cherry picked from commit a1ea678f78)
We have a special implemenation nm_match_spec_split() to split
a string. We also need the reverse operation to be able to convert
a list of specs to string without loss.
(cherry picked from commit bd57d76af8)
In some cases we want the returned value to be stripped. In some cases,
we want to read the raw value instead of the string parsed by GKeyFile.
Add an flags argument to nm_config_data_get_value(). It is up to the caller
to determine the exact meaning (and whether to strip).
By adding the flags argument, the caller can get the desired behavior easier
without having to workaround it afterwards. But more importantly, it becomes
apparent that there are different ways to retrieve the value and the caller
should decide on the details.
(cherry picked from commit d3e2193783)
Via escape sequences, the user still can specify trailing and leading
white spaces: such as "\s \s" will result in 3 spaces.
(cherry picked from commit 7498b670a8)
g_key_file_get_value() returns the raw value as stored in the file.
When accessing a string value, in most cases it is correct to use
g_key_file_get_string() instead.
When working with internals, such as comparing two keyfiles for
equality, g_key_file_get_value() is correct.
When parsing booleans, we parse it based on the raw value.
Fix the usages. This is a change in behavior if the config file
contained unusual strings.
(cherry picked from commit 0abb502ff3)
Some plugins had their local defines for the name of the sections and
keys in NMConfig. Move those defines to "nm-config.h".
Usually plugins make use of code in core, but not the other
way round. Defining the names inside "nm-config.h" is no violation of
that because the config section names are anyway not local to the
plugin, but global in the shared name-space with other settings.
For example, another plugins shouldn't reuse the section "ifnet".
For that reason, it is correct and consistent to move these defines
to "nm-config.h".
We don't use those names in core, we merely signal their existance.
(cherry picked from commit 6d6ab20be0)
Add function to parse as boolean according our NMConfig convention.
Split this out from nm_config_keyfile_get_boolean() so that we can use
it independently. Also, change the return type to gint, so that one might
pass -1 to indicate an invalid/missing boolean value.
Thereby also don't log a warning in nm_config_keyfile_get_boolean()
We don't want to log a warning every time we access a keyfile value.
If we want to warn about invalid values, we should do it once after
the configuration is loaded. And then we should not only do it
for booleans, but for other types as well.
(cherry picked from commit 35d2981546)
We don't use this argument. A failure to retrieve a key is (for
every practical purpose) the same as no such key.
(cherry picked from commit a5f7abb842)
GKeyFile considers the order of the files, so add a possibility
to check whether to keyfiles are equal -- also with respect to
the order of the elements.
(cherry picked from commit 7fbfaf567d)
The content of the no-auto-default state file is part of NMConfig.
During a reload, also reload that.
This way, a user could edit the no-auto-default file and it would
be properly reloaded.
(cherry picked from commit 4a8a0b0918)
We used to merge the spec list for no-auto-default from keyfile with the
content of the state file. Since the addition of the "except:" spec this
is wrong.
For example, if the user configured:
no-auto-default=except:mac:11:11:11:11:11
and statefile contained "11:11:11:11:11" and "22:22:22:22:22", we would
wrongly not match "11:11:11:11:11". The two lists must be kept separate,
so that devices that are blocked by internal decision always match.
This separation is also clearer. Now the spec list is devided into a
part that comes from user configuration, and a part that comes from
internal decision.
(cherry picked from commit 3e4458659b)
We have a hack to extend GKeyFile to support specifying an 'option+'
key. Also add support for 'option-'.
Options that make use of these modifiers can only be string lists.
So do the concatenation not based on plain strings, but by treating
the values as string lists. Also, don't add duplicates.
(cherry picked from commit fab5c6a372)
The original backport was different then what was done on master.
Make 'nm-config.c' more similar to what we have on master.
Fixes: d510f0a039
(cherry picked from commit 643f042b9b)
