[Swan-dev] length of ISAKMP Message is larger than can fit

[Andrew Cagney]

I touched it last so I guess it's me ...

On Mon, 1 Jul 2019 at 13:40, Paul Wouters <paul at nohats.ca> wrote:
>
>
> It seems we can end up entering in_struct() when we got an ICMP instead
> of an IKE message.

The code was changed so it extracts the header from the ICMP message
and then uses that to find the sender using a hash table lookup.
However, it's all a bit dodgy in that in_struct() pedantically insists
on being passed a buffer that would hold the entire message.  Looks
like my hack didn't work as expected.

> Simply launch pluto against an IP that is not running pluto, and you
> will see:
>
> "private#192.1.2.23/32"[1] ...192.1.2.23 #4: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response
> length of ISAKMP Message is larger than can fit
> "private#192.1.2.23/32"[1] ...192.1.2.23 #4: STATE_PARENT_I1: retransmission; will wait 1 seconds for response
> length of ISAKMP Message is larger than can fit
> "private#192.1.2.23/32"[1] ...192.1.2.23 #4: STATE_PARENT_I1: retransmission; will wait 2 seconds for response
> length of ISAKMP Message is larger than can fit
> "private#192.1.2.23/32"[1] ...192.1.2.23 #4: STATE_PARENT_I1: 3 second timeout exceeded after 3 retransmits.  No response (or no acceptable response) to our first IKEv2 message
> "private#192.1.2.23/32"[1] ...192.1.2.23 #4: deleting state (STATE_PARENT_I1) aged 4.020s and NOT sending notification
> length of ISAKMP Message is larger than can fit
>
>
> I guess someone changed the err msg queue handling?
>
> Paul
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev