similar to: Upgrade to 1.1pre14

Hello, this morning I apparently had tinc crash on me. In 2 independent tinc clusters of 3 nodes each (but located in the same datacenter), one tinc process crashed in each of the clusters. One process apparently with `status=6/ABRT`, the other with `status=11/SEGV`. Interestingly, they crashed with only 5 minutes difference. The only thing I can come up with that might explain this correlation

Hi I have some problems with my vpn. Im running version 1.1pre15 on all nodes. I have four nodes in my network. Node1 -> connects to Node2 Node2 -> connects to Node1 Node3 -> connects to Node1 and Node2 Node4 -> connects to Node1 and Node2 The problem is the connection between Node3 and Node4. The traffic is going via Node1 and Node2. Its unstable. package drops almost all the time

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

I'm running tinc 1.1pre11 with AutoConnect set to 'yes' and I recently started seeing lots of these messages on my VPN and cannot connect to various hosts from other hosts: (I have obscured the hostnames and vpn name, but otherwise this is a direct paste from syslog) Aug 19 14:51:51 AAA tinc.nnn[2217]: Got REQ_KEY from XXX while we already started a SPTPS session! Aug 19 14:51:54 AAA

Thanks Guus I have one more question. - We see several log messages that we dont currently understand - Can you comment on what they mean and if they are concerning? I've obfuscated IP's and node names so please ignore those. Our tinc daemon command is: tincd -n <vpn name> -- Received short packet -- Got REQ_KEY from node003 while we already started a SPTPS session! -- Invalid

Hi, I've been running tinc for a couple of months and it's great, but I have a periodic problem which maybe you guys can figure out. I operate a 3-node tinc VPN, lets say A, B and C. A / \ B --- C The problem is that after a while, node C can't exchange data with node B. It works fine (ping and other traffic) for about 10 minutes, then fails. Here is some debug

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

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

Are you sure it is enabled by default? On Fri, Mar 16, 2018 at 4:07 PM, Todd C. Miller <Todd.Miller at sudo.ws> wrote: > On Fri, 16 Mar 2018 14:37:58 -0700, al so wrote: > > > Is SPTPS protocol enabled in 1.1 by default? Or we need to manually > enable > > it. > > It is enabled by default. You can disable it by setting > ExperimentalProtocol = no in

Hi, I'm currently trying to troubleshoot what appears to be a very subtle bug (most likely a race condition) in SPTPS that causes state to become corrupted during SPTPS key regeneration. The tinc version currently deployed to my production nodes is git 7ac5263, which is somewhat old (2014-09-06), but I think this is still relevant because the affected code paths haven't really changed

On Fri, 16 Mar 2018 14:37:58 -0700, al so wrote: > Is SPTPS protocol enabled in 1.1 by default? Or we need to manually enable > it. It is enabled by default. You can disable it by setting ExperimentalProtocol = no in tinc.conf. - todd

Hi, I am testing tinc for a very large scale deployment. I am using tinc-1.1 for testing. test results below are for tinc in switch mode. all other settings are default. test is performed in LAN env. 2 different hosts. I am getting only 24.6 Mbits/sec when tinc is used. without tinc on the same hosts/link I get 95 to 100 Mbits/sec using iperf. Over Tinc: iperf -c 192.168.9.9 -b 100m -l 32k -w

Here is some examples of using templates for TINC configurations and settings: In your startup script, BEFORE starting TINC VPN, put a number of entries to configure your VPN: sh ./templatewriter.sh LAN LOSI101 8540 255.255.255.0 0.0.0.0 10.99.0.11 10.98.0.11 ConnectTo=LOSI102 ConnectTo= ConnectTo= **PUT MORE ENTRIES HERE FOR MORE COMPLEX VPN setups ######Templatewriter.sh #!/bin/bash

Hi there, we're using tinc to mesh together hosts in a public datacenter (instead of using a private VLAN, sort of). So all hosts are reasonably modern; connections are low latency with an available bandwith of around 500Mbit/s or 1Gbit/s (depending on how close they are to each other). Iperf between two nodes directly reports around 940Mbit/s. The CPUs are Intel(R) Core(TM) i7-4770 CPU @

Hi guys, thanks in advance for any answers. Trying to get tinc up and running, I hit a roadblock though. What I’m trying to do is to connect to my roaming notebook to my company network. All hosts on our network live in the 10.42.x.x range, netmask is 255.255.0.0. Tinc 1.1pre14 service is running on a Windows host 10.42.2.50. Public ports are natted through, telnetting public ip port 655 the

Hello, 1.1pre17 does not support Windows XP.  The reason is that InitOnceExecuteOnce is not supported. I believe it is better to take the Windows XP name out of the download link. -rsd -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190708/b68071ed/attachment.html> -------------- next part

Is SPTPS protocol enabled in 1.1 by default? Or we need to manually enable it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180316/2360e357/attachment.html>

Hi, Raul Thank you. In addition, there’s another information I didn’t mention earlier that B have the default route to Internet, where B will advertise this default route to both A and C, so that A and C can go to Internet through B, but A and C wouldn’t have each other’s route accordingly. You can think about A and C share the same internet gateway, but they wouldn’t know each other. Assume A

Hi Guus, I know this comes up from time to time. So it is time to update our expectations. Is there a roadmap for a 1.1 backward compatibility already? -rsd -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20141228/fcb2b44a/attachment.html>

Is there any indication of when we might see the protocol stabilize in the 1.1pre branch? It seems to be quite an improvement already. Perhaps some configuration could be added to allow for specifying a protocol version, rather than the 'ExperimentalProtocol=yes' flag? What are the roadblocks to stabilizing it and is there any need or desire for help accomplishing this? While I'm