friendly (there are only few hooks in the system). Make the structures
opaque and the interface more strict.
- Remove PFIL_HOOKS option by making pfil(9) mandatory.
and into in6_if_link_up.
This fixes a possible panic where link is up but not the interface.
Note that a better solution would be to listen to the routing socket
in the kernel, but I don't know how to do that.
Reachable Router tests for IFF_UP as well.
addresses as detached.
Likewise, when the link state changes to up, mark all detached IPv6
as tentative and start DAD on them.
Advertised router reachability now checks that link state is not down.
This means that when an interface link state changes, the default IPv6
router may change as well.
ip6_insertfraghdr either sets a result parameter or returns an error.
While the caller only uses the result parameter in the non-error case,
knowing that requires cross-module static analysis, and that's not
robust against distant code changes. Therfore, set ip6f to NULL
before the function call that maybe sets it, avoiding a spuruious
warning and changing the future possible bug from an unitialized
dereference to a NULL deferrence.
From "http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-00":
A host that receives an IPv6 packet which includes a Fragment
Header with the "Fragment Offset" equal to 0 and the "M" bit equal
to 0 MUST process such packet in isolation from any other packets/
fragments, even if such packets/fragments contain the same set
{IPV6 Source Address, IPv6 Destination Address, Fragment
Identification}. That is, the Fragment Header of "atomic
fragments" should be removed by the receiving host, and the
resulting packet should be processed as a non-fragmented IPv6
datagram. Additionally, any fragments already queued with the
same set {IPV6 Source Address, IPv6 Destination Address, Fragment
Identification} should not be discarded upon receipt of the
"colliding" IPv6 atomic fragment, since IPv6 atomic fragments do
not really interfere with "normal" fragmented traffic.
Depending on compiler options, this code can be involved in an
(apparently) spurious compiler warning. However, it was not
immediately obvious the the compiler was wrong.
trigger the following warning when gcc-4.5 was silent:
nd6_rtr.c: In function 'nd6_ra_input':
nd6_rtr.c:788: warning: 'ext' may be used uninitialized in this function
Eventually determined that it was not unreasonable for gcc-4.1 to
bleat in this case as there is a nasty 'goto insert' which could
indeed have resulted in an uninitialised variable use. Yay gcc 4.1.
Part 1:
nd6_purge can be called after dom_ifdetach, and if_afdata[AF_INET6] is
going to be freed and point to garbage. Make sure we check for NULL, before
taking the pointer offset.
While I am here, add an M_ZERO.
