On Sun, Apr 19, 2020 at 3:57 PM The Wanderer <wanderer@xxxxxxxxxxx> wrote: > > On 2020-04-19 at 15:04, The Wanderer wrote: > > > On 2020-04-19 at 14:30, Daniel Lenski wrote: > > > >> On Sun, Apr 19, 2020 at 4:54 AM The Wanderer > >> <wanderer@xxxxxxxxxxx> wrote: > > >>> Do I need to do the work to obfuscate the full log, or is this > >>> enough to point us somewhere that might be useful? Should I try > >>> connecting again (I've shut down the tunnel now) and actually > >>> using this VPN for a while, to see whether I notice any lag etc. > >>> after the rekey occurs? > >> > >> I suggest that you try running openconnect without any kind of > >> wrapper script, just "openconnect -u user --prot=gp > >> server.compay.com/whatever --dump -vvvvv 2>&1 | tee > >> openconnect.log". Do that in a terminal and see how it runs. It > >> appears that the wrapper scripts you're using are adding a > >> significant amount of confusion about what's going on here. > > > > I don't really see how they're doing that, but sure, I can do this > > for one session's worth. > > A brother of mine who is my superior in shell scripting has pointed out > that the order of redirection operators matters. Apparently '2>&1 >> > file' - which is what I was using - doesn't actually redirect stderr to > the file, but '>> 2>&1 file' does, for reasons connected to how the > shell handles file descriptors under the hood. (And confusingly so, > given that '2>&1 | tee file' works, and I suspect '| 2>&1 tee file' > would not.) > > > I've got it running now (using the command from my innermost > > non-routing-script script, verbatim except for omitting > > --passwd-on-stdin and recombining it back onto one line, with that > > redirection modification added). I'll go grocery shopping pretty > > soon, and close the session and report results before the end of the > > night. The every-30-seconds ping keepalive to a machine across the > > VPN is running alongside it. > > > > This is with 8.05, by the way - the version from the most recent set > > of logs, which so far has not seen the connection drop like this. I > > can run a similar check (most likely overnight tonight) with 8.08, if > > desired. > > The result of this, from about 3.3 hours' worth, is attached - again > trimmed to head (ending a reasonable distance after the tunnel starts > normal operation) and tail (starting a reasonable distance before the > rekey, ending with EOF), compressed, and obfuscated probably more than > is necessary. Everything in this log looks perfectly 100% fine. You connect, you get a 180 minute rekey interval, 179 minutes later OpenConnect does a rekey, it reconnects to ESP… everything works fine. Matches my own testing with versions ranging from pre-v8.0 to v8.08. > If you need me to do the 8.08 equivalent, please let me know as soon as > reasonably practical. I expect it will give the same result. > I've discovered one reason to keep using a wrapper script for calling > openconnect. When I exited with Ctrl+C (which as I understand matters > should be producing SIGINT), which in the past has apparently killed the > wrapper script and led openconnect to exit cleanly, this time it > apparently terminated openconnect where it sat - with the result that > my original /etc/resolv.conf, adjusted by the Debian-shipped vpnc > routing script, was left in its tunnel-up state. Sending SIGINT (Ctrl-C) or SIGTERM to OpenConnect *is* the correct way to close it cleanly. When OpenConnect receives SIGINT or SIGTERM, it runs the vpnc-script with reason=disconnect, sends a logout to the VPN server, and closes the tunnel. This has been the case since v8.0. Prior to v8.0, SIGINT behaved more like SIGHUP: it would run the vpnc-script to remove the routes, and would close the tunnel, but *would not* send a logout request to the VPN server. If this isn't working correctly, I'll again conjecture that it's because of your wrapper scripts. Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
