The NM 'iface' isn't always the IP iface (like for modems) so
to avoid a warning, only flush routes and addresses on deactivate
when the iface can actually handle it.
It was somewhat pointless since the IP config is always known when
stage4 gets scheduled, so why not just pass the config to stage5
immediately? Also helps consolidate the v4/v6 failure handling
logic and makes the operational flow clearer where both v4 and
v6 are active and proceeding in parallel.
Once we've sent a method call over DBus requesting that the modem be
disabled, we should assume that the modem is disabled unless we hear
otherwise. Otherwise, code that checks the modem state immediately
after it gets disabled might think that it's enabled when it almost
certainly is not.
While this should never happen while the PPP manager is alive, modems
can switch their IP method while alive, since the net port is sometimes
discovered after the serial ports have been. This happens for some
devices that have separate drivers for the net and serial sides, like
ZTE Icera-based devices (cdc-ether and cdc-acm) and newer Sierra
devices (sierra and sierra-net). Just be paranoid here and ensure
that the PPP manager gets cleaned up.
Partial attempt at fixing lp:752143
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.
It's the thing that owns the secrets anyway, and it simplifies things to
have the secrets handling there instead of half in NMActRequest and
half in NMManager. It also means we can get rid of the ugly signals
that NMSettingsConnection had to emit to get agent's secrets, and
we can consolidate the requests for the persistent secrets that the
NMSettingsConnection owned into NMSettingsConnection itself instead
of also in NMAgentManager.
Since the NMActRequest and the NMVPNConnection classes already tracked
the underlying NMSettingsConnection representing the activation, its
trivial to just have them ask the NMSettingsConnection for secrets
instead of talking to the NMAgentManager. Thus, only the
NMSettingsConnection now has to know about the agent manager, and it
presents a cleaner interface to other objects further up the chain,
instead of having bits of the secrets request splattered around the
activation request, the VPN connection, the NMManager, etc.
When a user makes an explicit request for secrets via GetSecrets
or activates a device, don't ask other users' agents for secrets.
Restrict secrets request to agents owned by the user that made the
initial activate or GetSecrets request.
Automatic activations still request secrets from any available agent.
Given connection details, complete the connection as well as possible
using the given specific object and device, add it to system
settings, and activate it all in one method.
Instead of a bizare mechanism of signals back to the manager
object that used to be required because of the user/system settings
split, let each place that needs secrets request those secrets
itself. This flattens the secrets request process a ton and
the code flow significantly.
Previously the get secrets flow was something like this:
nm_act_request_get_secrets ()
nm_secrets_provider_interface_get_secrets ()
emits manager-get-secrets signal
provider_get_secerts ()
system_get_secrets ()
system_get_secrets_idle_cb ()
nm_sysconfig_connection_get_secrets ()
system_get_secrets_reply_cb ()
nm_secrets_provider_interface_get_secrets_result ()
signal failure or success
now instead we do something like this:
nm_agent_manager_get_secrets ()
nm_agent_manager_get_secrets ()
request_start_secrets ()
nm_sysconfig_connection_get_secrets ()
return failure or success to callback
Use the interfaces kernel index when we can to avoid unecessary
iface->index lookups; and let callers figure out which address
family they really want to flush.
Some stuff we build (the DHCP manager) gets built independently
so that we can use it for unit tests. For that, we need to build
the logging bits separately too, since the independent DHCP
library can't use them if they are embedded in NM.
Due to various ordering issues in ModemManager, when the Enable()
call fails because a PIN is required, MM will disable the modem
and *then* complete the dbus call. That means that NM gets the
Enable property change before the Enable() call completes, and NM
would then transition the device to DISCONNECTED. What we
really want to do is get the response from MM and then figure out
whether to fail activation or get secrets, not go to DISCONNECTED.
To fix this, ignore Enabled property changes to FALSE while
activating so we can handle it ourselves. There are still a few
fixes left in nm-applet to make the secrets request for PINs work
on-the-fly, but saved in the connection works fine.
