[Swan-dev] problem from IRC: confusing message and action of lost final packet

Andrew Cagney andrew.cagney at gmail.com
Sun Sep 23 16:57:25 UTC 2018

On Sat, 22 Sep 2018 at 14:34, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> <mcp> since libreswan 3.26 + 83e33a69b27f6c5d5f4aff2fc94a1357d5126ed1 I
> get these syslog messages very often:
> http://paste.debian.net/hidden/a99f6aa9/ - that's annoying ;)
> <DHR-x> I've just pushed fa004e7d4b83fbeaa8d0f6d8430a96aed97a97b9
> to log the state name
> <mcp> DHR-x, LetoTo, LetoThinkpad: message ignored because it contains a
> payload type (ISAKMP_NEXT_HASH) unexpected by state STATE_QUICK_R2
> <mcp> DHR-x, LetoTo, LetoThinkpad: message ignored because it contains a
> payload type (ISAKMP_NEXT_ID) unexpected by state STATE_MAIN_I4
> <mcp> with fa004e7d4b83fbeaa8d0f6d8430a96aed97a97b9 applied
> <DHR-x> STATE_QUICK_R2 is after responder has negotiated an IPSec SA.  So
> no messages are expected.  But perhaps your side is retransmitting (due to
> loss of packet).
> <DHR-x> This should be detected and dealt with.  But I think someone
> recently hacked on the previous-received-packet-retention code and may
> have broken this.  Andrew?
> <DHR-x> STATE_MAIN_I4 is a similar situation, but for Main Mode
> (negotiating an IKE SA).
> <DHR-x> Cagney?
> <cagney_> DHR-x, ikev2?
> [no longer IRC]
> The failure is not just a confusing message.  Pluto also sends a
> complaining notification to its peer.  The correct action is to
> - discard the repeated inbound IKE packet
> - take it as a trigger to resend the last outbound IKE packet
> Cagney:

.. and since if it is IKEv1 then we could well be stuffed no matter what we do.

> Did you not delete the retained packets in these states?  This is my
> vague recollection.  Also that I questioned whether this would cause
> problems.

Are you referring to this exchange between myself and Paul or
something else (links always help)?

[Swan-dev] IKEv1 xauth core dump from freeanychunk() fix

and this follow-up between you and me?

[Swan-dev] ikev1 retransmits: only save the received packet when responding

(I didn't see any further follow-up)


More information about the Swan-dev mailing list