Subject: Re: Reminder that we are supporting two parallel IPsec implementations
To: None <>
From: Matt Thomas <>
List: tech-net
Date: 09/11/2003 18:53:14
On Thursday, September 11, 2003, at 05:45 PM, Jonathan Stone wrote:

>>        the code is identical in sys/netipsec.
> So if it's identical, you would accept demonstrationn of a bug against
> the sys/netipsec code as applicable to the KAME sys/netkey tree?
> If so,, the bug can be demonstrated quite easily[*].  With
> approximately 340 SAs total, setkey starts returning EAGAIN.
> For racoon, when racoon calls pfkey_dump_sadb(), (e.g., processing a
> new SA) pfke_dump_sadb calls pfkey_recv() to walk through the SA
> database, one SA at a time.  Again, at around 340 SAs, the call to
> pfkey_recv() calls recv() which sleeps forever: racoon is deadlocked,
> sleeping inside the kernel in sbwait() where it is never going to be
> woken up.
> Even if I increase ths eize of the raw queue by a factor of 8, this
> behaviour still occurs, and it occurs *at the same number of SAs*.

Note that the kernel *already* has a method to avoid the problem.
netkey should use a PF_KEY specific so_receive to dump the SADB
directly into the users buffer.  (check to see if you are doing a
dump and if so, do the uiomoves your self, otherwise just invoke
soreceive to do the heavy lifting).
Matt Thomas                     email:
3am Software Foundry              www: Cupertino, CA              
disclaimer: I avow all knowledge of this message.