[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