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].
If there was an existing dhclient config file, don't leak it when
merging to the new configuration.
Found by Mathieu Trudel-Lapierre <mathieu@canonical.com>
Commit 217c5bf6ac fixed processing of unix
signals: signals are blocked in all threads and a dedicated thread handles the
signals using sigwait().
However, the commit forgot that child processes inherit signal mask as well.
That is why we have to unblock signals for child processes we spawn from NM, so
that they can receive signals.
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.
When NM was registering all of its enum types by hand, it was using
NamesLikeThis rather than the default names-like-this for the "nick"
values. When we switched to using glib-mkenums, this resulted in
dbus-glib using different strings for the D-Bus error names, causing
compatibility problems.
Fix this by using glib-mkenums annotations to manually fix all the
enum values back to what they were before. (This can't be done in a
more automated way, because the old names aren't 100% consistent. Eg,
"UNKNOWN" frequently becomes "UnknownError" rather than just
"Unknown".)
Rather than generating enum classes by hand (and complaining in each
file that "this should really be standard"), use glib-mkenums.
Unfortunately, we need a very new version of glib-mkenums in order to
deal with NM's naming conventions and to fix a few other bugs, so just
import that into the source tree temporarily.
Also, to simplify the use of glib-mkenums, import Makefile.glib from
https://bugzilla.gnome.org/654395.
To avoid having to run glib-mkenums for every subdirectory of src/,
add a new "generated" directory, and put the generated enums files
there.
Finally, use Makefile.glib for marshallers too, and generate separate
ones for libnm-glib and NetworkManager.
So that dhclient will, in turn, pass it to the action script
(the action script tries to send a DBus signal to NetworkManager
over the system bus).
Dhclient "execve"s the action script with a hand-constructed environment
that only includes specific variables, plus whatever is passed to
dhclient with "-e".
As far as I know, dhcpcd has no option equivalent to dhclient's "-e".
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.
If the client was disabled with --with-dhclient=no or
--with-dhcpcd=no, then it's corresponding _PATH will be an empty
string. In that case we want to ignore that client completely
since it was disabled at build time.
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.
