similar to: Tinc 1.1pre15 double-crash

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'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

Hello, After upgrading to 1.1pre14, enabling ExperimentalProtocol, I receive a lot of messages like these: Received short packet from nodename (ip port 655) Handshake phase not finished yet from nodename (ip port 21785) Got REQ_KEY from node while we already started a SPTPS session! Invalid packet seqno: 0 != 1 from node (ip port 21785) Failed to verify SIG record from node (ip port 21785) No

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, 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

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 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

Hi, Guus Thanks a lot for your suggestion, actually I did something else as below. But one question here is if I don’t add "/sbin/ifconfig myvpn 10.0.0.1 netmask 255.255.255.0”, it seems the crontab wouldn’t trigger tinc-up, and then the ip addr of myvpn wouldn’t be configured, then it will prompt the error of "Can't write to Linux tun/tap device (tun mode) /dev/net/tun:

On Fri, May 26, 2017 at 09:30:44AM +0800, Bright Zhao wrote: > Due to some routing rotation purpose, I use crontab to add below info: > > 0 * * * * echo Subnet = 54.169.128.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp > 0 * * * * echo Subnet = 54.169.0.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp > 1 * * * * /usr/sbin/tincd -n myvpn -k > 1 * * * * /usr/sbin/tincd -n myvpn

Hi, All Due to some routing rotation purpose, I use crontab to add below info: 0 * * * * echo Subnet = 54.169.128.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp 0 * * * * echo Subnet = 54.169.0.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp 1 * * * * /usr/sbin/tincd -n myvpn -k 1 * * * * /usr/sbin/tincd -n myvpn --debug=3 30 * * * * sed -i '/54.169.128.0\/17/d' /etc/tinc/myvpn/hosts/aws_sgp

Hi all, I'm using a tinc 1.0.19 (from Debian Squeeze) setup with some nodes connecting to a "server" node which has "StrictSubnets = yes". Whenever a new node is added to the mesh, a process generates and drops its host file in the server's host directory before the node is booted and tries to connect. For instance, I create a node "node_2" and a host file

Hallo David, Am Mon, 6 May 2019 16:43:28 +0800 schrieb David Penn <px920906 at gmail.com>: > *tinc.conf > Name = envy13 > Device = /dev/net/tun I think, you do not need to specify "Device". (I never did) > ConnectTo = main > > *hosts/main > Address = <my vps ext ip address> > Port = 655 > Subnet = 10.0.0.1/32 > > *hosts/envy13 >

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 @

1. Is there any tools/command, we can show the subnet where a certain tinc nodes learnt? So that I can know the weight for certain subnet(in real time), instead of go back to the node’s (who advertise the subnet) configuration file to check. 2. So far in order to change the weight of a subnet, or something else, I have to reset the tinc daemon( tincd -k -n myvpn and then tincd -n myvpn) in

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

SIGHUP (-kHUP) should reload that config for you and SIGURS2 (-kUSR2) will drop currently known subnets (etc) to syslog. This will not work on Windows. Both of these are in the tinc manual (http://tinc-vpn.org/documentation/tinc.pdf). From: tinc [mailto:tinc-bounces at tinc-vpn.org] On Behalf Of Bright Zhao Sent: Saturday, May 6, 2017 9:33 AM To: tinc at tinc-vpn.org Subject: Show the subnets

Hello, Linux has a recvmmsg() system call which allows to achieve several recvfrom() at a time. The patch below makes tinc use it (patch against 1.1-pre11). Basically the patch turns the handle_incoming_vpn_data variables into arrays (of size 1 when recvmmsg is not available, and thus compiled the same as before), and makes the code index into the arrays. You may want to use interdiff -w

I found the server(1.1.1.1) didn’t receive the MTU probe from client, so I add iptables -A INPUT -p udp —port 443 -j ACCEPT. After this, I see one packet matching on the server side, and the MTU negotiation works, but when I tear down the tinc, and re-establish the tinc connection, the counter of below UDP/443 never increase, and also my other tinc nodes never add this statement on iptables, but