In message <20040522001518.C623A17921@portal.hamachi.org>Bill Sommerfeld writes

>For what it's worth, I made a very similar-in-concept fix to Solaris
>PF_KEY in the past year.
>
>Before the fix, Solaris would ensure delivery of both the start and
>the end of the SADB_DUMP but might truncate messages from the middle.

Bill,

I want to re-emphasise something. That Solaris behaviour you describe
from before your does not (repeat not), have the bug I'm talking about.

What I see KAME_PF do is, it delivers some prefix of the DUMP
responses, up to some point; then it drops everything after that
point -- including the last DUMP response message.

That behaviour leaves the (KAME-coded) apps with no way to detect
truncation, and no way to detect the end of the dump stream (and thus
no way to break the loop which issues recv()s, looking for the last
DUMP response message, which bears the `end-of-stream' marker).  The
KAME apps then deadlock, because they never see that last record with
the end-of-stream marker.

Appealing to RFC-2367 to save *that*, is, well, ...  choose your own
opinion.

Kudos to your office neighbour that Solaris didn't have that
particular bug, even before your fix.


--Jonathan