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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
