Large packets stop working when transferring big data

[michael.uray]

You could use --mtu-test and see the results.

This is my result:

Code: Select all

Thu Apr 13 18:54:13 2017 us=27013 michael.uray/83.65.96.213:51371 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1522,1522] remote->local=[1522,1472]
Thu Apr 13 18:54:13 2017 us=27066 michael.uray/83.65.96.213:51371 NOTE: This connection is unable to accommodate a UDP packet size of 1522. Consider using --fragment or --mssfix options as a workaround.

[300000]

can you try put this. on server and try again
hash-size 1372 1372
bcast-buffers 131072
tcp-queue-limit 131072
tun-mtu 60000

mssfix 0
sndbuf 0
rcvbuf 0
push "sndbuf 3999999 "
push "rcvbuf 3999999 "

[michael.uray]

can you try put this. on server and try again
hash-size 1372 1372
bcast-buffers 131072
tcp-queue-limit 131072
tun-mtu 60000

mssfix 0
sndbuf 0
rcvbuf 0
push "sndbuf 3999999 "
push "rcvbuf 3999999 "

I tried your recommendation and the result is as followed.
Tests where always done from client1 -> server -> client2 if no explicit other way is described.

The largest possible ping through the tunnel is 1472, what is exactly the same which is possible when I try to ping the server directly via the Internet without VPN.
It does not start fragmenting the packets, larger packets do not get through the tunnel.

When I open up an UltraVNC connection through the tunnel (means transferring a bit more data via TCP, probably more than the MTU size), then the largest possible ping drops suddenly to 1419 bytes.
After about one minute with no (or low) data transfer via the UltraVNC connection the maximum possible ping goes up to 1472 bytes again.

In the server log are a couple messages like this:

Code: Select all

Tue Apr 18 13:05:30 2017 us=448212 michael.uray/83.65.96.213:50051 write UDPv4: Message too long (code=90)
Tue Apr 18 13:05:57 2017 us=37568 michael.uray/83.65.96.213:50051 PID_ERR replay-window backtrack occurred [1] [SSL-1] [0_00012223334556666666666666666666666666666666667777777777777777] 0:3121 0:3120 t=1492513557[0] r=[-2,64,15,1,1] sl=[15,64,64,272]

An interesting thing is also, that this time a 1600 byte ping from the server to client2 got not interrupted by the UltraVNC connection.
Maybe has this something to do with that, that the link-mtu could not got applied?

Code: Select all

Tue Apr 18 13:01:31 2017 us=738259 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 60042'
Tue Apr 18 13:01:31 2017 us=738259 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 60000'

The ping on the server behaves also kinda weird.
It shows the warning "WARNING: probably, rcvbuf is not enough to hold preload." right after the start of the command execution.
Then it shows within a second about 400 ping results with a time about 90ms each, what is actually not possible, because this amount of results with this response time would take more than 30s.
After that the ping behavior looked normal and it responded with 8-9ms.

[300000]

you can add this line to the client

tun-mtu 60000

basic if you run over openvpn you can expect as good as go direct connection . but that is the best you can use

i have run this one and download over 10 gb without drop connection and everything go ok

sometime vnc use more data when first time it conneted so the ping drop . but after that it is nomar as expect


you cant get maximum size of the possible packets 1600. if everything over 1500 it will cut into small to tranfer so how can you get 1600.

every nerwork device the defaul value is 1500 . but that number nerver get in full . if there are too many connection the value shou stay under 1420 for good connection or it will cut off

if you check every device you only can find number they set is 1500 but nerver 1600 as you think.