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.
NM shouldn't really be calling Enable(False) except in response to
direct user requests to turn off WWAN, much like rfkill, since
Enable(False) /is/ essentially rfkill for 3G. Instead, we should
be powering up the modem before trying to use it, and only
disconnecting after we're done. Let the user do enable/disable
when they want to.
This also fixes issues with other devices like GPS potentially
using the modem-manager at the same time as NM and ensures that NM
won't punch the modem in the face while GPS is using it.
Previously, ppp code would flip device state to _NEED_AUTH before
asking for secrets update; this is not the case anymore after landing
of f28a0df4a66e8f6c98327691c9c90df0604bbd28; hence, we need to
allow update of secrets in all ACTIVATING stages.
This patch updates this behaviour for all device classes with ppp
support.
NM didn't pass it to MM anyway, so it was mainly unused, but the band settings
were still wrong. Fix that (and still preserve ABI) by adding a new property
for allowed bands that can actually hold all the bands instead of limiting
to 16-bits. Clean up some of the deprecation stuff at the same time to make
it clearer what's deprecated and what to do about it.
So that Bluetooth can use them. They used to be NMDevice subclasses, but
we need them to be generic objects that both bluetooth and the normal
modem stack can use. All because GObject can't do multiple inheritance,
but that would probably be even messier.
So now that we have generic modem objects, we can create the actual
NMDevice subclasses that will wrap them for non-BT modems, and then
also have NMDeviceBt wrap them too for DUN.
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.
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.
With the addition of IPv6, both v4 and v6 configuration are run in
parallel, and when both have finished, then activation can proceed.
Unfortunately, two of the 3 users of PPP (PPPoE and 3G) ran PPP at
stage2, and when the PPP IPv4 config was received, jumped directly
to activation stage4. That caused the IPv6 code never to run, and
thus we hung at stage4 waiting for it to complete when nothing had
started it in the first place.
Instead, move PPP to stage3 so that
nm_device_activate_stage3_ip_config_start() can kick off both v4
and v6 IP code and we can successfully complete IP configuration
in all cases. PPP previously being in stage2 was an artifact of
the more simplistic pre-IPv6 configuration code where it didn't
matter if you skipped stage3.
