Although not a problem for tinc internally, the size of the struct was 12
bytes instead of 4, causing some problems when interpreting the value
received from tincd by the CLI.
If --with-systemd is given when running the configure script, two
systemd service files will be installed. There is a template
tinc@.service, which can be used to control individual instances of
tinc. For example:
systemctl enable tinc@foo
Will create an instance for tinc with netname foo. There is also a
tinc.service, which can be used to start and stop all instances at once.
In commit b7b5d51, AC_CONFIG_MACRO_DIRS([m4]) was added to configure.ac,
which is the current proper way of including the m4 directory. However,
old versions of autoconf ignore it and need the -I m4 statement in
Makefile.am. Both the old and new way of indicating that the m4/
directory should be included can coexist.
In cases when tinc has all available nodes in outgoing connections and
can not establish those connection due to network outage periodic_handler()
would crash since tmp_node_tree->count is 0.
This commit adds also new flag node->status.has_cfg_address to prevent
update_udp_address() from removing this flag.
Fixed node_status_t->unused - 13 + 19 = 32
When AutoConnect is on tinc needs to know if nodes have Address to defined
in thier hosts files. Currently tinc parsed node's host files if StrictSubnet
was enabled. To reduce the parsing overhead I have merged load_all_subnets
with load_all_nodes, such that load_all_subnets has been removed and
load_all_nodes has if-statement extracting Subnet information from node's host
file.
When AutoConnect is enabled tinc tries to connect to other nodes picking them at random.
This may be sane default behavior but it may take ages if only few nodes have
defined Address in thier config.
Proposed solution to this problem:
- Filter out nodes without known address in periodic_handler
I have added new node->status.has_known_address bool
- On update_node_udp() update this flag
In some cases - mostly when e->to == myself the prevedge is set to NULL,
causing invalid memory access. In rare cases this may lead to malformed mst
or segfaults.
In some cases - mostly when e->to == myself the prevedge is set to NULL,
causing invalid memory access. In rare cases this may lead to malformed mst
or segfaults.
If ADD_EDGE came from tinc version 1.0.x local_address.sa.sa_family is set to 0.
If it came from tinc version 1.1.x forwarded for older verion it will be 255 - AF_UNKNOWN.
When tinc gets ADD_EDGE from older versions it will allocate
new edge in protocol_edge.c:189 due to missed case in lines 149-171 where
local_address is not defined.
The information is of grate value when monitoring multiple
nodes in one window. Without it the user is forced to quit top, exit tinc
and go back to shell to refresh his memory about which node is in
what window.
