Hi,

I have setup a testing environnement with 3 x Proxmox in datacenter using Ceph and TINC.

I have tested the official bin of Tinc from Debian Stretch repo, but i have found a segmentation fault when you disable Cipher/Digest, so i have compile latest Tinc from this github and it works, but some times now, i see slow down request with Ceph, like this :

2018-03-04 21:22:30.450461 mon.sd-58652 mon.0 10.10.10.1:6789/0 5567 : cluster [WRN] Health check failed: 3 slow requests are blocked > 32 sec (REQUEST_SLOW)
2018-03-04 21:22:36.502007 mon.sd-58652 mon.0 10.10.10.1:6789/0 5568 : cluster [WRN] overall HEALTH_WARN 4 slow requests are blocked > 32 sec
2018-03-04 21:22:36.546041 mon.sd-58652 mon.0 10.10.10.1:6789/0 5569 : cluster [WRN] Health check update: 4 slow requests are blocked > 32 sec (REQUEST_SLOW)
2018-03-04 21:22:38.132093 osd.0 osd.0 10.10.10.3:6800/2205 783 : cluster [WRN] 3 slow requests, 3 included below; oldest blocked for > 30.873970 secs
2018-03-04 21:22:38.132098 osd.0 osd.0 10.10.10.3:6800/2205 784 : cluster [WRN] slow request 30.873970 seconds old, received at 2018-03-04 21:22:07.258064: osd_op(client.1696664.0:776670 1.6b 1:d6adde44:::rbd_data.134774b0dc51.0000000000000349:head [write 6553604096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:22:38.132103 osd.0 osd.0 10.10.10.3:6800/2205 785 : cluster [WRN] slow request 30.873875 seconds old, received at 2018-03-04 21:22:07.258158: osd_op(client.1696664.0:776671 1.6b 1:d6adde44:::rbd_data.134774b0dc51.0000000000000349:head [write 6799364096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:22:38.132105 osd.0 osd.0 10.10.10.3:6800/2205 786 : cluster [WRN] slow request 30.807665 seconds old, received at 2018-03-04 21:22:07.324369: osd_op(client.1696664.0:776672 1.36 1:6ca12491:::rbd_data.134774b0dc51.000000000000f421:head [write 218726420480] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:22:41.546322 mon.sd-58652 mon.0 10.10.10.1:6789/0 5570 : cluster [WRN] Health check update: 5 slow requests are blocked > 32 sec (REQUEST_SLOW)
2018-03-04 21:22:42.540770 osd.2 osd.2 10.10.10.2:6800/2334 745 : cluster [WRN] 1 slow requests, 1 included below; oldest blocked for > 30.280664 secs
2018-03-04 21:22:42.540773 osd.2 osd.2 10.10.10.2:6800/2334 746 : cluster [WRN] slow request 30.280664 seconds old, received at 2018-03-04 21:22:12.260071: osd_op(client.1696664.0:776675 1.52 1:4b1c8676:::rbd_data.134774b0dc51.0000000000007db8:head [write 17776644096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:22:43.132888 osd.0 osd.0 10.10.10.3:6800/2205 787 : cluster [WRN] 4 slow requests, 1 included below; oldest blocked for > 35.874792 secs
2018-03-04 21:22:43.132892 osd.0 osd.0 10.10.10.3:6800/2205 788 : cluster [WRN] slow request 30.874467 seconds old, received at 2018-03-04 21:22:12.258388: osd_op(client.1696664.0:776674 1.69 1:97d477a8:::rbd_data.134774b0dc51.0000000000007d99:head [write 26132488192] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:22:48.133662 osd.0 osd.0 10.10.10.3:6800/2205 789 : cluster [WRN] 5 slow requests, 1 included below; oldest blocked for > 40.875568 secs
2018-03-04 21:22:48.133674 osd.0 osd.0 10.10.10.3:6800/2205 790 : cluster [WRN] slow request 30.874829 seconds old, received at 2018-03-04 21:22:17.258802: osd_op(client.1696664.0:776686 1.1f 1:f9142487:::rbd_data.134774b0dc51.0000000000007d97:head [write 10526724096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:08.136866 osd.0 osd.0 10.10.10.3:6800/2205 791 : cluster [WRN] 5 slow requests, 3 included below; oldest blocked for > 60.878780 secs
2018-03-04 21:23:08.136869 osd.0 osd.0 10.10.10.3:6800/2205 792 : cluster [WRN] slow request 60.878780 seconds old, received at 2018-03-04 21:22:07.258064: osd_op(client.1696664.0:776670 1.6b 1:d6adde44:::rbd_data.134774b0dc51.0000000000000349:head [write 6553604096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:08.136871 osd.0 osd.0 10.10.10.3:6800/2205 793 : cluster [WRN] slow request 60.878686 seconds old, received at 2018-03-04 21:22:07.258158: osd_op(client.1696664.0:776671 1.6b 1:d6adde44:::rbd_data.134774b0dc51.0000000000000349:head [write 6799364096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:08.136873 osd.0 osd.0 10.10.10.3:6800/2205 794 : cluster [WRN] slow request 60.812475 seconds old, received at 2018-03-04 21:22:07.324369: osd_op(client.1696664.0:776672 1.36 1:6ca12491:::rbd_data.134774b0dc51.000000000000f421:head [write 218726420480] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:10.656907 mon.sd-58652 mon.0 10.10.10.1:6789/0 5571 : cluster [WRN] Health check update: 6 slow requests are blocked > 32 sec (REQUEST_SLOW)
2018-03-04 21:23:12.545443 osd.2 osd.2 10.10.10.2:6800/2334 747 : cluster [WRN] 1 slow requests, 1 included below; oldest blocked for > 60.285357 secs
2018-03-04 21:23:12.545446 osd.2 osd.2 10.10.10.2:6800/2334 748 : cluster [WRN] slow request 60.285357 seconds old, received at 2018-03-04 21:22:12.260071: osd_op(client.1696664.0:776675 1.52 1:4b1c8676:::rbd_data.134774b0dc51.0000000000007db8:head [write 17776644096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:13.137740 osd.0 osd.0 10.10.10.3:6800/2205 795 : cluster [WRN] 5 slow requests, 1 included below; oldest blocked for > 65.879653 secs
2018-03-04 21:23:13.137751 osd.0 osd.0 10.10.10.3:6800/2205 796 : cluster [WRN] slow request 60.879329 seconds old, received at 2018-03-04 21:22:12.258388: osd_op(client.1696664.0:776674 1.69 1:97d477a8:::rbd_data.134774b0dc51.0000000000007d99:head [write 26132488192] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:18.138549 osd.0 osd.0 10.10.10.3:6800/2205 797 : cluster [WRN] 6 slow requests, 2 included below; oldest blocked for > 70.880452 secs
2018-03-04 21:23:18.138560 osd.0 osd.0 10.10.10.3:6800/2205 798 : cluster [WRN] slow request 60.879714 seconds old, received at 2018-03-04 21:22:17.258802: osd_op(client.1696664.0:776686 1.1f 1:f9142487:::rbd_data.134774b0dc51.0000000000007d97:head [write 10526724096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:18.138563 osd.0 osd.0 10.10.10.3:6800/2205 799 : cluster [WRN] slow request 30.878458 seconds old, received at 2018-03-04 21:22:47.260058: osd_op(client.1696664.0:776704 1.69 1:97d477a8:::rbd_data.134774b0dc51.0000000000007d99:head [write 26173444096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:36.518081 mon.sd-58652 mon.0 10.10.10.1:6789/0 5572 : cluster [WRN] overall HEALTH_WARN 6 slow requests are blocked > 32 sec
2018-03-04 21:23:40.468816 mon.sd-58652 mon.0 10.10.10.1:6789/0 5573 : cluster [WRN] Health check update: 9 slow requests are blocked > 32 sec (REQUEST_SLOW)
2018-03-04 21:23:46.548919 mon.sd-58652 mon.0 10.10.10.1:6789/0 5574 : cluster [WRN] Health check update: 10 slow requests are blocked > 32 sec (REQUEST_SLOW)
2018-03-04 21:23:48.143487 osd.0 osd.0 10.10.10.3:6800/2205 800 : cluster [WRN] 9 slow requests, 4 included below; oldest blocked for > 100.885379 secs
2018-03-04 21:23:48.143491 osd.0 osd.0 10.10.10.3:6800/2205 801 : cluster [WRN] slow request 30.882169 seconds old, received at 2018-03-04 21:23:17.261274: osd_op(client.1696664.0:776721 1.6b 1:d6adde44:::rbd_data.134774b0dc51.0000000000000349:head [write 6553604096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:48.143497 osd.0 osd.0 10.10.10.3:6800/2205 802 : cluster [WRN] slow request 30.882064 seconds old, received at 2018-03-04 21:23:17.261379: osd_op(client.1696664.0:776722 1.6b 1:d6adde44:::rbd_data.134774b0dc51.0000000000000349:head [write 6799364096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:48.143499 osd.0 osd.0 10.10.10.3:6800/2205 803 : cluster [WRN] slow request 30.882034 seconds old, received at 2018-03-04 21:23:17.261409: osd_op(client.1696664.0:776723 1.1f 1:f9142487:::rbd_data.134774b0dc51.0000000000007d97:head [write 10526724096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:48.143500 osd.0 osd.0 10.10.10.3:6800/2205 804 : cluster [WRN] slow request 60.883385 seconds old, received at 2018-03-04 21:22:47.260058: osd_op(client.1696664.0:776704 1.69 1:97d477a8:::rbd_data.134774b0dc51.0000000000007d99:head [write 26173444096] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:23:51.549206 mon.sd-58652 mon.0 10.10.10.1:6789/0 5575 : cluster [WRN] Health check update: 11 slow requests are blocked > 32 sec (REQUEST_SLOW)
2018-03-04 21:23:56.549489 mon.sd-58652 mon.0 10.10.10.1:6789/0 5578 : cluster [WRN] Health check update: 16 slow requests are blocked > 32 sec (REQUEST_SLOW)
2018-03-04 21:23:53.144284 osd.0 osd.0 10.10.10.3:6800/2205 805 : cluster [WRN] 10 slow requests, 1 included below; oldest blocked for > 105.886180 secs
2018-03-04 21:23:53.144296 osd.0 osd.0 10.10.10.3:6800/2205 806 : cluster [WRN] slow request 30.882599 seconds old, received at 2018-03-04 21:23:22.261645: osd_op(client.1696664.0:776727 1.69 1:97d477a8:::rbd_data.134774b0dc51.0000000000007d99:head [write 26173448192] snapc a=[] ondisk+write+known_if_redirected e201) currently sub_op_commit_rec from 1
2018-03-04 21:24:04.475247 mon.sd-58652 mon.0 10.10.10.1:6789/0 5579 : cluster [INF] Health check cleared: REQUEST_SLOW (was: 16 slow requests are blocked > 32 sec)
2018-03-04 21:24:04.475287 mon.sd-58652 mon.0 10.10.10.1:6789/0 5580 : cluster [INF] Cluster is now healthy
2018-03-04 21:24:29.898012 mon.sd-58652 mon.0 10.10.10.1:6789/0 5581 : cluster [INF] mon.2 10.10.10.3:6789/0
2018-03-04 21:24:29.898065 mon.sd-58652 mon.0 10.10.10.1:6789/0 5582 : cluster [INF] mon.1 10.10.10.2:6789/0
2018-03-04 21:24:36.535533 mon.sd-58652 mon.0 10.10.10.1:6789/0 5583 : cluster [INF] overall HEALTH_OK

The cluster have 1 VM, i don't stress it for the moment and i don't know why i get slow request, it make no sense because i don't use any ressource from the cluster, i'm testing stability with zero activity first.

I have disable Cipher and Digest to get better latency and bandwith and use less cpu on proxmox host, and i have set high priority process in each tinc conf file.

thanks :-)

There are a lot kernel bypassing work in linux network stack, like packet_mmap, dpdk or the recent ebpf/xdp framework. I'm wondering if tinc could take advantage of these tricks, or even use raw sockets instead of the conventional udp+tuntap interface to reduce the kernel overhead?

Wireguard has drawn a lot of attention recently, but I think it is not much superior over tinc other than it seats in the kernel, while only handle a small part of tinc's job. Also, raw socket is not linux-specific, so if tinc could use raw sockets, it could be a state of the art high performance cross platform solution.

Hey,

I've been trying to figure out an issue with Tinc running on my servers that I've discovered yesterday. I have 63 hosts inter-connected via Tinc and I'm getting 100% CPU usage and growing memory usage from Tinc after I start it on most of the hosts:

tincd[5418]: Metadata socket read error for host1 (1.2.3.4 port 655): Connection reset by peer
tincd[5418]: Metadata socket read error for host2 (1.2.3.5 port 655): Connection reset by peer
tincd[5418]: Metadata socket read error for host3 (1.2.3.6 port 655): Connection reset by peer
tincd[5418]: Metadata socket read error for host4 (1.2.3.7 port 655): Connection reset by peer
tincd[5418]: Metadata socket read error for <unknown> (1.2.3.8 port 38498): Connection reset by peer
tincd[5418]: Metadata socket read error for host5 (1.2.3.9 port 655): Connection reset by peer

And when I stop most of the Tinc services on servers the CPU load does not go down. I need to stop the processes myself. But when I start them back up again I get insane high CPU usage again.
I have no idea what is causing this, and this makes Tinc essentially unusable.

Cross compiling failed with reference documentation readme.android.The last update of this document is 2014. Can you update it now?
There was an error running the command CC=/tmp/my-android-toolchain/bin/arm-linux-androideabi-gcc ./configure --host=arm-linux --disable-lzo --with-openssl-lib=$HOME/android/openssl-1.0.1g --with-openssl-include=$HOME/android/openssl-1.0.1g/include/ --disable-hardening,
checking openssl/evp.h usability... no
checking openssl/evp.h presence... no
checking for openssl/evp.h... no
configure: error: LibreSSL/OpenSSL header files not found.
But my openssl openssl-devel is all installed.
seek help！！！

Playing with tinc and missing (in documentation) a way to modify the 900 second maximum timeout for reconnect attempts, a look at the source revealed that there is a MaxTimeout setting to that effect, and that it even works :)

Shouldn't it be added to the documentation?

Hello,

It would be nice to be able to set the log level from the tinc.conf file.

A LogLevel or Debug variable could be added, having the same effect as the --debug command line option. The command line option would override the parameter set in the configuration file, if defined.

This would be particularly useful for an Android port of tinc, which doesn't easily allow the user to pass command line options. Ref: pacien/tincapp#16

TODOlist:

• something like get_config_int(cfg_debug, &debug_level), possibly in tincd.c?
• make tinc fsck validate such key.
• add such option in the manual.

tinc version: tinc version 1.1pre15 (built Dec 26 2017 21:04:50, protocol 17.7)

The following invitation-created script produces a nonsensical warning when the invitation is accepted, seemingly due to the single empty line.

#!/bin/sh

cat > "$INVITATION_FILE" <<EOF
Name = $NODE
Mode = switch
Netname = $NETNAME
ConnectTo = $NAME
Ifconfig = dhcp

# [Entry node configuration]
EOF

tinc export >> "$INVITATION_FILE"

$ tinc join host/key
Connected to host port 655...
Ignoring unknown variable '' in invitation.
...........................................................+++ p
...............................................+++ q

Please review the following tinc-up script:

#!/bin/sh
dhclient -nw "$INTERFACE"
ip link set "$INTERFACE" up

Do you want to use this script [y]es/[n]o/[e]dit? y

tinc-up enabled.
Configuration stored in: /etc/tinc/netname
Invitation succesfully accepted.

This weekend I benchmarked Tinc (multiple versions) on the smallest DigitalOcean instance.

I found that it generates very high CPU load (much more than on a desktop), and network performance maxes out at around 200 MBit/s with iperf3 from one Tinc node to another, when the raw interface can deliver 1000 Mbit/s without noticeable CPU load.

This is a write up of the little investigation I did, maybe as a help if some third party Tinc contributor wants to try and solve this problem (or if I find the time for it myself at some point).

Note that I'm extremely new to Tinc (I started reading into the code this weekend), so some of this may not be 100% accurate, but @gsliepen was extremely helpful in answering my questions on the #tinc IRC channel - thanks for this.

There seem to be two things that make Tinc slow on these machines:

• Encryption:
  • The latest Tinc 1.1 branch switched from AES+SHA to ChaCha-Poly1305 (also, the Cipher and Digest config options are no longer configurable and are ignored). While ChaCha is faster than AES on standard machines, it cannot compete with the AES-NI hardware acceleration for AES that many modern CPU (and also those cloud machines) provide; the speed difference is approximately 4x (can also be tested with Tinc's sptps_speed utility).
  • ChaCha takes around 65% of CPU time in perf (make sure to use CFLAGS=-fno-omit-frame-pointer ./configure for measuring this).
  • Re-enabling AES would make the symmetric encryption overhead pretty much negligible, at least on Gigabit-Link machines.
  • But according to @gsliepen, this is not so easy / there is trade-off involved, because the OpenSSL interface that Tinc used in the past for AES(-NI) is not quite stable. Maybe libsodium could be used instead? No software fallback seems to be provided though.
• Syscalls:

  • When watching Tinc in htop while iperf3 is running, there's a lot of red, meaning time spent in the kernel. This is even more prominent when Cipher = none and Digest = none, which is still possible in Tinc 1.0.

  • In htop when enabling Display options -> Detailed CPU I can see that around 25-30% of the time is spent in softirq processing (violet colour). This also hints that lots of expensive syscalls are done (these are not as expensive on physical machines, but on some forms of virtualisation, it can be very expensive).

  • Changing the MTU might be a quick fix here, but one can't change the MTU to be higher than 1500 on DigitalOcean instances (then no UDP packets go through); AWS EC2 supports Jumbo Frames with MTU = 9000 (and Tinc has a ./configure option for that), but AWS EC2 only supports it on specific instances; it's not a general purpose workaround (definitely not once you send data outside of your data center).

  • The best way to improve this is to reduce the number of syscalls done using Linux's high-performance multi-data syscalls like writev(), recvmmsg() and sendmmsg(), in order to not have to do one syscall per UDP packet (which is a lot of syscalls given that the MTU restricts them to 1500 bytes size).

  • Tinc 1.1 has already implemented the use of recvmmsg() (original patch with details here).

  • For the reader passing-by, the flow through kernel and userspace with Tinc as a user-space VPN works like this: UDP packet arrives on real socket, tincd reads it, decrypts, writes it to tun interface file descriptior, from which the local client application can read it like over a real socket. When an application sends something over the Tinc VPN, sending it over the VPN network interface, tincd reads it from the tun device, encrypts it, and sends it out over the real network socket.

  • Tinc 1.0 performs the syscall chain select - read - sendto - recvfrom - write for each UDP packet it receives, that is:

    • select (wait for data)
    • read (from tun device from which user data comes)
    • sendto (to tinc peer via UDP)
    • recvfrom (from peer tinc via UDP)
    • write (to tun device for user application)

  • We can observe this nicely by running perf trace -p $(pidof tincd) during an iperf3 session:

    23156.949 ( 0.005 ms): pselect6(n: 8, inp: 0x7fff63d12350, outp: 0x7fff63d123d0, tsp: 0x7fff63d12270, sig: 0x7fff63d12280) = 2
    23156.957 ( 0.004 ms): read(fd: 3</dev/net/tun>, buf: 0x7fff63d11c16, count: 1508            ) = 1457
    23156.972 ( 0.011 ms): sendto(fd: 5, buff: 0x7fff63d11c08, len: 1471, addr: 0x7f6397e1f480, addr_len: 16) = 1471
    23156.979 ( 0.004 ms): recvfrom(fd: 5, ubuf: 0x7fff63d11528, size: 1661, addr: 0x7fff63d11500, addr_len: 0x7fff63d114ec) = 70
    23156.992 ( 0.009 ms): write(fd: 3</dev/net/tun>, buf: 0x7fff63d11536, count: 56             ) = 56
    

    Notably (this is Tinc 1.0.26) one syscall is made per UDP packet, we can see it in the size of read() and sendto(), in this case 1457 and 1471 - just below the interface's default MTU of 1500. (The reads from the other side are small, as it makes sense, as I'm sending from this node using iperf -c othernode.)

  • As mentioned above, in Tinc 1.1 recvmmsg() is used, which batches many of those little recvfroms, and improves the syscall chain to N * (select - read - sendto - gettimeofday) - recvmmsg - write write write...

  • For one of these chains, the time spent is roughly (on that smallest DigitalOcean instance):

    • 8 ms for the N write calls
    • 0.2 ms for the recvmmsg that's the equivalent data of all those writes - that optimisation seems to have worked very well, a 40x syscall time difference for the same data
    • 8 ms for the N select - read - sendto - gettimeofday calls, of this roughly:
      • 2 ms for select
      • 2 ms for read
      • 2 ms for sendto
      • 2 ms for gettimeofday

  • Consequently, there's still approximately as much to optimise on the "write to tun device" side as there is on the "read from real socket" side.

  • It seems that the following optimisations remain possible:

    • Batching the writes into one writev().
      • Here's an overview on the relevant code (as of commit e44c337ea): At the place where the recvmmsg() takes place, it does for(int i = 0; i < num /* received packets */; i++) { handle_incoming_vpn_packet(ls, &pkt[i], &addr[i]) } for each packet, and that handle_incoming_vpn_packet() eventually leads via receive_packet(), route(), route_ipv4(), send_packet(), devops.write(packet), write_packet() to the write() syscall. I assume that's the data path that would have to be changed to operate on the entire num packets if we want to write them in one writev() call eventually.
      • My guess is that all function on this code path would have to be changed to an array of packets instead of a single packet.
      • Care must be taken at the route() function, where the packets can be split: Some may not be for us, but to be forwarded to other nodes, so they would not have to be written to our tun device. However, writev() should still be able to deal with this in a zero-copy fashion, since the N starting addresses it takes do not have to be contiguous.
    • Batching the sendtos into one sendmmsg().
      • This is very analogous to the writev() point above, but for the real socket, not to the tun device.
      • It is my understanding that no special care with routing would be needed, since when on their way outward, all packets already contain their target addresses, and from those the inputs to sendmmsg can be directly constructed.
    • Batching the reads into one bigger read().
      • I did not look into this in detail, but since the tun device is just a file descriptor, my guess is that we could simply read bigger chunks witht the same syscall here. But I may be wrong.
    • Removing the gettimeofdays
      • That gettimeofday is new in Tinc 1.1, version 1.0 didn't have that per packet. I think it is used to check that the MAC'd packet is recent, but not sure yet.
      • It is a common optimisation in web servers to debounce these gettimeofday calls so that they happen only in specific scheduled intervals, typically using a thread.
      • @gsliepen mentioned that only one this is needed per select() call, of which we would have much less when both recvmmsg() and sendmmsg() are implemented, so this optimisation may no longer be necessary at that point.

  • As a result, the optimal syscall chain would probably be: select - read - sendmmsg - gettimeofday - recvmmsg - writev.

  • I expect that we could get a similar 40x overhead reduction as with recvmmsg() - if this turns out true, we'd be in good shape.

Overall, I'm quite confident that by doing these two optimisations (hardware accelerated AES and multi-packet bundling syscalls), Tinc will be able to achive Gigabit link speed with little or negligible CPU utilisation, even on those small cloud instances. (And maybe saturate 10 Gig Ethernet on real machines?)

Now we just have to implement them :)

I don't do a lot of compiling from source, so forgive me if this is just ignorance, but I recently compiled 1.1pre15 from source on Ubuntu 17.10. I wanted the binaries to be located in standard system (not /usr) directories, and I wanted to manage the service with systemd so the configuration was done like this:

./configure --prefix= --with-systemd

then make
then sudo make install

When I then configured a network and tried to bring the tinc service up using

systemctl enable tinc@<netname>

the service didn't come up and the error log told me that /usr/sbin/tincd was not found.

To make it work, I had to edit the [email protected] file that was installed in /lib/systemd/system/[email protected] and change the two instances of /usr/sbin/tincd to /sbin/tincd.

After that, everything worked as expected.

Maybe I don't understand how ./configure is supposed to work, but when I ran it with --prefix= isn't that what made the install directory for tincd be /sbin/ and shouldn't that have also modified the [email protected] file so that it pointed to the correct path?

Or do I have this all wrong?

When trying to compile the latest tinc [from the 1.1 branch] from git, it seems the following error now occurs when compiling the code.

CC openssl/prf.o
In file included from openssl/prf.c:24:0:
openssl/digest.h:27:2: error: unknown type name 'HMAC_CTX'
HMAC_CTX *hmac_ctx;
^~~~~~~~

I am using OpenSSL 1.0.2n, gcc 7.3.1 and it seems ever since commit [ https://github.com/gsliepen/tinc/commit/ecfef0eeb9b52f6d75b4aa936a1e11e6d8e678e3 ] from Feb 18th, I cannot compile the code anymore.

I am trying to access the output of tinc join INVITATION and tinc -n NETWORK start -D -d3 via an AutoIT Script on Windows 7.

I neither can read 'live' output generated by tinc join nor tinc start. But reading tinc --version or tinc --help works.

I also tried to access the console output via Java, but the output is always empty, while tinc is running.

Do you use different techniques to write to console in tinc --version and tinc start?

protocol_edge.c : add_edge_h allocates over 12kB of data on the stack (MAX_STRING_SIZE * 6), which could overrun the stack on some systems, depending on stack size.

Note:
#define MAX_STRING_SIZE 2049

Also, in protocol_key.c : req_key_ext_h, the use of sscanf into a stack buffer "buf" may result in a stack overflow if the value read is larger than the buffer.

I've read from the mailing list that tinc was not FIPS compatible due to the use of non-compliant algorithms from a non-validated library (https://www.tinc-vpn.org/pipermail/tinc/2016-July/004610.html). However, since then, tinc has switched over to using FIPS compliant algorithms (AES-256, SHA-256, RSA) from a library with a FIPS validated module (OpenSSL). If I'm correct, then the only thing left to do to gain compliance is a call out to FIPS_mode_set(). Would it be possible to add a flag like --fips-mode that runs this check in the main function?

Hi,

Since tinc.service is removed I can't seem to find a way to start all enabled [email protected], or to automatically start them at system startup.

$ sudo systemctl enable tinc@mynet
Created symlink from /etc/systemd/system/tinc.service.wants/[email protected] to /usr/lib/systemd/system/[email protected].

systemctl start tinc does not work:

$ sudo systemctl start tinc
Failed to start tinc.service: Unit tinc.service not found.

$ sudo systemctl status tinc 
● tinc.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Am I doing anything wrong?

I deal with setting up automated deployments a lot, and one current pain point is that tinc generate-ed25519-keys really wants to be interactive.

It would be great if it could learn a flag so that it can be given the location where to generate its keys, like OpenSSL supports.

Hi Guus,

I use tinc 1.1 and played around with invite / join. I found out, that invited nodes only can connect via a relay to other (prior existing) nodes. A part (Ed25519PublicKey) of the host files are exchanged with invited nodes.
I figured out that no direct connection is possible with hosts, their hostfile only contains the Ed25519PublicKey value and not the RSA PUBLIC KEY.

If I exchange the complete hostfiles between the nodes, direct connections are possible.

So I came up with a question: Why are only Ed25519PublicKey Values exchanged at first connection between Nodes, which do not have their complete hostfiles?

The motivation of the question is that I plan to create a cross-plattform gui with automatic host file distribution.

Kind regards
tknapp

this morning we had router-upgrades that created (partial) network-loss of our tinc-daemons accross data-centers. some of them (8/60) failed and died with send_meta() called with NULL pointer!.

we're using old distribution versions:

tinc version 1.0.16
tinc version 1.0.26

i've checked the changelog, but could not find relevant commits in newer releases.
the most recent commit referring to "NULL pointer" is e913f3f (1.0.24)

At this line , the code assumes Cipher is always not null, and cause a null-pointer dereference when otherwise.

Requesting the addition of client GUIs for Windows and Mac. Adding a GUI would greatly increase adoption, especially in the corporate sector to support road warriors.

After running into some issues with the tinc systemd integration where I was unable to make it wait for the network to be online (on CentOS 7), see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1394512 I propose to remove tinc.service and modify [email protected] to the following, this is modelled after the [email protected] file:

[Unit]
Description=Tinc net %i
After=network.target

[Service]
Type=simple
WorkingDirectory=/etc/tinc/%i
ExecStart=/usr/sbin/tincd -n %i -D
ExecReload=/usr/sbin/tincd -n %i -kHUP
TimeoutStopSec=5
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target

Hello,
I really don't have much to add in detail to this issue as of current, but I'll try to go through and get as much detail as possible of the issue and the environment that I work on.

Upon recent installation of my Ubuntu 17.04 Server, it appears that the tinc service under systemd does start as expected, but however the nets.core simply appears to not be acknowledged.
I have a network named "backend" and have made sure that it is in the file, the permissions are proper on the directory, and it's contents including the shell scripts, and have confirmed that the configuration has previously worked on a Debian 8 installation running systemd. This leads me to believe that the issue may be related to this version of ubuntu specifically.

I can however, manually run the command tincd -n backend to get the interface, and the tunnel working which is good.

as previously mentioned, I don't have much to add other than the symptoms, and what I have done, but will be sure to provide as much information as I can if requested.

Thanks,
Andrew

eBPF (Extended Berkeley Packet Filters) is a new feature that was first added to Linux 3.15. Will Tinc 1.x supports it ?

"One of the more interesting features in this cycle is the ability
to attach eBPF programs (user-defined, sandboxed bytecode executed
by the kernel) to kprobes. This allows user-defined instrumentation
on a live kernel image that can never crash, hang or interfere with
the kernel negatively. (Right now it's limited to root-only, but in
the future we might allow unprivileged use as well.)"

From: https://lkml.org/lkml/2015/4/14/232

e.g. add %dir %{_sysconfdir}/tinc into %file section.
BTW, would you mind drop the rpm spec and debian directory into tarball (might into distro dir) as well?

Hi,

I want to have the same functionality described as below, but do not know how to achieve it, any tips?
https://www.questarter.com/q/tinc-vpn-can-not-access-local-lan-subnet-1_909795.html

These files require to be ran with admin rights, otherwise driver installation will fail. The most intuitive way to do this, is to right-click the file and choose "Run as administrator". However, that means the working directory is set incorrectly to C:\Windows\System32 instead of the location of the .bat file (blame Microsoft for that). Simply adding cd /d "%~dp0" to the top of both scripts should solve the issue. I'd commit the change myself but I can't seem to find these two files in the source tree.

Here is my situation on a windows machine:
I run tinc and it is using my last available tap adapter.
Than try to start openvpn but it gives me an error "All Tap-Windows adapters on this system are currently in use"
But when openvpn is running ok and I try to start the tinc service I get no error on stderr.
Using tinc cli I issue the start command and the output is this:

Could not create tinc service: (1073) The specified service already exists.
tinc service started

But in reality the service has stopped because openvpn has used my only tap adapter.

Is it possible to get on stderr the reason why tincd service has not started?

When data is encrypted to be sent to a node, are the session keys unique between each node or is the same session key shared across the entire subnet?

To illustrate, if I had nodes A, B, and C, and they all wanted to send data to one another, would it look like this:

A <-- k1 --> B
B <-- k2 --> C
C <-- k3 --> A

Or does it look more like this:

A <-- k1 --> B
B <-- k1 --> C
C <-- k1 --> A

My main concern is having a "bad" node eavesdrop on traffic that it's not participating in. I understand that this isn't likely in routing mode, since nodes talk directly to each other, but the model is a bit more unclear to me when in other modes such as switching.

If it helps paint a clearer picture, I'm just looking to encapsulate traffic across a LAN in case it becomes hostile but I'm also concerned about the compromise of a node within the mesh.

On https://www.tinc-vpn.org/pipermail/tinc/2015-April/004092.html you say that encryption settings only affect outgoing packets -- is it somehow possible that it's the other way around?

I have 2 servers, A and B, running tinc, and A has encryption disabled in its config file, B has it enabled. On B, if I run iperf3 -c A (means B sends), it's fast, if I run with -R (means A sends), it's slow.

I can reproduce this when I switch A and B.

Currently, invites are valid for 1 week, which is hard coded (version 1.1pre14). I would like them to be valid for just a couple of seconds, since I'm scripting the invite/join process. It would be great to be able to configure the TTL!

Where can I find clues about what's going wrong.
Thanks

OS: Debian 9

tincd -n vpn -D -d

tincd 1.0.31 starting, debug level 1
Segmentation fault

strace tincd -n vpn -D -d

(...)
open("/etc/tinc/vpn/tinc.conf", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=93, ...}) = 0
read(3, "Name = usa02\nMode = switch\nConne"..., 4096) = 93
read(3, "", 4096) = 0
close(3) = 0
open("/etc/tinc/vpn/conf.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
rt_sigaction(SIGHUP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGILL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGTRAP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGABRT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGBUS, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGFPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGKILL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = -1 EINVAL (Invalid argument)
rt_sigaction(SIGUSR1, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGSTKFLT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGCONT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGSTOP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = -1 EINVAL (Invalid argument)
rt_sigaction(SIGTSTP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGTTIN, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGTTOU, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGURG, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGXCPU, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGXFSZ, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGVTALRM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGPROF, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGWINCH, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGIO, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGPWR, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGSYS, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_3, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_4, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_5, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_6, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_7, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_8, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_9, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_10, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_11, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_12, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_13, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_14, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_15, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_16, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_17, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_18, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_19, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_20, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_21, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_22, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_23, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_24, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_25, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_26, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_27, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_28, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_29, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_30, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_31, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGRT_32, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGHUP, {sa_handler=0x5615102611b0, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0x561510261250, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=0x561510261210, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGBUS, {sa_handler=0x561510261320, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGILL, {sa_handler=0x561510261320, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=0x561510261570, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x5615102614d0, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {sa_handler=0x561510261310, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {sa_handler=0x5615102612f0, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGCHLD, {sa_handler=0x561510261570, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGALRM, {sa_handler=0x561510261180, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGWINCH, {sa_handler=0x561510261170, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
rt_sigaction(SIGABRT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fbe171df060}, NULL, 8) = 0
open("/var/run/tinc.vpn.pid", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
read(3, "10005\n", 4096) = 6
close(3) = 0
getpid() = 10008
kill(10005, SIG_0) = -1 ESRCH (No such process)
open("/var/run/tinc.vpn.pid", O_RDWR|O_CREAT, 0644) = 3
fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
flock(3, LOCK_EX|LOCK_NB) = 0
getpid() = 10008
fstat(3, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
write(3, "10008\n", 6) = 6
flock(3, LOCK_UN) = 0
close(3) = 0
getpid() = 10008
write(2, "tincd 1.0.31 starting, debug lev"..., 36tincd 1.0.31 starting, debug level 1) = 36
write(2, "\n", 1
) = 1
open("/etc/tinc/vpn/hosts/usa02", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0600, st_size=857, ...}) = 0
read(3, "Address = 54.39.56.183\nSubnet = "..., 4096) = 857
read(3, "", 4096) = 0
close(3) = 0
open("/etc/tinc/vpn/rsa_key.priv", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0600, st_size=3243, ...}) = 0
fstat(3, {st_mode=S_IFREG|0600, st_size=3243, ...}) = 0
read(3, "-----BEGIN RSA PRIVATE KEY-----\n"..., 4096) = 3243
close(3) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
+++ killed by SIGSEGV +++
Segmentation fault
root@usa02:/etc/tinc/vpn#

I notice that tincd daemon dead on my server sometime, in syslog i found this
Nov 17 15:34:07 isol kernel: [2504875.622373] tincd[26100]: segfault at 7fffbfb9c000 ip 00007efe8fa6e034 sp 00007fffbfb994a8 error 4 in libc-2.19.so[7efe8f9d6000+1ba000]

my server is ubuntu 14.04.5 LTS

thanks

Placeholder for a discussion of potential WireGuard backend.

Hello,

is there a bijective mapping between invitation file name on server and the invited node's name?

Thanks.

It would be helpful to be able to have the up/down scripts recieve the debug level.
for example --debug=3 could cause a DEBUG environmental variable set to 3 to be passed to tinc-up so that debug output from the tinc-up script can show up in stderr without having to modify the script to set an equivalent variable.

hi and, first off, thanks for providing such an awesome piece of sorftware :)
here's the issue:
I'm running a tincd at home with an internal IP address of 192.168.1.55 and an external IP address of... let's say ext.ip (forwarding port 655->655 and 24000->655 (in case of restrictive net-admins)). When I'm out with my laptop, its tinc connects fine with with the one running at home, but tinc -n <netname> dump connections on my laptop sometimes shows the internal IP of the server at home instead of the external IP:

(laptop) # tinc -n <netname> dump connections
<servername> at 192.168.1.55 port 655 options 0 socket 11 status 4

but this cannot be true as 192.168.1.55 doesn't even exist in the network that my laptop is in at this moment. The host file of the server on the laptop contains

Address = 192.168.1.55
Address = ext.ip 655
Address = ext.ip 24000

PS: I'm running tinc-1.1pre15 on both systems

Hello!

I keep running into a problem with invitations, using 1.1pre14.

I have a machine designated to create invitations to other machines in my network. First time I start tinc after reboot, tinc will respond to invites with Got invitation from X.X.X.X port XXXXX but we don't have an invitation key. However, after doing a tinc reload, it will start accepting invites. From time to time it starts responding with the same error again, until I do a tinc reload again.

When creating the invites, there is never any errors, and there is a new file created in the invitations directory each time.

The machine's config is:

AutoConnect = yes
AddressFamily = ipv4
DeviceType = tap
LocalDiscovery = yes
Mode = switch
Name = hub
PingInterval = 30
PingTimeout = 5
ProcessPriority = high

Hello, I found the tinc-down not called when I stop service, so I investigate the problem, and found that KillMode is default to control-group, this option will send TERM signal to all process in same group, include tinc-down script.

Add "KillMode=process" will fix this problem.

Hi, I'm new to tinc, I want to share my local network over tinc.

A: 192.168.100.1/32 master node
B: 192.168.1.0/24 client node, ip 192.168.1.105, I want to share over tinc

I follow this https://www.tinc-vpn.org/documentation/Example-configuration.html but it's not works.

I can ping B from A, but I can not ping other host in B's network, like 192.168.8.120

the setup is

A:
ip link set $INTERFACE up
ip addr add 192.168.100.1/16 dev $INTERFACE

Subnet=192.168.100.1/32

B:
ip link set $INTERFACE up
ip addr add 192.168.1.105/16 dev $INTERFACE

Subnet = 192.168.1.0/24

I already spend days on this, please help me, thanks!

BTW, I also create a question https://unix.stackexchange.com/q/422991/47774

Sorry for post question here, I tried to join mailing list, but nothing happens, maybe need to approve.

Steps to reproduce:

• Create a pidfile that contains the pid of a thread. You can find one with ps -efL and select a value from the LWP column where the LWP is not equal to the PID
• Attempt to start tincd with the pidfile created earlier

tinc will now generate an error "A tincd is already running for net 'netname' with pid 'pid'" while this is not true. It is true that the pid is claimed by a thread and cannot be used for a process.

This is most likely caused by the line here: https://github.com/gsliepen/tinc/blob/master/src/pidfile.c#L77 which checks for ESRCH only, while this probably results in an EPERM error

The current tinc/README file mentions that installation instructions may be found in the INSTALL file. Where is this file? Thank you

Currently in router mode, if no subnet is specified in host files, tinc won't know how to route the packages, and will report "Destination Net Unknown".

Could we have an option to enable some sort of automatic peer address discovery? i.e. remote peer will announce what IP it have on its interface.

Guus:

1. on linux:

# uname -a
Linux mail-serv 4.12.8-1-ec2 #1 SMP Mon Aug 21 22:43:04 PDT 2017 x86_64 GNU/Linux

2. using package:

https://www.archlinux.org/packages/community/x86_64/tinc/

3. this simple tinc configuration:

# cat /etc/tinc/mail/tinc.conf
AddressFamily = ipv4
Device = /dev/net/tun 
DeviceType = tun
Name = mail_1
ConnectTo = mail_2

4. starts fine when running on the host:

# journalctl -u tinc@mail
Oct 10 20:08:34 serv-1 systemd[1]: Started Tinc net mail.
Oct 10 20:08:34 serv-1 tincd[9842]: tincd 1.0.32 starting, debug level 0
Oct 10 20:08:34 serv-1 tincd[9842]: /dev/net/tun is a Linux tun/tap device (tun mode)
Oct 10 20:08:34 serv-1 tincd[9842]: Ready

5. it also starts fine in container with nspawn private network

systemd-nspawn ... --private-network

6. however when running in container with nspawn shared host network,

systemd-nspawn ... # remove option: --private-network 

tinc produces error:

# journalctl -M mail-serv -u tinc@mail
Oct 10 20:16:28 mail-serv tincd[735]: tincd 1.0.32 starting, debug level 0
Oct 10 20:16:28 mail-serv tincd[735]: /dev/net/tun is a Linux ethertap device
Oct 10 20:16:28 mail-serv tincd[735]: Ready
Oct 10 20:16:28 mail-serv tincd[735]: Error while reading from Linux ethertap device /dev/net/tun: File descriptor in bad state
...
Oct 10 20:16:31 mail-serv tincd[735]: Too many errors from /dev/net/tun, exiting!
Oct 10 20:16:31 mail-serv tincd[735]: Terminating

7. so in the last scenario same device /dev/net/tun is somehow detected as ethertap, not tun/tap

for reference: systemd-nspawn

https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html

Question: are there any quick pointers on how to resove this?

Thank you.

Might be a minor problem. I'll look into it.

Currently in tinc 1.1 if you call tinc start it will look for a tinc.conf file in etc/tinc/tinc.conf to use a certain network you must call tinc -n netname start even if you are in the netname directory. Could we get it so that if you are in etc/tinc/netname/ tinc will use the tinc.conf of the directory that i am in and not default to the general one? It should be just a small change, but it would make things a little bit easier.

Raspbian doesnt start tinc deamon on boot properly with Systemd:

tinc.service:
[Unit]
Description=Tinc VPN
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/tinc

[Install]
WantedBy=multi-user.target

and [email protected]:
[Unit]
Description=Tinc net %i
PartOf=tinc.service
ReloadPropagatedFrom=tinc.service

[Service]
Type=simple
WorkingDirectory=/etc/tinc/%i
ExecStart=/usr/sbin/tincd -n %i -D -d3 --logfile
ExecReload=/usr/sbin/tincd -n %i -kHUP
TimeoutStopSec=5
Restart=always
RestartSec=60

[Install]
WantedBy=tinc.service

after boot is ifconfig status:
mojtinc: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet6 fe80::a94d:42fc:d57c:ad7a prefixlen 64 scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500
after tinc restart:
pi@raspberrypi:~ $ sudo systemctl restart tinc
pi@raspberrypi:~ $ ifconfig

mojtinc: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.1.5 netmask 255.255.0.0 destination 192.168.1.5
inet6 fe80::53ea:5266:7a5b:a660 prefixlen 64 scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500

I tried to change unit file:
[Unit]
Description=Tinc VPN
Wants=network-online.target
After=network-online.target

but without any success.
Any idea?

hi and thanks for this cool piece of software!

I am trying to set up a mesh between a couple of friends and I hoped that invites may help make this idea more sexy to the less tech-versed among them. However, the way I understood invitations is that the inviting node will always be the single connection point for the invitee (modulo manual tinkering with host-files). This goes totally against the mesh/peer-to-peer idea and, in my case, I cannot guarantee that the inviting node will always be online.
I did play around with the invitation-created script which allows to publish at least the currently known host-configurations (which, by the way, would be useless to the invitee if they themselves were created by the invitation process, because, if I understood correctly, the invitee has no means to communicate their address/port to the inviting node). However, when the mesh grows, older invitees are left with only few connections.

So, I would love to see a functionality allowing the invitee to publish address/port changes at least to the inviter, better yet, allow any node on the mesh to publish an address/port update (of their own host-config) to the mesh, in order to allow establishing connections to them. Or maybe anyone can think of a better way to keep well-informed and updated host-configurations spread in the network in an automated manner?

cheers & thanks

Hello,

once we added our servers behind Tinc VPN server to zabbix server, it continuously reports connection problems. Simple icmp test (ping, mtr) didn't show any issues. zabbix server is using TCP port 10050 for connecting to it's clients. Once we put our monitored servers to public network and connect them to zabbix server, the connection issues go away.
ifconfig reports no drops and overruns.
We interconnected two network sites via Tinc vpn with 1.0.26 and 1.0.33 versions

I ran a ping from node1 (172.16.0.1) to node2 (172.16.0.101), both tinc 1.1pre15 here is the log:

tinc (node2):

Received packet of 46 bytes from node1 (xxx.xxx.xxx.xxx port 655)
Writing packet of 46 bytes to Linux tun/tap device (tap mode)
Broadcasting packet of 46 bytes from node1 (xxx.xxx.xxx.xxx port 655)
Read packet of 42 bytes from Linux tun/tap device (tap mode)
Sending packet of 42 bytes to node1 (xxx.xxx.xxx.xxx port 655)
Sending packet from node2 (MYSELF port 655) to node1 (xxx.xxx.xxx.xxx port 655) via node1 (xxx.xxx.xxx.xxx port 655) (UDP)

tcpdump (node2):

09:00:01.356556 ARP, Request who-has 172.16.0.101 tell 172.16.0.1, length 28
09:00:01.356597 ARP, Reply 172.16.0.101 is-at 42:b9:5e:a6:10:de (oui Unknown), length 28

tcpdump (node1):

16:59:48.118951 ARP, Request who-has 172.16.0.101 tell 172.16.0.1, length 28
16:59:48.418158 [|ARP]
        0x0000:  0001 0800 0604 0002 42b9 5ea6 10de ac10  ........B.^.....
        0x0010:  0065 f2e5 1cd0 8b8c                      .e......

The node2 is running on openSUSE Tumbleweed 20180420 (kernel 4.16.2), we can see it missing something on the tail of the packet (I had try both IPv4 and IPv6).

And the node1 is running on Arch (kernel 4.14.34), which is normal.

So I have no idea on where is the bug.

I also noticed that tinc top (in Tinc 1.1) seems to show the IN/OUT packets and bytes swapped, e.g. when I use iperf3 -c (which sends) it shows a lot of incoming traffic.

Hi! Looking at changelog I wan't able to find an answer whether the bug has been fixed, and our testing suggests it wasn't. We have to restart daemons now and it leads to connectivity issues, so it would be really neat to reload the hostfiles instead.

https://www.tinc-vpn.org/pipermail/tinc/2015-October/004264.html