We don't want error logging for nm_platform_link_add() which
tries to load the bonding module. Later we will run tests as non-root,
where modprobe will fail. Logging an error would break the tests.
Even if asserts are not enabled, still let the compiler see what we would
assert. Otherwise, we get warnings about unused variables or we migth miss
compile errors inside nm_assert().
Since introduction for support of ip6-privacy (use_tempaddr,
RFC4941) with commit d376270bfe,
the sysctl value from /etc was always read first.
This is problematic, because an explicit setting in the
connection should not be ignored over a global configuration.
Drop that old behavior. It was also problematic, because we did
not read any files under /etc/sysctl.d (except for sysctl.conf).
Also, we did not honor per-interface configurations.
Now we also use as last fallback the value from
/proc/sys/net/ipv6/conf/default/use_tempaddr
That has the advantage of falling back to the system default value
so that NM doesn't need to have it's own default policy
(Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525).
This is a change in behavior.
Support default value for setting 'ipv6.ip6-privacy' in
NetworkManager.conf.
If the global value is unset, preserve old behavior of looking into
/etc/sycctl.conf first. That behavior was introduced with commit
d376270bfe, since we support ip6-privacy
setting.
If the global value is set to "unknown", add a new fallback
that instead reads the runtime value from
"/proc/sys/net/ipv6/conf/default/use_tempaddr"
This seems more sensible behavior because we fallback to sysctl,
but instead of looking at static files in /etc, read /proc.
But to preserve the old behavior, we only do that when a global
value is configured at all.
https://bugzilla.gnome.org/show_bug.cgi?id=721200
The route-metric can be configured per connection via the
ipv4.route-metric and ipv6.route-metric fields. When the
value is left at -1 (the default), we would determine the
route-metric based on the device type (nm_device_get_priority()).
Extend that scheme by making the default value overwritable in
NetworkManager.conf.
Add support for a new section [connection] in NetworkManager.conf.
If the connection leaves an option at "unknown"/"default", we can
support overwriting the value from global configuration.
We also support other sections that are named with "connection"
as a prefix, such as [connection2], [connection-wifi]. This is
to support multiple default values that can be applied depending
on the used device.
I think this has great potential. Only downside is that when
the user looks at a connection value, it will see that it is
unspecified. But the actually used value depends on the device
type and might not be obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=695383https://bugzilla.redhat.com/show_bug.cgi?id=1164677
Add a function to get a concise representation of the
device type.
libnm already has nm_device_get_type_description() for that
and it is shown by
nmcli -f GENERAL.TYPE device show
Reimplement that function for nm-core. Just take care that the
two implementations don't diverge.
You can reset the default value via
$ nmcli connection modify id CON ipv4.dns-options ""
and set an empty value with
$ nmcli connection modify id CON ipv4.dns-options " "
The advantage of this is that if we later add another function
pointer we don't have to touch any existing calls which would
only pass NULL to that argument.
Using a variadic argument and partial initialization of an
auto variable gives us that flexibility.
Instead of having a get_func() and out2in_func(), have only one
get_func() that accepts an argument of the output format.
This way, a conversion to parsable input format, doesn't have to go
first thourgh get_func() and mangle the pretty string in out2in_func().
This fixes conversions via nmc_property_out2in_cut_paren().
For example, nmc_property_802_1X_get_private_key_password_flags()
would return a localized string _("0 (none)"). There is no guarantee
that out2in_func() would find the expected output format after
localizing.
This also fixes nmc_property_out2in_routes() which expected
a format "dst =" (would be "ip =") and expects mandatory
'nh' and 'mt' arguments. In fact, the regex didn't match and
nmc_property_out2in_routes() always failed.
While at it, also combine the implementation of
nmc_property_ipv4_get_routes() and nmc_property_ipv6_get_routes().
Previously, it would silently accept a value set to "empty".
This is however not a valid number and we should raise a
warning just like for any other invalid number.
Before, get_property_for_dbus() would @ignore_defaults.
That is for example wrong for properties of type G_TYPE_STRV.
In this case, if one operand has the property at its default
(NULL) and the other has it to an empty string list, both would
compare equal.
This has the effect that different settings might compare equal.
When generating a connection to assume it, also record the route-metric.
Do that by looking at the metric of the (best) default-route.
This is especially important since d51975ed92.
Now NM would also manage the default-route for assumed connections.
So the generated assumed connection would have a route metric based on
the device type, which might differ from the external configuration.
This caused NM to replace the externally configured default-route.
https://bugzilla.gnome.org/show_bug.cgi?id=750405
If the valgrind logfile is empty, don't log an error message with
the location of the logfile.
Also, if the test didn't fail due to memleaks, log a different message.
Turns out the dconf modules is leaky and breaks the valgrind run. In any case,
it's not a good idea to load the modules for the daemon, it just takes time
and memory.
On a Fedora/x86_64 desktop it adds up to 5M to the RSS.
Fixes for example valgrind tests for ./libnm/tests/test-nm-client:
==25772== Conditional jump or move depends on uninitialised value(s)
==25772== at 0x40198D8: index (strchr.S:106)
==25772== by 0x400777C: expand_dynamic_string_token (dl-load.c:369)
==25772== by 0x400777C: fillin_rpath (dl-load.c:439)
==25772== by 0x4007FCF: _dl_init_paths (dl-load.c:816)
==25772== by 0x4002F38: dl_main (rtld.c:1194)
==25772== by 0x401750F: _dl_sysdep_start (dl-sysdep.c:249)
==25772== by 0x4004C20: _dl_start_final (rtld.c:306)
==25772== by 0x4004C20: _dl_start (rtld.c:412)
==25772== by 0x4000C97: ??? (in /usr/lib64/ld-2.21.so)
==25772== by 0x1: ???
==25772== by 0xFFEFFF6B2: ???
==25772== by 0xFFEFFF6EF: ???
==25772==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:index
fun:expand_dynamic_string_token
fun:fillin_rpath
fun:_dl_init_paths
fun:dl_main
fun:_dl_sysdep_start
fun:_dl_start_final
fun:_dl_start
obj:/usr/lib64/ld-2.21.so
obj:*
obj:*
obj:*
}
The previous patch 9ffcecf86a was
completely wrong.
It tried to fix callers that provided a floating GVariant reference.
We require the caller to unref @secrets, so the correct fix it to
ensure that the reference is not floating.
Fixes: 9ffcecf86a
Fixes: 6793a32a8c
Add the new configuration option 'assume-ipv6ll-only' which specifies
the devices for which NM will try to assume an existing IPv6LL-only
configuration.
The new default behavior is to ignore such configurations since IPv6LL
addresses are automatically assigned by the kernel when the device is
brought up and thus the presence of an IPv6LL address doesn't mean
that the device was configured by the administrator.
The previous behavior was to always assume IPv6LL-only configurations
but this often had the unwanted effect of preventing other on-disk
configurations to be activated. To preserve the old behavior the
option must be set to '*'.
https://bugzilla.redhat.com/show_bug.cgi?id=1138426
Alias files have a ':' to separate the base name from their
alias. But we didn't always ensure not to write-out files without
colon, and also initscripts doesn't have that restriction.
We should detect alias files and handle them properly (e.g. by
reloading the base file).
This fixes an error that a `nmcli con load` would have tried to
load the alias file. Also extend load_connection() to support
passing filenames other then the base file.
We only have to handle this in plugin.c. Inside reader.c we always
have the normalized base filename.
Or detection of alias files only looks whether the filename has a ':'
and whether a corresponding base file exists.
Previously, if the main ifcfg file doesn't define any
static ip addresses, any alias files would be ignored.
We should also allow alias files with (pure) 'dhcp' connections,
just like initscripts do.
Reported-by: Marek Hulan <mhulan@redhat.com>
connection_from_file() used to log a warning about failure,
but only when an @error argument was given.
update_connection() didn't ensure that in several cases,
so we would not log any failure reason when an ifcfg file
failed to read.
This behavior of controlling logging by passing @error (or not)
is unexpected. Instead, refactor the code so that the caller
can do appropriate logging.
Another reason for this refactoring is that PARSE_WARNING() does
not mention the file for which the failure is and uses some extra
indention that looks wrong. IOW, connection_from_file() doesn't
have the context to give the logging line a proper formatting.
It seems like a poor default for various downstream toolchains. We can't
anticipate the compiler warnings for future compiler versions and older
ones are prone to false positives. Also, older gdbus-codegen is known
to generate code that triggers compiler warnings.
Let's keep it enabled for maintainer builds and distcheck so that we're
sure a tool chain that builds releases without warnings exists.
