Drop nm_utils_init() and nm_utils_deinit(), and do some things via
constructors and other things via just-in-time initialization.
(Among other things, this fixes the fact that the daemon was failing
to call nm_utils_init().)
https://bugzilla.gnome.org/show_bug.cgi?id=740893
In general, we shouldn't end up with an unencrypted copy of a
certificate key anyway, so this function ought to be unnecessary (or
at least, not broadly useful enough to be in the public API).
nm-applet's GConf migration tool needs it, but that will eventually go
away, and until then it can just use libnm-util.
crypto_md5_hash() only has two users:
(a) crypto_make_des_aes_key()
(b) nm_utils_uuid_generate_from_string()
For (b) it is just a complicated way to compute the MD5 hash. The
restrictions on salt and password don't matter. Actually they
are harmful because we cannot compute the MD5 hash of the empty
word.
For (a), the caller should make sure to pass whatever restrictions
he wants to enforce on the data.
For example, it is counterintuitive, that crypto_md5_hash() would
require @salt_len, enforce it to be at least 8 bytes, and then just
use the first 8 bytes. If the caller (a) wants that behavior, he
should make sure that he passes in 8 bytes.
Likewise for the empty word. If the caller does not want to compute
the hash of empty passwords, he must not hash them.
Indeed, all of this was enforced by assertions, any caller already
did the right thing.
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
