On 18 May 2018 at 10:07, Andrew Cagney <andrew.cag...@gmail.com> wrote: > On 17 May 2018 at 23:00, Paul Wouters <p...@nohats.ca> wrote: >> >> I'm looking at a case where IKE_AUTH is fragmented, with iOS as >> initiator and libreswan as responder. Something is wrong and >> both ends seem to be just retransmiting the same packet: > > Grep for, and look carefully at, the incoming packet size. My (I > should probably read the source code) guess is that iOS re-sent the > the entire packet as 12 fragments but our end, not knowing how to deal > with fragmented re-transmits, is responding immediately with the first > packet each time.
Looking at the code I was half right.. The code doesn't know how to deal with re-transmitted fragments so triggers a call to process_recent_rtransmit() for all fragments (It should only trigger on the last fragment?). However, the code sending out the re-transmits does seem to do the right thing - send all fragments (alas logging to confirm this is lacking). Depressingly, I suspect the best way to test this is with the packet filter / firewall. Andrew > >> [root@euk-88957 ~]# grep "sending 340 bytes for >> ikev2-responder-retransmit through" /var/log/pluto.log May 17 >> 20:34:26.548937: | sending 340 bytes for ikev2-responder-retransmit through >> eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:26.970419: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:26.972670: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:26.974875: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:29.546602: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:29.970454: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:29.972705: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:29.975048: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:32.555937: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:32.978128: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 17 20:34:32.980411: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:54690 (using #7) >> May 18 01:49:49.959394: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:49.961646: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:49.967761: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:52.555534: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:52.978057: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:52.980392: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:52.982603: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:55.563520: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:55.981792: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> May 18 01:49:55.984003: | sending 340 bytes for ikev2-responder-retransmit >> through eth0:4500 to 5.31.204.40:10100 (using #33) >> >> 12 retransmits in 6 seconds. This seems a bit much to me. >> >> But according to RFC 7296, we MUST answer. So arguably this is the >> iphone's fault. But should we limit the number to something more sane >> in this case? >> >> I don't know yet what's going on. It seems the iphone didn't like our >> IKE_AUTH, but retransmiting it won't change the outcome. One possibility >> is that things are getting mangled (by accident or on purpose?) and >> it just hasn't yet gathered all our fragments successfully ? The only >> other case would be that it did receive all fragments, and either >> the resulting cleartext is mangled or or it didn't like some validly >> formatted content. But in that case, I don't think it should blindly >> retransmit the IKE_AUTH in the hope that things will get better? >> >> >> Paul >> _______________________________________________ >> Swan-dev mailing list >> Swan-dev@lists.libreswan.org >> https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev