Re: Error when executing ./autogen.sh
On Sun, 2020-04-19 at 18:13 +0200, videoclocknet wrote: > Guys, with Ubuntu Server 18.04 I've got the following message when > executing ./autogen.sh: > > # ./autogen.sh > autoheader: warning: missing template: LIBPROXY_HDR > autoheader: Use AC_DEFINE([LIBPROXY_HDR], [], [Description]) > > So the configure file is not finally generated. I had pkg-config > package installed in its last version > > It seems that's happening to more people in other distros: > https://github.com/dlenski/openconnect/issues/3 > https://github.com/dlenski/openconnect/issues/37 > > I've got to solve it by passing the description argument when defining > the LIBPROXY_HDR library. So if you've got: > > AC_DEFINE([LIBPROXY_HDR], ["proxy.h"]) > > You need to change it to: > AC_DEFINE([LIBPROXY_HDR], ["proxy.h"], [libproxy header file]) > > This is at lines 729 and 735 of configure.ac file. Thanks for the report. > - Is there any reason to not pass the description argument in these 2 cases? No reason. I just failed to add it when I added the description to most other AC_DEFINE macros, when autoconf started whining about it a few years ago. > - Would it be appropriate to make this change on master? Yes, I've done so. Thanks. smime.p7s Description: S/MIME cryptographic signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: GlobalProtect connection loss
On Tue, Apr 21, 2020 at 5:11 AM The Wanderer wrote: > > On 2020-04-20 at 22:26, Daniel Lenski wrote: > > > On Mon, Apr 20, 2020 at 7:20 PM The Wanderer > > 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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: GlobalProtect connection loss
On 2020-04-20 at 22:26, Daniel Lenski wrote: > On Mon, Apr 20, 2020 at 7:20 PM The Wanderer > 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 signature.asc Description: OpenPGP digital signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
