similar to: High-performant tinc (without encryption?)

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

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 @

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

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

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)

> The goal is to create a working setup as easily as possible. > This is going fairly well with 1.1 ;-) thank you. > - if people are able to read it, you can just as well leave it to a > warning > > and suggest running again with a --autoport flag to enable automatic port > > generation > > I'm sure I will get some emails from people complaining that if tinc

I like the config generator of tinc 1.1! An issue to consider on the default behavior: It turns out 'tinc -n mynet init mynodename' makes up a default Port=... when the standard port is taken: "Warning: could not bind to port 655. Tinc will instead listen on port 22911". It is nice that this is autodetected and warned, but I wonder whether it is nice to let this

Hi Eric, Which version are you using? I have similar issues with the newest 1.1pre10. Did you check out the ?LocalDiscovery? option? For 1.1, you also can get more information about the actual connection mode by using the ?info [node]? command. Cheers, Steffen > Am 05.12.2014 um 12:26 schrieb Eric Feliksik <feliksik at gmail.com>: > > Dear all, > > I have 3 nodes: A, B

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

Jean-Daniel Dubois Snoop@cgocable.ca Pr?pos? Multim?dia Multimedia Employee Cog?co C?ble Canada Inc. 1 877 727-4387 1 819 375-7274 -----Message d'origine----- De : Snoop [mailto:snoop@cgocable.ca] Envoy? : 19 novembre, 2001 20:08 ? : samba-admin@lists.samba.org Objet : why is samba more performant with 8 MB buffer (which algorith is used) Hi im doing a project on samba and its global

Dear group, Last night I was playing around with my home desktop trying to get the sound to work and somehow I broke some dependencies, now yum update would not run. Can someone help me troubleshoot this. This is the output I am getting from yum update. Thank you in advance. [root at venus ~]# yum update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons:

With pleasure we announce the release of tinc version 1.0.23. Here is a summary of the changes: * Start authentication immediately on outgoing connections (useful for sslh). * Fixed segfault when Name = $HOST but $HOST is not set. * Updated the build system and the documentation. * Clean up child processes left over from Proxy = exec. This version of tinc is compatible with 1.0pre8, 1.0

With pleasure we announce the release of tinc version 1.0.23. Here is a summary of the changes: * Start authentication immediately on outgoing connections (useful for sslh). * Fixed segfault when Name = $HOST but $HOST is not set. * Updated the build system and the documentation. * Clean up child processes left over from Proxy = exec. This version of tinc is compatible with 1.0pre8, 1.0

Hi, As I only RedHat-7.2 the only update I can find is Updates for i386 libxslt-1.0.7-2.i386.rpm So I guess i better go for icecast 1.XXX or will I have the same probolam ? Has anyone got this to work on As I only RedHat-7.2 AJB <p>-----Original Message----- From: owner-icecast@xiph.org [mailto:owner-icecast@xiph.org]On Behalf Of Geoff Shang Sent: 13 January 2003 7:24 AM To:

Hi all, I tried Tinc 1.1 from git on 4 nodes, each one in a datacenter. They were able to ping each other, etc... but I had problem with multicast, nothing seemed to pass (all is OK with Tinc 1.0.23). I checked logs and on every nodes I have a lot of: Failed to decrypt and verify packet And Error while decrypting: error:00000000:lib(0):func(0):reason(0) So I get back to 1.0.23 which works

I've uploaded Xapian 1.0.23 (including Search::Xapian 1.0.23.0), which as usual you can download from: http://xapian.org/download This release fixes a few bugs and improves portability to Cygwin. This will probably be the last release from the 1.0 series. 1.2.0 was released 8.5 months ago, and we'll probably want to start a new development series soon, so it's time to retire 1.0.

Report by Eric Lindblad 11-09-2015 http://www.ericlindblad.blogspot.com I compiled xapian-core-1.0.23 today on Interix. 'gmake check' summary PASS: btreetest, quartztest, stemtest, termgentest FAIL: apitest, internaltest, queryparsertest MS XP SP3 HOME modified SFU Interix 3.5 w/ getopt.h, inttypes.h, & stdint.h copied over from SUA Interix for Vista (and newer) into

Hello, I've built LLVM natively on a fpu-less (soft-float) mips32 target, and built mesa to use it. However llvm apparently cannot determine what machine it's running on and builds code for a generic mips target with fpu. Is there a way to have llc/llvm always use "-march=mipsle -mcpu=mips32 -mattr=+soft-float" as a default command line, something similar to gcc's