I touched it last so I guess it's me ... On Mon, 1 Jul 2019 at 13:40, Paul Wouters <[email protected]> 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 > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
