#19 reload-on-HUP feature incompatible with listen{} option

closed-fixed
None
5
2004-09-07
2004-09-04
Kolja Waschk
No

Using racoon 0.3.3-1 on Debian sarge, with
kernel-image-2.6.7-1-686.

If the "listen" option is used, racoon stops to operate
properly after receiving a SIGHUP to reload its
configuration.

In particular, the following appears in the syslog
(LOCAL being the IPv4 address specified in the "listen"
option), when trying to start an actual connection:

INFO: initiate new phase 1 negotiation:
LOCAL[500]<=>REMOTE[500]
INFO: begin Identity Protection mode.
DEBUG: new cookie: c928ebc99c495474
DEBUG: add payload of len 48, next type 0
DEBUG: 80 bytes from LOCAL[500] to REMOTE[500]
ERROR: getsockname (Socket operation on non-socket)
ERROR: sendfromto failed
ERROR: failed to begin ipsec sa negotication.

It is working perfectly, even after SIGHUP, with the
same configuration file if "listen" isn't specified.
In both cases it works perfectly _before_ SIGHUP is
received.
It doesn't depend on whether the configuration file
actually changed between program start and SIGHUP or
not (unless the "listen" was added, which would trigger
the problem on the next SIGHUP).

Please let me know what further info would be helpful
if it can't be reproduced elsewhere.

Kolja

Discussion

  • Aidas Kasparas
    Aidas Kasparas
    2004-09-06

    Logged In: YES
    user_id=39627

    Ok, I can reproduce it even on latest CVS. Will investigate
    why this happens.

    On the other hand, on SIGHUP racoon forgets everything,
    therefore I see little benefit for HUP'ing it vs complete
    restart.

     
  • Aidas Kasparas
    Aidas Kasparas
    2004-09-06

    • status: open --> open-accepted
     
  • Aidas Kasparas
    Aidas Kasparas
    2004-09-06

    Logged In: YES
    user_id=39627

    Please, try attached patch agains current cvs and report did
    it fix your problem.

     
  • Aidas Kasparas
    Aidas Kasparas
    2004-09-06

     
    Attachments
  • Kolja Waschk
    Kolja Waschk
    2004-09-06

    Logged In: YES
    user_id=478715

    > try attached patch

    Yes, the hup.patch works for me (tried it against 0.3.3
    ipsec-tools release).

    > little benefit for HUP'ing it vs complete restart

    The "racoon-tool" script that comes with the Debian
    ipsec-tools package uses HUP several times (unfortunately
    even immediately after starting racoon for the first time).
    I assume it's easier for that script to simply send a HUP
    and forget about the rest, than to send a termination signal
    & wait for the process to release all ressources & re-start.

    Thanks for your immediate response

     
  • Aidas Kasparas
    Aidas Kasparas
    2004-09-07

    • assigned_to: nobody --> monas
    • status: open-accepted --> closed-fixed
     
  • Aidas Kasparas
    Aidas Kasparas
    2004-09-07

    Logged In: YES
    user_id=39627

    Fix just went into CVS.