Rather than requiring crypto_init() to have been called beforehand,
just have every method that depends on it call it itself.
This required adding a GError argument to crypto_is_pkcs12_data(),
which in turn required a few other changes elsewhere.
We were always using the gateway field of the first address in
ipv4.addresses / ipv6.addresses to set the gateway, but to be
compatible with old behavior, we should actually be using the first
non-0 gateway field (if the first one is 0).
nm_device_removed() calls nm_device_release_one_slave() in order to
fix up NetworkManager's master/slave bookkeeping, but we don't want to
tell the kernel to actually unslave the device, since that would
happen automatically anyway if the device was really removed, and
shouldn't happen if the device is just being removed from NM's device
list.
(In particular, don't remove all libvirt-created virtual network
devices from virbr0 when NetworkManager exits.)
nm_device_get_hw_address() may return NULL and nm_platform_link_get_type may
return NM_LINK_TYPE_NONE. While it might be a good idea to check for such cases
at the init time it seems easier to just ignore it and prevent blowing up in
subsequent deactivation.
A quick test case:
# while :; do ip link add moo0 type veth peer moo1; ip link del moo0 ; done
Yields:
NetworkManager:ERROR:devices/nm-device-ethernet.c:268:constructor:
assertion failed: (link_type == NM_LINK_TYPE_ETHERNET ||
link_type == NM_LINK_TYPE_VETH)
nm_device_set_hw_addr: assertion 'addr != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=740992
nmcli currently does not wait for the connection to fully deactivate, which
can take some time due to dispatcher scripts or cleanup operations like
DCB. Change it to wait until the connection is deactivated, or until
a short timeout has expired. The user can adjust the timeout with
"--wait" if they want.
https://bugzilla.gnome.org/show_bug.cgi?id=740775https://bugzilla.redhat.com/show_bug.cgi?id=1168383
For IPv4, iproute for example defaults to a metric of 0.
Hence, the name NM_PLATFORM_ROUTE_METRIC_DEFAULT was misleading.
Also add a NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP4 define for completeness.
https://bugzilla.gnome.org/show_bug.cgi?id=740780
We recently changed default values for route metrics. Revise that
again and increase the space between the default values.
No strong reason to do this, but it seems better to have larger
gaps and make use of the available range.
The parent device is just the device that happens to be the best device.
It does not mean, that its route metric should be inherited to the VPN
connection.
This also makes the resulting route metric for VPN connections much
more predictable: now it is either ipv4.route-metric from the connection,
or it falls back to NM_VPN_ROUTE_METRIC_DEFAULT (10).
Every Makefile in the subtrees would include -lreadline
as part of LIBS, hence every application would link against
the library.
This was broken since we added 'm4/ax_lib_readline.m4'.
Fixes: 29297f8531
Also read the command line argument as G_OPTION_ARG_INT64 type. Otherwise, on
32-bit integers, you could not enter any number larger then G_MAXINT32.
Signed-off-by: Thomas Haller <thaller@redhat.com>
For IPv4 addresses, the kernel automatically adds a route when
configuring an IP address. Unfortunately, there is no way to control
this behavior or to set the route metric.
Fix this, by adding our own route and removing the kernel provided
one.
Note that this adds a major change in that we no longer call
nm_ip4_config_commit() for assumed devices.
https://bugzilla.gnome.org/show_bug.cgi?id=723178
Signed-off-by: Thomas Haller <thaller@redhat.com>
The function was changed to return NULL instead of empty hash by commit
ad56cfa914. Later, the condition had to be
relaxed for NMSettingGeneric (commit 4d32618264).
Unforfunately, it shows up that there are other use cases that require
presence of a setting (that might have all properties default), such as
NMSettingBridgePort for bridge slave connections.
libnm already behaves this way, since commit
6325c596c0.
https://bugzilla.gnome.org/show_bug.cgi?id=740681
NMIPRoute is used by NMSettingIPConfig, but also
NMIPConfig. In the former case, default routes are (still)
disallowed. But in the NMIPConfig use-case, it can make sense
to expose default routes as NMIPRoute instances.
Relax the restriction on the NMIPRoute API to allow this
future change.
No code actually supports having NMIPRoute instances with
prefix length zero (default routes). Up to now, all such uses
would be a bug.
https://bugzilla.gnome.org/show_bug.cgi?id=739969
Signed-off-by: Thomas Haller <thaller@redhat.com>
The previous nm-dhcp-systemd code for logging the lease expiry time,
and exporting that value to D-Bus was clamping the value to
G_MAXUINT32-1, but that's unnecessary on x86_64, and incorrect on x86
(since time_t is signed).
Correctly adding a value to the current time and not overflowing seems
to be more-or-less impossible without having separate cases for 4- and
8-byte time_t. Since this was basically just for logging purposes
anyway, just log the number of seconds rather than the timestamp, and
then we don't have to worry about sizeof(time_t).
VLAN device watches the parent and reacts to its state change. However, on
creation, the device was made managed, even if the parent was unmanaged. Fix
that and export VLAN parent device property too. The property is added to
libnm/libnm-glib and nmcli as well.
https://bugzilla.redhat.com/show_bug.cgi?id=1114681
Rename NMSecretAgent to NMSecretAgentOld, to leave the name
"NMSecretAgent" open for a new-and-improved version in NM 1.2.
Also, a handful of NMSecretAgentSimple fixups.
https://bugzilla.gnome.org/show_bug.cgi?id=740345
set_connection_path() is almost always called right before enable(),
and it's unclear why it would be called anywhere else. So just
merge the two methods.
nm_secret_agent_simple_*() functions should take an
NMSecretAgentSimple, not an NMSecretAgent.
The type macros were incorrectly validating against
NM_TYPE_SECRET_AGENT rather than NM_TYPE_SECRET_AGENT_SIMPLE.
/libnm/crypto/PKCS#8: OK
/libnm/crypto/cert/pem: ==16241== Conditional jump or move depends on uninitialised value(s)
==16241== at 0x121967: crypto_load_and_verify_certificate (crypto.c:605)
==16241== by 0x12512E: nm_utils_file_is_certificate (nm-utils.c:2279)
==16241== by 0x1201F1: test_cert (test-crypto.c:113)
nmt-editor.c: In function ‘nmt_editor_constructed’:
nmt-editor.c:365:2: error: ‘page’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
add_sections_for_page (editor, grid, page);
^