similar to: Status of Experimental Protocol

Hello, I think routing could be improved in several ways, at least, there lacks some documentation describing how Tinc routes packets. In order to test Tinc, I setup the following virtual network: - tinc 1.1pre9 with ExperimentalProtocol=yes - use of network namespaces (actually python-nemu[1]) - star topology, where all nodes runs tinc except the center, which I use to filter communications,

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>

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

On Jun 16, 2015 3:25 AM, "shikkc" <shikkc at kirktis.net> wrote: > > My package presents options in menuconfig so you can select to build with/without: readline, curses, openssl, lzo, zlib. Spiffy. Can you post this enhancement here as a git AM or as a Github branch? -------------- next part -------------- An HTML attachment was scrubbed... URL:

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 @

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)

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

Is your package built with or without OpenSSL? How do you intergrate with UCI? Can I view the makefile somewhere? Florian Am 15.06.2015 um 11:48 schrieb shikkc: > I already have a package made, if anyone would like me to I could submit > it. > > On 2015-06-13 17:26, Florian Klink wrote: >> Hey Saverio, >> >> I'd really like the idea of a tinc-1.1-pre package

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

Hi all, TL;DR: when Tinc 1.1 release? I plan to use Tinc for my GSoC project which basically simplifies setup of a Tinc mesh providing IPv6 to nodes in community mesh networks. As I'm new to Tinc I don't know it's history and the changes from 1.0 to 1.1, but it seems to have at least a different syntax in some cases. To make and keep it simple for users, I'd like to stick

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,

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

I'm been experiencing a very very odd problem for the past several weeks and am throwing it out in case someone can shed some light on it for me. There is a single box on our tinc mesh which can be pinged from all hosts, but cannot ping any. It is not limited to ping, the box cannot communicate over tinc. tinc is running in router mode for this mesh. ~30 other nodes function normally,

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

First off, thanks to all who have made tinc possible and continue to work developing it. I hope perhaps in time I can become a useful part of this community. :) I'm having an interesting issue with tincctl and was hoping someone could shed some light on it. Everything seems to work correctly when I build for OSX; however on linux and windows builds, I always receive connection

Hello, Thanks to recent fix of 'Failed to decrypt and verify packet' issue by Etienne, I decided to upgrade tinc on a few nodes. I had to go back to 1.1pre9 immediately because tinc on my laptop didn't survive the restart of other nodes. It aborted with the following message: Error while waiting for input: Bad file descriptor I could reproduce the issue. Here is strace output:

I have about 15 nodes running 1.1pre15 connected and running quite well. I don't remember why I installed 1.1preX originally. Possibly because I added a router with custom firmware to the network (Tomato Shibby firmware for my ASUS router) which included 1.1pre14. Now I'm trying to add an Openwrt device and it includes 1.0.33 only. This will replace the Tomato Shibby device with

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

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