In the past networkmanager did not allow to manually disconnect devices.
Manually disconnected devices will not be automatically reconnected until one
of the following events occur:
1. user activates a connection for the currently disconnected device
2. network manager awakes from hibernate/suspend
3. network manager is restarted (e.g. reboot)
Add a Disconnect method to generic NMDevice dbus interface; set a new private
autoconnect_inhibit flag if Disconnect method is called through dbus.
Based on this auto activation for devices gets inhibited until one
of the above events occur.
For private keys, don't just verify that the key can be read; try to
decrypt it to ensure that the password is actually valid.
Also fix a stupid {} mistake that caused crashes when setting pkcs#12
certificates because the check for PATH scheme wouldn't happen and
the private key would be NULL when trying to set the client cert to
the same data as the private key.
To be backwards compatible clients need to handle both paths to private
keys and the decrypted private key data, which is what used to get passed
in the private-key and phase2-private-key attributes of the 802.1x setting.
When moving a connection around between system-settings and user-settings,
if the private key is decrypted data, the settings service needs to store
that decrypted data somewhere so that the key can be sent to NM during
the connection process.
But we don't want to store the decrypted private key data, so we have to
re-encrypt it (possibly generating a private key password if one wasn't
sent with the decrypted data) and save it to disk, then send NM a path
to that private key during connection.
To help clients do this, and so that they don't have to carry around
multiple crypto implementations depending on whether they want to use
NSS or gnutls/gcrypt, add a helper to libnm-util.
Furthermore, I misunderstood a bunch of stuff with crypto padding when
writing the encrypt/decrypt functions long ago, so fix that up. Don't
return padding as part of the decrypted data, and make sure to verify
the padding's expected lengths and values when decrypting. Many thanks
to Nalin Dahyabhai for pointing me in the right direction.
Instead of doing this in every device subclass, do it in the NMDevice
superclass. nm_device_can_activate() already did the same logic that
each of the subclass device_state_changed() handlers were doing to
figure out whether they could do the transition from unavailable
to disconnected, so just use that in NMDevice and kill lots of code.
Keep a reference to the netlink monitor for as long as we have
signals attached to it. Also don't bother looking up the ifindex
in the carrier state signal handlers since we already have it
lying around in priv.
Previous connection-assumption code that made sure not to touch
ethernet devices when NM quit also didn't clean up after devices
that were physically removed, which was wrong.
Or really, any time the parent IP4 config is cleared which is pretty
much only when the device is going down. Avoids a warning when
nm_system_add_ip4_vpn_gateway_route() can't get the parent IP4Config
because it doesn't exist.
The secrets provider might be unrefed while processing the response,
causing a double-free when the unref triggers the weak ref notifier
and clears out the GetSecretsInfo, but then later the dbus handler
that got the response in the first place tries to free the info
explicitly. So keep the provider around while processing the result.
Instead of immediately... devices handled externally from NM (by
ModemManager or Bluez or whatever) have a slight delay in reporting
to NM that they device has been removed (due to internal housekeeping
and then pushing the event into D-Bus signals or something) and thus
when NM notices PPP failures and tries to reschedule activation
of autoconnect=true connections, it fails the reactivation because
the device actually is no longer present, but it hasn't gotten the
device-removed event from MM or Bluez yet. That sets the invalid
tag on the connection, and when the device gets replugged, the
invalid tag suppresses autoconnect.
We don't actually care when pppd goes into the 'network' phase or the
'authenticate' phase, because we're looking for the IP4 configuration
to come back, and the device is already in the IP_CONFIG state.
Handling those phases would cause the device's state to jump around
between NEED_AUTH and IP_CONFIG when we were already past that phase.
Specifically, when the PPP link went down, the device would jump from
FAILED to IP_CONFIG because pppd entered the 'network' phase when
cleaning up the link. The device would also jump from IP_CONFIG to
NEED_AUTH during the connection process when we already had secrets.
add function nm_modem_manager_has_modem_for_iface to modem-manager api
and ignore device additions in nm-manager if the iface is claimed by
modem-manager; also forget about already managed devices once they get
claimed by modem-manager.
Overload the certificate and key properties to allow paths to the
certificates and keys using a special prefix for the property data.
Add API to libnm-util for easy certificate path handling, and
documentation for NMSetting8021x.
