Re: [Swan-dev] when to abort retransmits ?
On 22 May 2018 at 11:43, Andrew Cagney wrote:
> On 22 May 2018 at 11:01, Paul Wouters 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
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] when to abort retransmits ?
On 22 May 2018 at 11:01, Paul Wouters 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 Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] when to abort retransmits ?
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. 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? 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 ? Paul ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] when to abort retransmits ?
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",
st->st_msgid_lastrecv,
enum_name(&ikev2_exchange_names, ix),
st->st_msgid_lastreplied);
...
and st->st_tpacket.len==0 when things get fragmented.
Andrew
On 22 May 2018 at 10:02, Andrew Cagney wrote:
> On 21 May 2018 at 23:11, Paul Wouters 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
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] when to abort retransmits ?
On 21 May 2018 at 23:11, Paul Wouters 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 Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] when to abort retransmits ?
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. To me, it just seems a bit excessive Paul ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] when to abort retransmits ?
On 18 May 2018 at 10:07, Andrew Cagney wrote: > On 17 May 2018 at 23:00, Paul Wouters 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.34: | 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.l
Re: [Swan-dev] when to abort retransmits ?
On 17 May 2018 at 23:00, Paul Wouters 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. > [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.34: | 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
[Swan-dev] when to abort retransmits ?
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: [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.34: | 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
