[strongSwan] [IKEv2 Mobike] error uninstalling route installed with policy

[amysue.z at gmail.com]

Hi Tobias,
Thanks for your reply

My pc is Centos 5.9
*lsb_release -a*
*LSB Version:
 :core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch*
*Distributor ID: CentOS*
*Description:    CentOS release 5.9 (Final)*
*Release:        5.9*
*Codename:       Final*

*cat /proc/version*
*Linux version 2.6.18-348.1.1.el5 (mockbuild at builder17.centos.org
<mockbuild at builder17.centos.org>) (gcc version 4.1.2 20080704 (Red Hat
4.1.2-54)) #1 SMP Tue Jan 22 16:24:03 EST 2013*

The strongswan version i*s Linux strongSwan U5.1.0/K2.6.18-348.1.1.el5*

I don't know how to add DBG statements to get_replay_state() for I don't
quite know the C language, could you give me some DBG statements?

Regards
Amy



2014-08-22 0:30 GMT+08:00 Tobias Brunner <tobias at strongswan.org>:

> Hi Amy,
>
> > Is this error cause ping fail?
> > error uninstalling route installed with policy
> > 192.168.168.0/24 === 172.16.1.20/32 fwd
>
> That's normal.  Because the interface that was referenced in this route
> (eth1) disappeared, the route was already removed by the kernel when
> charon eventually tries to uninstall it, so you get this error/warning.
>
> Your main problem is this:
>
> > Aug 21 18:30:19 05[KNL] unable to copy replay state from old SAD entry
> > with SPI c84ed7a1
> > Aug 21 18:30:19 05[KNL] unable to copy replay state from old SAD entry
> > with SPI 0dbbeb51
>
> For some reason retrieving the current ESP sequence numbers for these
> SAs failed on your system.
>
> Because we can't update the IPsec SAs installed in the kernel directly,
> but have to delete and reinstall them instead, we need to copy the old
> replay state to the new SA.  If that fails the newly installed SAs can't
> be used as the sequence numbers aren't in-sync between the two peers.
> I'm not sure when this could actually fail.  The XFRM_MSG_GETAE query
> seems to have been successful (you'd have gotten an additional error
> otherwise), and I don't see how the kernel could not return the
> requested state without reporting an error.
>
> You could try to add some DBG statements in get_replay_state() in
> kernel_netlink_ipsec.c to see what's going on (e.g. what message types
> the kernel returns or what attribute types if out_aevent is assigned).
>
> What kernel version do you use?  What strongSwan version?  Any custom
> patches applied to either one?
>
> In any case we should probably check early on if get_replay_state()
> actually returned anything and fail if it did not so that the IPsec SAs
> could be rekeyed (we already use this fallback on other platforms, e.g.
> FreeBSD, where updating SAs is not possible at all).
>
> Regards,
> Tobias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20140822/16202b1d/attachment.html>