Re: PFkey update to get recent racoon working on NetBSD

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

On Jun 24,  4:34am, VANHULLEBUS Yvan wrote:
} 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 ?

     Okay, I'll send that under seperate cover.

} You may have missed some parts of the patchset, or they may be more

     Possibly.

} 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).

     Ah right.  I was working in netipsec and running regular IPSEC.
I've just updated netkey/key.c

} > } 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).

     Oops, I had updated net/pfkeyv2.h, but forgot to install it.  It's
now installed and everything has been rebuilt.  I just did a NAT-T test.
racoon no longer complains about not being able to set a key, but it is
back to the old symptom of repeatedly trying to establish phase 2.

} >  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.
} 
}-- End of excerpt from VANHULLEBUS Yvan