DHCPv6 IA_NA assignments do not contain a prefix length, they are for a
single address (/128) only. However, the ISC DHCPv6 client incorrectly
assumes IA_NA assignments come with a implicit prefix length of /64, and
passes this incorrect information on to NetworkManager, which adds this
prefix as a on-link route. This will cause communication failures in
certain networks, for example NBMA networks, and in organisations using
longer prefix lengths than /64 for their LANs. For more discussion
regarding this problem, see RFC 5942 section 5.
This patch makes NM ignore the false prefix length attribute provided by
the ISC DHCPv6 client, instead setting it to a /128 (single address) in
all cases. Note that this does not preclude an on-link prefix from being
added by NM if it is being advertised in the correct way, i.e., by
including a Prefix Information Option with the L flag set in an ICMPv6
Router Advertisement.
For what it's worth I've also sent a patch to ISC to change the hard-
coded implicit prefix length value from /64 to /128 in [ISC-Bugs #29468].
The DHCP code usually ignores dhclient state transitions to the
same state it's currently in. This turns out to be wrong, since
dhclient will use the same reason code (which NM uses for the
state value) for operations like RENEW and REBIND. i.e. you'll
see states like this:
BOUND
RENEW (first renew)
RENEW (second renew)
RENEW (third renew)
etc
Therefore to ensure we trigger dispatcher scripts and internal
housekeeping code for renewals we need to make sure we process
these events even though they use the same state as the previous
event.
The DHCP code usually ignores dhclient state transitions to the
same state it's currently in. This turns out to be wrong, since
dhclient will use the same reason code (which NM uses for the
state value) for operations like RENEW and REBIND. i.e. you'll
see states like this:
BOUND
RENEW (first renew)
RENEW (second renew)
RENEW (third renew)
etc
Therefore to ensure we trigger dispatcher scripts and internal
housekeeping code for renewals we need to make sure we process
these events even though they use the same state as the previous
event.
Otherwise it doesn't auto-scan and we get no network list. As a later
optimization, we could detect this, call iwmx_sdk_get_connected_network()
to get the current NSP, match that up with a connection, and "assume"
the connection like we do for Ethernet devices.
Add support for Fedora's dhclient's built-in RFC3442 classless static
routes format.
Since the Fedora format uses the same name as the dhcpcd format, we
need to refactor a bunch of the code to ensure we can distinguish
between the types. Do this at runtime now by consolidating the
classless static routes parsing code into the DHCP Client base class
and rework the unit tests so that we can test all variations of the
classless static route parsing code at the same time.
This also fixes a bug with the dhcpcd classless static route
gateway handling that would return the wrong gateway address.
Many thanks to Jiri Popelka from Red Hat for the initial patch
and explanations.
config.h defines _GNU_SOURCE, which in turn defines the bits necessary
for kill, isblank, and isascii. So wherever we use those, we need
to make sure config.h is included.
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.
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.
