This should usually not happen, but we can still see this case, e.g., if we have manually configured the exact address to be configured. (this is an unexpected side effect of a clarification in rfc2462bis)
attach is all done).
…e when net.inet.ip.rtexpire is 0
…h()/if_detach(), respectively) to cover future extentions in ifnet->if_afdata. This may be a dirty hack, but equivalent fix need be merged to *BSDs, to prevent kernel crash in IPv6 multicast forwarding at PIM-SM Rendezvous-Point router.
(M_DONTWAIT(mbuf flag) is equal to M_NOWAIT(malloc() flag) in every BSD except freebsd5, so this problem occurs only in freebsd5)
… multiple mbufs and there's no assumption made about m->m_len here. from freebsd
this could result in an unexpected code path. consider the case 0x80000000 is given as a "port" with AI_NUMERICSERV.