[Openswan dev] odd behaviour in new test, deleted conn to OE?

[Paul Wouters]

I am testing a bit with the new kernel, doing --down/--add,--up,--delete
pseudo randomly, which is what triggered the first crash, and I noticed 
something odd.

I have a conn for the bofh-fedoratest connection. bofh is my desktop, on
193.110.157.17, and the fedorabox is on 193.110.157.22. bofh is also doing OE,
while the fedorabox can't do OE, since it has no key in the DNS. Yet, after
deleting the fedoratets conn on bofh, I got an OE connection from bofh to
fedoratest:

doing a --up

Feb 10 11:57:47 bofh pluto[850]: "fedoratest" #85: initiating Main Mode
Feb 10 11:57:47 bofh pluto[850]: "fedoratest" #85: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Feb 10 11:57:47 bofh pluto[850]: "fedoratest" #85: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Feb 10 11:57:48 bofh pluto[850]: "fedoratest" #85: Peer ID is ID_IPV4_ADDR: '193.110.157.22'
Feb 10 11:57:48 bofh pluto[850]: "fedoratest" #85: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Feb 10 11:57:48 bofh pluto[850]: "fedoratest" #85: ISAKMP SA established
Feb 10 11:57:48 bofh pluto[850]: "fedoratest" #86: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS {using isakmp#85}
Feb 10 11:57:48 bofh pluto[850]: "fedoratest" #86: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Feb 10 11:57:48 bofh pluto[850]: "fedoratest" #86: sent QI2, IPsec SA established {ESP=>0xee9fad37 <0xdbc6d50f}

--down from the other end:

Feb 10 11:57:48 bofh pluto[850]: "fedoratest" #85: received Delete SA payload: deleting ISAKMP State #85

--delete localally:
Feb 10 11:58:17 bofh pluto[850]: "fedoratest": deleting connection
Feb 10 11:58:17 bofh pluto[850]: "fedoratest" #86: deleting state (STATE_QUICK_I2)
Feb 10 11:58:23 bofh pluto[850]: "packetdefault"[1] 0.0.0.0/0=== ...193.110.157.22===? #87: responding to Main Mode from unknown peer 193.110.157.22
Feb 10 11:58:23 bofh pluto[850]: "packetdefault"[1] 0.0.0.0/0=== ...193.110.157.22===? #87: transition from state (null) to state STATE_MAIN_R1
Feb 10 11:58:23 bofh pluto[850]: "packetdefault"[1] 0.0.0.0/0=== ...193.110.157.22===? #87: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Feb 10 11:58:24 bofh pluto[850]: "packetdefault"[1] 0.0.0.0/0=== ...193.110.157.22===? #87: Peer ID is ID_IPV4_ADDR: '193.110.157.22'
Feb 10 11:58:24 bofh pluto[850]: "packetdefault"[1] 0.0.0.0/0=== ...193.110.157.22===? #87: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Feb 10 11:58:24 bofh pluto[850]: "packetdefault"[1] 0.0.0.0/0=== ...193.110.157.22===? #87: sent MR3, ISAKMP SA established

So far, I can understand the isakmp SA,

Feb 10 11:58:24 bofh pluto[850]: "private-or-clear#0.0.0.0/0"[3] ...193.110.157.22 #88: responding to Quick Mode
Feb 10 11:58:24 bofh pluto[850]: "private-or-clear#0.0.0.0/0"[3] ...193.110.157.22 #88: transition from state (null) to state STATE_QUICK_R1
Feb 10 11:58:25 bofh pluto[850]: "private-or-clear#0.0.0.0/0"[3] ...193.110.157.22 #88: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Feb 10 11:58:25 bofh pluto[850]: "private-or-clear#0.0.0.0/0"[3] ...193.110.157.22 #88: IPsec SA established {ESP=>0xcda2ba7d <0xdbc6d510}

But this successful IPsec SA on instance 3 is odd. Where did bofh get the
key from? It can only have gotten it from within pluto, from the "deleted"
connection. Is there still some "deleting" happening after the log message?
Is this is race condition? Or am I losing it?

I made barfs on both ends, which I can put up if useful.

Another thing I noticed, which might be related, is that a connection which
is only --added on both ends, and then --up'ed on one end, will never terminate
again. Doing a --down on one end will immediately cause a new negotiation to
trigger the conn to come up again.

This is using openswan-2 head

But the good news is that 2.6.3-rc1 indeed no longer gives the crash :)

Paul