Bug 432805 - ipsec restart does not work
ipsec restart does not work
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openswan (Show other bugs)
All Linux
high Severity medium
: rc
: ---
Assigned To: Karl Wirth
Depends On:
Blocks: 253052
  Show dependency treegraph
Reported: 2008-02-14 09:38 EST by Janne Karhunen
Modified: 2013-08-05 20:43 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2008-0395
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 11:29:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Restart fix. (518 bytes, patch)
2008-02-15 12:51 EST, Janne Karhunen
no flags Details | Diff

  None (edit)
Description Janne Karhunen 2008-02-14 09:38:39 EST
Description of problem:

'service ipsec restart' tries to reload kernel modules and fails restarting.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. service ipsec restart 
Actual results:

Shutting down IPsec:  Stopping Openswan IPsec...
[  OK  ]
Starting IPsec:  Starting Openswan IPsec 2.6.07...
FATAL ERROR: Both KLIPS and NETKEY IPsec code is present in kernel
OOPS, should have aborted!  Broken shell!

Expected results:

[  OK  ]

Additional info:
Comment 1 Janne Karhunen 2008-02-14 12:53:17 EST
Seems that manual 'start & stop & start' works. Restart doesn't, even if you add
sleep between start_it & stop_it.
Comment 2 Janne Karhunen 2008-02-14 14:14:06 EST
Klips check seems to be the reason - it looks for /proc/net/ipsec/version which
seems to be there on restart. In this case having /proc/net/ipsec/version does
not mean klips being actually present. Off to kernel code to check who creates
this proc element and more importantly, why.
Comment 3 Janne Karhunen 2008-02-14 15:45:45 EST
Not only the _startklips thing seem broken, but the more obvious question being
why would it get called in the first place.
Comment 4 Janne Karhunen 2008-02-15 10:10:01 EST
$IPSECprotostack evaluation in _realsetup seems to yield result that we would be
using klips - and only on restart :)
Comment 5 Janne Karhunen 2008-02-15 10:16:05 EST
Or more specifically, it's this:
    elif test -f $kamepfkey
            netkey=true; klips=false;
            netkey=false; klips=true;

Which seems to think that /proc/net/pfkey is not there. Probably has not shown
yet by the time, so trying to sleep it.

Comment 6 Janne Karhunen 2008-02-15 10:33:06 EST
Not the sleep, but instead the whole evaluation does not make sense. As is the
case with most of the stack evaluation(s) all around the scripts. Uh-oh.
Negating the evaluation to elif 'test ! -f $kamepfkey' makes it work (and these
types of 'fixes' seem to be deployed all around the code) but nevertheless,
evaluation is still bogus. What this would really need is a considerable rewrite
when it comes to evaluating which stack is being used - and the same method
should be used everywhere.
Comment 7 Janne Karhunen 2008-02-15 12:43:14 EST
[ -e /proc/net/pfkey ] || /sbin/modprobe af_key &>/dev/null
in ipsec 'restart' solves it as well as it can be without rewriting anything.
Comment 8 Janne Karhunen 2008-02-15 12:51:25 EST
Created attachment 295024 [details]
Restart fix.
Comment 9 Paul Wouters 2008-02-26 14:57:28 EST
This is already solved in the current GIT #testing (2.5) version, and will be
updated in the next release of GIT #ikev2 (2.6)
Comment 10 Paul Wouters 2008-03-07 13:44:59 EST
Actually, the issue was not entirely solved. I've made some minor changes.

The best option now is to add protostack=netkey to the ipsec.conf's "config
setup' section. Then most of the script won't be called, and netkey will be
asumed, and even if the kernel modules are not loaded, they'll get loaded.
Comment 11 Paul Wouters 2008-03-10 17:13:19 EDT
Fixed in 2.6.08 (and 2.6.09
Comment 12 Steve Conklin 2008-03-13 15:31:08 EDT
paul, which file is this fixed in? I don't see any changes to
programs/setup/setup.in, which is where I'd expect to see changes to the init
script. I'm missing something.

Comment 13 Paul Wouters 2008-03-13 16:46:55 EDT
The change is in programs/_realsetup/_realsetup.in

        if test \! -f $kamepfkey
                @MODPROBE@ af_key;
        netkey=true;  klips=false; mast=false;;

Comment 21 errata-xmlrpc 2008-05-21 11:29:00 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.