There is a hard coded 30 second timer in the kernel that
kicks off phase 1 negotiations.
I can semi-reliably power up my IPsec devices and get
the same traffic keys. That is, I run setkey -D once the network is passing ESP
packets and I note down the output. Then reboot and find that setkey -D gives
For these tests, timing is important. I have to begin a
ping from one laptop through the IPsec tunnel to a distant laptop at the same
time as I power on both IPsec devices. I can get the same setkey -D output about
80% of the time if I do this carefully.
These are the same boards I
recently reported racoon taking 30s to become ready to handle traffic on. The
266MHz PPC, 128MB Ram, Flash storage, no keyboard, no mouse, no
hard drive and no real time clock.
With such hardware we have a real
problem getting random numbers out of the boards that are different on different
boot-ups. We are running kernel 2.6.21 with the recent patchs that fix a
partially broken /dev/random. Using scripts inspired by the urandom man page we
cat some random data from a file into /dev/urandom. Tests as part of the boot
scripts can then extract some random data from /dev/urandom and we see that the
outputs are always different *provided* the data we use to seed the random
number subsystem is different (and the same for the same data). Note that with a
previous kernel, before the recent patches, we could get the same random numbers
every time no matter what data we catted into /dev/urandom. Obviously the
seeding process happens before we run setkey -f ipsec.conf and
Given that we know we can get random numbers from /dev/urandom it
is alarming to get the same traffic keys.
We think that racoon gets its
random numbers from openssl which in turn seeds itself from the linux random
number system (the racoon debug logs hint to this). In which case, as we don't
specifically run any openssl program when we boot up, when does this openssl
seeding happen? Or am I misunderstanding the way this works?
appreciate that this might not strictly be within the bounds of what the
ipsec-tools software does but I wonder if you guys have any ideas about this
issue? Am I simply missing a particular command and will be kicking myself after
reading the first reply? Is racoon doing something wrong or is the blame more
likely with openssl?
PS Still not had the
software rebuilt by our suppliers to check whether that patch solved the racoon
startup delay problem.