[Design] pluto not responding -- possibly not re-entrant (updown)

Hi Folks --

I've managed to get pluto into a state where it isn't responding:

time ipsec auto --status
... bored now ... ^C

real 3m54.604s
user 0m0.000s
sys 0m0.040s

I notice some weird things in the ps listing.

   http://www.av8n.net/tmp/bad1-ps.txt

However the fact that the _downup script for one conn runs as the descendent of the _downup for another conn isn't as weird as you might think; it's because I put a --replace command in my _downup script.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

   http://www.monmouth.com/~jsd/vpn/_downup I thought this was legal; nobody ever told me that pluto was non-reentrant.

Things ran fine for ten days or so before hanging. Therefore my first hypothesis was that it was a race condition. But after looking at the code, I'm suspecting a plain old deadly embrace; it may be that this part of my _downup script had not been exercised previously.

 >>>> If it is not allowed to put ipsec auto commands in updown scripts, this needs to be documented. <<<<<<

Actually, if this is not allowed, it would be friendly to defend against it, perhaps by making a run-time check on the pgid.

Here's a traceback:
(gdb) where
#0 0x40142544 in __libc_read () from /lib/i686/libc.so.6
#1 0x40198154 in __DTOR_END__ () from /lib/i686/libc.so.6
#2 0x400dd42d in _IO_new_file_underflow (fp=0x80a19c8) at fileops.c:542
#3 0x400dfcc9 in _IO_default_uflow (fp=0x80a19c8) at genops.c:420
#4 0x400decff in __uflow (fp=0x80a19c8) at genops.c:377
#5 0x400d456d in _IO_getline_info (fp=0x80a19c8, buf=0xbffff000 "",
n=255, delim=10, extract_delim=1, eof=0x0) at iogetline.c:71
#6 0x400d464d in _IO_getline (fp=0x80a19c8, buf=0xbffff000 "", n=255,
delim=10, extract_delim=1) at iogetline.c:41
#7 0x400d3494 in _IO_fgets (buf=0xbffff000 "", n=256, fp=0x80a19c8) at
iofgets.c:50
#8 0x0805b006 in do_command (c=0x80a12f8, verb=0x807c13a "up") at
kernel.c:885
#9 0x0805dc45 in route_and_eroute (c=0x80a12f8, st=0x80a1cc8) at
kernel.c:2362
#10 0x0805dfcd in install_ipsec_sa (st=0x80a1cc8, inbound_also=0) at
kernel.c:2518
#11 0x0805a095 in quick_inI2 (md=0x809ee38) at ipsec_doi.c:3486
#12 0x08060a4d in process_packet (mdp=0x808bb9c) at demux.c:1663
#13 0x0805f5f4 in comm_handle (ifp=0x809e4e8) at demux.c:881
#14 0x08052a4f in call_server () at server.c:798
#15 0x08051368 in main (argc=4, argv=0xbffffb54) at main.c:441
#16 0x4007e507 in __libc_start_main (main=0x8050d74 <main>, argc=4,
ubp_av=0xbffffb54, init=0x8049894 <_init>, fini=0x80749f0 <_fini>,

     rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffffb4c) at ../sysdeps/generic/libc-start.c:129

The barf is available:
http://www.av8n.net/tmp/barf1.txt

I've left it in the bad state for now. Please let me know if you want me to make any more observations on it.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek