[Swan-dev] when to abort retransmits ?

Andrew Cagney andrew.cagney at gmail.com
Tue May 22 14:27:02 UTC 2018

I'm not even sure pluto fragmented its auth reply (I've pushed some
log lines so we can tell).  This is on the re-transmit path:

    /* this should never happen */
    if (st->st_tpacket.len == 0) {
        pexpect(st->st_tpacket.len == 0); /* get noticed */
        libreswan_log("retransmission for message ID: %u exchange %s
failed lastreplied %u - we have no stored packet to retransmit",
            enum_name(&ikev2_exchange_names, ix),

and st->st_tpacket.len==0 when things get fragmented.


On 22 May 2018 at 10:02, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> On 21 May 2018 at 23:11, Paul Wouters <paul at nohats.ca> 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

More information about the Swan-dev mailing list