public inbox for govpn-devel@lists.cypherpunks.ru
Atom feed
* [Govpn-devel] working with 32it version
@ 2016-02-14 22:11 alxkor
2016-02-16 8:42 ` stargrave
0 siblings, 1 reply; 2+ messages in thread
From: alxkor @ 2016-02-14 22:11 UTC (permalink / raw)
To: govpn-devel
[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]
Hi, govpn developers!
just checked 5.5 release on 32bit client and have some news:
1. it didn't crashes just after start, as 5.4 does
2. it doesn't works right
with default settings, 64 bit client works well, 32bit with same produces this on server side:
2016/02/12 20:54:29.509300 main.go:85: Server started
2016/02/12 20:54:53.403081 udp.go:99: Peer handshake finished: *.*.*.*:52964 **********************
2016/02/12 20:54:53.403222 udp.go:166: Peer created: **********************
2016/02/12 20:55:52.970751 peer.go:223: Padded data packet size 1515 is bigger than MTU 1514 **********************:*.*.*.*:52964
2016/02/12 20:55:52.970786 peer.go:223: Padded data packet size 1515 is bigger than MTU 1514 **********************:*.*.*.*:52964
2016/02/12 20:55:52.970983 peer.go:223: Padded data packet size 1515 is bigger than MTU 1514 **********************:*.*.*.*:52964
(how to reproduce: connect to service on the far end, make it to produce continious stream longer than mtu. the session will hang indefinetely, because of server trying to send something bigger than its own mtu allows. )
looks like off-by one error?
no fiddling with client config helps.
simple but ugly workaround: configure _server_ to use mtu 1515
P.S. this server users 5.4 64bit version
[-- Attachment #2: Type: text/html, Size: 1581 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Govpn-devel] working with 32it version
2016-02-14 22:11 [Govpn-devel] working with 32it version alxkor
@ 2016-02-16 8:42 ` stargrave
0 siblings, 0 replies; 2+ messages in thread
From: stargrave @ 2016-02-16 8:42 UTC (permalink / raw)
To: alxkor; +Cc: govpn-devel
Greetings!
*** alxkor [Sun, 14 Feb 2016 17:11:29 -0500]:
>just checked 5.5 release on 32bit client and have some news:
>1. it didn't crashes just after start, as 5.4 does
Yep, it was unexpected bug/issue with specific sync/atomic Go library.
>2016/02/12 20:54:29.509300 main.go:85: Server started
>2016/02/12 20:54:53.403081 udp.go:99: Peer handshake finished: *.*.*.*:52964 **********************
>2016/02/12 20:54:53.403222 udp.go:166: Peer created: **********************
>2016/02/12 20:55:52.970751 peer.go:223: Padded data packet size 1515 is bigger than MTU 1514 **********************:*.*.*.*:52964
>2016/02/12 20:55:52.970786 peer.go:223: Padded data packet size 1515 is bigger than MTU 1514 **********************:*.*.*.*:52964
>2016/02/12 20:55:52.970983 peer.go:223: Padded data packet size 1515 is bigger than MTU 1514 **********************:*.*.*.*:52964
>(how to reproduce: connect to service on the far end, make it to produce continious stream longer than mtu. the session will hang indefinetely, because of server trying to send something bigger than its own mtu allows. )
>looks like off-by one error?
Seems you are right. I assumed that it will be convenient to be able to
send 1500 MTU packets + 14 bytes Ethernet overhead, but I did not take
into account that single padding byte.
>no fiddling with client config helps.
>simple but ugly workaround: configure _server_ to use mtu 1515
Yes, MTU is just a check condition that we are not trying to send too
much data. In my real setups in practice I have lower MTU like 14xx.
I will commit that default MTU should be 1515, instead of 1514.
Thanks for reporting that.
But I am not sure that it depends on either 32 or 64 bit version.
As I can see, it must behave similary.
--
Happy hacking, Sergey Matveev
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-02-16 8:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-14 22:11 [Govpn-devel] working with 32it version alxkor
2016-02-16 8:42 ` stargrave