Jivin Vrabete, Brad lays it down ...
> Hi,
>
> 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 crp->crp_etype is not checked.
>
> Here's my take on the problem. 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 crp->crp_etype and, when that is EAGAIN, to change ipsp->ocf_cryptoid
> to the new value. (See attached patch).
>
> 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.
Sorry for dragging my feet on this one. Just added your patch to the
current ocf/openswan code here and it all looks good.
I had to also add the code for the "batched" mode operation, but it was just a repeat of what you had already done for immediate mode.
> 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.
A naive (or overly optimistic) approach would be to just re-call
crypto_dispatch on the request. Which I did and it worked, a small cleanup
in crypto.c and everyone is mostly happy :-)
I can run ping over the tunnel and pull drivers out while it is running
without losing any packets. Not sure I would trust it under heavy load
though ;-)
I have attached two patches for use with the latest
ocf-linux-20080917/openswan-2.6.16 versions on ocf-linux.sourceforge.net.
They have your patches and a my additions all rolled into one.
Thanks,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
|
