[Swan-dev] xauth_send_request has a comment that confuses me

[Paul Wouters]

On Mon, 2 Oct 2017, Antony Antony wrote:

> well if the comment was true I could avoid double sending in server.c

I don't understand that part. We still have the issue of sending some
kind of Main or Aggressive Mode message, immediately following by an
XAUTH request message. I'm not sure why it matters which Mode the message
went out as?

> Paul, do you know how to check in resend_ike_v1_msg wheater a st is Main
> mode or Aggressive mode? Both cases current state is STATE_XAUTH_R0. I want
> to know the previous one, STATE_AGGR_R2 or STATE_MAIN_R3.

You could look at (st->st_connection->policy & POLICY_AGGRESSIVE) to
determine that. But again, I don't see why knowing this should make a
difference to the retransmit timer code.

>>         /* Schedule retransmit before sending, to avoid race with master thread */
>>
>> I don't understand the comment, because I'm pretty sure this is the main thread?
>> The comment comes from openswan 2.1.4 when xauth was added.
>>
>> Maybe Antony can tell why we check for EVENT_v1_RETRANSMIT and
>> EVENT_NULL before setting it to EVENT_v1_RETRANSMIT? My guess is
>> that checking for EVENT_v1_RETRANSMIT just ensures the old timer
>> remains, but I'm unsure why. I also don't understand why not
>> having an event would be reason to still not schedule one?
>
> my guess, this is happening in a thread. And the main thread event may occur
> while xauth is working.

I don't think this is happening in a thread? Only alwaysok/file/pam
authentication is happening inside a thread. All the rest of xauth
happens in the main process. (I thought Andrew had pulled out
alwaysok/file from threads but I guess he didn't end up doing that)

In fact, I just removed the pthread include from ikev1_xauth.c :P

Paul