src/sys/netkey, branch releng/6.1

MFC:

2006-01-27T21:50:11Z

rev. 1.39 sys/net/if_gre.c rev. 1.21 sys/netinet/ip_gre.c rev. 1.4 sys/netinet/ip_gre.h rev. 1.12 sys/netipsec/keysock.c rev. 1.3 sys/netipsec/keysock.h rev. 1.32 sys/netkey/keysock.c rev. 1.9 sys/netkey/keysock.h Fix stack corruptions on amd64. Vararg functions have a different calling convention than regular functions on amd64. Casting a varag function to a regular one to match the function pointer declaration will hide the varargs from the caller and we will end up with an incorrectly setup stack. Entirely remove the varargs from these functions and change the functions to match the declaration of the function pointers. Remove the now unnecessary casts. Lots of explanations and help from: peter PR: amd64/89261

MFC: Use sparse initializers for "struct domain" and "struct protosw".

2005-11-16T10:31:23Z

MFC: scope cleanup. with this change

2005-11-04T20:26:16Z

- 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. sys/net/if_gif.c: 1.53 sys/net/if_spppsubr.c: 1.120 sys/netinet/icmp6.h: 1.19 sys/netinet/ip_carp.c: 1.28,1.29 sys/netinet/ip_fw2.c: 1.107 sys/netinet/tcp_subr.c: 1.230,1.231,1.235 sys/netinet/tcp_usrreq.c: 1.125 sys/netinet6/ah_core.c: 1.26 sys/netinet6/icmp6.c: 1.63,1.64 sys/netinet6/in6.c: 1.52 sys/netinet6/in6.h: 1.38 sys/netinet6/in6_cksum.c: 1.11 sys/netinet6/in6_ifattach.c: 1.27 sys/netinet6/in6_pcb.c: 1.63 sys/netinet6/in6_proto.c: 1.33 sys/netinet6/in6_src.c: 1.31,1.32 sys/netinet6/in6_var.h: 1.22 sys/netinet6/ip6_forward.c: 1.29 sys/netinet6/ip6_input.c: 1.83 sys/netinet6/ip6_mroute.c: 1.30 sys/netinet6/ip6_output.c: 1.95 sys/netinet6/ip6_var.h: 1.33 sys/netinet6/ipsec.c: 1.43 sys/netinet6/mld6.c: 1.21 sys/netinet6/nd6.c: 1.50 sys/netinet6/nd6_nbr.c: 1.30 sys/netinet6/nd6_rtr.c: 1.27 sys/netinet6/raw_ip6.c: 1.54 sys/netinet6/route6.c: 1.12 sys/netinet6/scope6.c: 1.13,1.14,1.15 sys/netinet6/scope6_var.h: 1.5 sys/netinet6/udp6_output.c: 1.23 sys/netinet6/udp6_usrreq.c: 1.55 sys/netkey/key.c: 1.72,1.73

MFC 1.74: SADB_UPDATE did not return an error when key length is invalid.

2005-09-03T16:13:05Z

Approved by: re (scottl)

fixed an unexpected addr/port matching failure in IPv6 SA management

2005-01-10T13:06:42Z

PR: kern/72393 MFC after: 3 days

/* -> /*- for license, minor formatting changes

2005-01-07T01:45:51Z

support TCP-MD5(IPv4) in KAME-IPSEC, too.

2004-11-08T18:49:51Z

MFC after: 3 week

Initialize struct pr_userreqs in new/sparse style and fill in common

2004-11-08T14:44:54Z

default elements in net_init_domain(). This makes it possible to grep these structures and see any bogosities.

Merge netipsec/key.c:1.17 into KAME pfkey implementation:

2004-09-30T00:49:55Z

date: 2004/09/26 02:01:27; author: sam; state: Exp; lines: +0 -5 Correct handling of SADB_UPDATE and SADB_ADD requests. key_align may split the mbuf due to use of m_pulldown. Discarding the result because of this does not make sense as no subsequent code depends on the entire msg being linearized (only the individual pieces). It's likely something else is wrong here but for now this appears to get things back to a working state. Submitted by: Roselyn Lee This change was also made in the KAME CVS repository as key.c:1.337 by itojun.

The KAME IPSEC implementation at one point used its own pseudo-random

2004-09-02T20:14:03Z

number generator, which was re-seeded via a timeout. Now centralized randomness/entropy is used, we can garbage collect the timeout and re-seeding code (which was largely a no-op). Discussed with: itojun, suz, JINMEI Tatuya < jinmei at isl dot rdc dot toshiba dot co dot jp >