similar to: tinc 1.1pre19 slower than tinc 1.0, experimentalProtocol even more

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

In the past 24 hours multiple persons have contacted me regarding the use of elliptic curve cryptography in tinc 1.1 in light of the suspicion that the NSA might have weakened algorithms and/or elliptic curves published by NIST. The new protocol in tinc 1.1 (SPTPS) uses ECDH and ECDSA to do session key exchange and authentication, in such a way that it has the perfect forward secrecy (PFS)

In the past 24 hours multiple persons have contacted me regarding the use of elliptic curve cryptography in tinc 1.1 in light of the suspicion that the NSA might have weakened algorithms and/or elliptic curves published by NIST. The new protocol in tinc 1.1 (SPTPS) uses ECDH and ECDSA to do session key exchange and authentication, in such a way that it has the perfect forward secrecy (PFS)

Tinc newbie here so apologies if this is obvious or has been discussed already; I did search but couldn't find anything. I'm testing tinc 1.1pre10 between a Windows 7 client and Linux server. The Linux machine is on the internet and the Windows machine is on my home network behind NAT. I have successfully configured a Linux client on my home network to communicate with the server

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

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

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

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

With pleasure we announce the release of tinc version 1.1pre10. Here is a summary of the changes: * Added a benchmark tool (sptps_speed) for the new protocol. * Fixed a crash when using Name = $HOST while $HOST is not set. * Use AES-256-GCM for the new protocol. * Updated support for Solaris. * Allow running tincd without a private ECDSA key present when ExperimentalProtocol is not

With pleasure we announce the release of tinc version 1.1pre10. Here is a summary of the changes: * Added a benchmark tool (sptps_speed) for the new protocol. * Fixed a crash when using Name = $HOST while $HOST is not set. * Use AES-256-GCM for the new protocol. * Updated support for Solaris. * Allow running tincd without a private ECDSA key present when ExperimentalProtocol is not

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

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

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

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

Hi everybody. I'm struggling with setting up an SPTPS connection between two of my machines. I attached the patch that I used to analyze this. Apparently different keys are derived depending on the crypto backend. Is this intentional? Linking to openssl results in char key[] = { 0xb2, 0x9d, 0x8d, 0x24, 0x91, 0x04, 0xaf, 0x25, 0x3f, 0x10, 0x34, 0x9d, 0xc7, 0x73, 0x8c, 0xe1, 0x24, 0x32,

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

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

While working on SPTPS UDP relaying I realized that there is one issue I didn't account for, which is that the sending node only knows the PMTU to the first relay node. It doesn't know the PMTU of the entire relay path beyond the first hop, because the relay nodes don't provide their own PMTU information over the metaprotocol. Now, in the legacy protocol this is not really an issue,