Re: [Openvpn-devel] OVPN vs IPSec performance as a transport

[Antonio Quartulli]

Hi,

On 05/01/18 15:06, Simon Matter wrote:
> Hi,
> 
>> That would explain it if it always worked that way.
>> But I can get 400%+ wire speed from A to B with compressible data, and
>> 102% with incompressible data.  If I do the same test from B to A or A
>> to B, I get those results.  If I hop off of that to C, speed goes from
>>> 1Gbps to sub-200Mbps.  In either case, the data has left the kernel
>> space to arrive at "nc", so just simply saying "it's kernel vs user"
>> doesn't answer it.
> 
> So if I understand correctly you are able to get wire speed over the
> OpenVPN link as long as you don't route traffic further via an other
> simple router?
> 
> Maybe you could try those two things:
> 1) Disable all LZO compression just to make sure it has nothing to do with
> it.
> 
> 2) Run tcpdump/wireshark on B and look in detail how data is moved over
> the different tun and ethernet devices. I'm sure you should see something
> there at least if you compare it with a run made without OpenVPN.

I agree on this point. If the slowdown comes from here, you should
definitely see something.

> 
> BTW, you don't have any iptables rules on any of the boxes, do you?
> 

Good point: iptables/ebtables can kill performances quite fast.
Are doing pure routing between the VPN tunnel and the Ethernet
interface? Or there is some NAT involved?

Cheers,


-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OVPN vs IPSec performance as a transport

[Simon Matter]

Hi,

> That would explain it if it always worked that way.
> But I can get 400%+ wire speed from A to B with compressible data, and
> 102% with incompressible data.  If I do the same test from B to A or A
> to B, I get those results.  If I hop off of that to C, speed goes from
>>1Gbps to sub-200Mbps.  In either case, the data has left the kernel
> space to arrive at "nc", so just simply saying "it's kernel vs user"
> doesn't answer it.

So if I understand correctly you are able to get wire speed over the
OpenVPN link as long as you don't route traffic further via an other
simple router?

Maybe you could try those two things:
1) Disable all LZO compression just to make sure it has nothing to do with
it.

2) Run tcpdump/wireshark on B and look in detail how data is moved over
the different tun and ethernet devices. I'm sure you should see something
there at least if you compare it with a run made without OpenVPN.

BTW, you don't have any iptables rules on any of the boxes, do you?

And, you could check all the kinds of checksumming and offloading on your
ethernet interfaces. Those settings can have a huge impact if they do
things wrong.

Regards,
Simon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OVPN vs IPSec performance as a transport

[Samuli Seppänen]

This does not answer your question, either, but there are more details
on OpenVPN performance optimization here:



Increasing the MTU helps as it reduces the number of user<->kernel-space
switches.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Il 05/01/2018 01:52, Tom Kunz ha scritto:
> That would explain it if it always worked that way.
> But I can get 400%+ wire speed from A to B with compressible data, and
> 102% with incompressible data.  If I do the same test from B to A or A
> to B, I get those results.  If I hop off of that to C, speed goes from
>>1Gbps to sub-200Mbps.  In either case, the data has left the kernel
> space to arrive at "nc", so just simply saying "it's kernel vs user"
> doesn't answer it.
> 
> 
> On 01/04/2018 06:37 PM, Greg Sloop  wrote:
>> I'm sure someone else, or a Google search will get you a more detailed
>> run-down - but the gist of the "problem" is this;
>>
>> OpenVPN is run in user-space, not kernel space. IPSec  runs in kernel
>> space, and the difference is vastly diminished throughput.
>>
>> HTH
>>
>> -Greg
>>
>> On Jan 4, 2018 3:23 PM, "Tom Kunz" > > wrote:
>>
>> Hi,
>>
>> I have been testing OVPN 2.4.4 vs StrongSwan IPSec, to be used as
>> transport, and I have found something that I think might be a
>> performance issue.  I have 3 linux boxes, A, B, and C.  All interfaces
>> are 1Gbps.  Each has an interface to the next one downstream:
>>
>> A - eth0=10.10.10.10/24  and
>> eth1=172.16.0.10/24 
>>
>> B - eth0=172.16.0.11/24  and
>> eth1=172.30.0.11/24 
>>
>> C - eth0=172.30.0.10/24  and
>> eth1=192.168.168.10/24 
>>
>> Packets route as usual through this with no encryption, and throughput
>> from A to C is at wire speed.  With IPSec between A, from
>> 172.16.0.10-172.16.0.11, I can still get wire speed from A to C. 
>> Then I
>> turn off IPSec, and I setup A as the server and B as the client, with
>> A's config being:
>>
>> =
>>
>> dev tun
>>
>> topology subnet
>> server 172.17.0.0 255.255.255.0
>> port 1194
>> proto udp
>> dh /etc/openvpn/keys/dh2048.pem
>> ca /etc/openvpn/keys/ca.crt
>> cert /etc/openvpn/keys/server.crt
>> key /etc/openvpn/keys/server.key
>> verb 3
>> keepalive 10 45
>> cipher aes-256-cbc
>> comp-lzo
>>
>> tun-mtu 5
>>
>> mssfix 0
>>
>> fragment 0
>>
>> client-config-dir ccd
>>
>> push "route 10.10.10.0 255.255.255.0"
>>
>> =
>>
>> and the client B config file is
>>
>> =
>>
>> verb 3
>> client
>> cipher AES-256-CBC
>> comp-lzo
>> tun-mtu 5
>> mssfix 0
>> fragment 0
>> remote 172.16.0.10  1194
>>
>> dev tun
>> redirect-private local
>> tls-client
>>
>> ca /etc/openvpn/keys/ca.crt
>> cert /etc/openvpn/keys/client1.crt
>> key /etc/openvpn/keys/client1.key
>>
>> =
>>
>> and I setup static routes on each side so that traffic is going
>> through
>> the tunnel from A to C and vice versa.
>>
>> I can pass traffic over this link, however when I do tests for
>> speed, I
>> am only getting about 200Mbps instead of 1Gbps.
>>
>> The funny thing is, I know that each of these machines can easily do
>> 1Gbps.  If I do my performance test from A to B, over the above ovpn
>> configs, I can get just over 1Gbps because of the MTU overhead being
>> removed. But as soon as I have it make the leap downstream once
>> more, I
>> lose 80+% of the speed.  And again, both non-encrypted traffic and
>> IPSec
>> do the exact same test at wire speed or just slightly under wire
>> speed.
>>
>> The way I do a speed test is on A:
>>
>> # nc -l -p  > /dev/null
>>
>> and over on C:
>>
>> # dd if=/dev/urandom of=blob.random.1G bs=10M count=100
>>
>> # time cat blob.random.1G | nc 10.10.10.10 
>>
>> tcpdumps over each interface confirm traffic is flowing in the
>> expected
>> fashion.
>>
>> Over unencrypted or IPSec, I am looking at about 4s to move 1G of data
>> from one end to the other, and with ovpn, 15-22s.  The machines
>> involved
>> are 2 Dell R720's with 8+G ram and a homebrew machine with several
>> Xeons
>> and 32G RAM.  Network cards involved are a mix of BCM Tigon3 "tg3"
>> driver and IGB driver gigabit NICs.
>>
>> Anyone have any suggestions or thoughts as to why the big perf
>> decrease
>> and what might be done to improve it?
>>
>> Thanks, 
>>
>> Tom
>>
>>
>>
>>
>> 
>> --

Re: [Openvpn-devel] [PATCH v3] travis-ci: add brew cache, remove ccache

[Илья Шипицин]

2018-01-05 3:23 GMT+05:00 Antonio Quartulli :

>
>
> On 05/01/18 03:37, Ilya Shipitsin wrote:
> > 1-2 minutes speedup osx builds by using brew cache.
> > Also, ccache was removed for a while (builds fail
> > after travis-ci upgraded clang to version 5.0.0)
> > ---
> > v2: this is a "v2" of previously issued "enable ccache for osx and mingw
> builds"
> > patch. I decided not to enable ccache for mingw builds as it does not
> > speedup them
> >
> > v3: removed ccache at all, because it fails on clang-5.0.0
>
> Does this patch make "[PATCH] travis-ci: speedup osx build by enabling
> brew cache​" obsolete?
>

yes


>
>
> Regards,
>
>
> --
> Antonio Quartulli
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OVPN vs IPSec performance as a transport

[Tom Kunz]

That would explain it if it always worked that way.
But I can get 400%+ wire speed from A to B with compressible data, and
102% with incompressible data.  If I do the same test from B to A or A
to B, I get those results.  If I hop off of that to C, speed goes from
>1Gbps to sub-200Mbps.  In either case, the data has left the kernel
space to arrive at "nc", so just simply saying "it's kernel vs user"
doesn't answer it.


On 01/04/2018 06:37 PM, Greg Sloop  wrote:
> I'm sure someone else, or a Google search will get you a more detailed
> run-down - but the gist of the "problem" is this;
>
> OpenVPN is run in user-space, not kernel space. IPSec  runs in kernel
> space, and the difference is vastly diminished throughput.
>
> HTH
>
> -Greg
>
> On Jan 4, 2018 3:23 PM, "Tom Kunz"  > wrote:
>
> Hi,
>
> I have been testing OVPN 2.4.4 vs StrongSwan IPSec, to be used as
> transport, and I have found something that I think might be a
> performance issue.  I have 3 linux boxes, A, B, and C.  All interfaces
> are 1Gbps.  Each has an interface to the next one downstream:
>
> A - eth0=10.10.10.10/24  and
> eth1=172.16.0.10/24 
>
> B - eth0=172.16.0.11/24  and
> eth1=172.30.0.11/24 
>
> C - eth0=172.30.0.10/24  and
> eth1=192.168.168.10/24 
>
> Packets route as usual through this with no encryption, and throughput
> from A to C is at wire speed.  With IPSec between A, from
> 172.16.0.10-172.16.0.11, I can still get wire speed from A to C. 
> Then I
> turn off IPSec, and I setup A as the server and B as the client, with
> A's config being:
>
> =
>
> dev tun
>
> topology subnet
> server 172.17.0.0 255.255.255.0
> port 1194
> proto udp
> dh /etc/openvpn/keys/dh2048.pem
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/server.crt
> key /etc/openvpn/keys/server.key
> verb 3
> keepalive 10 45
> cipher aes-256-cbc
> comp-lzo
>
> tun-mtu 5
>
> mssfix 0
>
> fragment 0
>
> client-config-dir ccd
>
> push "route 10.10.10.0 255.255.255.0"
>
> =
>
> and the client B config file is
>
> =
>
> verb 3
> client
> cipher AES-256-CBC
> comp-lzo
> tun-mtu 5
> mssfix 0
> fragment 0
> remote 172.16.0.10  1194
>
> dev tun
> redirect-private local
> tls-client
>
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/client1.crt
> key /etc/openvpn/keys/client1.key
>
> =
>
> and I setup static routes on each side so that traffic is going
> through
> the tunnel from A to C and vice versa.
>
> I can pass traffic over this link, however when I do tests for
> speed, I
> am only getting about 200Mbps instead of 1Gbps.
>
> The funny thing is, I know that each of these machines can easily do
> 1Gbps.  If I do my performance test from A to B, over the above ovpn
> configs, I can get just over 1Gbps because of the MTU overhead being
> removed. But as soon as I have it make the leap downstream once
> more, I
> lose 80+% of the speed.  And again, both non-encrypted traffic and
> IPSec
> do the exact same test at wire speed or just slightly under wire
> speed.
>
> The way I do a speed test is on A:
>
> # nc -l -p  > /dev/null
>
> and over on C:
>
> # dd if=/dev/urandom of=blob.random.1G bs=10M count=100
>
> # time cat blob.random.1G | nc 10.10.10.10 
>
> tcpdumps over each interface confirm traffic is flowing in the
> expected
> fashion.
>
> Over unencrypted or IPSec, I am looking at about 4s to move 1G of data
> from one end to the other, and with ovpn, 15-22s.  The machines
> involved
> are 2 Dell R720's with 8+G ram and a homebrew machine with several
> Xeons
> and 32G RAM.  Network cards involved are a mix of BCM Tigon3 "tg3"
> driver and IGB driver gigabit NICs.
>
> Anyone have any suggestions or thoughts as to why the big perf
> decrease
> and what might be done to improve it?
>
> Thanks, 
>
> Tom
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 
>

--
Check out the vibrant tech 

Re: [Openvpn-devel] OVPN vs IPSec performance as a transport

[Greg Sloop <gr...@sloop.net>]

I'm sure someone else, or a Google search will get you a more detailed
run-down - but the gist of the "problem" is this;

OpenVPN is run in user-space, not kernel space. IPSec  runs in kernel
space, and the difference is vastly diminished throughput.

HTH

-Greg

On Jan 4, 2018 3:23 PM, "Tom Kunz"  wrote:

> Hi,
>
> I have been testing OVPN 2.4.4 vs StrongSwan IPSec, to be used as
> transport, and I have found something that I think might be a
> performance issue.  I have 3 linux boxes, A, B, and C.  All interfaces
> are 1Gbps.  Each has an interface to the next one downstream:
>
> A - eth0=10.10.10.10/24 and eth1=172.16.0.10/24
>
> B - eth0=172.16.0.11/24 and eth1=172.30.0.11/24
>
> C - eth0=172.30.0.10/24 and eth1=192.168.168.10/24
>
> Packets route as usual through this with no encryption, and throughput
> from A to C is at wire speed.  With IPSec between A, from
> 172.16.0.10-172.16.0.11, I can still get wire speed from A to C.  Then I
> turn off IPSec, and I setup A as the server and B as the client, with
> A's config being:
>
> =
>
> dev tun
>
> topology subnet
> server 172.17.0.0 255.255.255.0
> port 1194
> proto udp
> dh /etc/openvpn/keys/dh2048.pem
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/server.crt
> key /etc/openvpn/keys/server.key
> verb 3
> keepalive 10 45
> cipher aes-256-cbc
> comp-lzo
>
> tun-mtu 5
>
> mssfix 0
>
> fragment 0
>
> client-config-dir ccd
>
> push "route 10.10.10.0 255.255.255.0"
>
> =
>
> and the client B config file is
>
> =
>
> verb 3
> client
> cipher AES-256-CBC
> comp-lzo
> tun-mtu 5
> mssfix 0
> fragment 0
> remote 172.16.0.10  1194
>
> dev tun
> redirect-private local
> tls-client
>
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/client1.crt
> key /etc/openvpn/keys/client1.key
>
> =
>
> and I setup static routes on each side so that traffic is going through
> the tunnel from A to C and vice versa.
>
> I can pass traffic over this link, however when I do tests for speed, I
> am only getting about 200Mbps instead of 1Gbps.
>
> The funny thing is, I know that each of these machines can easily do
> 1Gbps.  If I do my performance test from A to B, over the above ovpn
> configs, I can get just over 1Gbps because of the MTU overhead being
> removed. But as soon as I have it make the leap downstream once more, I
> lose 80+% of the speed.  And again, both non-encrypted traffic and IPSec
> do the exact same test at wire speed or just slightly under wire speed.
>
> The way I do a speed test is on A:
>
> # nc -l -p  > /dev/null
>
> and over on C:
>
> # dd if=/dev/urandom of=blob.random.1G bs=10M count=100
>
> # time cat blob.random.1G | nc 10.10.10.10 
>
> tcpdumps over each interface confirm traffic is flowing in the expected
> fashion.
>
> Over unencrypted or IPSec, I am looking at about 4s to move 1G of data
> from one end to the other, and with ovpn, 15-22s.  The machines involved
> are 2 Dell R720's with 8+G ram and a homebrew machine with several Xeons
> and 32G RAM.  Network cards involved are a mix of BCM Tigon3 "tg3"
> driver and IGB driver gigabit NICs.
>
> Anyone have any suggestions or thoughts as to why the big perf decrease
> and what might be done to improve it?
>
> Thanks,
>
> Tom
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OVPN vs IPSec performance as a transport

[Tom Kunz]

Hi,

I have been testing OVPN 2.4.4 vs StrongSwan IPSec, to be used as
transport, and I have found something that I think might be a
performance issue.  I have 3 linux boxes, A, B, and C.  All interfaces
are 1Gbps.  Each has an interface to the next one downstream:

A - eth0=10.10.10.10/24 and eth1=172.16.0.10/24

B - eth0=172.16.0.11/24 and eth1=172.30.0.11/24

C - eth0=172.30.0.10/24 and eth1=192.168.168.10/24

Packets route as usual through this with no encryption, and throughput
from A to C is at wire speed.  With IPSec between A, from
172.16.0.10-172.16.0.11, I can still get wire speed from A to C.  Then I
turn off IPSec, and I setup A as the server and B as the client, with
A's config being:

=

dev tun

topology subnet
server 172.17.0.0 255.255.255.0
port 1194
proto udp
dh /etc/openvpn/keys/dh2048.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
verb 3
keepalive 10 45
cipher aes-256-cbc
comp-lzo

tun-mtu 5

mssfix 0

fragment 0

client-config-dir ccd

push "route 10.10.10.0 255.255.255.0"

=

and the client B config file is

=

verb 3
client
cipher AES-256-CBC
comp-lzo
tun-mtu 5
mssfix 0
fragment 0
remote 172.16.0.10  1194

dev tun
redirect-private local
tls-client

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key

=

and I setup static routes on each side so that traffic is going through
the tunnel from A to C and vice versa.

I can pass traffic over this link, however when I do tests for speed, I
am only getting about 200Mbps instead of 1Gbps.

The funny thing is, I know that each of these machines can easily do
1Gbps.  If I do my performance test from A to B, over the above ovpn
configs, I can get just over 1Gbps because of the MTU overhead being
removed. But as soon as I have it make the leap downstream once more, I
lose 80+% of the speed.  And again, both non-encrypted traffic and IPSec
do the exact same test at wire speed or just slightly under wire speed.

The way I do a speed test is on A:

# nc -l -p  > /dev/null

and over on C:

# dd if=/dev/urandom of=blob.random.1G bs=10M count=100

# time cat blob.random.1G | nc 10.10.10.10 

tcpdumps over each interface confirm traffic is flowing in the expected
fashion.

Over unencrypted or IPSec, I am looking at about 4s to move 1G of data
from one end to the other, and with ovpn, 15-22s.  The machines involved
are 2 Dell R720's with 8+G ram and a homebrew machine with several Xeons
and 32G RAM.  Network cards involved are a mix of BCM Tigon3 "tg3"
driver and IGB driver gigabit NICs.

Anyone have any suggestions or thoughts as to why the big perf decrease
and what might be done to improve it?

Thanks, 

Tom




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3] travis-ci: add brew cache, remove ccache

[Antonio Quartulli]

On 05/01/18 03:37, Ilya Shipitsin wrote:
> 1-2 minutes speedup osx builds by using brew cache.
> Also, ccache was removed for a while (builds fail
> after travis-ci upgraded clang to version 5.0.0)
> ---
> v2: this is a "v2" of previously issued "enable ccache for osx and mingw 
> builds"
> patch. I decided not to enable ccache for mingw builds as it does not
> speedup them
> 
> v3: removed ccache at all, because it fails on clang-5.0.0

Does this patch make "[PATCH] travis-ci: speedup osx build by enabling
brew cache​" obsolete?


Regards,


-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v3] travis-ci: add brew cache, remove ccache

[Ilya Shipitsin]

1-2 minutes speedup osx builds by using brew cache.
Also, ccache was removed for a while (builds fail
after travis-ci upgraded clang to version 5.0.0)
---
v2: this is a "v2" of previously issued "enable ccache for osx and mingw builds"
patch. I decided not to enable ccache for mingw builds as it does not
speedup them

v3: removed ccache at all, because it fails on clang-5.0.0

 .travis.yml   |  2 +-
 .travis/build-deps.sh | 10 --
 2 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 1f669b30..43217b59 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -78,10 +78,10 @@ addons:
   - man2html
 
 cache:
-  ccache: true
   directories:
   - download-cache
   - ${HOME}/opt
+  - ${HOME}/Library/Caches/Homebrew
 
 before_install:
   - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update ; fi
diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
index e787abab..bc538853 100755
--- a/.travis/build-deps.sh
+++ b/.travis/build-deps.sh
@@ -130,16 +130,6 @@ build_openssl () {
 fi
 }
 
-# Enable ccache
-if [ "${TRAVIS_OS_NAME}" != "osx" ] && [ -z ${CHOST+x} ]; then
-# ccache not available on osx, see:
-# https://github.com/travis-ci/travis-ci/issues/5567
-# also ccache not enabled for cross builds
-mkdir -p "${HOME}/bin"
-ln -s "$(which ccache)" "${HOME}/bin/${CC}"
-PATH="${HOME}/bin:${PATH}"
-fi
-
 if [ ! -z ${CHOST+x} ]; then
   #
   # openvpn requires at least mingw-gcc-4.9, which is available at xenial 
repo
-- 
2.14.3


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: speedup osx build by enabling brew cache

[Илья Шипицин]

wait a bit,

we might need to remove ccache (it became broken after travis-ci upgraded
to clang-5)

https://travis-ci.org/chipitsine/openvpn/jobs/325002858

2018-01-04 17:19 GMT+05:00 Ilya Shipitsin :

> 1-2 minutes speedup by using brew cache, also ccache
> is no more disabled for osx build (even it does not
> speedup significantly, it simplifies the overall script)
>
> ---
> this is a "v2" of previously issued "enable ccache for osx and mingw
> builds"
> patch. I decided not to enable ccache for mingw builds as it does not
> speedup them
>
>  .travis.yml   | 5 +++--
>  .travis/build-deps.sh | 7 ++-
>  2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 1f669b30..34e0ac04 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -82,10 +82,11 @@ cache:
>directories:
>- download-cache
>- ${HOME}/opt
> +  - ${HOME}/Library/Caches/Homebrew
>
>  before_install:
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update ; fi
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo; fi
> +  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update; fi
> +  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo ccache; fi
>
>  install:
>- if [ ! -z "${CHOST}" ]; then unset CC; fi
> diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
> index e787abab..e7036b6b 100755
> --- a/.travis/build-deps.sh
> +++ b/.travis/build-deps.sh
> @@ -130,11 +130,8 @@ build_openssl () {
>  fi
>  }
>
> -# Enable ccache
> -if [ "${TRAVIS_OS_NAME}" != "osx" ] && [ -z ${CHOST+x} ]; then
> -# ccache not available on osx, see:
> -# https://github.com/travis-ci/travis-ci/issues/5567
> -# also ccache not enabled for cross builds
> +# Enable ccache except cross builds
> +if [ -z ${CHOST+x} ]; then
>  mkdir -p "${HOME}/bin"
>  ln -s "$(which ccache)" "${HOME}/bin/${CC}"
>  PATH="${HOME}/bin:${PATH}"
> --
> 2.14.3
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] travis-ci: speedup osx build by enabling brew cache

[Ilya Shipitsin]

1-2 minutes speedup by using brew cache, also ccache
is no more disabled for osx build (even it does not
speedup significantly, it simplifies the overall script)

---
this is a "v2" of previously issued "enable ccache for osx and mingw builds"
patch. I decided not to enable ccache for mingw builds as it does not
speedup them

 .travis.yml   | 5 +++--
 .travis/build-deps.sh | 7 ++-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 1f669b30..34e0ac04 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -82,10 +82,11 @@ cache:
   directories:
   - download-cache
   - ${HOME}/opt
+  - ${HOME}/Library/Caches/Homebrew
 
 before_install:
-  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update ; fi
-  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo; fi
+  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update; fi
+  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo ccache; fi
 
 install:
   - if [ ! -z "${CHOST}" ]; then unset CC; fi
diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
index e787abab..e7036b6b 100755
--- a/.travis/build-deps.sh
+++ b/.travis/build-deps.sh
@@ -130,11 +130,8 @@ build_openssl () {
 fi
 }
 
-# Enable ccache
-if [ "${TRAVIS_OS_NAME}" != "osx" ] && [ -z ${CHOST+x} ]; then
-# ccache not available on osx, see:
-# https://github.com/travis-ci/travis-ci/issues/5567
-# also ccache not enabled for cross builds
+# Enable ccache except cross builds
+if [ -z ${CHOST+x} ]; then
 mkdir -p "${HOME}/bin"
 ln -s "$(which ccache)" "${HOME}/bin/${CC}"
 PATH="${HOME}/bin:${PATH}"
-- 
2.14.3


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Check for more data in control channel

[Steffan Karger]

If control channel packets arrive quickly after each other, or out of
order, there might be more data available than we can read in one
tls_process() call.  If that happened, and no further control channel
packet arrived (e.g. because the last two packets arrived out-of-order),
we would wait for 16 second ("coarse timer") before we would read the
remaining data.  To avoid that, always schedule ourself again if there
was control channel data, to check whether more data is available.

For mbedtls, we could implement a slightly more elegant "is there more
data?" function, instead of blindly rescheduling.  But I can't find a way
to implement that for OpenSSL, and the current solution is very simple and
still has quite low overhead.

Signed-off-by: Steffan Karger 
---
 src/openvpn/ssl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 7b42845..15a37a3 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2935,6 +2935,9 @@ tls_process(struct tls_multi *multi,
 {
 state_change = true;
 dmsg(D_TLS_DEBUG, "TLS -> Incoming Plaintext");
+
+/* More data may be available, wake up again asap to check. */
+*wakeup = 0;
 }
 }
 
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Summary of the community meeting (Wed, 3rd Jan 2018)

[Samuli Seppänen]

Hi,

Here's the summary of the IRC meeting. Unfortunately I had forgotten to
send the meeting invitation until it was already too late.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 3rd Jan 2017
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:



The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



SUMMARY

cron2, mattock, ordex and syzzer participated in this meeting.

--

Noted that Patchwork is not detecting patches sent to the list. Mattock
is investigating the problem.

--

Discussed the suggestion by Internet Bug Bounty to sponsor OpenVPN bug
bounties:



Mattock has had discussions with OSTIF about IBB and IBBs policy of "no
overlap". These discussions are ongoing and more details will follow.

--

Syzzer gave an update on his and gertvandijk's control channel
optimization work.

They believe that we should ditch unique_retry and to do a 'fast
retransmit', similar to what many TCP implementations do.  That is, if
we receive multiple ACKs for packets with IDs higher than some packet we
did not yet get an ACK for, we immediately retransmit that (instead of
waiting for the 2s exp backoff timeout). With our current 4-packet send
windows, that won't do much, but as soon as we increase the send buffer
size that improves things a lot.

Another thing they've been looking at is if we can implement dynamic
send window scaling without wire protocol changes. That will, however,
depend on advertising the window size to the other end.

Right now the receive window is hardcoded to 8 packets. It was agreed
that we could use a peer-id-link with which we implement larger receive
windows without dynamic window scaling or fast retransmit. This could go
into 2.4 and would be fairly trivial to implement. If the client does
not advertise any window size, we would assume 8 packets. Larger send
windows would only be implemented in master.

---

Full chatlog attached.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock
(12:02:00) ordex: mattock: about patchwork: notsure what's wrong, but suddenly 
it stopped showing patches in the list
(12:02:12) ***cron2 needs to merge quite a bit... no reviewing right now (only 
tablet with me)
(12:09:39) mattock: ordex: it is receiving emails, but not parsing them
(12:10:32) mattock: it had the same problem earlier, and then it was about a 
rackspace "welcome" email that lacked message id
(12:10:42) mattock: but I don't see anything similar in the INBOX now
(12:11:52) ordex: mh
(12:12:24) ordex: is there any log you could check? maybe showing some error? 
(maybe you've done that already)
(12:15:50) mattock: I did debug the problem previously but failed to make notes 
into JIRA
(12:15:59) mattock: so I have to relearn how to debug patchwork
(12:17:00) mattock: how did you guys resend patches to patchwork?
(12:17:11) mattock: is modify as new -> send to patchwork address enough?
(12:17:35) ordex: probably
(12:17:38) cron2: i bounce from mutt
(12:17:43) ordex: I normally use the "redirect" plugin in thunderbird
(12:18:11) ordex: mattock: I can do it with one patch for you now i you want
(12:20:34) mattock: ordex: please do
(12:20:44) mattock: I will install the redirect plugin
(12:20:48) ordex: ok, to patchw...@openvpn.net , right ?
(12:20:51) mattock: yes
(12:21:00) ordex: done
(12:21:03) mattock: thanks!
(12:21:12) ordex: it was: [Openvpn-devel] [PATCH] reliable: remove 
reliable_unique_retry()
(12:22:50) cron2: syzzer has been quite busy
(12:26:23) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2018-01-03
(12:26:27) vpnHelper: Title: Topics-2018-01-03 – OpenVPN Community (at 
community.openvpn.net)
(12:30:30) syzzer: cron2: new years' cleanup :)
(12:32:03) mattock: let's start
(12:32:15) mattock: I have ~20 minutes (lunch appointment)
(12:32:28) mattock: topic #1: quick update on IBB
(12:32:42) mattock: I have not heard anything, and I assume nobody else has 
either
(12:33:01) syzzer: not me at least
(12:33:01) mattock: however, I've been discussing the OSTIF<->IBB angle with 
Derek from OSTIF
(12:33:41) mattock: I will help coordinate co-operation between those parties
(12:34:00) mattock: hopefully openvpn will be supported by both eventually
(12:34:05) mattock: more details will follow
(12:34:13) syzzer: very good :)
(12:34:46) mattock: topic #2
(12:34:52) mattock: Update on control channel optimization (gertvandijk, 
syzzer) 
(12:35:35) syzzer: ok, so gertvandijk was wise enough to take a holiday break, 
so not much news on the ledbat front
(12:36:16) syzzer: but I've been trying to figure out what our current 
reliability layer does, and how the various design choices impact performance
(12:36:51) syzzer: my laptop is currently crunching to produce graphs, but 
you've seens