2000-03-26 00:33:07 +00:00
|
|
|
## Produce this file with automake to get Makefile.in
|
|
|
|
|
2014-04-06 20:47:26 +00:00
|
|
|
sbin_PROGRAMS = tincd tinc sptps_test sptps_keypair
|
2000-03-26 00:33:07 +00:00
|
|
|
|
2014-06-29 14:22:10 +00:00
|
|
|
## Make sure version.c is always rebuilt with the latest git information
|
2015-05-19 12:09:53 +00:00
|
|
|
.PHONY: ${srcdir}/version.c version_git.h
|
2014-06-29 14:22:10 +00:00
|
|
|
version_git.h:
|
|
|
|
echo >$@
|
2014-07-12 15:01:41 +00:00
|
|
|
-(cd $(srcdir) && git describe) && echo '#define GIT_DESCRIPTION "'`(cd $(srcdir) && git describe) | sed 's/release-//'`'"' >$@
|
2015-05-19 12:09:53 +00:00
|
|
|
${srcdir}/version.c: version_git.h
|
2014-06-29 13:57:42 +00:00
|
|
|
|
2013-09-15 15:35:55 +00:00
|
|
|
if LINUX
|
|
|
|
sbin_PROGRAMS += sptps_speed
|
|
|
|
endif
|
|
|
|
|
2013-07-17 16:02:07 +00:00
|
|
|
DEFAULT_INCLUDES =
|
|
|
|
|
2014-04-06 20:47:26 +00:00
|
|
|
ed25519_SOURCES = \
|
|
|
|
ed25519/add_scalar.c \
|
|
|
|
ed25519/ed25519.h \
|
|
|
|
ed25519/fe.c ed25519/fe.h \
|
|
|
|
ed25519/fixedint.h \
|
|
|
|
ed25519/ge.c ed25519/ge.h \
|
|
|
|
ed25519/key_exchange.c \
|
|
|
|
ed25519/keypair.c \
|
|
|
|
ed25519/precomp_data.h \
|
|
|
|
ed25519/sc.c ed25519/sc.h \
|
|
|
|
ed25519/sha512.c ed25519/sha512.h \
|
|
|
|
ed25519/sign.c \
|
|
|
|
ed25519/verify.c
|
|
|
|
|
2014-04-14 19:43:45 +00:00
|
|
|
chacha_poly1305_SOURCES = \
|
|
|
|
chacha-poly1305/chacha.c chacha-poly1305/chacha.h \
|
|
|
|
chacha-poly1305/chacha-poly1305.c chacha-poly1305/chacha-poly1305.h \
|
|
|
|
chacha-poly1305/poly1305.c chacha-poly1305/poly1305.h
|
|
|
|
|
2009-12-31 12:19:13 +00:00
|
|
|
tincd_SOURCES = \
|
2013-08-13 18:35:48 +00:00
|
|
|
buffer.c buffer.h \
|
|
|
|
cipher.h \
|
|
|
|
conf.c conf.h \
|
|
|
|
connection.c connection.h \
|
|
|
|
control.c control.h \
|
|
|
|
control_common.h \
|
|
|
|
crypto.h \
|
|
|
|
device.h \
|
|
|
|
digest.h \
|
|
|
|
dropin.c dropin.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
dummy_device.c \
|
2013-08-13 18:35:48 +00:00
|
|
|
ecdh.h \
|
|
|
|
ecdsa.h \
|
|
|
|
ecdsagen.h \
|
|
|
|
edge.c edge.h \
|
|
|
|
ethernet.h \
|
|
|
|
event.c event.h \
|
|
|
|
fake-gai-errnos.h \
|
|
|
|
fake-getaddrinfo.c fake-getaddrinfo.h \
|
|
|
|
fake-getnameinfo.c fake-getnameinfo.h \
|
|
|
|
getopt.c getopt.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
getopt1.c \
|
2013-08-13 18:35:48 +00:00
|
|
|
graph.c graph.h \
|
|
|
|
hash.c hash.h \
|
|
|
|
have.h \
|
|
|
|
ipv4.h \
|
|
|
|
ipv6.h \
|
|
|
|
list.c list.h \
|
|
|
|
logger.c logger.h \
|
|
|
|
meta.c meta.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
multicast_device.c \
|
2013-08-13 18:35:48 +00:00
|
|
|
names.c names.h \
|
|
|
|
net.c net.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
net_packet.c \
|
|
|
|
net_setup.c \
|
|
|
|
net_socket.c \
|
2013-08-13 18:35:48 +00:00
|
|
|
netutl.c netutl.h \
|
|
|
|
node.c node.h \
|
|
|
|
prf.h \
|
|
|
|
process.c process.h \
|
|
|
|
protocol.c protocol.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
protocol_auth.c \
|
|
|
|
protocol_edge.c \
|
|
|
|
protocol_key.c \
|
|
|
|
protocol_misc.c \
|
|
|
|
protocol_subnet.c \
|
|
|
|
raw_socket_device.c \
|
2013-08-13 18:35:48 +00:00
|
|
|
route.c route.h \
|
|
|
|
rsa.h \
|
|
|
|
rsagen.h \
|
2013-08-23 17:24:36 +00:00
|
|
|
script.c script.h \
|
2013-08-13 18:35:48 +00:00
|
|
|
splay_tree.c splay_tree.h \
|
|
|
|
sptps.c sptps.h \
|
|
|
|
subnet.c subnet.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
subnet_parse.c \
|
2013-08-13 18:35:48 +00:00
|
|
|
system.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
tincd.c \
|
2013-08-13 18:35:48 +00:00
|
|
|
utils.c utils.h \
|
2014-04-06 20:47:26 +00:00
|
|
|
xalloc.h \
|
2015-05-05 21:05:22 +00:00
|
|
|
version.c version.h \
|
2014-12-29 21:57:18 +00:00
|
|
|
ed25519/ecdh.c \
|
|
|
|
ed25519/ecdsa.c \
|
2014-04-14 19:43:45 +00:00
|
|
|
$(ed25519_SOURCES) \
|
|
|
|
$(chacha_poly1305_SOURCES)
|
2013-05-01 10:20:06 +00:00
|
|
|
|
2013-05-01 15:17:22 +00:00
|
|
|
tinc_SOURCES = \
|
2013-08-13 18:35:48 +00:00
|
|
|
dropin.c dropin.h \
|
|
|
|
getopt.c getopt.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
getopt1.c \
|
2015-01-15 21:57:56 +00:00
|
|
|
fsck.c fsck.h \
|
2013-08-13 18:35:48 +00:00
|
|
|
info.c info.h \
|
|
|
|
invitation.c invitation.h \
|
|
|
|
list.c list.h \
|
|
|
|
names.c names.h \
|
|
|
|
netutl.c netutl.h \
|
2013-08-23 17:24:36 +00:00
|
|
|
script.c script.h \
|
2013-08-13 18:35:48 +00:00
|
|
|
sptps.c sptps.h \
|
|
|
|
subnet_parse.c subnet.h \
|
|
|
|
tincctl.c tincctl.h \
|
|
|
|
top.c top.h \
|
2014-04-06 20:47:26 +00:00
|
|
|
utils.c utils.h \
|
2015-05-05 21:05:22 +00:00
|
|
|
version.c version.h \
|
2014-12-29 21:57:18 +00:00
|
|
|
ed25519/ecdh.c \
|
|
|
|
ed25519/ecdsa.c \
|
|
|
|
ed25519/ecdsagen.c \
|
2014-04-14 19:43:45 +00:00
|
|
|
$(ed25519_SOURCES) \
|
|
|
|
$(chacha_poly1305_SOURCES)
|
2013-05-01 15:17:22 +00:00
|
|
|
|
|
|
|
sptps_test_SOURCES = \
|
2013-08-13 18:35:48 +00:00
|
|
|
logger.c logger.h \
|
|
|
|
sptps.c sptps.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
sptps_test.c \
|
2014-04-06 20:47:26 +00:00
|
|
|
utils.c utils.h \
|
2014-12-29 21:57:18 +00:00
|
|
|
ed25519/ecdh.c \
|
|
|
|
ed25519/ecdsa.c \
|
2014-04-14 19:43:45 +00:00
|
|
|
$(ed25519_SOURCES) \
|
|
|
|
$(chacha_poly1305_SOURCES)
|
2014-04-06 20:47:26 +00:00
|
|
|
|
|
|
|
sptps_keypair_SOURCES = \
|
|
|
|
sptps_keypair.c \
|
|
|
|
utils.c utils.h \
|
2014-12-29 21:57:18 +00:00
|
|
|
ed25519/ecdsagen.c \
|
2014-04-06 20:47:26 +00:00
|
|
|
$(ed25519_SOURCES)
|
2013-05-01 15:17:22 +00:00
|
|
|
|
2013-09-15 15:35:55 +00:00
|
|
|
sptps_speed_SOURCES = \
|
|
|
|
logger.c logger.h \
|
|
|
|
sptps.c sptps.h \
|
|
|
|
sptps_speed.c \
|
2014-04-06 20:47:26 +00:00
|
|
|
utils.c utils.h \
|
2014-12-29 21:57:18 +00:00
|
|
|
ed25519/ecdh.c \
|
|
|
|
ed25519/ecdsa.c \
|
|
|
|
ed25519/ecdsagen.c \
|
2014-04-14 19:43:45 +00:00
|
|
|
$(ed25519_SOURCES) \
|
|
|
|
$(chacha_poly1305_SOURCES)
|
2013-09-15 15:35:55 +00:00
|
|
|
|
2013-05-01 10:20:06 +00:00
|
|
|
## Conditionally compile device drivers
|
2011-12-04 00:20:59 +00:00
|
|
|
|
2013-05-01 10:20:06 +00:00
|
|
|
if LINUX
|
|
|
|
tincd_SOURCES += linux/device.c
|
|
|
|
endif
|
|
|
|
|
|
|
|
if BSD
|
|
|
|
tincd_SOURCES += bsd/device.c
|
2013-05-01 15:17:22 +00:00
|
|
|
if TUNEMU
|
2013-08-14 14:17:12 +00:00
|
|
|
tincd_SOURCES += bsd/tunemu.c bsd/tunemu.h
|
2013-05-01 15:17:22 +00:00
|
|
|
endif
|
2013-05-01 10:20:06 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
if SOLARIS
|
|
|
|
tincd_SOURCES += solaris/device.c
|
|
|
|
endif
|
|
|
|
|
|
|
|
if MINGW
|
2013-08-14 14:17:12 +00:00
|
|
|
tincd_SOURCES += mingw/device.c mingw/common.h
|
2013-05-01 10:20:06 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
if CYGWIN
|
|
|
|
tincd_SOURCES += cygwin/device.c
|
|
|
|
endif
|
|
|
|
|
2011-12-04 00:20:59 +00:00
|
|
|
if UML
|
|
|
|
tincd_SOURCES += uml_device.c
|
|
|
|
endif
|
|
|
|
|
|
|
|
if VDE
|
|
|
|
tincd_SOURCES += vde_device.c
|
|
|
|
endif
|
2011-06-25 15:08:40 +00:00
|
|
|
|
2013-05-01 15:17:22 +00:00
|
|
|
if OPENSSL
|
|
|
|
tincd_SOURCES += \
|
|
|
|
openssl/cipher.c \
|
|
|
|
openssl/crypto.c \
|
2013-08-14 14:17:12 +00:00
|
|
|
openssl/digest.c openssl/digest.h \
|
2013-05-01 15:17:22 +00:00
|
|
|
openssl/prf.c \
|
|
|
|
openssl/rsa.c
|
|
|
|
tinc_SOURCES += \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
openssl/cipher.c \
|
|
|
|
openssl/crypto.c \
|
2013-08-14 14:17:12 +00:00
|
|
|
openssl/digest.c openssl/digest.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
openssl/prf.c \
|
2013-05-01 15:17:22 +00:00
|
|
|
openssl/rsa.c \
|
|
|
|
openssl/rsagen.c
|
|
|
|
sptps_test_SOURCES += \
|
|
|
|
openssl/crypto.c \
|
2013-08-14 14:17:12 +00:00
|
|
|
openssl/digest.c openssl/digest.h \
|
2013-05-01 15:17:22 +00:00
|
|
|
openssl/prf.c
|
2014-04-06 20:47:26 +00:00
|
|
|
sptps_keypair_SOURCES += \
|
2014-12-29 21:57:18 +00:00
|
|
|
openssl/crypto.c
|
2013-09-15 15:35:55 +00:00
|
|
|
sptps_speed_SOURCES += \
|
|
|
|
openssl/crypto.c \
|
|
|
|
openssl/digest.c openssl/digest.h \
|
|
|
|
openssl/prf.c
|
2014-12-31 23:52:39 +00:00
|
|
|
else
|
|
|
|
if GCRYPT
|
2013-05-01 15:17:22 +00:00
|
|
|
tincd_SOURCES += \
|
|
|
|
gcrypt/cipher.c \
|
|
|
|
gcrypt/crypto.c \
|
2013-08-14 14:17:12 +00:00
|
|
|
gcrypt/digest.c gcrypt/digest.h \
|
2013-05-01 15:17:22 +00:00
|
|
|
gcrypt/prf.c \
|
|
|
|
gcrypt/rsa.c
|
|
|
|
tinc_SOURCES += \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
gcrypt/cipher.c \
|
|
|
|
gcrypt/crypto.c \
|
2013-08-14 14:17:12 +00:00
|
|
|
gcrypt/digest.c gcrypt/digest.h \
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
gcrypt/prf.c \
|
2013-05-01 15:17:22 +00:00
|
|
|
gcrypt/rsa.c \
|
|
|
|
gcrypt/rsagen.c
|
|
|
|
sptps_test_SOURCES += \
|
|
|
|
gcrypt/cipher.c \
|
|
|
|
gcrypt/crypto.c \
|
2013-08-14 14:17:12 +00:00
|
|
|
gcrypt/digest.c gcrypt/digest.h \
|
2013-05-01 15:17:22 +00:00
|
|
|
gcrypt/prf.c
|
2014-12-29 21:57:18 +00:00
|
|
|
sptps_keypair_SOURCES += \
|
|
|
|
openssl/crypto.c
|
|
|
|
sptps_speed_SOURCES += \
|
|
|
|
openssl/crypto.c \
|
|
|
|
openssl/digest.c openssl/digest.h \
|
|
|
|
openssl/prf.c
|
|
|
|
else
|
|
|
|
tincd_SOURCES += \
|
|
|
|
nolegacy/crypto.c \
|
|
|
|
nolegacy/prf.c
|
|
|
|
tinc_SOURCES += \
|
|
|
|
nolegacy/crypto.c \
|
|
|
|
nolegacy/prf.c
|
|
|
|
sptps_test_SOURCES += \
|
|
|
|
nolegacy/crypto.c \
|
|
|
|
nolegacy/prf.c
|
|
|
|
sptps_keypair_SOURCES += \
|
|
|
|
nolegacy/crypto.c
|
|
|
|
sptps_speed_SOURCES += \
|
|
|
|
nolegacy/crypto.c \
|
|
|
|
nolegacy/prf.c
|
2009-09-10 17:32:54 +00:00
|
|
|
endif
|
2014-12-31 23:52:39 +00:00
|
|
|
endif
|
2009-09-10 17:32:54 +00:00
|
|
|
|
2013-03-08 15:22:56 +00:00
|
|
|
tinc_LDADD = $(READLINE_LIBS) $(CURSES_LIBS)
|
2013-09-15 20:03:00 +00:00
|
|
|
sptps_speed_LDADD = -lrt
|
2011-05-15 11:16:48 +00:00
|
|
|
|
Use a smarter algorithm for choosing MTU discovery probe sizes.
Currently, tinc uses a naive algorithm for choosing MTU discovery probe
sizes, picking a size at random between minmtu and maxmtu.
This is of course suboptimal - since the behavior of probes is
deterministic (assuming no packet loss), it seems likely that using a
non-deterministic discovery algorithm will not yield the best results.
Furthermore, the randomness introduces a lot of variation in convergence
times.
The random solution also suffers from pathological cases - since it's
using a uniform distribution, it doesn't take into account the fact that
it's often more interesting to send small probes rather than large ones,
because getting replies is the only way we can make progress (assuming
the worst case scenario in which the OS doesn't know anything, therefore
keeping maxmtu constant). This can lead to absurd situations where the
discovery algorithm is close to the real MTU, but can't get to it
because the random number generator keeps generating numbers that are
past it.
The algorithm implemented in this patch aims to improve on the naive
random algorithm. It is organized around "cycles" of 8 probes; the sizes
of the probes decrease as we go through the cycle, thus making sure the
algorithm can cover lots of ground quickly (in case we're far from
actual MTU), but also examining the local area (in case we're close to
actual MTU). Using cycles ensures that the algorithm will "go back" to
large probes to better cover the new interval and to protect against
packet loss.
For the probe size itself, various mathematical models were simulated in
an attempt to find the one that converges the fastest; it has been
determined that using an exponential based on the size of the remaining
interval was the most effective option. The exponential is adjusted with
a magic multiplier fine-tuned to make tinc jump to the "most
interesting" (i.e. 1400+) section as soon as discovery starts.
Simulations indicate that assuming no packet loss and no help from the
OS (i.e. maxmtu stays constant), this algorithm will typically converge
to the *exact* MTU value in less than 10 probes, and will get within 8
bytes in less than 5 probes, for actual MTUs between 1417 and ~1450
(which is the range the algorithm is fine-tuned for). In contrast, the
previous algorithm gives results all over the place, sometimes taking
30+ probes to get in the ballpark. Because of the issues with the
distribution, the previous algorithm sometimes never gets to the precise
MTU value within any reasonable amount of time - in contrast, the new
algorithm will always get to the precise value in less than 30 probes,
even if the actual MTU is completely outside the optimized range.
2014-12-30 16:34:48 +00:00
|
|
|
LIBS = @LIBS@ -lm
|
2000-03-26 00:33:07 +00:00
|
|
|
|
2009-09-10 17:32:54 +00:00
|
|
|
if TUNEMU
|
|
|
|
LIBS += -lpcap
|
|
|
|
endif
|
|
|
|
|
2015-05-17 21:36:15 +00:00
|
|
|
AM_CFLAGS = -DCONFDIR=\"$(sysconfdir)\" -DLOCALSTATEDIR=\"$(localstatedir)\" -DSBINDIR=\"$(sbindir)\" -iquote.
|