[Openswan Users] DPD and ERROR: netlink response for Add SA esp.xxxxxxxx at y.y.y.y included errno 17: File exists

[L Felgr]

> > Q: If the powercycled unit comes back on, and reconnects to the other unit,
> the IPsec SA should be re-established
> > and the older SA on the unit that did not get power cycled should get
> replaced. Are you not seeing that
> > happening?
> >  
> > R: I am not sure. If I select appropriate lines from syslog listing from Dev1
> then I can see this:
> > ****************************************
State of Dev1: running
State of Dev2:  power off
Let us start Dev2
> > Action: Dev2 - power on
Now let us see the reaction of IPsec system on Dev1
> > ****************************************
> > 2011-07-18 11:43:10 pluto[431]: "ipsec1" #9: STATE_QUICK_R2: IPsec SA
> established tunnel mode {ESP=0x0b056df3 0x17354389
> > xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
> > ****************************************
State of Dev1: running, IPsec tunnel reestablihed - OK
State of Dev2:  running
Let us reboot Dev2
> > Action: Dev2 - reboot
Now let us see the reaction of IPsec system on Dev1
> > ****************************************
> > 2011-07-18 11:47:59 pluto[431]: "ipsec1" #12: STATE_QUICK_R2: IPsec SA
> established tunnel mode {ESP=0xf05a1802
> > 0x32e9fe4f xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
> > ****************************************
State of Dev1: running, IPsec tunnel reestablihed - OK
State of Dev2:  running
Let us reboot Dev2
> > Action: Dev2 - another reboot
Now let us see the reaction of IPsec system on Dev1
> > ****************************************
> > 2011-07-18 11:59:07 pluto[431]: "ipsec1" #17: STATE_QUICK_R1: sent QR1,
> inbound IPsec SA installed, expecting QI2
> > 2011-07-18 11:59:07 pluto[431]: "ipsec1" #17: ERROR: netlink response for Add
> SA esp.b056df3 at 10.0.3.114 included errno
> > 17: File exists
****************************************
State of Dev1: running, IPsec error
State of Dev2:  running
>
> My answer would be "that kernel did not actually reboot". SPIs are not serially
> numbered, so rebooting
> a device should give totally different SPI numbers. Try using "ip xfrm pol" and
> "ip xfrm state" before
> starting openswan. It should be totally empty. If not, there is some weird
> kernel state saving happening
> somewhere when you think the unit is rebooting.
>
I see that I explained things badly. Let me clarify some details.

1) Situation:
192.168.2.0/24==Dev1==10.0.2.125 <-> GSM network <-> 10.0.3.114==Dev2==192.168.3.0/24

2) Dev1 is never restarted in any way. No power cycle (voltage off/on). No reboot (typing "reboot" on command line).

3) Dev2 is power cycled only once and then rebooted twice.

4) I have added some comment lines to the syslog listing above to make it more descriptive.

> > Do you think I should use one of --debug-* options? Would it help to solve the
> problem?
>
> I doubt it. NETKEY has no debugging facilities. This is already the most you can
> get the kernel to tell you.
>
I tried --debug-dpd starting whack a few days ago and it gave some additional lines in syslog listing but nothing useful
for me.

L. Felgr

> Paul
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110720/d9932cdf/attachment.html