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.
Ensure that updating the connection really sends out the updated signal, and
that trying to update/delete a read-only connection over D-Bus returns an
error.
instead of an NMSettingsConnectionInterface, because we won't always have an
object that implements NMSettingsConnectionInterface. Plus, since NMConnection
is a prerequisite of NMSettingsConnectionInterface, the NMConnection will
always be there anyway.
Since NMSettingsConnectionInterface already has NM_TYPE_CONNECTION as a prerequisite,
which already implements these properties, it's pointless to have them on
NMSettingsConnectionInterface too.
Make NMSettingsService implement most of the NMSettingsInterface
API to make subclasses simpler, and consolidate exporting of
NMExportedConnection subclasses in NMSettingsService instead of
in 3 places. Make NMSysconfigSettings a subclass of
NMSettingsService and save a ton of code.
Mark activation requests that contain connections to be assumed,
and use that to short-circuit various parts of the activation
process by not touching various device attributes, since they
are already set up. Also ensure the device is not deactivated
when it initially becomes managed, because that would kill the
connection we are about to assume.
The old NMExportedConnection was used for both client and server-side classes,
which was a mistake and made the code very complicated to follow. Additionally,
all PolicyKit operations were synchronous, and PK operations can block for a
long time (ie for user input) before returning, so they need to be async. But
NMExportedConnection and NMSysconfigConnection didn't allow for async PK ops
at all.
Use this opportunity to clean up the mess and create GInterfaces that both
server and client objects implement, so that the connection editor and applet
can operate on generic objects like they did before (using the interfaces) but
can perform specific operations (like async PK verification of callers) depending
on whether they are local or remote or whatever.
This allows a device (or a companion) to signal that it is not a good
time for a specific device to autoconnect to a network.
The OLPC mesh device will use this to prevent automatic connection
to WLAN networks while the mesh device is active.
