similar to: PMTU = 1518 over local network at 1500 MTU

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

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

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

You could remove them with sieve in the latest version of pigeonhole. On Mar 24, 2015 7:33 AM, Florent B <florent at coppint.com> wrote: > > I know about RFC's, but that could be an option, not enabled by default.

Thank you for your report, we'll look into it! Aki > On December 27, 2017 at 8:16 PM Florent B <florent at coppint.com> wrote: > > > Hi, > > This repository does not work with Aptly. > It seems "architecture" line is wrong in InRelease file (needs to be > "Architectures:" instead of "Architecture:"). > 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

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

I sent you a pull request that addresses the general issue, at least for the short term: https://github.com/gsliepen/tinc/pull/83 On 16 May 2015 at 19:36, Guus Sliepen <guus at tinc-vpn.org> wrote: > 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

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

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

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

Oh, goodie! I'd made a start on the send direction here: https://github.com/dtaht/tinc/commits/master Perhaps that will help. I would not just pull that as it was just some late night hacking... and it turns out the posix time calls I upgraded to to get better than second resolution are not supported on OSX. My ultimate intent was to move to not bottlenecking or dropping packets on the

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 @

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

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>

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

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

On Wed, 21 Mar 2018 19:28:05 -0600, "Todd C. Miller" wrote: > Note that it will only be used if you generate ed25519 keys to use > with it. The new protocol is one of the main reasons to run 1.1. Also, tinc 1.1 can still interoperate with tinc 1.0 nodes using the legacy protocol. You can read more about sptps in the tinc 1.1 manual in the security section. - todd