When key_timehandler_spd() spent over one second, the "now" argument of
key_timehandler_sad() could be older than sav->created. That caused SA
was expired immediately.
this structure is part of the kernel/user ABI and so we would need to
version the ioctl ABI again in order to remove this field. but that's
a big pain so let's just leave the field there. the problem that
was being fixed in FreeBSD related to this was a failure to locate
filter rules in certain situations, but having an unused always-zero
field there won't cause that problem.
When a machine sends a IP broadcast packet to an Ethernet interface that the
checksum offload flags are set, the packet goes through ether_output() ->
looutput() and the offload flags is cleard without calculating the checksum.
And then, ip_input() calculate the packet's checksum because it's csum_flags is
zero. It regard as bad checksum and it's dropped because the packet's ifp
is s not lo0's. Fixes this bug by passing csum_flags as "calculated and good"
when IN_LOOPBACK_NEED_CHECKSUM() is false. Adviced by ryo@.
This problem was seen when "routed -s" was used and the machine's interface's
offload flags were set. bad checksum field of "netstat -s" was increased every
30 minutes.
This driver also works as-is with a D-Link DGE-530T rev. D2 and a
TP-Link TG-3468 v3, as both match pre-existing PCI vendor and device ID
values. (It should also work with a TG-3468 v2, but would need another
vendor ID match added for that variant.) While here, also note it
supports UDP checksum offload, too.
It's been broken since we enabled dropping privs.
It's also probably the wrong place to do this, and support for
SIOCSIFINFO_IN6 will be in the next dhcpcd import.
this is needed so that glibc falls back to emulation and apps behaving
properly, since EOPNOTSUPP is a documented and expected return code, but
ENOSYS is not
right now there are no filesystems in NetBSD tree supporting the fallocate
VOP, so no point trying to map this to a native call
supposed to help with problem reported in
https://mail-index.netbsd.org/tech-kern/2019/11/03/msg025641.html
mrg