<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: No. STATE_MAIN* and STATE_QUICK* are IKEv1 Did you not delete the retained packets in these states? This is my vague recollection. Also that I questioned whether this would cause problems. Of course it could be that: - my recollections are wrong - the cause of these problems is elsewhere _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
