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.
Since NM adds the gateway host route in the manner that's correct
for the current routing situation, we don't really want random
gateway host routes from the VPN server getting added instead.
For IPv6 autoconf, the addresses returned from NMIP6Manager will
already have been added to the interface, and if we remove and readd
them it will cause additional netlink notifications which may cause us
to think additional changes have been made. So change the
config-applying code to only remove addresses that aren't part of the
new config.
Automatic IPv6 configuration is handled by the kernel, but to
integrate it properly with NetworkManager, we need to watch what the
kernel does to see whether or not it was successful (so that we can
let the user know if there is no IPv6 router present, for example).
NMIP6Manager takes care of this.
rtnl_addr requires that all addresses have the "peer" attribute set in
order to be compared for equality, but this attribute is not normally
set. As a result, most addresses will not compare as equal even to
themselves, busting caching. We fix this for now by poking into the
guts of libnl if it is broken...
Since the new PolicyKit does away with easy checking of authorizations,
we get to implement it by ourselves, but that's OK since we can actually
use it for a lot more stuff. So add the GetPermissions call which returns
the permissions the caller actually has, and a signal informing callers
that their permissions might have changed. Hook this all up to
PolicyKit so it's useful.
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.
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.
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.
