At the end of xauth_send_request:
/* RETRANSMIT if Main, SA_REPLACE if Aggressive */
/* ??? the actual code seems to force EVENT_v1_RETRANSMIT */
if (st->st_event->ev_type != EVENT_v1_RETRANSMIT) {
delete_event(st);
event_schedule_ms(EVENT_v1
On Sun, 1 Oct 2017, D. Hugh Redelmeier wrote:
At the end of xauth_send_request:
/* RETRANSMIT if Main, SA_REPLACE if Aggressive */
/* ??? the actual code seems to force EVENT_v1_RETRANSMIT */
if (st->st_event->ev_type != EVENT_v1_RETRANSMIT) {
delete_event
On Mon, Oct 02, 2017 at 12:43:51PM -0400, Paul Wouters wrote:
> On Sun, 1 Oct 2017, D. Hugh Redelmeier wrote:
>
> > At the end of xauth_send_request:
> >
> >/* RETRANSMIT if Main, SA_REPLACE if Aggressive */
> > /* ??? the actual code seems to force EVENT_v1_RETRANSMIT */
> > if (
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 m
> 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)
>
>
It does the following:
On Mon, Oct 02, 2017 at 01:50:18PM -0400, Paul Wouters wrote:
> 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,
On Mon, 9 Oct 2017, Antony Antony wrote:
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.
It seems different. Atleast in our test cases, and smc entry supprt this
