[Swan-dev] when to abort retransmits ?

Andrew Cagney andrew.cagney at gmail.com
Tue May 22 18:26:14 UTC 2018


On 22 May 2018 at 11:43, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> On 22 May 2018 at 11:01, Paul Wouters <paul at nohats.ca> 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 */

One mystery solved.  The above doesn't trip because the below, which
gets called to delete the previous transmit, contains a bug:

#define freeanychunk(ch) { pfreeany((ch).ptr); (ch).ptr = NULL; }

Since .len isn't cleared code assumes think there is a chunk when
there isn't :-(

>>> 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 :-).

I've pushed ikev2-frag-03-retrans which fools east into thinking it is
seeing a lot of re-transmits.

With the current sources it will send back a re-transmit after each
fragment is received.  With the above applied it only re-transmits
once.  I'll push once I've got more test results.

> 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


More information about the Swan-dev mailing list