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.
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.
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.
Like the OLPC mesh interface, which uses the same actual MAC & radio
as the OLPC wifi device, and thus when mesh is active the wifi
shouldn't be scanning.
The DBusGProxy was getting destroyed after all the ListConnections calls
were completed, and thus the dbus match was removed, and the signals
weren't getting reflected back up into NM to be handled. Fix that by
attaching the DBusGProxy to the NMConnection it represents to ensure it
lives until that NMConnection dies.
Found by Ricardo Salveti de Araujo <ricardo.salveti@openbossa.org>
The link cache was updated immediately, but the carrier state signals
were emitted a lot later, when the cache data was already stale. So
just update the cache at the same time we emit the signals. The
carrier-state-request stuff wasn't originally converted to deferred
for any netlink-specific reason, just to smooth the initial device
creation process in NM.
