search for: req_key

....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 tinc.nnn[2217]: Got REQ_KEY from YYY while we already started a SPTPS session! Aug 19 14:52:04 AAA tinc.nnn[2217]: Got REQ_KEY from ZZZ while we already started a SPTPS session! Aug 19 14:52:06 AAA tinc.nnn[2217]: Got REQ_KEY fr...

...lid packet seqno: 384 != 0 from node_2 (10.0.0.3 port 655) May 09 09:25:25 node-1 tincd[14195]: Invalid packet seqno: 385 != 0 from node_2 (10.0.0.3 port 655) May 09 09:25:25 node-1 tincd[14195]: Invalid packet seqno: 386 != 0 from node_2 (10.0.0.3 port 655) May 09 09:25:44 node-1 tincd[14195]: Got REQ_KEY from node_3 while we already started a SPTPS session! May 09 09:25:44 node-1 tincd[14195]: Handshake phase not finished yet from node_3 (10.0.0.2 port 655) May 09 09:25:44 node-1 tincd[14195]: Got REQ_KEY from node_2 while we already started a SPTPS session! May 09 09:25:44 node-1 tincd[14195]: Got...

...utput: of tincd when above is run. Received packet of 1450 bytes from server (10.172.241.254 port 655) Writing packet of 1450 bytes to Linux tun/tap device (tap mode) Received packet of 96 bytes from server (10.172.241.254 port 655) Writing packet of 96 bytes to Linux tun/tap device (tap mode) Got REQ_KEY from server (10.172.241.254 port 655): 15 server hostA 21 .....key is removed from here.... and for lines below .... Received packet of 1450 bytes from server (10.172.241.254 port 655) Writing packet of 1450 bytes to Linux tun/tap device (tap mode) Received packet of 96 bytes from server (10.172.24...

...4:16 JOTVPN console-kit-daemon[1658]: console-kit-daemon[1658]: GLib-CRITICAL: Source ID 190 was not found when attempting to remove it Dec 10 15:44:16 JOTVPN console-kit-daemon[1658]: GLib-CRITICAL: Source ID 190 was not found when attempting to remove it Dec 10 15:47:22 JOTVPN tinc.vpn[1021]: Got REQ_KEY from Node4 while we already started a SPTPS session! Dec 10 15:47:22 JOTVPN tinc.vpn[1021]: Got REQ_KEY from Node1 while we already started a SPTPS session! Dec 10 15:47:22 JOTVPN tinc.vpn[1021]: Got REQ_KEY from Node3 while we already started a SPTPS session! Dec 10 15:48:13 JOTVPN mpt-statusd: de...

...I'm guessing SPTPS is not designed solely to address these (relatively simple) issues. - The way SPTPS is currently implemented in tinc, sending packets over TCP is extremely inefficient because instead of using PACKET messages like the legacy protocol does, it encapsulates the packet in a REQ_KEY message (for backwards compatibility reasons, I guess). The problem is, the packet contents are encoded using... base64. Now, I know that TCP over TCP is not supposed to be very efficient in the first place, but a 40% encoding overhead seems excessive to say the least. More generally, it's...

...in config file -- does this mean this node can only send packets (meta and data connections) directly to those hosts, and that packets destined to others will be relayed through the ConnectTo hosts? "nexthop" seems to confirm this -- only Connections are nexthops -- but then ADD_EDGE and REQ_KEY meta messages (as documented here https://www.tinc-vpn.org/documentation/The-meta_002dprotocol.html#The-meta_002dprotocol) seem to imply direct data packets are possible. 3. What is the routing behavior when multiple nodes advertise the same subnet at the same weight? I think this is it: https://g...

...but create a PKI is another issue for us. Instead, we have an idea : would it be possible to have a option in tinc.conf like "TrustedNodes=aaa,bbb,ccc" ? With this option : (a) any ADD_EDGE/ADD_SUBNET/ANS_KEY/... will be cancelled if it comes from a non-trusted connection (b) all REQ_KEY will be sent to trusted nodes only. (a) is easy, but we do not know how to manage (b). In net_packet.c and protocol_key.c we see : send_req_key(n->nexthop->connection, myself, n); The question is : how to be sure that "n->nexthop->connection" will be a "truste...

...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 packet seqno: 7951 != 1 from node003 (22.22.22.22 port 655) -- Failed to verify SIG record from node003 (22.22.22.22 port 655) -- message repeated 3 times: [ Received short packet] -- Metadata socket read error for node004 (33.33.33....

...B: Temporarily setting debug level to 5. Kill me with SIGINT again to go back to level 0. Read packet of 74 bytes from Linux tun/tap device (tun mode) Sending packet of 74 bytes to lleuad (84.92.216.214 port 655) No valid key known yet for lleuad (84.92.216.214 port 655), queueing packet Sending REQ_KEY to lleuad (84.92.216.214 port 4227): 15 athos lleuad Sending 16 bytes of metadata to lleuad (84.92.216.214 port 4227) Got ANS_KEY from lleuad (84.92.216.214 port 4227): 16 lleuad athos 14EDE2A2E4C14F97B3CBF94A388C79C420D6096B29D9F1EB 91 64 4 0 Flushing queue for lleuad (84.92.216.214 port 655) Got...

...DD_EDGE from crux (192.168.192.17 port 32852): ..... Node crux (192.168.192.17 port 655) became reachable Read packet of 98 bytes from Linux tun/tap device Sending packet of 98 bytes to crux (192.168.192.17 port 655) No valid key known yet for crux (192.168.192.17 port 655), queueing packet Sending REQ_KEY to crux (192.168.192.17 port 32852): 15 helix crux Sending 14 bytes of metadata to crux (192.168.192.17 port 32852) Got ANS_KEY from crux (192.168.192.17 port 32852): 16 ..... Flushing queue for crux (192.168.192.17 port 655) Got REQ_KEY from crux (192.168.192.17 port 32852): 15 crux helix Sending...

...NG/PONG from A to B but no other data gets through. From the syslog on B we see: Feb 19 15:13:11 linux tinc.vpn[2414]: Node A (12.221.73.89) became reachable Feb 19 15:13:11 linux tinc.vpn[2414]: Got ADD_SUBNET from A (12.221.73.89): 10 A 192.168.0.0/24 Feb 19 15:13:22 linux tinc.vpn[2414]: Got REQ_KEY from A (12.221.73.89): 15 A B Feb 19 15:13:22 linux tinc.vpn[2414]: Sending ANS_KEY to A (12.221.73.89): 16 B A B157130AC44115976F7A773719D0DBEC8E2EADD4EF0BA824 91 64 4 Feb 19 15:13:22 linux tinc.vpn[2414]: Sending 68 bytes of metadata to A (12.221.73.89) Feb 19 15:13:22 linux tinc.vpn[2414]: R...

...hat 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 metaconnections). So, in your example, B will send a REQ_KEY message to A, which will forward it to C, which will respond with an ANS_KEY message, also forwarded through A. - These "data keys" are generated on-the-fly and are eph...

...(212.79.9.74) Jun 27 09:05:04 pcamueller tinc[28135]: Connection with 192.168.9.1 (212.79.9.74) activated *** SERVER (when PINGed from client) *** Jun 27 09:06:03 lemon tinc.9[10186]: Got request from 192.168.9.99 (192.168.2.100 ): 160 c0a80901 c0a80963 Jun 27 09:06:03 lemon tinc.9[10186]: Got REQ_KEY origin 192.168.9.99 destination192.168.9.1 from 192.168.9.99 (192.168.2.100) Jun 27 09:06:03 lemon tinc.9[10186]: Sending ANS_KEY to 192.168.9.99 (192.168.2.1 00) Jun 27 09:06:03 lemon tinc.9[10186]: Got request from 192.168.9.99 (192.168.2.100): 161 c0a80901 c0a80963 962093104 2rrsesncmha0uws71...

...f 42 bytes from Windows tap device Cannot route packet: ARP request for unknown address 192.168.2.200 Read packet of 74 bytes from Windows tap device Sending packet of 74 bytes to office (111.111.111.111 port 655) No valid key known yet for office (111.111.111.111 port 655), queueing packet Sending REQ_KEY to office (111.111.111.111 port 655): 15 support office Sending 15 bytes of metadata to office (111.111.111.111 port 655) Flushing 15 bytes to office (111.111.111.111 port 655) Read packet of 110 bytes from Windows tap device Cannot route packet from support (MYSELF): unknown IPv4 destination addre...

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 key from node after 10 seconds, restarting SPTPS The first message usually shows for many nodes at once (like a local problem). The o...

...his mean this node can only send packets (meta and > data connections) directly to those hosts, and that packets destined to > others will be relayed through the ConnectTo hosts? > > "nexthop" seems to confirm this -- only Connections are nexthops -- but > then ADD_EDGE and REQ_KEY meta messages (as documented here > https://www.tinc-vpn.org/documentation/The-meta_ > 002dprotocol.html#The-meta_002dprotocol) seem to imply direct data > packets are possible. > > 3. What is the routing behavior when multiple nodes advertise the same > subnet at the same weight?...

Hi all! I still have never managed to fully wrap my head around how UDP data tunnels can be established between nodes. Everytime I think I understand it, I see something that confuses me again Just now I am seeing the following: I have nodes A, B + C A has everybody's keys and host configuration files. B and C only have A's key, and host config with A's public IP address. B and

...rent key regeneration protocol - maybe we should simply come up with a new one. How about simply terminating the current SPTPS channel and creating a new one? That would remove the need for a key regeneration protocol altogether, since it's just creating and terminating SPTPS channels. In fact, req_key_ext_h(REQ_KEY) is already smart enough to restart SPTPS if there's already a channel. Furthermore, if we allow the old and new channels to overlap for a short period of time, we can prevent packet loss during regeneration.

...38.216.106 port 655): 16 Office Lukav_Beast 52201D7CFDC2C7E1FD7871A36E651B7AC24A52B4ED892CD953397F6BA859AB22D5D4CB235B9CF85910B6BDE91A34C85E 427 672 4 0 94.155.19.130 13935 Using reflexive UDP address from Office: 94.155.19.130 port 13935 UDP address of Office set to 94.155.19.130 port 13935 Got REQ_KEY from Backbone (164.138.216.106 port 655): 15 Office Lukav_Beast Program received signal SIGSEGV, Segmentation fault. 0x000055555556de41 in send_ans_key (to=to at entry=0x555555851060) at protocol_key.c:382 382        return send_request(to->nexthop->connection, "%d %s %s %s %d %d %d %...

...g ADD_SUBNET from client1 (2.2.2.2 port 35031) Got ADD_EDGE from client1 (2.2.2.2 port 35031) Forwarding ADD_EDGE from client1 (2.2.2.2 port 35031) UDP address of client1 set to 2.2.2.2 port 655 Sending ANS_KEY to client1 (2.2.2.2 port 35031) UDP address of client1 set to 2.2.2.2 port 19446 Sending REQ_KEY to client1 (2.2.2.2 port 35031) Sending PACKET to client1 (2.2.2.2 port 35031) Sending PACKET to client1 (2.2.2.2 port 35031) Got ANS_KEY from client1 (2.2.2.2 port 35031) Got ANS_KEY from client1 (2.2.2.2 port 35031) Got PING from client1 (2.2.2.2 port 35031) Sending PONG to client1 (2.2.2.2 port...