The RDNSS and DNSSL failure cases wouldn't clear out the idle
handler of a previous success (if that success hadn't fired yet);
it seems pointless to signal success and then immediately fail.
Second, it would cause a dangling GSource if the device was
removed or NM quit at the right time.
This patch makes NM set the "accept_ra" sysctl to 1 rather than 2. This
causes the kernel to process RAs even if it configured to forward IPv6
traffic on the interface in question.
IPv6 forwarding would likely be enabled on a host running virtualised
operating systems with virtualised network adapters, for example. This
should not prevent NM from successfully activating IPv6 on a
NM-controlled interface configured with IPv6 mode Auto.
Verifies that provided message consists of at least the link message
header. nlmsg_parse() does this so it needs to be called prior to
accessing the message contents.
Like if the IP interface doesn't have an ifindex yet. Previously
the connection would just go merrily along and wait for IPv6 to
complete even though it had already failed. Happens if you try
to do IPv6 on mobile broadband connections, which we'll add support
for later.
RFC6101 adds the DNS Search List option to router advertisements. This
allows stateless configuration of suffixes to try when doing DNS lookups.
Make sure we catch these when provided by the kernel and reconfigure
things appropriately.
NOTE: this commit depends on a kernel patch:
http://marc.info/?l=linux-netdev&m=129216173321352&w=2
RFC5006/RFC6106 specifies fairly clearly how to handle multiple RDDNS options.
Unfortunately the previous code didn't deal with this and hence would
misbehave in all but the simplest setups. The new code should be fully
compliant with the following exceptions:
- Router lifetime not respected
- No "sufficient number" management.
- DHCPv6 servers might not be prioritised over RDDNS ones.
Pad the DNS server expiry somewhat to give a bit of slack in cases
where one RA gets lost or something (which can happen on unreliable
links like wifi where certain types of frames are not retransmitted).
The kernel apparently caches the value and will send Managed/Other flags
in the newlink message even if the router is no longer reachable and
and RA hasn't been received for a while. So we need to make sure we
check for IF_RA_RCVD before paying attention to Managed/Other.
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.
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.
Poll the device's IPv6 flags so we're notified when the RA has
been parsed and what the flags are. Only when that's complete
and the device's target state has been reached (or Managed mode
was indicated by the RA) should we continue with IP configuration.
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.
The RA flags aren't in the link flags, they are in the special
PROTINFO flags that the IPv6 stack sends. To get these, because
libnl doesn't have native support for them, we get to parse the
netlink messages directly. Furthermore, the PROTINFO message
isn't sent unless it's explicitly requested with a
RTM_GETLINK/AF_INET6 message, meaning we get to poll for it
periodically.
So switch over to the netlink monitor object (killing a lot of
duplicate code) and start requesting the PROTINFO bits from
netlink.
