Displaying 20 results from an estimated 1000 matches similar to: "tinc 1.1pre19 slower than tinc 1.0, experimentalProtocol even more"
2013 Dec 17
1
Speed issue in only one direction
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
2013 Sep 14
4
Elliptic curves in tinc
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)
2013 Sep 14
4
Elliptic curves in tinc
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)
2014 Apr 18
2
tinc 1.1pre10 "failed to decrypt record" on Windows client
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
2014 Jul 16
2
Some questions about SPTPS
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
2018 Mar 16
3
SPTPS in 1.1
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>
2015 May 16
2
"Invalid KEX record length" during SPTPS key regeneration and related issues
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
2015 May 17
2
"Invalid KEX record length" during SPTPS key regeneration and related issues
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
2014 Feb 25
3
PMTU = 1518 over local network at 1500 MTU
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
2014 Feb 07
2
[Announcement] Tinc version 1.1pre10 released
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
2014 Feb 07
2
[Announcement] Tinc version 1.1pre10 released
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
2015 Dec 02
5
[PATCH] Receive multiple packets at a time
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
2014 Apr 06
1
Status of Experimental Protocol
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
2018 Mar 21
2
SPTPS in 1.1
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
2016 May 18
0
Upgrade to 1.1pre14
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
2015 Apr 21
1
Questions about routing issue
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
2015 Jul 05
3
Different PRF with --disable-legacy-protocol?
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,
2018 Mar 16
0
SPTPS in 1.1
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
2015 Aug 19
0
Seeing: "Got REQ_KEY from XXX while we already started a SPTPS session!"
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
2014 Sep 28
1
Proposals for UDP information transport over the metagraph
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,