Opened 12 years ago

Closed 11 years ago

#209 closed Bug / Defect (fixed)

2.3: options not pushed sucessfully in server mode after client restart

Reported by: lvp Owned by: David Sommerseth
Priority: blocker Milestone: release 2.3
Component: Generic / unclassified Version: OpenVPN git master branch (Community Ed)
Severity: Patch Queue: Merged Keywords: push

Description (last modified by Eric Crist)

A system is setup in server mode for IPv6 access (only) since early 2011 on Debian squeeze running (and earlier). Exchanging with openvpn_2.3-alpha1-debian0_i386.deb (identical configuration apart fromDN syntax in verify script), I can reproduce the following problem. Also with self-compiled versions from openvpn-201219.tar.gz and some other back to 201135 (201130, 201120, 201117 do segfault on start). (This test case done on x86_64 system.)

Everything is fine if there is no active instance on the server for the connecting client. But if the client is restarted and not timed out on the server, option pull/push is not working correctly. PUSH_REQUEST is sent every 5 seconds but not replied to. See attached server log for both cases (addresses etc. modified, verb 6).

Client is 2.1.4 on OpenWRT, in this case. (Setup pushes environment variables to allow IPv6 setup in client up-script without new IPv6 support there.)

server side openvpn --version
OpenVPN 2.3-alpha1 x86_64-linux-gnu [SSL (OpenSSL)] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110522-1 (2.2.0)] built on Feb 21 2012
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@…>

$ ./configure --enable-pthread --enable-password-save --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=${prefix}/share/man --with-ifconfig-path=/sbin/ifconfig --with-route-path=/sbin/route CFLAGS=-g -O2 build_alias=x86_64-linux-gnu host_alias=x86_64-linux-gnu LDFLAGS= CPPFLAGS= --no-create --no-recursion



Attachments (1)

openvpn-push-problem.log (96.7 KB) - added by lvp 12 years ago.

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by lvp

Attachment: openvpn-push-problem.log added

comment:1 Changed 12 years ago by Eric Crist

Description: modified (diff)

comment:2 Changed 12 years ago by lvp

May I ask if there is any reason for me to test a newer build regarding this bug?

comment:3 Changed 12 years ago by David Sommerseth

Keywords: push added
Milestone: release 2.3beta 2.3
Owner: set to David Sommerseth
Priority: majorblocker
Severity: Not set (if unsure, select this one)Patch Queue: In progress
Status: newaccepted
Version: 2.3-beta / 2.3-RCgit master branch

This bug is most likely related to this proposed patch: [PATCH Fix reconnect issues when --push and UDP is used on the server]

I've seen this issue from the beginning of the 2.3 code base, so it's a regression since 2.2. As you can see from the patch, the bug and the patch introducing it has been identified. Now we're waiting for James Yonan to weight in on this issue as well. But if that doesn't happen reasonably soon, we'll apply the patch above and provide a better fix later on if that makes sense.

But please feel free to try the latest git tree and apply this patch on top of it.

comment:4 Changed 12 years ago by David Sommerseth

Milestone: beta 2.3release 2.3
Severity: Patch Queue: In progressPatch Queue: Merged

A partial fix has been committed.

commit 5d4f5435a421299ed047485d8d99bdf9a0d22fd1
Author: David Sommerseth <>
Date:   Sun Sep 9 03:30:46 2012 +0200

    Fix reconnect issues when --push and UDP is used on the server
    When the server is configured with UDP and --push statements, reconnecting
    often fails by the client never receiving PUSH_REPLY.  The client sends
    PUSH_REQUEST and the server logs these requests but does not send them.
    This bug got introduced in commit ff65da3a230b658b2c1d52dc1a48612e80a2eb42
    which tries to avoid sending duplicated PUSH messages if the client/server
    connection is slow.
    This patch keeps this behaviour, but instead of a session wide PUSH_REPLY
    block it sets an expiry time for the PUSH_REPLY block.  The expiry time
    is set to 30 seconds.
    Signed-off-by: David Sommerseth <>
    Cc: James Yonan <>
    Acked-by: Gert Doering <>
    Acked-by: James Yonan <>

This will certainly improve things, but we're still investigating if there is a better fix for it.

comment:5 Changed 11 years ago by David Sommerseth

Resolution: fixed
Status: acceptedclosed

Closing this as fixed, as there has been no response to this ticket since the 2.3.0 release. The referenced commit should solve this behaviour too, and other reports have indicated this as well.

$ git tag --contains 5d4f5435a421299ed047485d8d99bdf9a0d22fd1
Note: See TracTickets for help on using tickets.