(I hope this doesn't break threading. If it does, let me know and I'll subscribe for any further replies.) On 2020-04-13 at 19:50, Daniel Lenski wrote: > On Mon, Apr 13, 2020 at 4:35 PM The Wanderer <wanderer@xxxxxxxxxxx> > wrote: > >> I'm currently running OpenConnect 8.08, installed via the package >> available in Debian testing. >> >> Until a few days ago or so, I was running version 8.05, which was >> at that time the latest available in Debian testing. >> >> Prior to that (for at most a week at the end of March), I was >> apparently running version 8.0.2, again installed via Debian >> testing. >> >> >> I am connecting to a GlobalProtect VPN, and using that to RDP to a >> Windows machine (via XFreeRDP), for eight hours or so a day. (You >> can probably guess why.) >> >> Prior to one of the version upgrades described above, I was able >> to remain connected for the entire period, without significant >> issues. I did not pay close enough attention to be certain which >> one, but I believe it was the transition from 8.05 to 8.08. >> >> After the upgrade, I appear to be seeing the connection drop every >> three hours to the minute - although not quite to the second; it >> seems to be something between 18 and ~45 seconds past the exact >> three-hour mark when the drop happens. I haven't tried to get this >> in any more detail than that, as of yet. >> >> According to the log which I generate by appending openconnect's >> stdout and (theoretically) stderr into a file, the "Tunnel timeout >> (rekey interval) and "Idle timeout" are both 180 minutes, which is >> that three hours. > > Good sleuthing so far. > > However, there were *no changes* to the handling of rekey between > v8.05 and v8.08 (at least none intended): > https://gitlab.com/openconnect/openconnect/-/compare/v8.05...v8.08#efecf80fa476ca5abf1502940e60d7984c6d1df9 > > There were *also* no intentional changes to the handling of rekey > between v8.02 and v8.08: > > https://gitlab.com/openconnect/openconnect/-/compare/v8.02...v8.08#efecf80fa476ca5abf1502940e60d7984c6d1df9 And I gather that there's no plausible way the idle timeout could be involved - e.g. with something mistakenly thinking we've been idle for the entire time, instead of having had ongoing active traffic? >> Because of the way I initiate the connection and generate that log, >> I don't actually know which of the messages in it come from normal >> operation and which come "at the end" when the connection is >> dropping or has dropped; I plan to copy the file out of the way for >> examination next time the connection drops, but that isn't expected >> to be until tomorrow, and depending on what's going on when the >> drop happens I may not be able to spare the time. >> >> Also starting after what I believe is the same upgrade, I have >> been getting >> >>> GlobalProtect login returned unexpected argument value arg[19]=4 >>> Please report 1 unexpected values above (of which 0 fatal) to >>> <openconnect-devel@xxxxxxxxxxxxxxxxxxx> >> >> on every connection. Whether this is related to the connection >> drops, or merely a coincidence of the new version, I don't know. > > This has nothing to do with the connection drops. I added this > purely as a diagnostic to help us gather information about parameters > from the GlobalProtect protocol whose meaning we don't yet > understand. In previous versions, this was simply ignored. That makes sense. > This particular one has already been reported; we still don't > understand what it means, but it's very common. ¯\_(ツ)_/¯ I saw some of those discussions in looking at the archives before I reported this. If I get a chance to figure out what that means, I'll be sure to pass any (visibly) potentially relevant information along. >> Anything I can do to help track this down? So far none of these >> connection drops have been timed to be a practical problem, but at >> some point one is going to come while I'm in the middle of a voice >> or even video call across the VPN, and that's going to be >> noticeable. > > Run it with `openconnect -vvvv --dump --timestamp`, and save that to > a file. The log size may be huge after ~3 hours, but it'll give you > precise timestamps for all messages. How huge are we talking about? A few hundred megabytes? A few gigabytes? My /tmp/ is only 6GB or so, but if the file is likely to fit there with room to spare it'll be less setup-modification hassle for me to drop it there instead of somewhere in my more-permanent bulk storage. > One of the messages that you should be looking for shortly before > the 3 hour mark is "GlobalProtect rekey due." That's showing up in the logs I have already, but there's no apparently relevant information in the logs around that, presumably because I'm only at default verbosity. I'll try this alternate connection tomorrow, and see what the results are. -- 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
