Guus Sliepen [Tue, 13 Oct 2015 12:14:08 +0000 (14:14 +0200)]
Determine the local node's address(es) and add them to its host config file.
Use the "UDP connect() to an external IP address" trick to determine the
local node's addresses in a platform independent way, without sending any
actual packets. Do this at meshlink_open() time, so the application has
immediate access to them when calling meshlink_export().
Guus Sliepen [Tue, 13 Oct 2015 12:12:13 +0000 (14:12 +0200)]
Don't append duplicate entries to configuration files.
Automatically detected addresses are appended to host config files by
Catta. However, it doesn't check whether the address is already known.
Have append_config_file() check that it doesn't write duplicate entries.
Guus Sliepen [Fri, 9 Oct 2015 20:47:55 +0000 (22:47 +0200)]
Fix a memory leak when retrying outgoing connections.
When retry_outgoing_handler() calls setup_outgoing_connection(), it can
be that the old configuration is still in memory. So clean that up
before reading in new configuration data.
Guus Sliepen [Wed, 21 Jun 2017 20:57:34 +0000 (22:57 +0200)]
Ignore address hints for our local node.
Catta also sees itself, which causes MeshLink to add address hints for
its own node. That causes link-local addresses to be added. When calling
meshlink_invite(), the first link-local address would then be used for
the invitation URL, which is not desirable.
Guus Sliepen [Tue, 18 Nov 2014 21:03:12 +0000 (22:03 +0100)]
In case two nodes start a SPTPS session simultaneously, deterministically choose one to succeed.
This fixes the problem where two nodes send a REQ_KEY to each other
simultaneously, which causes both of them to drop their current state
and respond to the other's REQ_KEY with an ANS_KEY, which won't succeed
any more because both of them forgot that state.
Guus Sliepen [Fri, 7 Nov 2014 23:53:58 +0000 (23:53 +0000)]
test/channel: don't let both sides connect to each other simultaneously.
The channel test fails to work reliably when the two threads are started
exactly simultaneously and both sides try to connect to each other. Both
sides simultaneously initiate a end-to-end SPTPS connection by sending
the appropriate req_key request, but upon reception of each others
request they reset their own state, causing SPTPS packets from the old
and the new state to cross each other. A timeout will occur eventually,
causing one side to try to restart the SPTPS connection. Since the
timeouts are slightly randomized, this sometimes causes the channel test
to work, sometimes not.
Guus Sliepen [Tue, 16 Dec 2014 13:51:36 +0000 (14:51 +0100)]
Add a function to set the default white/blacklisting behaviour.
This function should be called right after meshlink_open(), and will
apply the default white/blacklist setting to newly learned nodes.
The status can later be changed using the meshlink_whitelist() and
meshlink_blacklist() functions.
We need to copy the data from the application *here*. To avoid multiple copies, prepare the
whole vpn_packet_t in meshlink_send(), so meshlink_send_from_queue() only has to dequeue
and call route(). We also don't need to take the mesh_mutex, since the only information we
use is the name of ourself and the destination node, which is guaranteed to be stable.
Saverio Proto [Tue, 19 Aug 2014 14:17:20 +0000 (16:17 +0200)]
manynodes: implemented /select to be able to select the node that will execute the console commands
by default node0 will be executing the commands
doing /select 1 for example, the node 1 will execute the console commands
Guus Sliepen [Tue, 12 Aug 2014 20:03:32 +0000 (22:03 +0200)]
Fix segfault when two nodes that just joined a mesh want to autoconnect to each other.
In this case, we have not exchanged public keys yet. That should not be
a problem, but we blindly pass a NULL pointer to sptps_start() in this
case which blindly dereferences it. Fix sptps_start() by making sure no
arguments are NULL, and teach MeshLink to exchange keys between
reachable nodes when it tries to make a meta-connection.
Aaron Krebs [Sat, 9 Aug 2014 15:54:56 +0000 (17:54 +0200)]
Replaced node_mutex with mesh_mutex.
This reverses the mutex use; instead of locking when modifying nodes,
we unlock when not modifying the mesh. Any API functions that wish
to use the mesh must aquire the lock first.
TODO: Currently there is a deadlock problem, and the discovery thread is not
cleanly handled yet.