Subject: Re: Reminder that we are supporting two parallel IPsec implementations
To: None <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/11/2003 17:45:14
> 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
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*.
That's a bug, and *your own CVS commit message* confirms that you
checked in an ad-hoc workaround. you please confirm that you have
understoond that point? I take it as read that you will refrain from
commititng ad-hoc workarounds in future.
[*] The code I have has some minor differences from the netipsec/
code, but none of those are in pf_key handling.