Opened 12 years ago

Closed 22 months ago

#91 closed Bug / Defect (fixed)

shaper does not work in linux clients

Reported by: JJK Owned by: JJK
Priority: minor Milestone: release 2.5
Component: Networking Version: OpenVPN 2.1.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: shaper linux iperf


in OpenVPN 2.1 the option --shaper does not work well on linux clients. If I specify

--shaper 100000

on a Linux client I see as 'iperf' performance
[ 3] 0.0-16.6 sec 48.0 KBytes 23.7 Kbits/sec

what's worse is that after the 'iperf' test, the openvpn server is unreachable for quite some time, and when it *does* respond, the ping times are really bad:
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=18634 ms

This is completely reproducible on various flavours of Linux.
The exact same thing works fine with OpenVPN 2.0.
Also, Windows clients do not seem to be affected.

Change History (13)

comment:1 Changed 11 years ago by willbryant

I think it's not working properly for me either. shaper 1470000 seems to work, but 1480000 will allow full speed without shaping.

Perhaps an overflow bug of some kind?

I'm using 2.1.0, ubuntu's package from Lucid.

comment:2 Changed 10 years ago by Samuli Seppänen

Can this be reproduced on recent openvpn versions, e.g. 2.3.x or Git master?

comment:3 Changed 9 years ago by Samuli Seppänen

Keywords: shaper, linux, iperfshaper linux iperf

comment:4 Changed 8 years ago by Samuli Seppänen

Owner: set to JJK
Status: newassigned

Assigning this ticket to its original reporter.

comment:5 Changed 8 years ago by JJK

For the record: this bug can be reproduced using v 2.3.6 and Git master.
I don't have the time right now to dive into the source code to find the root cause.

comment:6 Changed 7 years ago by kb4fxc

I found the cause of this issue and by hacking 4 lines of code, fixed the problem. The problem occurs in versions >= 2.1.0 due to an API incompatibility between the openvpn_gettimeofday() function and gettimeofday(), which was originally used.

The hack is simple: In the shaper.h header, just change the name of openvpn_gettimeofday to gettimeofday and recompile.

This resolves the issue for me. I didn't look for why openvpn_gettimeofday() is broken here. The "proper" fix would probably be to resolve the differences between the functions. I've tried this hack on 64-bit and 32-bit Linux boxes with success.

Here is a code fragment:

/*ASSERT (!openvpn_gettimeofday (&tv, NULL)); The original statement.... */
ASSERT (!gettimeofday (&tv, NULL));

comment:7 Changed 7 years ago by Gert Döring

Milestone: release 2.3.9

janjust, could you check this quick fix and send a formal patch? Then this could nicely go into 2.3.9

@kb4fxc: thanks for finding this, and sorry for letting this lie around for so long.

comment:8 Changed 7 years ago by Gert Döring

Mmmh. Magic code #ifdef TIME_BACKTRACK_PROTECTION (otime.h, openvpn_gettimeofday() has the same call convention as gettimeofday() but will adjust the time value returned under certain conditions)

comment:9 Changed 7 years ago by Samuli Seppänen

Milestone: release 2.3.9release 2.3.12

comment:10 Changed 6 years ago by Gert Döring

Milestone: release 2.3.12release 2.3.14

comment:11 Changed 6 years ago by Gert Döring

it could possibly be a bug in the TIME_BACKTRACK_PROTECTION code in otime.c/otime.h

With that, it *should* fix the issue if one sets


in syshead.h

comment:12 Changed 2 years ago by Gert Döring

see also

commit e9e47f498674f6db8c3b88b32c877c5beb09a888 (master)
commit 51ee3574faade4dae5762140ea9f3a5eadc9d1e3 (release/2.5)
Author: Vladislav Grishenko
Date: Tue Sep 22 22:08:41 2020 +0500

Fix update_time() and openvpn_gettimeofday() coexistence

which might be closer to the root cause than "just use gettimeofday()".

comment:13 Changed 22 months ago by Gert Döring

Milestone: release 2.3.14release 2.5
Resolution: fixed
Status: assignedclosed

Since I never heard back here, I assume that this is fixed in 2.5.0 and later and will close this ticket now.

Not sure we'll backport this to the 2.4 series - if someone really urgently wants that, let us know.

Note: See TracTickets for help on using tickets.