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 ([email protected] <[email protected]>) (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 <[email protected]>: > 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 > >
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
