similar to: Seeing: "Got REQ_KEY from XXX while we already started a SPTPS session!"

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 the KEX message the other nodes will > send both KEX and SIG messages at the same time. However, the node > expects SIG to arrive after KEX. Therefore, there is an implicit > assumption that messages won't

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

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

Hello, this morning I apparently had tinc crash on me. In 2 independent tinc clusters of 3 nodes each (but located in the same datacenter), one tinc process crashed in each of the clusters. One process apparently with `status=6/ABRT`, the other with `status=11/SEGV`. Interestingly, they crashed with only 5 minutes difference. The only thing I can come up with that might explain this correlation

Hi I have some problems with my vpn. Im running version 1.1pre15 on all nodes. I have four nodes in my network. Node1 -> connects to Node2 Node2 -> connects to Node1 Node3 -> connects to Node1 and Node2 Node4 -> connects to Node1 and Node2 The problem is the connection between Node3 and Node4. The traffic is going via Node1 and Node2. Its unstable. package drops almost all the time

On Sun, May 17, 2015 at 07:46:45PM +0100, Etienne Dechamps wrote: > I sent you a pull request that addresses the general issue, at least > for the short term: https://github.com/gsliepen/tinc/pull/83 Merged. > > You are right. The main issue with the SPTPS datagram protocol is that > > it actually doesn't handle any packet loss or reordering during > > authentication

Here are a few facts that should make things clearer. Regarding keys: - The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels. - The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of

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

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

Thanks Guus I have one more question. - We see several log messages that we dont currently understand - Can you comment on what they mean and if they are concerning? I've obfuscated IP's and node names so please ignore those. Our tinc daemon command is: tincd -n <vpn name> -- Received short packet -- Got REQ_KEY from node003 while we already started a SPTPS session! -- Invalid

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>

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

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

On Wed, 21 Mar 2018 19:28:05 -0600, "Todd C. Miller" wrote: > Note that it will only be used if you generate ed25519 keys to use > with it. The new protocol is one of the main reasons to run 1.1. Also, tinc 1.1 can still interoperate with tinc 1.0 nodes using the legacy protocol. You can read more about sptps in the tinc 1.1 manual in the security section. - todd

Hi, If I have an R object UUU, where the second element is U2, based on "g" column of my.table my.table of UUU is: mmm ggg gindex map Info aaa123 U1 1 1 1 aaa124 U1 1 2 1 bbb1378 U2 2 1 1 bbb8888 U2 2 2 0 bbb1389 U2 2 3

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

Hi list, My case : Local UNIX user : ZTEST domain : uuq.ork domain user : UUQ\ztest smb.conf for standalone samba : /home/hywu/smb.conf [/home/hywu] # cat /home/hywu/smb.conf [global] passdb backend = smbpasswd workgroup = WORKGROUP security=user Smbpasswd fail to change local UNIX user password (ZTEST) when samba role is DC. I want to change password of local UNIX user "ZTEST" but

On Wed, 21 Mar 2018 14:54:07 -0700, al so wrote: > Are you sure it is enabled by default? Yes. See the description of ExperimentalProtocol in the tinc.conf manual for details. If you don't believe that, check src/protocol.c and you will see that the "experimental" flag is set to true by default. - todd

I am surprised this experimental protocol is enabled by default. On Wed, Mar 21, 2018 at 3:07 PM, Todd C. Miller <Todd.Miller at sudo.ws> wrote: > On Wed, 21 Mar 2018 14:54:07 -0700, al so wrote: > > > Are you sure it is enabled by default? > > Yes. > > See the description of ExperimentalProtocol in the tinc.conf manual > for details. If you don't believe

On Thu, 25 Jan 2024 18:27:48 +0800 hhyy ww via samba <samba at lists.samba.org> wrote: > Hi list, > > My case : > Local UNIX user : ZTEST > domain : uuq.ork > domain user : UUQ\ztest > smb.conf for standalone samba : /home/hywu/smb.conf > > [/home/hywu] # cat /home/hywu/smb.conf > [global] > passdb backend = smbpasswd > workgroup = WORKGROUP >