Bug 225328 - LSPP: ipsec drops first packet when using IKE daemon
LSPP: ipsec drops first packet when using IKE daemon
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Brian Brock
: OtherQA
Depends On:
Blocks: 234654 RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-01-29 17:12 EST by Joy Latten
Modified: 2010-10-22 08:44 EDT (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2007-0959
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 14:23:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
LSPP.65 kernel patch for this issue. (5.58 KB, patch)
2007-02-19 12:19 EST, Eric Paris
no flags Details | Diff

  None (edit)
Description Joy Latten 2007-01-29 17:12:11 EST
Description of problem:
The IKE daemon creates SAs when needed.
Thus, first time a packet comes in, if there isn't an SA,
kernel tells IKE to go and establish one. In the meantime,
this packet gets dropped. From user or application viewpoint, 
app has to be issued again since the SA should be established
next time around.

In LSPP, because more SAs will get created than normally, this
can become very problematic. 
 
How reproducible:
Very.

Steps to Reproduce:
1. configure ipsec with racoon
2. do a ping to remote, it will fail.
3. wait a few seconds
4. do the ping again, it should work
  
Actual results:
connection: resource temporarily unavailable

Expected results:
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x: icmp_seq=1 ttl=63 time=0.866 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=63 time=0.742 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=63 time=0.650 ms
Comment 2 James Morris 2007-02-12 08:58:01 EST
This is fixed upstream now:
http://marc.theaimsgroup.com/?l=git-commits-head&m=117104425107990&w=2
Comment 3 Irina Boverman 2007-02-14 16:02:41 EST
per 2/12 discussion, we should build lspp kernel with this fix.
Comment 4 Eric Paris 2007-02-19 12:19:29 EST
Created attachment 148346 [details]
LSPP.65 kernel patch for this issue.

This is the upstream backport of this patch.  Lots of testing is needed in the
LSPP kernel before internal submission is made.
Comment 5 Joy Latten 2007-02-20 13:29:27 EST
Successfully ran a 16 hour labeled ipsec stress test on the lspp 65 kernel with
this patch. So far things look good. I will try a regular ipsec stress test next.
Comment 6 Eric Paris 2007-03-06 16:30:51 EST
Joy is blaming this patch for the creation of multiple SAs.  I will wait to hear
results of that discussion before anything else is done here.
Comment 7 Eric Paris 2007-03-28 14:54:04 EDT
There is still some multiple SA discussion.  Part of it will be fixed in another
kernel patch (IBM has not opened the BZ but will today) and part of it will be
handled in the userspace ipsec daemon.
Comment 8 Joy Latten 2007-03-28 16:17:50 EDT
Eric, can we use this bugreport for the change needed in the kernel, the one
where we just needed to add the check for the protocol id. That check narrowed
it down from triple SAs to double SAs.

The userspace patch will hopefully narrow down the double SA to just a single one.

So there will be 2 fixes, one for the kernel as described above ( and hopefully
can be used for this bug report) and one for userspace for which I can open a
new bugreport for. 

Let me know if this is ok and I will proceed.
Comment 9 Eric Paris 2007-03-28 18:41:24 EDT
No this bug is being used to track the fix so we don't drop the first packet. 
(see the patch in comment #2)

We need a new bug to track the proto matching fix which was not caused by this
patch but which was brought to the surface by this patch.
Comment 10 RHEL Product and Program Management 2007-03-28 18:42:05 EDT
This request was evaluated by Red Hat Kernel Team for inclusion in a Red
Hat Enterprise Linux maintenance release, and has moved to bugzilla 
status POST.
Comment 11 Don Zickus 2007-04-23 17:52:52 EDT
in 2.6.18-16.el5
Comment 13 John Poelstra 2007-08-27 14:29:35 EDT
A fix for this issue should have been included in the packages contained in the
RHEL5.1-Snapshot3 on partners.redhat.com.  

Requested action: Please verify that your issue is fixed as soon as possible to
ensure that it is included in this update release.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to FAILS_QA.

More assistance: If you cannot access bugzilla, please reply with a message to
Issue Tracker and I will change the status for you.  If you need assistance
accessing ftp://partners.redhat.com, please contact your Partner Manager.
Comment 14 Joy Latten 2007-08-28 14:07:27 EDT
Verified that this is fixed. 
Comment 16 errata-xmlrpc 2007-11-07 14:23:05 EST
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.

http://rhn.redhat.com/errata/RHBA-2007-0959.html

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