On 22 May 2018 at 11:01, Paul Wouters <[email protected]> wrote: > On Tue, 22 May 2018, Andrew Cagney wrote: > >> 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). > > > I don't know. I will see if I still have the logs.
I hope so. Per my last reply, I don't think Pluto responded with fragments (or even more is screwed up). If it was, I think the re-transmit would have triggered this pexpect: pexpect(st->st_tpacket.len == 0); /* get noticed */ >> 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. > > > Possibly it should wait until it has received a whole list of fragments? I've got a hack to look at the SKF payload and only respond on the first fragment (I think we just pick one :-). However, like the check for message IDs, it isn't ideal - I don't think the code should be acting on the contents of the packet's header until after it has confirmed the packets integrity. IKEv1 does this by checking that the re-transmit is identical to the previously validated .st_rpacket? >> You're suspecting that the iPhone can't decrypt the fragmented reply, > > > No. I think it can decrypt it fine, but didn't like the content. For > example an AUTH failure of the responder. >> 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. > > > Depends on the kind of AUTH failure? If it is a CA it doesn't trust > sure. But if the AUTH failed integrity, then perhaps the packet was > mangled and it should try and get a new copy via retransmit ? If integrity failed then, yes the packet gets ignored. Andrew _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
