- struct timeval time is gone
time.tv_sec -> time_second
- struct timeval mono_time is gone
mono_time.tv_sec -> time_uptime
- access to time via
{get,}{micro,nano,bin}time()
get* versions are fast but less precise
- support NTP nanokernel implementation (NTP API 4)
- further reading:
Timecounter Paper: http://phk.freebsd.dk/pubs/timecounter.pdf
NTP Nanokernel: http://www.eecis.udel.edu/~mills/ntp/html/kern.html
case:
<driver>_ioctl(ifp, SIOCSIFADDR, struct ifreq *)
where it should be calling:
<driver>_ioctl(ifp, SIOCSIFADDR, struct ifaddr *)
and "Bad Things Happen (TM)"
Returning an error is good enough because none of the drivers handle INET6.
The problem here is that handling SIOCSIFADDR is a kludge. The ioctl gets
passed a struct ifreq * from userland, but then in the control routines
SIOCSIFADDR is handled "specially", and we call:
ifp->if_ioctl(ifp, SIOCSIFADDR, struct ifaddr *)
directly with the ifaddr we computed for that interface. It would be nice
if we called the ioctl routine if the original struct ifreq, and computed
the ifaddr, or passed it directly. This way all the ioctls would be treated
the same way, and we would not have the problem of pointer overloading.
* RFC 3542 isn't binary compatible with RFC 2292.
* RFC 2292 support is on by default but can be disabled.
* update ping6, telnet and traceroute6 to the new API.
From the KAME project (www.kame.net).
Reviewed by core.
value. Previously the router should treat the recieved router
advertisement as having a 0 router lifetime. The RFC now says that the
router should treat the "Reserved" field the same way as if it was the
medium (default) preference.
From the KAME project via SUZUKI Shinsuke.
RFC4191
- supports host-side router-preference
RFC3542
- if DAD fails on a interface, disables IPv6 operation on the
interface
- don't advertise MLD report before DAD finishes
Others
- fixes integer overflow for valid and preferred lifetimes
- improves timer granularity for MLD, using callout-timer.
- reflects rtadvd's IPv6 host variable information into kernel
(router only)
- adds a sysctl option to enable/disable pMTUd for multicast
packets
- performs NUD on PPP/GRE interface by default
- Redirect works regardless of ip6_accept_rtadv
- removes RFC1885-related code
From the KAME project via SUZUKI Shinsuke.
Reviewed by core.
logic, and then call nd6_llinfo_settimer. Instead, call
nd6_llinfo_settimer immediately.
This should cause no functional change. I've been running this
patch for months.
In ipcomp6_input(), check 'md' not 'm' after a call to m_pulldown(): 'm'
may be a stale pointer at this point, and we're interested in whether or
not m_pulldown() failed.
Noticed by: Coverity Prevent analysis tool
- most of the kernel code will not care about the actual encoding of
scope zone IDs and won't touch "s6_addr16[1]" directly.
- similarly, most of the kernel code will not care about link-local
scoped addresses as a special case.
- scope boundary check will be stricter. For example, the current
*BSD code allows a packet with src=::1 and dst=(some global IPv6
address) to be sent outside of the node, if the application do:
s = socket(AF_INET6);
bind(s, "::1");
sendto(s, some_global_IPv6_addr);
This is clearly wrong, since ::1 is only meaningful within a single
node, but the current implementation of the *BSD kernel cannot
reject this attempt.
- and, while there, don't try to remove the ff02::/32 interface route
entry in in6_ifdetach() as it's already gone.
This also includes some level of support for the standard source
address selection algorithm defined in RFC3484, which will be
completed on in the future.
From the KAME project via JINMEI Tatuya.
Approved by core@.
pass it to in_pcbbind() so that can allocate a low numbered port
if setsockopt() has been used to set IP_PORTRANGE to IP_PORTRANGE_LOW.
While there, fail in_pcbconnect() if the in_pcbbind() fails - rather
than sending the request out from a port of zero.
This has been largely broken since the socket option was added in 1998.
m0. But m0 may be freed later, so trying to use sip6 at the end of this
function is wrong. My guess is that we want to reference the data area
of m (the mbuf about to be send) instead at this point.
Fix a panic on Xen (where a data area of a mbuf may be unmapped when the
mbuf is freed), and probably potential data/pool corruption in other cases.
over IPsec tunnels.
I have changed the default to 2 [copy]. I've verified that this works with
all my IPSEC setups, and this change has also been discussed in tech-net.