TCPOnly obsolete? Maybe not

[Nick Hibma]

>> Consider the case where you have the following setup
>> 
>> 	client	-	fw	-	server
>> 
>> The client and server successfully setup a tunnel and UDP communication starts to happen. Then the client shuts up and the server only needs to send data to the client if the remote tool accesses the client’s UI.
>> 
>> If the firewall times out the NAT UDP hole, the server has a problem: The UDP tunnel has been marked as possible, but the UDP tunnel does no longer work because the fw has timed out the UDP hole it punched.
>> 
>> PING/PONG packets are sent on the meta channel, so that is not a solution.
> 
> Tinc also sends PMTU probes via UDP at the same interval as the
> PING/PONG packets via the meta channel. They help to keep the UDP NAT
> mapping alive, and also allow tinc to detect when UDP is not possible
> anymore, and will cause it to fall back to TCP in that case.

We (2 people) looked through the code for an hour and we both missed that. PMTU discovery is switched off as I don’t want the overhead. If that is being sent at regular intervals my comment is invalid.

Well, I’ve switched to TCPOnly for now and I’d really like that to stay available. I also would love to have a UDPonly option as well :-)

Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20140618/4611dcbc/attachment.sig>