[Swan-dev] iphone ios8 gets xauth request before isakmp is established

Wolfgang Nothdurft wolfgang at linogate.de
Thu Dec 18 16:44:14 EET 2014


Am 16.12.2014 um 18:26 schrieb Paul Wouters:
> On Tue, 16 Dec 2014, Wolfgang Nothdurft wrote:
>
> ExecSum: try attached patch?
>
>>>> So I think the problem can also be solved, if the retransmit for the
>>>> xauth password request were reduced to 10 or 20 seconds.
>>>>
>>>> snippet from ikev1_xauth.c (xauth_send_request):
>>>>
>>>> 795         event_schedule(EVENT_v1_RETRANSMIT,
>>>> EVENT_RETRANSMIT_DELAY_0 * 3,
>>>> 796                    st);
>>>
>>> That looks much better compared to adding a sleep() :)
>>>
>>> I've reduced this specific timeout to 1* EVENT_RETRANSMIT_DELAY_0 to
>>> work around the issue now. In general, the retransmit/timeout behaviour
>>> of libreswan will see some modernization in the next two months which
>>> will also reduce all timeouts to modern day timings.
>>
>> The IPhone works with this change, but the customer criticized that it
>> now take ages (15 seconds) to connect. ;)
>
> So I think the problem might relate to:
>
> In complete_v1_state_transition():
>
> [...]
>                 /* if requested, send the new reply packet */
>                  if (smc->flags & SMF_REPLY) {
>          [...]
>          send_ike_msg(st, enum_name(&state_names, from_state));
>          }
> [...]
>                 /* Special case for XAUTH server */
>                  if (st->st_connection->spd.this.xauth_server) {
>                          if (st->st_oakley.doing_xauth &&
>                              IS_ISAKMP_SA_ESTABLISHED(st->st_state)) {
>                                  libreswan_log(
>                                          "XAUTH: Sending XAUTH
> Login/Password Request");
>                                  xauth_send_request(st);
>                                  break;
>                          }
>                  }
>
>          {
>          // note in email: similar checks for mode_cfg
>          modecfg_send_request(st);
>          }
>
>
> I guess this does not really follow our state machine model very well.
>
> The xauth_send_request() and modecfg_send_request() should really
> cause a different state change and get scheduled properly. Note that
> these functions already build a packet from scratch.
>
> It is a bit odd that one incoming packet results in us sending two (or
> three?) packets back. And we surely rapid fire these two packets in the
> iphone case right after each other.
>
> Possibly, xauth_send_request() should really be a new event scheduled,
> eg:    event_schedule(EVENT_v1_SEND_XAUTH, 1 /* second delay */. st);
>
> Attached a completely untested patch, let me know how that works out? :)
> (it also does not really follow our state model properly)
>

It crashed immediately ;)

I modified your patch to work around the asserts (st == NULL, but 
st->st_event != NULL) for xauth, don't know if this would be correct for 
a final patch.

But it works. T
he one second between ISAKMP established and sending the xauth requeset 
is now more than enough, so that a reordering shouldn't happen anymore.
The retransmit also works, if I block the first xauth password request.

Wolfgang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libreswan-3.12-xauth_delay2.patch
Type: text/x-patch
Size: 2463 bytes
Desc: not available
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20141218/a078294d/attachment.bin>


More information about the Swan-dev mailing list