On 21 May 2018 at 23:11, Paul Wouters <[email protected]> wrote: > On Fri, 18 May 2018, Andrew Cagney 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. > > > All of it, both sides, resend the exact same sized packets. What has > happened is that both sides are in some state. The initiator did not > like our IKE_AUTH reply, so it retransmits. We don't even look at the > content. Since the msgid is the same, we determine this is a retransmit > and not a "new" or "different" IKE_AUTH (which the RFC doesn't allow > you to do anyways). And so we just retransmit our reply. Both ends have > no way of behaving differently until the iphone gives up entirely.
The same packet len, or the same packet? It doesn't take much for fragments to all be the same size. Per earlier post, pluto, looking at send_recorded_v2_ike_msg() should send all the fragments (unfortunately there's no debug log to confirm this, just lots of same-sized sends). However, where pluto is screwing up is by not also checking the fragment number. It should only re-transmit on reception of the first (or last?) fragment. Sending all fragments back for every fragment received is excessive. You're suspecting that the iPhone can't decrypt the fragmented reply, or never gets one of the fragments? If the iPhone did receive all the fragments but didn't like the auth then it should come back with a new informational(delete) exchange. Andrew , pluto sends all > To me, it just seems a bit excessive > > Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
