## Frequently Asked Questions If you have a common problem or question, you will probably be able to find an answer here. If it is not here, and even the documentation is of no help, please contact the authors. [[!toc levels=2]] ##Error messages ### Bogus data received Jan 1 12:00:00 host tinc.net[1234]: Bogus data received from node (192.0.43.10) Tinc tries to connect to another node but reports that bogus data has been received. This problem is almost always caused by a problem with the RSA keys from one of the nodes. Check that there is only one key in each rsa_key.priv and in each host config file. Also make sure that the host config files with the same name contain the same key on both nodes. When in doubt, remove the rsa_key.priv files, remove the public keys from the host config files, generate new keys and distribute them again. ### Cannot ping the other node(s) PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.1 icmp_seq=1 Destination Net Unknown Or when logging with debug level 5: Jan 1 12:00:00 host tinc.net[1234]: Cannot route packet from node (MYSELF): unknown IPv4 destination address 192.168.1.1 When trying to ping another node, it can happen that there is no response. First, check that the other node is really online, and that tinc has made a connection with it. When running tinc in router mode (which is the default), check that the node you are trying to reach has a Subnet statement in its host config file that contains the IP address you are trying to reach. ### File descriptor in bad state Jan 1 12:00:00 host tinc.net[1234]: Error while reading from ethertap device: File descriptor in bad state There is a problem reading packet from the virtual network device. Check that the tun module is loaded, and that tinc tries to open the right device file. If you have added Device and/or Interface statements to tinc.conf, try removing them, tinc's defaults usually work fine. ### Packets looping back to us Jan 1 12:00:00 host tinc.net[1234]: Packet with destination 192.168.1.1 is looping back to us! A packet is received from the tapdevice, and tinc tries to send it to the right destination, but finds out that this packet should be send to itself. Chances are that a "Subnet = ..." line in the host configuration file of this tinc daemon is wrong. Change it to a subnet that is accepted locally by another interface, or if that is not the case, try changing the prefix length into /32. ## Platform specific questions ### Error while writing to Generic BSD tap device /dev/tap0: Input/output error on MacOSX or *BSD tinc needs to be running *before* configuring the network interface. Try assigning a static ip address, while tinc is running: ifconfig tap0 If you are still having trouble, check that you have the tun/tap devices installed and configured for your kernel. ### Is there an app for tinc? Tinc itself supports many platforms. Code was merged in version 1.0.10 that in principle allows tinc to run on iPhone and iPod devices. However, as far as we know, no one has created an iOS app for tinc. The latest version in the git [[repository]] allows tinc to be compiled for Android. There is an unofficial Android app for tinc that can be found on [Google Play](https://play.google.com/store/apps/details?id=org.poirsouille.tinc_gui). ## Generic questions ### Why tinc? > Question: I've been using VPNs in a production environment, and until now that has been with FreeS/WAN. I would like to know what the differences are between tinc and FreeS/WAN. Here's what we think of that: * FreeS/WAN requires a kernel patch (IPSec is not yet a part of the mainstream kernel), while tinc runs completely in userspace. The advantages of the latter should be clear: portability is increased and errors in the implementation will not lead to kernel crashes. * Both FreeS/WAN and tinc use tunnels to send packets, but with FreeS/WAN, all tunnels have to be explicitly configured on all hosts, while tinc can set up a large part of the tunnels without requiring too much changing of configuration files. For the addition of 1 extra host in a VPN that is already made out of X hosts, FreeS/WAN requires a modification in X+1 configuration files, while for tinc, only 2 modifications are required. * tinc is made for solidness: some disfunctional hosts on the VPN won't lead to the coming down of the entire VPN, while this is not true for most VPN implementations (especially when a star topology is used and the central node goes down). * Configuring tinc is mostly experienced to be easier than that of FreeS/WAN (according to users of both packages). * tinc will support the transmission of any kind of network package, not limiting it to IPv4 or IPv6. Multicast and broadcast packets will also be supported in the future. Other reasons to use tinc instead of other solutions: * Although tinc uses a non-standard protocol, it does not suffer from the inefficiencies of most of the standard protocols. * The executable is very small, less than 150 kilobytes, the real memory usage is usually about 2 megabytes.