#
272461 |
|
02-Oct-2014 |
gjb |
Copy stable/10@r272459 to releng/10.1 as part of the 10.1-RELEASE process.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
220206 |
|
31-Mar-2011 |
fabient |
Optimisation in IPSEC(4): - Remove contention on ISR during the crypto operation by using rwlock(9). - Remove a second lookup of the SA in the callback.
Gain on 6 cores CPU with SHA1/AES128 can be up to 30%.
Reviewed by: vanhu MFC after: 1 month
|
#
194062 |
|
12-Jun-2009 |
vanhu |
Added support for NAT-Traversal (RFC 3948) in IPsec stack.
Thanks to (no special order) Emmanuel Dreyfus (manu@netbsd.org), Larry Baird (lab@gta.com), gnn, bz, and other FreeBSD devs, Julien Vanherzeele (julien.vanherzeele@netasq.com, for years of bug reporting), the PFSense team, and all people who used / tried the NAT-T patch for years and reported bugs, patches, etc...
X-MFC: never
Reviewed by: bz Approved by: gnn(mentor) Obtained from: NETASQ
|
#
193731 |
|
08-Jun-2009 |
zec |
Introduce an infrastructure for dismantling vnet instances.
Vnet modules and protocol domains may now register destructor functions to clean up and release per-module state. The destructor mechanisms can be triggered by invoking "vimage -d", or a future equivalent command which will be provided via the new jail framework.
While this patch introduces numerous placeholder destructor functions, many of those are currently incomplete, thus leaking memory or (even worse) failing to stop all running timers. Many of such issues are already known and will be incrementaly fixed over the next weeks in smaller incremental commits.
Apart from introducing new fields in structs ifnet, domain, protosw and vnet_net, which requires the kernel and modules to be rebuilt, this change should have no impact on nooptions VIMAGE builds, since vnet destructors can only be called in VIMAGE kernels. Moreover, destructor functions should be in general compiled in only in options VIMAGE builds, except for kernel modules which can be safely kldunloaded at run time.
Bump __FreeBSD_version to 800097. Reviewed by: bz, julian Approved by: rwatson, kib (re), julian (mentor)
|
#
191599 |
|
27-Apr-2009 |
bz |
key_gettunnel() has been unsued with FAST_IPSEC (now IPSEC). KAME had explicit checks at one point using it, so just hide it behind #if 0 for now until we are sure if we can completely dump it or not.
MFC after: 1 month
|
#
139823 |
|
06-Jan-2005 |
imp |
/* -> /*- for license, minor formatting changes
|
#
135947 |
|
29-Sep-2004 |
sam |
Add missing locking for secpolicy refcnt manipulations.
Submitted by: Roselyn Lee
|
#
119643 |
|
01-Sep-2003 |
sam |
Locking and misc cleanups; most of which I've been running for >4 months:
o add locking o strip irrelevant spl's o split malloc types to better account for memory use o remove unused IPSEC_NONBLOCK_ACQUIRE code o remove dead code
Sponsored by: FreeBSD Foundation
|
#
105197 |
|
16-Oct-2002 |
sam |
"Fast IPsec": this is an experimental IPsec implementation that is derived from the KAME IPsec implementation, but with heavy borrowing and influence of openbsd. A key feature of this implementation is that it uses the kernel crypto framework to do all crypto work so when h/w crypto support is present IPsec operation is automatically accelerated. Otherwise the protocol implementations are rather differet while the SADB and policy management code is very similar to KAME (for the moment).
Note that this implementation is enabled with a FAST_IPSEC option. With this you get all protocols; i.e. there is no FAST_IPSEC_ESP option.
FAST_IPSEC and IPSEC are mutually exclusive; you cannot build both into a single system.
This software is well tested with IPv4 but should be considered very experimental (i.e. do not deploy in production environments). This software does NOT currently support IPv6. In fact do not configure FAST_IPSEC and INET6 in the same system.
Obtained from: KAME + openbsd Supported by: Vernier Networks
|