As long as at least one IP config method completes, and as long as
methods that the user required to complete do complete, allow the
connection to complete.
When this property is TRUE, IP configuration can continue as long
as at least on IP configuration type succeeds. This allows
connections to networks where the user does not necessarily know
whether the network supports IPv4 or IPv6 and does not require
that both complete succesfully.
Since most of the time the user doesn't really care what type
of connectivity they have, as long as they have *some* connectivity,
this allows better "Just Works" behavior as long as the system
settings plugins and connection editors/applets use the right
defaults.
Suggested defaults for may-fail are:
IPv4: no (ie, require IPv4 connectivity)
IPv6: yes (ie, do not require IPv6 connectivity)
Users who require a specific type of connectivity are probably
knowlegable enough to check the box as needed for their network.
When the client exits it may take a short amount of time for the
dhclient hook script to deliver the options to NetworkManager; so
we need to keep the client object around a bit (so we know what
NMDHCPClient the options getting delivered are for). If we don't,
the DHCPManager will dispose of the DHCPClient object and then
when the options come in, it can't match up the PID from the
options with the PID of an existing NMDHCPClient. So put the
clients on a removal timer that keeps them around for a bit before
we let the manager dispose of them.
Since we're keeping the PID around too instead of zeroing it when
the client exits (for the reason above), track whether the client
is really dead yet so we don't indiscriminately kill a random
process that happens to re-use the PID.
Ignore early exits of the client in info-only mode; since there is
no address lease the client doesn't need to stick around after
getting DNS/etc options from the server.
Clients in IPv6 info-only mode may exit after getting a response
from the server, since there are no leases involved in info-only
mode. To ensure that the client's options are received when the
event comes in (which could be after we get the child watch
callback for the exit) we still need the client's PID.
Stage 1 gets overridded by most device subclasses and it turns out
they don't every chain back up to NMDevice's stage1 implementation.
It's a bit complicated to make them all do that, so for now just
move the IPv6 address config a bit later.
The RA interval is configurable on the router and we don't want
to miss one. 20s is still a lot less than we allow for DHCP so
the latency isn't that big of an issue.
This reverts commit 3d69429a1e.
Apparently the 'netdev' group rules aren't as widespread anymore
and Debian ships with ConsoleKit by default, and thus can
use at_console.
Two things:
1) we need to bounce IPv6 on the interface because otherwise the
kernel won't start listening for new RAs. So code gets added
to handle the 'disable_ipv6' /proc/sys/net/ipv6 parameter for
each interface.
2) Second, we need to grab a default route (if we find one) before
reading addresses, so that we can add it to each address that we
get out of the kernel. Most of the time we'll get an -EEXIST error
when adding address, but that's OK since we're just trying to add
the same route back that the kernel already added from the RA. We
also need to make sure the route and address caches are up-to-date
otherwise we won't get a complete picture of the routing table.
