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. 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. 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. 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. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
