<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Paul,<br>
<br>
This is now happening on 3.6. It again appears to be happening when
the remote device changes IP address.<br>
<div class="moz-cite-prefix">On 11/10/2013 21:46, Nick Howitt wrote:<br>
<blockquote>Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2]
88.104.20.228 #688: the peer proposed: 172.17.2.0/24:0/0 ->
192.168.30.0/24:0/0<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: responding to Quick Mode proposal {msgid:b07c164b}<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: us:
172.17.2.0/24===82.19.147.85<82.19.147.85>[@Nick]<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: them: 88.104.20.228===192.168.30.0/24<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: keeping refhim=4294901761 during rekey<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: transition from state STATE_QUICK_R0 to state
STATE_QUICK_R1<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed,
expecting QI2<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: Dead Peer Detection (RFC 3706): enabled<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: transition from state STATE_QUICK_R1 to state
STATE_QUICK_R2<br>
Nov 9 08:15:43 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#705: STATE_QUICK_R2: IPsec SA established tunnel mode
{ESP=>0xf828c24d <0x959c10f5 xfrm=AES_256-HMAC_SHA1
NATOA=none NATD=none DPD=enabled}<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #691: the peer
proposed: 172.17.2.0/24:0/0 -> 192.168.10.0/24:0/0<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706: responding to
Quick Mode proposal {msgid:8697ba01}<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706: us:
172.17.2.0/24===82.19.147.85[@Nick]---82.19.147.1<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706: them:
82.30.103.217<82.30.103.217>===192.168.10.0/24<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706: keeping
refhim=4294901761 during rekey<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706: transition
from state STATE_QUICK_R0 to state STATE_QUICK_R1<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting
QI2<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706: Dead Peer
Detection (RFC 3706): enabled<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706: transition
from state STATE_QUICK_R1 to state STATE_QUICK_R2<br>
Nov 9 08:22:30 server pluto[10996]: "MumIn" #706:
STATE_QUICK_R2: IPsec SA established tunnel mode
{ESP=>0x33658ba2 <0x3906478a xfrm=AES_256-HMAC_SHA1
NATOA=none NATD=none DPD=enabled}<br>
Nov 9 08:25:39 server pluto[10996]: "PaulIn"[2] 88.104.20.228
#702: ESP traffic information: in=0B out=4KB<br>
Nov 9 08:26:21 server pluto[10996]: packet from
62.122.68.153:53489: next payload type of ISAKMP Message has an
unknown value: 133<br>
Nov 9 08:26:21 server pluto[10996]: packet from
62.122.68.153:53489: ASSERTION FAILED at
/home/build/rpmbuild/BUILD/libreswan-3.6/programs/pluto/demux.c:18<br>
</blockquote>
<br>
It is PaulIn which changes IP address<br>
<br>
ipsec then restarts and everything is OK again:<br>
<br>
<blockquote>Nov 9 08:26:22 server ipsec__plutorun: !pluto
failure!: exited with error status 134 (signal 6)<br>
Nov 9 08:26:22 server ipsec__plutorun: restarting IPsec after
pause...<br>
Nov 9 08:26:34 server ipsec__plutorun: Starting Pluto
subsystem...<br>
</blockquote>
<br>
This happened at least twice yesterday.<br>
<br>
Regards,<br>
<br>
Nick<br>
</div>
<blockquote cite="mid:525863AA.7050303@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
The code block here is:<br>
<br>
<tt> switch (maj) {</tt><tt><br>
</tt><tt> case ISAKMP_MAJOR_VERSION:</tt><tt><br>
</tt><tt> process_v1_packet(mdp);</tt><tt><br>
</tt><tt> break;</tt><tt><br>
</tt><tt><br>
</tt><tt> case IKEv2_MAJOR_VERSION:</tt><tt><br>
</tt><tt> process_v2_packet(mdp);</tt><tt><br>
</tt><tt> break;</tt><tt><br>
</tt><tt><br>
</tt><tt> default:</tt><tt><br>
</tt><tt> bad_case(maj);</tt><tt><br>
</tt><tt> }</tt><tt><br>
</tt><br>
Line 196 is "bad_case(maj);"<br>
<br>
HTH,<br>
<br>
Nick<br>
<br>
<div class="moz-cite-prefix">On 11/10/2013 19:55, Paul Wouters
wrote:<br>
</div>
<blockquote
cite="mid:alpine.LFD.2.10.1310111453310.13161@bofh.nohats.ca"
type="cite"> <br>
On Mon, 7 Oct 2013, Nick Howitt wrote: <br>
<br>
<blockquote type="cite">I'm still running 3.6rc1 and it failed 5
times last night, possibly triggered by the far router which
perhaps went throutgh an IP <br>
change (noise on the line?). <br>
</blockquote>
<br>
<blockquote type="cite">Oct 6 20:01:35 server pluto[28831]:
packet from 80.6.166.163:500: next payload type of ISAKMP
Message has an unknown value: 133 <br>
Oct 6 20:01:35 server pluto[28831]: packet from
80.6.166.163:500: ASSERTION FAILED at <br>
/home/build/rpmbuild/BUILD/libreswan-3.6rc1/programs/pluto/demux.c:196:
case 0 unexpected <br>
</blockquote>
<br>
As I gave you an informal version, can you tell me what the code
around <br>
line 196 is? The oly switch statement I see there is the switch
(maj) <br>
which could not possibly hit that bad_case() unless there was
some weird <br>
memory corruption. <br>
<br>
Paul <br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>