[Openvpn-devel] OpenVPN 2.0 Yo-Yo effect...
Hi, Since I've upgraded to OpenVPN 2, I've started seeing an interesting effect. Originally (way back at _test23) it didn't happen very much, and seemingly a restart of either the server or client would fix it, but recently it's been happening a lot. For historical reasons (I used to be on windows) I set my ping and ping-reset times to very low values (10 and 60) so that I'd see the adaptor go down within a minute of when my connection went down. Under the old 1.5 vpns this was fine, but since the upgrade some of the windows installation's I've used have reported that the openvpn adaptor goes up and down every couple of minutes and in the recent _beta2 it seems to happen quite often (although it's still random in that sometimes it won't). So far I've observed this between windows-windows and windows-linux machines. I haven't seen it between linux and linux boxes, but that may be because it's harder to spot (since there isn't an adaptor up/down indicator by default). Having checked some recent logs I haven't seen it happen much between linux-linux (just the hourly key-expiration). Unfortunately the closest example I have to hand doesn't have client ping-reset as well as server ping-reset. The log for the client list says it's starting up ok, then one line saying replay window backtrack and then no other messages (for about half a day in fact), and the server reports inactivity timesout approximately every minute or so. As far as I'm aware the internet connections are fine. So basically I was wondering if there was something in the ping code, or the inactivity checker that may have changed that someone knows about which could account for this behaviour? I'll be happy to provide configs/logs if they'd be at all helpful... Thanks, Mike 5:)
Re: [Openvpn-devel] OpenVPN 2.0 Yo-Yo effect...
On Saturday 05 June 2004 15:36, Mike Auty wrote:
> Hi,
> Since I've upgraded to OpenVPN 2, I've started seeing an interesting
> effect. Originally (way back at _test23) it didn't happen very much,
> and seemingly a restart of either the server or client would fix it, but
> recently it's been happening a lot.
> For historical reasons (I used to be on windows) I set my ping and
> ping-reset times to very low values (10 and 60) so that I'd see the
> adaptor go down within a minute of when my connection went down. Under
> the old 1.5 vpns this was fine, but since the upgrade some of the
> windows installation's I've used have reported that the openvpn adaptor
> goes up and down every couple of minutes and in the recent _beta2 it
> seems to happen quite often (although it's still random in that
> sometimes it won't).
Try this patch
--
vda
--- ping-inline.h.orig Wed Apr 21 08:03:22 2004
+++ ping-inline.h Sun May 30 18:07:54 2004
@@ -50,9 +50,10 @@
{
void check_ping_send_dowork (struct context *c);
if (c->options.ping_send_timeout
- && !c->c2.to_link.len
&& event_timeout_trigger (&c->c2.ping_send_interval,
-&c->c2.timeval))
+&c->c2.timeval)
+ && !c->c2.to_link.len
+)
check_ping_send_dowork (c);
}
Re: [Openvpn-devel] OpenVPN 2.0 Yo-Yo effect...
Thanks for the super fast reply, Sadly I don't have the facilities to build a new windows version. Would you mind exaplaining briefly what it does? It only seems to change the order of two checks, but I'm not sure what they do. Thank again, Mike 5:)
Re: [Openvpn-devel] OpenVPN 2.0 Yo-Yo effect...
On Saturday 05 June 2004 21:46, Mike Auty wrote: > Thanks for the super fast reply, > Sadly I don't have the facilities to build a new windows version. > Would you mind exaplaining briefly what it does? It only seems to > change the order of two checks, but I'm not sure what they do. Thank > again, Mike 5:) If there happens to be a packet to send when openvpn checks whether it needs to send a ping, openvps erroneously decide to set ping interval timeout to 365 days. -- vda
Re: [Openvpn-devel] OpenVPN 2.0 Yo-Yo effect...
Denis Vlasenko said: > On Saturday 05 June 2004 21:46, Mike Auty wrote: > > Thanks for the super fast reply, > > Sadly I don't have the facilities to build a new windows version. > > Would you mind exaplaining briefly what it does? It only seems to > > change the order of two checks, but I'm not sure what they do. Thank > > again, Mike 5:) > > If there happens to be a packet to send when openvpn checks whether > it needs to send a ping, openvps erroneously decide to set ping > interval timeout to 365 days. This is a known bug in 2.0-beta2 and will be fixed in beta3 which I expect to release within a day or two. James
[Openvpn-devel] OpenVPN 2.0-beta3 released
Change Log: 2004.06.05 -- Version 2.0-beta3 * More changes to TAP-Win32 driver's INF file which affects the placement of the driver in the Windows device namespace. This is done to work around an apparent bug in Windows when short HWIDs are used, and will also ease the upgrade from 1.x to 2.0 by reducing the chances that a reboot will be needed on upgrade. Like beta2, this upgrade will delete existing TAP-Win32 interfaces, and reinstall a single new interface with default properties. * Major rewrite of I/O event wait layer in the style of libevent. This is a precursor to TCP support in --mode server. * New feature: --status. Outputs a SIGUSR2-like status summary to a given file, updated once per n seconds. The status file is comma delimited for easy machine parsing. * --ifconfig-pool now remembers common names and will try to assign a consistent IP to a given common name. Still to do: persist --ifconfig-pool memory across restarts by saving state in file. * Fixed bug in event timer queue which could cause recurring timer events such as --ping to not correctly schedule again after firing. This in turn would cause spurrious ping restarts and possible connection outages. Thanks to Denis Vlasenko for tracking this down. * Possible fix to reported bug where --daemon argument was not printing to syslog correctly after restart. * Fixed bug where pulling --route or --dhcp-option directives from a server would problematically interact with --persist-tun on the client. * Updated contrib/multilevel-init.patch (Farkas Levente). * Added RPM build option to .spec and .spec.in files to optionally disable LZO inclusion (Ian Pilcher). * The latest MingW runtime and headers define 'ssize_t', so a patch is needed (Gisle Vanem). James
