<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=602403309-26052008><FONT face=Arial
size=2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial size=2>OCF has support for
session migration: if a driver is removed from the system, OCF will
automatically migrate existing sessions to the next suitable driver. But it
seems the OCF patch to openswan does not handle the session migration return
codes from OCF. In neither of ipsec_ocf_xmit and ipsec_ocf_rcv c<FONT
size=2>rp->crp_etype is not checked.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial size=2>Here's my take on
the problem. </FONT></SPAN><SPAN class=602403309-26052008><FONT face=Arial
size=2>The problem occurs because crp->crp_sid is allways reset to the
initial ipsp->ocf_cryptoid value. When migrationg the session, OCF replaces
the existing sessions to new ones and stores the new session id in
crp->crp_sid. But since both ipsec_ocf_xmit and ipsec_ocf_rcv are overwriting
that value, OCF will try to use the old (removed) driver and it will eventually
try to dereferntiate a NULL pointer. My proposal is to check c<FONT
size=2>rp->crp_etype and, when that is EAGAIN, to change
ipsp->ocf_cryptoid to the new value. (See attached
patch).</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial size=2>There is an
additional problem: OCF relies on crp->crp_desc->CRD_INI to properly
intialize the algortihms for the newly created sessions
(crypto.c::crypto_invoke, crypto_newssession. OCF patch to Openswan does not set
all the fields in CRD_INI structure before calling crypto_dispatch. That works
fine except for session migration, when the wrong value is allocated
for cri_mlen = 12 and will make authetication algorithms fail. By
setting cri_mlen = 12 before calling crypto_dispatch in both
ipsec_ocf_xmit and ipsec_ocf_rcv, session migration will properly
initialize the authetication algortihms and the migration will
work.</FONT></SPAN></DIV>
<DIV><SPAN class=602403309-26052008></SPAN> </DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial size=2>The only thing I was
not able to figure out is how to re-submit the 2 packets that are going to get
lost when the 2 Openswan relaed sessions are migrated.</FONT></SPAN></DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=602403309-26052008></SPAN> </DIV>
<DIV><SPAN class=602403309-26052008><FONT face=Arial size=2>Brad
Vrabete</FONT></SPAN></DIV>
<DIV><SPAN class=602403309-26052008> </SPAN></DIV></BODY></HTML>