similar to: Proposals for UDP information transport over the metagraph

Here are a few facts that should make things clearer. Regarding keys: - The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels. - The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of

Hi all! I still have never managed to fully wrap my head around how UDP data tunnels can be established between nodes. Everytime I think I understand it, I see something that confuses me again Just now I am seeing the following: I have nodes A, B + C A has everybody's keys and host configuration files. B and C only have A's key, and host config with A's public IP address. B and

Hi all, I have two nodes, connected to a switch, using Tinc 1.1 from git. They connect each other with sptps, and to other nodes in the Internet with old protocol because they have Tinc 1.0. There is no problem with remote nodes, but between my 2 local nodes, they see 1518 PMTU. But local network is 1500 MTU !!! So nodes can ping each other but larger data does not go. test1=sllm1 test2=sllm2

Hi, I believe I have found a bug with regard to the LocalDiscovery feature. This is on tinc-1.1pre7 between two Windows nodes. Steps to reproduce: - Get two nodes talking using LocalDiscovery (e.g. put them on the same LAN behind a NAT with no metaconnection to each other) - Make one ping the other. Expected result: - The two nodes should ping each other without any packet loss, hopefully at

I would like to discuss the following commit: https://github.com/gsliepen/tinc/commit/4a0b9981513059755b9fd15b38fc198f46a0d6f2 ("Determine peer's reflexive address and port when exchanging keys") This is a great feature as it basically allows peers to do UDP Hole Punching (via MTU probes) even when both are having their source ports rewritten by a NAT, which is extremely useful.

On Sat, May 16, 2015 at 04:53:33PM +0100, Etienne Dechamps wrote: > I believe there is a design flaw in the way SPTPS key regeneration > works, because upon reception of the KEX message the other nodes will > send both KEX and SIG messages at the same time. However, the node > expects SIG to arrive after KEX. Therefore, there is an implicit > assumption that messages won't

Hello. Finally I discovered the mailinglists and subscribed. Before, I were in #tinc, pinging guus all the time with various stuff/problems/patches/etc. So... the problems, in no particular order. 1) Quite often, after re-starting a client (I run in tunnelserver mode), no packets are flowing. Tcpdump shows packets being sent from client but nothing gets received, and on the server both send

Hallo, I have a couple of tinc hosts in the same network, some using the latest tinc 1.1 git and some using 1.0.24. It seems like traffic between 1.1 and 1.0 nodes is always transfered using TCP (and an intermediate node, if not directly connected), never with UDP. Viewed from host W (tinc 1.1): (All after successfully pinging an IP behind the remote side to trigger UDP path probing, and

Well this has had me stumped for days now. For months I've been using tinc in TCPOnly because I always received the unknown host error when using UDP. On Monday, i set the flag IndirectData = yes in my host files, and removed the TCPOnly line. Initially, everything worked great. My throughput increased from 600KB/sec to 2MB/sec between the sites. However, I also did some testing with

Dear Guus, I've attached my first git commit to your repository. It does not contain any new functionalities, but it is a first try to interact with your git copy. Could you please verify, if you can push this commit to your repository? If it works, I'll send you the rest of my work, which contains: 1) some small improvements in logging (using flags instead of counters) 2) the

Hi Guus, while checking the source code, I stumbled upon PMTU Discovery. I've got a question regarding the process of sending/receiving PMTU packets. As I understand, the packet flow is like this: 1 .Tinc creates a packet with a specific payload length to send it as an PMTU probe. (The data part is just some random bytes.) 2. This packet gets compressed and sent

TL;DR: a proposal for a new tinc feature that allows nodes to filter ADD_SUBNET messages based on the metaconnection on which they are received, so that nodes can't impersonate each other's VPN Subnets. Similar to StrictSubnets in spirit, but way more flexible. BACKGROUND: THE ISSUE OF TRUST IN A TINC NETWORK In terms of metaconnections (I'm not discussing data tunnels here), one of

Hello, I'm running a tinc network including dozens of nodes in switch mode. Some are running stable branch 1.0, while a small set of nodes are running 1.1 with ed25519 support. I discovered some routing issue between two nodes: (names are hidden) A (1.1): ConnectTo = B ConnectTo = C IndirectData = yes Mode = Switch B (1.0): Mode = Switch C (1.1 but only with RSA key): Mode = Switch

I've been using SPTPS (a.k.a ExperimentalProtocol) for a while now, but I've only recently started looking into the details of the protocol itself. I have some questions about the design: - I am not sure what the thread model for SPTPS is when compared with the legacy protocol. SPTPS is vastly more complex than the legacy protocol (it adds a whole new handshake mechanism), and

Hi all, I'm back again with my speed issues. The past issues where dependant of network I used. Now I run my tests in a lab, with 2 configurations linked by a Gigabit switch : node1: Intel Core i5-2400 with Debian 7.2 node2: Intel Core i5-3570 with Debian 7.2 Both have AES and PCLMULQDQ announced in /proc/cpuinfo. I use Tinc 1.1 from Git. When I run an iperf test from node2 (client) to

On Sun, May 17, 2015 at 07:46:45PM +0100, Etienne Dechamps wrote: > I sent you a pull request that addresses the general issue, at least > for the short term: https://github.com/gsliepen/tinc/pull/83 Merged. > > You are right. The main issue with the SPTPS datagram protocol is that > > it actually doesn't handle any packet loss or reordering during > > authentication

+0100 From: Daniel Schall <tinc-devel at mon-clan.de> Date: Thu, 6 Jan 2011 17:00:35 +0100 Subject: [PATCH] Improved PMTU discovery diff --git a/lib/dropin.c b/lib/dropin.c index 52fb5b8..2b803b1 100644 --- a/lib/dropin.c +++ b/lib/dropin.c @@ -165,8 +165,8 @@ #endif =20 #ifdef HAVE_MINGW -int usleep(long usec) { - Sleep(usec / 1000); - return 0; -} +//int usleep(long usec) { +//

Hi, I've got a relatively simple tinc setup. I've got two "servers" that are on the public internet that act as routers for three "clients" that are behind NATs. Those servers are called aaaaa and bbbbb the clients are xxxxx, yyyyy and zzzzz Unfortunatly the servers have problems accepting a connection from the clients syslog on aaaaa: Sep 29 18:28:58 schuerrer

Hi Guus and List, Since the CVE-2013-1428 was announced, I followed the recommendation to update my windows machines to tinc1.1pre7. I've had connectivity issues since upgrading. I've done some debugging but I can't figure out when or why its happening. All machines on the network are running Windows 7 or Windows 2008R2 Enterprise server and tinc 1.1pre7. I've got one master

Am 23.06.2020 09:28, schrieb Marek Greško: Hi > if you need clampmss then it is highly probable there is a PMTU > discovery problem. The clampmss does not work for UDP. Is there a way to check if I have this problem? > I probably counted the size incorrectly. So you are able to ping with > size 1464 and not with 1466. How about trying same ping sizes from the > internet towards