Re: PFkey update to get recent racoon working on NetBSD

[VANHULLEBUS Yvan <vanhu%NetBSD.org@localhost>]

On Sun, Jan 31, 2010 at 10:07:31PM -0800, John Nemeth wrote:
> On May 13,  6:21am, VANHULLEBUS Yvan wrote:
[....]
> } Second patchset is commit on FreeBSD's HEAD:
> } http://svn.freebsd.org/viewvc/base?view=revision&revision=194062
> } which mostly includes the "correct" version (well, there are still a
> } few known bugs in specific situations, I'll have to make some test
> } setups to be able to hunt them).
> 
>      I found this patchset and applied what appeared to be the
> pertinent parts.  Unfortunately, the result was that racoon couldn't
> communicate with the kernel.

Can you send me a racoon.debug and configuration files ?

You may have missed some parts of the patchset, or they may be more
differences between FreeBSD and NetBSD than what I expacted in the
PFKey interface (but I don't think so, as I already did a similar job
in the other way, from NetBSD to FreeBSD, some years ago).


> } If someone starts porting that to NetBSD (don't forget that NetBSD
> } still ships both IPSEC and FAST_IPSEC, work will need to be done
> 
>      They use common code for key management, so not a big deal.

Not exactly: they use code which mostly derivated from the same
sources, but, for example, each one has it's own key.c (in netkey for
IPSEC, and in netipsec for FAST_IPSEC).


> } twice....), please let me know, that may avoid 2 guys doing the same
> } job at the same time, and I can also give some hints, code review,
> } etc....
> 
>      Does anything need to be done with racoon?

Nothing except using HEAD (and of course recompile it, as kernel
patchset changes at least net/pfkeyv2.h).


>  Do you have a detailed
> description of the PFKey interface?

NAT-T extensions don't have standard description, and we didn't took
time to generate a detailed description of the way we use it, sorry.

But basically, the idea is that ports information for peers (I'm
talking about tunnel endpoints here, NOT traffic endpoints) MUST NOT
be sent in  SADB_EXT_ADDRESS_*, but in SADB_X_EXT_NAT_T_[S|D]PORT.


Yvan.