This issue applies to the 0.6.6 release (at least).
The implementation of the isakmp INITIAL CONTACT
message can corrupt the PF_KEY interface during phase 2
negotiations. The info_recv_initialcontact() uses the
pfkey_dump_sadb() which (can) discard kernel replies to
the getspi PF_KEY message (which is required for phase2)
To demonstrate the problem take two freshly started
racoons: one server and one roadwarrior (anonymous).
Initiate a key exchange from the road warrior. When
phase 1 completes both parties will send the INITIAL
CONTACT message before phase2 completes. The
roadwarrior will (can?) discard the getspi kernel
replies on the PF_KEY interface. This will halt the
key exchange. A second attempt will succeed since
there will be no INITIAL CONTACT message sent.
It seems to me like it is necessary to have a single
point of interface to the PF_KEY socket. Maybe via the
pfkey_handler?. Going in the "back door" with
pfkey_sadb_dump() looks like a way to guarantee broken
code. And then there is the question about whether the
SADB_DUMP message should be used at all since RFC 2367
cautions against it.