optimization made last year. should solve PR 17867 and 10195.
IP_HDRINCL behavior of raw ip socket is kept unchanged. we may want to
provide IP_HDRINCL variant that does not swap endian.
counting mistake that causes panic - see PR 15953 and 13813.
i am unable to find the real cause of problem, so it is a shortterm workaround,
hopefully.
ipsec key is not found. rather experimental. kame 1.83 -> 1.84
nuke IPSEC_SRCSEL which does not do the right thing.
adjust state->ro if the tunnel endpoint is offlink. KAME PR 233.
kame 1.84 -> 1.85
- let ipfilter look at wire-format packet only (not the decapsulated ones),
so that VPN setting can work with NAT/ipfilter settings.
sync with kame.
TODO: use header history for stricter inbound validation
- use of IPv4 mapped address on outbound socket
- explicit port numbers via sendto().
old code grabbed port number from inpcb/in6pcb.
in the above case, old code failed to lookup ipsec policy (oops).
sync with kame.
to mention here. notable changes are like below.
kernel:
- make PF_KEY kernel interface more robust against broken input stream.
it includes complete internal structure change in sys/netkey/key.c.
- remove non-RFC compliant change in PF_KEY API, in particular,
in struct sadb_msg. we cannot just change these standard structs.
sadb_x_sa2 is introduced instead.
- remove prototypes for pfkey_xx functions from /usr/include/net/pfkeyv2.h.
these functions are not supplied in /usr/lib.
setkey(8):
- get/delete does not require "-m mode" (ignored with warning, if you
specify it)
- spddelete takes direction specification
avoid use of macros to manipulate sockaddrs (hides error case too much).
correct IPv4 packet handling when ip option is present.
preparations for ipsec policy engine upgrades.
- parse IPv6 header by using common function, ip6_{last,next}hdr.
- fix behaivior in multiple AH cases.
make strict boundary checks on mbuf chasing.
(sync with latest kame)
between protocol handlers.
ipsec socket pointers, ipsec decryption/auth information, tunnel
decapsulation information are in my mind - there can be several other usage.
at this moment, we use this for ipsec socket pointer passing. this will
avoid reuse of m->m_pkthdr.rcvif in ipsec code.
due to the change, MHLEN will be decreased by sizeof(void *) - for example,
for i386, MHLEN was 100 bytes, but is now 96 bytes.
we may want to increase MSIZE from 128 to 256 for some of our architectures.
take caution if you use it for keeping some data item for long period
of time - use extra caution on M_PREPEND() or m_adj(), as they may result
in loss of m->m_pkthdr.aux pointer (and mbuf leak).
this will bump kernel version.
(as discussed in tech-net, tested in kame tree)
itojun