git bisect start
# bad: [2baaa653a9961acda26f8b38e780db4acbab774a] testing: cleanup
xauth-pluto-26 to avoid race on ipsec stop git bisect bad
2baaa653a9961acda26f8b38e780db4acbab774a # good:
[961c67d31dcbbef9846df63a13674409acfc6c2c] testing: for
kvm-install-hive build into $(KVM_OBJDIR) git bisec
Forgive my use of IKEv2 terminology in what is an IKEv1 problem. Here's my
understanding of XAUTH:
- initiator sends final SA exchange packet (in IKEv2 this is called AUTH so
I'm calling it that)
- responder establishes connection and replies with its own AUTH reply
- initiator receives AUTH and
My bad.
Can you try the attached which I'll call fix #1. It eliminates a continue
that would cause code setting ST=NULL to be skipped (as you
can tell by the duplicate T's I'm running F26 with a kvm in the background
:-).
Fix #2, is to be robust against continue; and fix #3 is to
On Thu, Oct 19, 2017 at 10:38:57AM -0400, Andrew Cagney wrote:
> where it sends out the AUTH reply (an st_event), and a short while later
> sends out an XAUTH request (an st_send_xauth_event, recent changes mean it
> is generated from scratch and doesn't replace the AUTH reply?).
>
> With this, th
Yea,
My fix is similar except I moved the code to before the switch - this bug
really isn't specific to PAM and other XAUTH algorithms need to do the same
thing. I'll push my fix
Andrew
On 19 October 2017 at 15:41, Antony Antony wrote:
> On Thu, Oct 19, 2017 at 10:38:57AM -0400, Andrew Cagne
