Opened 9 years ago

Last modified 4 years ago

#91 assigned Bug / Defect

shaper does not work in linux clients

Reported by: JJK Owned by: JJK
Priority: minor Milestone: release 2.3.14
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
Cc:

Description

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 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
64 bytes from 192.168.200.1: 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 (11)

comment:1 Changed 9 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 7 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 7 years ago by Samuli Seppänen

Keywords: shaper, linux, iperfshaper linux iperf

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

Owner: set to JJK
Status: newassigned

Assigning this ticket to its original reporter.

comment:5 Changed 5 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 5 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 5 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 5 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 4 years ago by Samuli Seppänen

Milestone: release 2.3.9release 2.3.12

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

Milestone: release 2.3.12release 2.3.14

comment:11 Changed 4 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

#define TIME_BACKTRACK_PROTECTION 0

in syshead.h

Note: See TracTickets for help on using tickets.