If a new device wasn't supported, it gets destroyed by the
NMDevice constructor() method. But in the constructor paths
the DHCP manager isn't created yet, and so we attempt to unref
a non-existent DHCP manager. Usually just a harmless warning,
but apparently a crash sometimes.
DHCPv6 doesn't really use broadcast; instead clients use reserved
multicast addresses to talk to the server. ff02::1:2 (link scope)
and ff05::1:3 (site scope) are used. This means the routing table
has to have a route that can handle outgoing traffic to these
addresses, which is ff00::/8. The kernel sometimes adds one for us,
so we need to (a) make sure we don't tear that route down, and
(b) that if it's not there before we start DHCPv6, that we add it.
Otherwise dhclient complains about not being able to send outgoing
traffic from it's send_packet6() function with "no route to host".
It will then use an expired lease, which causes NM to assign that
leases IP address to the interface, whcih causes the kernel to
assign the required ff00::/8 route, and then dhclient performs a
renew (since the expired lease has expired of course) and then
everything works out in the end. But the latency sucks.
So make DHCPv6 faster by ensuring that dhclient has the routes
it needs before we start the DHCP session.
This reverts commit b172519045.
When something like NTP updates the system clock, that can cause
dhclient to expire the lease, and at that point we just want NM
to let dhclient re-aquire the lease instead of failing the
whole connection.
Monitor the kernel firmware directory (set at configure-time with
--with-kernel-firmware-dir=<path>) for changes, and if there
are any, try bringing up devices that are missing firmware.
This commit implements MAC cloning feature in NetworkManager. To support that,
'PermHwAddress' property is added into *.Device.Wired and *.Device.Wireless
interfaces. The permanent MAC address is obtained when creating the device, and
is used for 'locking' connections to the device. If a cloned MAC is specified
in connection to be activated, the MAC is set to the interface in stage1. While
disconecting, the permanent MAC is set back to the interface.
Track missing firmware and ensure the device can't be used when firmware
is missing. Add a property for missing firmware so that clients can do
something intelligent with this information.
All IPv6 enabled sites are expected to provide router advertisement
support apparently. If standalone DHCP is really used in the wild
then we can clearly re-enable it later.
Use the interfaces kernel index when we can to avoid unecessary
iface->index lookups; and let callers figure out which address
family they really want to flush.
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.
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.
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.
Where we can do so, let's use ifindex since that's actually unique
and doesn't change when the interface name changes. We already use
ifindex in a bunch of places, and netlink *only* uses ifindex, so
this will make it easier later when we move over to ifindexes fully.
nm_device_set_use_dhcp() and nm_device_get_use_dhcp() were somewhat
confusing and don't really reflect the new DHCP architecture with
NMDHCPClient. Now that timeout and state signals are specific to
the NMDHCPClient it doesn't make sense to check for DHCP use
in the callbacks for those signals since they'll never get called
if DHCP isn't in use. We might as well just keep the DHCP manager
around and check whether a DHCP client instance exists when we need
to figure out whether DHCP is in use.
Since the same interface could be used for both DHCPv4 and DHCPv6 we
can't just use 'iface' for tracking DHCP client lease changes. Instead
use a generated client ID, and track DHCP events based on the client's
PID instead of interface name.
