Some adjustments need to be made to read and write secret flags, and
to ensure that connections that don't have system-owned secrets are
still parsed as expected. testcases for 802.1x connections to come
shortly.
First, it was not easily possible to set a private key without
also providing a password. This used to be OK, but now with
secret flags it may be the case that when the connection is read,
there's no private key password. So functions that set the
private key must account for NULL passwords.
Unfortunately, the crytpo code did not handle this case well.
We need to be able to independently (a) verify that a file looks
like a certificate or private key and (b) that a given password
decrypts a private key. Previously the crypto code would fail
to verify the file when the password was NULL.
So this change fixes up the crytpo code for a more distinct
split between these two operations, such that if no password is
given, the file is still checked to ensure that it's a private
key or a certificate. If a password is given, the password is
checked against the private key file.
This commit also changes how private keys and certificates were
handled with the BLOB scheme. Previously only the first certificate
or first private key was included in the property data, while now
the entire file is encoded in the data. This is intended to fix
cases where multiple private keys or certificates are present in
a PEM file. It also allows clients to push certificate data to
NetworkManager for storage in system settings locations, which was
not as flexible before when only part of the certificate or key
was sent as the data.
Like if the IP interface doesn't have an ifindex yet. Previously
the connection would just go merrily along and wait for IPv6 to
complete even though it had already failed. Happens if you try
to do IPv6 on mobile broadband connections, which we'll add support
for later.
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
deactivate_quickly is misnamed these days; it was originally used
for quickly tearing down a device for sleep and such. But these
days it's used for the bulk of device deactivation. Only the wifi
class used the actual deactivate method. So combine the two and
make device implementations less complicated.
If configuration fails, there won't be an IPv6 config for the device,
thus the route flush when deactivating the device if it fails would
only flush IPv4 routes. We don't know how far through IPv6 setup
we got, so we do want to flush IPv6 routes on deactivate if we
started IPv6 config at any point.
When a DBus error is received, the values of the other parameters
may be undefined, but bindings will assume they're valid and fail.
Capture this case and pass NULL to the callbacks.
Also, allow passing NULL instead of a callback, for bindings that
don't support the argument types.
Clients need to do their own logging using glib or whatever; these
macros while somewhat helpful were not flexible and are not a
substitute for actual logging in the client. g_warning, g_message,
and g_error are more suitable anyway.
It's always used with a GByteArray anyway, as are most
functions in nm-utils.h. Even better, we can skip the
memcpy since it turns out to be pointless.
Will be used for things like activating a VPN connection before
signaling that the device is activated, or maybe for bridges and
bonds, to ensure that applications don't think the system has
connectivity before everything is set up.
