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. If you need me to do the 8.08 equivalent, please let me know as soon as reasonably practical. 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. I was able to recoonstruct that file to a functional state (and, honestly, probably verbatim except for the comments) from memory, and as far as I can see nothing else seems to have been left un-cleaned-up (aside from a couple of useless but should-be-harmless routes) - but that was an unexpected behavior, the more so given that I don't find any special mention of how to safely exit by searching the openconnect man page for 'exit|quit|close'. Is this behavior expected? If so, what's the safe way to exit and shut things down, from a direct invocation like this? -- 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:
vpn-3hours-nodisconnect-fullmanualinvocation-headtail-obfuscated.log.7z
Description: application/7z-compressed
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
