On Tue, Apr 21, 2020 at 5:11 AM The Wanderer <wanderer@xxxxxxxxxxx> wrote: > > On 2020-04-20 at 22:26, Daniel Lenski wrote: > > > On Mon, Apr 20, 2020 at 7:20 PM The Wanderer <wanderer@xxxxxxxxxxx> > > wrote: > > > >> If no difference is made, then barring any further lightbulbs, I'll > >> bite the bullet and bisect. I think this is a promising lead, > >> though, and I do thank you for investigating this far. > > > > Sounds good. I am very cautiously optimistic that running with the > > hipreport.sh script specified will fix it, and if that's the case > > then I am very confident that the patch will make OpenConnect do the > > Right Thing even when no HIP script is specified. And apparently the > > Right Thing is to ask the server a question where we already know > > the answer, over and over and over… > > I am pleased to report that when I woke up this morning, the tunnel was > still up, and the ping was still running with no signs of a problem. > > I killed the ping, and was able to separately ping a different address > which happens to be across the VPN. Hooray! > The log (about 1.3MB; I'm not planning to obfuscate it for sharing > unless necessary) contains what looks like seven HIP-report check-ins, > with three rekeys, and stretches from 22:17 last night to 7:55 this > morning (EST). > > There *was* one snag; /etc/resolv.conf had reverted to my non-VPN form, > so I couldn't do DNS lookups on any trans-VPN systems, I had to ping > them by known IP address. However, I suspect that that's a side effect > of my misunderstanding the requirements of what the routing-etcetera > script needs to look like and do, and will be resolved when I get that > replaced; unless it persists past that point, I don't think we need to > investigate it here. Yep, likely a problem with vpnc-script or NetworkManager. Has nothing to do with the tunnel staying up. > My guess as to why the server behaves this way is that just because the > answer is "no HIP report needed" once, doesn't mean it will *always* be > that, so it wants the client to keep checking in case the answer has > changed. Since the official client and server come from the same people, > I can very easily imagine the server being coded such that it assumes > the client will always do this check (because the client in their > control always does) and doesn't know what to do if that assumption is > violated. Yep, that's basically my conjecture as well. Thanks for helping elucidate this very obscure and hard-to-test corner of the GP protocol. > Thanks very much again for tracking this down this far. I'll test the > patched version once it's available (I may or may not build it myself, > since cleaning it back out of the system once installed would be a pain > unless the build-and-install method was a Debian package), and let you > know about any further issues, but it looks like this did in fact solve > the problem. https://gitlab.com/openconnect/openconnect/-/merge_requests/95 We'll get this into a release; for the time being you have a workaround at least. Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
