We trigger a new solicitation upon seeing the new token. Kernel triggers one
too, but that one is of no use to us, since the advertisement might arrive sooner
than we learn about the token change.
(cherry picked from commit 24e7ea7860)
A solicitation loop could result for two cases:
1) a router sent DNS information, then removed that information without
sending it with lifetime=0
2) two routers exist, one sending DNS information and the other not, and
the first router which sends DNS information disappears
In these cases a solicitation would be generated when the DNS information
reached 1/2 its lifetime. A router would then reply to the solicitation
without DNS information, which would then trigger another lifetime check,
which finds that the DNS info is still 1/2 lifetime. Which triggers
another solicitation, etc.
Fix this by ensuring that a solicitation is never sent less than
rtr_solicitation_interval seconds after the last one.
If a route or gateway's priority increased, the item would be added
to the array again without removing the older entry. At the same time
don't bother adding an item with a zero lifetime, since it will just
be removed again by the clean_* functions.
Instead of having it all in the Linux implementation, move all the
timeout logic and most of the processing logic into the NMRDisc
base class so that it can be used by NMFakeRDisc as well. This
will help increase testability since now we can test the timeout
and expiry logic from the fake plugin too.
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Ethernet-like interfaces aren't the only type of interfaces that can
run IPv6 but the rdisc code only returns an address if the interface's
hardware address is 6 bytes.
Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own
specifications for constructing IPv6 addresses and we should honor
those.
So instead of expecting a MAC address, let each device subclass
generate an Interface Identifier and use that for rdisc instead.
Abstract class, fake implementation and a manual testing tool for
NetworkManager's internal IPv6 router discovery module. When a real
implementation is ready, it will replace nm-ip6-manager and will be used
by nm-device.
