[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PFkey update to get recent racoon working on NetBSD
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
} 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
Main Index |
Thread Index |