Red Hat Bugzilla – Bug 834397
ikev2 crashes when firing up a few conns at once
Last modified: 2014-10-14 04:18:36 EDT
Description of problem:
ikev2 crashes when firing up a few conns at once.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.
Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
This requires a backport of libreswan 6883fac8a9974afa5c2374202ff7dc05cfedf89d
yes, the crasher fairly simple. configure a few ikev2 connections with ikev2=insist and auto=start and start openswan. Be sure to have more connections than CPU cores on the (virtual) machine.
do use different IPs/IDs for the two test machines, so it appears that it is setting up connections to multiple different machines (so there is no attempt to share the parent sa)
I'll make a libreswan test case and link it here
could you provide me more information or reproducer? I am not able to reproduce this bug.
This configuration was on the machine which was supposed to crash.
On machine <machineX> was the part of this configuration related to machineX and value of auto option was add.
# ipsec auto --status|grep 'newest ISAKMP SA'
000 "test1": newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "test2": newest ISAKMP SA: #3; newest IPsec SA: #7;
000 "test3": newest ISAKMP SA: #4; newest IPsec SA: #8;
000 "test4": newest ISAKMP SA: #5; newest IPsec SA: #6;
Everything was ok, no crash.
If would be possible to test it on a single machine (loopback) it would be great.
try adding rekey=yes and then ipsec restart on machine0 so machine 1-5 all reconnect to it at the same time?
it did not help and I have not been able to reproduce it. I tested it on s390x, ppc64, x86_64 and i386 and openswan-2.6.32-27 and -16.
Were you able to reproduce it somewhere?
I can crash it using:
Use auto=add on machine0 and auto=start on machine1
Then on machine0, start openswan using:
service ipsec start
then on machine1 start openswan
The nhelpers=1 ensures there are not too many helpers available for work
The env variable fakes a busy system where the crypto takes long.
Note it is hard to see in the noise and restarts. I see this for openswan 2.6.32-27.1
ABORT at /root/rpmbuild/BUILD/openswan-2.6.32/programs/pluto/ikev2_parent.c:1555
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.