On 10/Jan - 12:23, Jonathan A. Kollasch wrote: > On Mon, Jan 09, 2012 at 05:58:07PM +0100, Matthias Drochner wrote: > > > > I've just made FAST_IPSEC the default implementation which gets > > used if the IPSEC kernel option is present. > > In common setups, it should work at least as good as the old > > (KAME) implementation. The new code has the potential to make > > use of crypto acceleration hardware, and to use multiple > > CPU cores. It also has some crypto algorithms updated, so > > it might solve interoperability problems (eg. if using > > AH with SHA2, or Camellia). > > There are still some open problems, in particular if PMTU > > discovery is used through a tunnel, or with IPv6 extension > > headers(*). > > > > The old KAME implementation is still available through > > the KAME_IPSEC kernel option. The old IPSEC_ESP option > > is meaningless with (FAST_)IPSEC (ESP is always enabled) > > but still in effect with KAME_IPSEC. > > > > I'd very much appreciate reports (positive or negative) > > about interoperability with non-NetBSD systems. > > > > best regards > > Matthias > > > > (*)There is a patch (by Arnaud Degroote) which adds proper > > extension header handling for IPv6. I have it ready for > > commit, I just don't know a good way to test it. If > > you can help, please speak up. > > i386 ALL is broken, both ipsec and pf have a 'union sockaddr_union'. By chance, it is the same definition, so probably not too hard to fix > > Also, I doubt kern/34843 is fixed yet either. the null pointer deferencing ? Do you have any recent backtrace and / or a repeatable scenario ? I will try to take a look, but my January month will be quite busy. -- Arnaud Degroote
Attachment:
signature.asc
Description: Digital signature