No description
1672dbd66b
Currently, if both write and read events fire at the same time on a
socket, the Windows-specific event loop will call both the write and
read callbacks, in that order. Problem is, the write callback could have
deleted the io handle, which makes the next call to the write callback a
use-after-free typically resulting in a hard crash.
In practice, this issue is triggered quite easily by putting the
computer to sleep, which basically freezes the tinc process. When the
computer wakes up and the process resumes, all TCP connections are
suddenly gone; as a result, the following sequence of events might
appear in the logs:
Metadata socket read error for node1 (1.2.3.4 port 655): (10054) An existing connection was forcibly closed by the remote host.
Closing connection with node1 (1.2.3.4 port 655)
Sending DEL_EDGE to everyone (BROADCAST): 13 4bf6 mynode node1
Sending 43 bytes of metadata to node2 (5.6.7.8 port 655)
Could not send 10891 bytes of data to node2 (5.6.7.8 port 655): (10054) An existing connection was forcibly closed by the remote host.a
Closing connection with node2 (5.6.7.8 port 655)
<CRASH>
In this example the crash occurs because the socket to node2 was
signaled for reading *in addition* to writing, but since the connection
was terminated, the attempt to call the read callback crashed the
process.
This commit fixes the problem by not even attempting to fire the write
callback when the write event on the socket is signaled - instead, we
just rely on the part of the event loop that simulates level-triggered
write events. Arguably that's even cleaner and faster, because the code
being removed was technically redundant - we have to go through that
write check loop anyway.
|
||
|---|---|---|
| bash_completion.d | ||
| doc | ||
| gui | ||
| m4 | ||
| src | ||
| systemd | ||
| test | ||
| .gitignore | ||
| AUTHORS | ||
| configure.ac | ||
| COPYING | ||
| COPYING.README | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| README.android | ||
| README.git | ||
| THANKS | ||
This is the README file for tinc version 1.1pre14. Installation instructions may be found in the INSTALL file. tinc is Copyright © 1998-2016 Ivo Timmermans, Guus Sliepen <guus@tinc-vpn.org>, and others. For a complete list of authors see the AUTHORS file. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. See the file COPYING for more details. This is a pre-release --------------------- Please note that this is NOT a stable release. Until version 1.1.0 is released, please use one of the 1.0.x versions if you need a stable version of tinc. Although tinc 1.1 will be protocol compatible with tinc 1.0.x, the functionality of the tinc program may still change, and the control socket protocol is not fixed yet. Security statement ------------------ This version uses an experimental and unfinished cryptographic protocol. Use it at your own risk. Compatibility ------------- Version 1.1pre14 is compatible with 1.0pre8, 1.0 and later, but not with older versions of tinc. When the ExperimentalProtocol option is used, tinc is still compatible with 1.0.X, 1.1pre11 and later, but not with any version between 1.1pre1 and 1.1pre10. Requirements ------------ In order to compile tinc, you will need a GNU C compiler environment. Please ensure you have the latest stable versions of all the required libraries: - LibreSSL (http://www.libressl.org/) or OpenSSL (https://openssl.org/) version 1.0.0 or later. The following libraries are used by default, but can be disabled if necessary: - zlib (http://www.zlib.net/) - LZO (https://www.oberhumer.com/opensource/lzo/) - ncurses (http://invisible-island.net/ncurses/) - readline (https://cnswww.cns.cwru.edu/php/chet/readline/rltop.html) Features -------- Tinc is a peer-to-peer VPN daemon that supports VPNs with an arbitrary number of nodes. Instead of configuring tunnels, you give tinc the location and public key of a few nodes in the VPN. After making the initial connections to those nodes, tinc will learn about all other nodes on the VPN, and will make connections automatically. When direct connections are not possible, data will be forwarded by intermediate nodes. Tinc 1.1 support two protocols. The first is a legacy protocol that provides backwards compatibility with tinc 1.0 nodes, and which by default uses 2048 bit RSA keys for authentication, and encrypts traffic using Blowfish in CBC mode and HMAC-SHA1. The second is a new protocol which uses Curve25519 keys for authentication, and encrypts traffic using Chacha20-Poly1305, and provides forward secrecy. Tinc fully supports IPv6. Tinc can operate in several routing modes. In the default mode, "router", every node is associated with one or more IPv4 and/or IPv6 Subnets. The other two modes, "switch" and "hub", let the tinc daemons work together to form a virtual Ethernet network switch or hub. Normally, when started tinc will detach and run in the background. In a native Windows environment this means tinc will install itself as a service, which will restart after reboots. To prevent tinc from detaching or running as a service, use the -D option. The status of the VPN can be queried using the "tinc" command, which connects to a running tinc daemon via a control connection. The same tool also makes it easy to start and stop tinc, and to change its configuration.