shaper does not work in linux clients

[JJK]

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.

[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.

[Samuli Seppänen]

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

[Samuli Seppänen]

Assigning this ticket to its original reporter.

[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.

[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));

[Gert Döring]

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.

[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)

[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

[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()".

[Gert Döring]

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.