similar to: Schedule for 1.1 final?

Hi, I'm using Tinc in a scenario where round-trip time matters. I've multiple nodes behind firewalls (with and without NAT) and a single public server node. How do I can get the current state of UDP data-connections between my firewall'd nodes? According to the docs: - 'dump connections' give me all TCP meta-connections of the current node - 'dump edges' give me

With pleasure we announce the release of tinc version 1.1pre11. Here is a summary of the changes: * Added a "network" command to list or switch networks. * Switched to Ed25519 keys and the ChaCha-Poly1305 cipher for the new protocol. * AutoConnect is now a boolean option, when enabled tinc always tries to keep at least three meta-connections open. * The new protocol now

With pleasure we announce the release of tinc version 1.1pre11. Here is a summary of the changes: * Added a "network" command to list or switch networks. * Switched to Ed25519 keys and the ChaCha-Poly1305 cipher for the new protocol. * AutoConnect is now a boolean option, when enabled tinc always tries to keep at least three meta-connections open. * The new protocol now

Hello I have currently a larger network deployed using 1.1pre11. I have now tried to use 1.1pre14 on a remote system, but I have problems to make it work with compression enabled. It appears that a 1pre14 client cannot talk to a 1.1pre11 server with compression enabled, even though the tunnel is being established with no errors. I have tried both lzo and zlib with various levels, none works.

Hi. I'm in desperate need of some good advice. I have a tinc network with 16 nodes. It's a star topology where all nodes are connecting to the one node (Node1) that have a static IP. Node 1 accepts incomming connections Node 2 through 16 connects to Node1 One of the nodes (Node5) stopped working a while ago (2 - 3 weeks or so), other than that everything was working fine. Today I

And how distant are we from a 1.1.0? :) On Sun, Dec 28, 2014 at 10:49 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sun, Dec 28, 2014 at 10:33:47AM -0200, Raul Dias wrote: > > > 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? > > The roadmap

Tried to Build Tinc. Linker was confused, Makefile lacking reference to -ltinfo I guess. FYI. root at rpzcentos tinc-1.1pre10]# make make all-recursive make[1]: Entering directory `/adev/tinc-1.1pre10' Making all in m4 make[2]: Entering directory `/adev/tinc-1.1pre10/m4' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/adev/tinc-1.1pre10/m4' Making all in

I have 2 nodes nodeA and nodeB I'm using tinc 1.1pre11 -- nodeA(fd80:2015:2105:abcd::1) : $ ip -6 route fd80:2015:2105:abcd::1 dev tun0 proto kernel metric 256 fd80:2015:2105:adcd::/64 dev tun0 metric 1024 fe80::/64 dev eth0 proto kernel metric 256 $ ping6 fd80:2015:2105:abcd::1 PING fd80:2015:2105:abcd::1(fd80:2015:2105:abcd::1) 56 data bytes 64 bytes from fd80:2015:2105:abcd::1:

Hi, I've got a four site site-to-site tinc mesh working nicely. I have the following systems at two of those sites: 10.a.a.2: Linux box running tinc and DHCP/DNS for site A 10.a.a.dhcp: Windows desktop with a GPU 10.b.b.2: Linux box running tinc and DHCP/DNS for site B 10.b.b.dhcp: Linux laptop I'd like to use Steam In-Home Streaming to game in the laptop streaming from the desktop. The

If tincd is started before name resolution comes up, it keeps failing for ever to resolve domain names in Address= host configuration variable after name resolution becomes possible. I think tincd should succeed in resolving domain names after name resolution becomes available.

On Thu, Dec 10, 2015 at 10:15:19AM +0100, Samuel Thibault wrote: > I did get a bit more than a hundred packets in the queue at 800Mbps. But > we can reduce to 64, yes. I wouldn't recommend using a static buffer, > since we'd want to go threaded at some point. Allocating an array on the > stack is very cheap anyway. I assumed that one would only get more than 1 packet at a

On Wed, Apr 27, 2016 at 10:22:27PM +0800, hshh wrote: > There is something wrong while routing ipv6 on tap, I prefer to use tun. Oh, what is wrong with IPv6 on tap? > Will you fix it soon? Yes. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc

I've been trying out IPv6 networking with tinc and noticed that it will not route smaller segments than /48 If I try to run ip -6 route add aaaa:bbbb:cccc:dddd::/64 dev tun0 I get network unreachable However if I run ip -6 route add aaaa:bbbb:cccc::/48 dev tun0 it works fine Is this is a limitation in tinc or the kernel network stack itself? -------------- next part -------------- An HTML

On Sun, Feb 1, 2015 at 11:19 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sun, Feb 01, 2015 at 04:08:47PM +0900, crocket wrote: > >> If tincd is started before name resolution comes up, it keeps failing >> for ever to resolve domain names in Address= host configuration >> variable after name resolution becomes possible. >> >> I think tincd should

Hello, did you read this paper? ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels https://www.cs.tau.ac.il/~tromer/mobilesc/

On Mon, Jan 05, 2015 at 08:10:48AM -0700, Lance Fredrickson wrote: > Allowing tinc to run without RSA keys is a very big > bonus for us embedded device users. We have a limited amount of nvram space > for storage (tomato firmware). RSA keys took up quite a bit, so being able > to run using only ED25519 makes tinc very appealing for this platform, and > saves tons of space for more

I can confirm that Steam In-Home Streaming does work properly over tinc, for having tried it myself, as long as tinc is configured to route the broadcasts properly, as Guus described. Note that it would be easier to set up tinc nodes on your Windows desktop and Linux laptops, to avoid the additional complication of having to relay broadcast packets between your local networks and the tinc network.

Dear all, I have 3 nodes: A, B and C. C has external IP and A and B are behind NAT. It turns out A and B route their traffic via the C, which they ConnectTo with; this instead of getting connection details from one another and contacting eachother directly (mesh style). The reason is, as I conclude from tincd debug output, is that they see the peer as having a minimum MTU of 0. I suspect this is

My intention was to sign the content of export-all with the nodes' public key, which would require the corresponding private key to verify. Does this make sense ? @ > Le 26 janv. 2016 ? 20:19, Guus Sliepen <guus at tinc-vpn.org> a ?crit : > >> On Tue, Jan 26, 2016 at 07:35:10PM +0100, Anton Voyl wrote: >> >> Is it possible to sign/verify data with the ed25519

Hallo, trying to compile the current 1.1 git snapshot under Debian Wheezy gives me: configure.ac:7: option `info-in-builddir' not recognized autoreconf: automake failed with exit status: 1 Do I now need a specific newer version of automake? Seems to be the result of commit 13f9bc1ff199bea46 "Add support for out-of-tree ("VPATH") builds." Undoing the change to