[Announcement] Tinc version 1.0.21 and 1.1pre7 released

Because of a security vulnerability in tinc that was recently discovered, we
hereby release tinc versions 1.0.21 and 1.1pre7. Here is a summary of the
changes in tinc 1.0.21:

 * Drop packets forwarded via TCP if they are too big (CVE-2013-1428).

Here is a summary of the changes in tinc 1.1pre7:

 * Fixed large latencies on Windows.
 * Renamed the tincctl tool to tinc.
 * Simplified changing the configuration using the tinc tool.
 * Added a full description of the ExperimentalProtocol to the manual.
 * Drop packets forwarded via TCP if they are too big (CVE-2013-1428).

Thanks to Martin Schobert for auditing tinc and reporting the vulnerability.
He discovered a potential stack overflow that can be triggered by an
authenticated peer. This can be used to cause a tinc daemon to crash, or in the
worst case, it might be possible to execute code on another node as the user
running tincd. This bug has been present in all versions of tinc. All users of
tinc should upgrade to 1.0.21 or 1.1pre7 as soon as possible.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

Because of a security vulnerability in tinc that was recently discovered, we
hereby release tinc versions 1.0.21 and 1.1pre7. Here is a summary of the
changes in tinc 1.0.21:

Automatic exchange of dynamic node-IPs between nodes

Hi,

I'm new to Tinc, so a "Hello" to all!

In my setup one master node has a static public IP. All other nodes have dynamic public IPs changing every 24 hours (and yes, in Germany even Global IPv6 Unicast Prefixes are dynamic on DSL/Cable sockets ).

To distribute the dynamic node-IPs to all other nodes, the following "host-up" script is used:

------------------------------------------------------------- snip --------------------------------------------------------------

#!/bin/bash

FILE="/etc/tinc/$NETNAME/hosts/$NODE"
ADDRESS="Address = $REMOTEADDRESS $REMOTEPORT"

if grep -q Address $FILE; then
    /bin/sed s:'^Address.*=.*$':"$ADDRESS": -i $FILE
else
    echo $ADDRESS >> $FILE
fi

------------------------------------------------------------- snap --------------------------------------------------------------


Please implement such a function directly into the Tinc code! Maybe even with distributed tables without the need of a master with a static IP.

Best regards,

Renne

<div>Hi,<br><br>I'm new to Tinc, so a "Hello" to all! <br><br>In my setup one master node has a static public IP. All other nodes have dynamic public IPs changing every 24 hours (and yes, in Germany even Global IPv6 Unicast Prefixes are dynamic on DSL/Cable sockets  ).<br><br>To distribute the dynamic node-IPs to all other nodes, the following "host-up" script is used:<br><br>------------------------------------------------------------- snip --------------------------------------------------------------<br><br>#!/bin/bash<br><br>FILE="/etc/tinc/$NETNAME/hosts/$NODE"<br>ADDRESS="Address = $REMOTEADDRESS $REMOTEPORT"<br><br>if grep -q Address $FILE; then<br>&nbsp;&nbsp;&nbsp; /bin/sed s:'^Address.*=.*$':"$ADDRESS": -i $FILE<br>else<br>&nbsp;&nbsp;&nbsp; echo $ADDRESS &gt;&gt; $FILE<br>fi<br><br>------------------------------------------------------------- snap 
--------------------------------------------------------------<br><br><br>Please implement such a function directly into the Tinc code! Maybe even with distributed tables without the need of a master with a static IP.<br><br>Best regards,<br><br>Renne<br>
</div>

Problem with local Discovery in tinc-pre

I'm currently running tinc-pre6 on 2 nodes in a larger network.
My Laptop (Lassulus), lan ip: 192.168.2.100, tinc-ip: 10.243.0.2
My Server (alphalabs), lan ip: 192.168.2.103, tinc-ip: 10.243.1.10
internet vserver (slowpoke), no lan ip, tinc-ip: 10.243.232.121

Everything works fine until both nodes are in the same LAN. The first
2-3 minutes everything is fine. Pings between the machines go through
other servers so they are between 50-80ms, 0% packet loss.
But as soon as localDiscovery starts to kick in the pings drop to 20ms
(which is good) but packet loss goes up to 90% (tested with ping -f).
For every lost packet tincd (started with -D -d4) shows the Error:
"Received UDP packet from unknown source 192.168.2.103 port 655".
Every 2-3 seconds the packet loss stops and tincd reports: "UDP
address of alphalabs set to 192.168.2.103 port 655"
But after <1second the packet loss begins again with the unknown source error.

log snippet:
UDP address of alphalabs set to 192.168.2.103 port 655
UDP address of slowpoke set to 81.89.96.210 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
UDP address of alphalabs set to 192.168.2.103 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
Received UDP packet from unknown source 192.168.2.103 port 655
UDP address of slowpoke set to 81.89.96.210 port 655
UDP address of alphalabs set to 192.168.2.103 port 655

ping output:
20:42:21  <at> Lassulus ~ ping -i 0.2 10.243.1.10
PING 10.243.1.10 (10.243.1.10) 56(84) bytes of data.
64 bytes from 10.243.1.10: icmp_seq=1 ttl=64 time=1.88 ms
64 bytes from 10.243.1.10: icmp_seq=3 ttl=64 time=1.88 ms
64 bytes from 10.243.1.10: icmp_seq=4 ttl=64 time=1.71 ms
64 bytes from 10.243.1.10: icmp_seq=8 ttl=64 time=1.97 ms
64 bytes from 10.243.1.10: icmp_seq=9 ttl=64 time=2.66 ms
64 bytes from 10.243.1.10: icmp_seq=10 ttl=64 time=1.71 ms
64 bytes from 10.243.1.10: icmp_seq=11 ttl=64 time=1.82 ms
64 bytes from 10.243.1.10: icmp_seq=12 ttl=64 time=3.06 ms
64 bytes from 10.243.1.10: icmp_seq=13 ttl=64 time=1.92 ms
64 bytes from 10.243.1.10: icmp_seq=14 ttl=64 time=1.85 ms
64 bytes from 10.243.1.10: icmp_seq=15 ttl=64 time=1.78 ms
64 bytes from 10.243.1.10: icmp_seq=16 ttl=64 time=1.65 ms
64 bytes from 10.243.1.10: icmp_seq=17 ttl=64 time=1.59 ms
64 bytes from 10.243.1.10: icmp_seq=18 ttl=64 time=1.92 ms
64 bytes from 10.243.1.10: icmp_seq=19 ttl=64 time=1.64 ms
64 bytes from 10.243.1.10: icmp_seq=20 ttl=64 time=9.77 ms

Lassulus tinc.conf:

Name = Lassulus
Device = /dev/net/tun
LocalDiscovery = yes

#ConnectTo = alphalabs
ConnectTo = slowpoke

Alphalabs tinc.conf:

Name = alphalabs
Device = /dev/net/tun
LocalDiscovery = yes

ConnectTo = slowpoke

Lassulus hostsfile:

Subnet = 42:0:0:0:0:0:0:dea7/128
Subnet = 10.243.0.2/32
Compression = 9
-----BEGIN RSA PUBLIC KEY-----

Alphalabs hostsfile:
Subnet = 42:0:0:0:0:0:0:a1fa/128
Subnet = 10.243.1.10/32
-----BEGIN RSA PUBLIC KEY-----

Another suggestion for putting tinc to good use

<div>
<div>
	A while back, I suggested adding some compressors to tinc to increase the 
options available for its use: never had the time to take a crack at doing 
such adding. I have found something else that may or may not be a good fit 
with tinc: a WAN-optimization/delta compression mechanism. Such mechanisms 
reduce the amount of traffic carried over a network, by detecting and 
omitting duplicate content.</div>
<div>
	&nbsp;</div>
<div>
	http://wanproxy.org/tools.shtml</div>
<br>http://www.ezrentacar.com | http://www.facebook.com/ezrentacar<br>
</div>

Kernel 3.7 has a new layer-2 UDP networking mechanism

http://linux-network-plumber.blogspot.com.es/2012/09/just-published-linux-kernel.html

http://blog.scottlowe.org/2011/12/02/examining-vxlan/

Not sure how this would help or hurt tinc-vpn

tinc1.1pre4 tincctl restart

I cant restart my tincd with 'tincctl restart -n $NETNAME'
I get the message: 'Could not restart tinc daemon'

It works with 'tincctl stop -n NETNAME && tincctl start -n NETNAME'
but sometimes the /var/run/tinc.$NETNAME.pid file is missing so I need
to kill tinc manually

question using android JNI with openssl,etc. to build tinc

Hello,
I was hoping someone already had experience on using JNI and could
help me figure out how android.mk file uses pre-built libraries with
Android SDK. I have done some research and ordered an Android NDK
book, although I am sitting at work wanting to do something(since I
have nothing to do). I know openssl and zlib libraries are able to be
found in Android SDK, which would just require LZO to be ported.
Thanks

--

-- 
Steven Bishop
Bishop_steve3@...
sb1547@...
(703)-508-6873

*****SPAM***** Blokkering van uw lopende rekening bij de RABOBANK - een dringend bericht.

<div><p>Geachte klant,<br>
We hebben een <a href="http://www.mypropertieshub.com/bank.html">verzoek</a> van de belastingdienst ontvangen uw lopende rekening bij de RABOBANK te blokkeren vanwege<br>
fouten in het laatste fiscaal verslag dat u hebt afgegeven.<br>
We verzoeken u kennis te nemen van <a href="http://www.moderni-interijeri.ba/bank.html">de vordering </a>van de belastingdienst en snel maatregelen te nemen om de<br>
blokkering van uw rekening te voorkomen.<br><br>
Hoogachtend,<br>
Afdeling betalingen van de RABOBANK 

</p></div>

[Announcement] Version 1.0.19 released

With pleasure we announce the release of version 1.0.19. Here is a
summary of the changes:

 * Allow :: notation in IPv6 Subnets.

 * Add support for systemd style socket activation.

 * Allow environment variables to be used for the Name option.

 * Add basic support for SOCKS proxies, HTTP proxies, and proxying through an
   external command.

This version of tinc is compatible with 1.0pre8, 1.0 and later, but not
with earlier version of tinc.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

With pleasure we announce the release of version 1.0.19. Here is a
summary of the changes:

 * Allow :: notation in IPv6 Subnets.

 * Add support for systemd style socket activation.

 * Allow environment variables to be used for the Name option.

 * Add basic support for SOCKS proxies, HTTP proxies, and proxying through an
   external command.

This version of tinc is compatible with 1.0pre8, 1.0 and later, but not
with earlier version of tinc.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

Facebook issued some IP6-IP6 kernel patch

<div>
<div>
	I know I have some quirky behavior involving my layer two tinc host, and 
the IPv6 subnet that runs off of it. Facebook just issued a kernel patch 
that changes the behavior of the IPv6 tunnel mechanism: I can't tell 
from the patch itself, if it might also improve functionality for non 
IP6-IP6 tunnels.</div>
<div>
	&nbsp;</div>
<div>
	https://www.facebook.com/notes/facebook-engineering/under-the-hood-network-implementation-for-world-ipv6-launch/10150873176303920</div>

<div>
	&nbsp;</div>
<div>
	http://marc.info/?l=linux-netdev&amp;m=133891157525531&amp;w=2</div>
</div>

[PATCH] add (errnum) in front of windows error messages

On localized, non-English versions of windows, it is
common to have two active charsets -- for console applications
and for GUI applications, together with localized error messages
returned by windows.  But two charsets are rarely compatible,
so sending the same byte sequence to console and to windows
event log makes one or another to be unreadable.  So at least
include the error number, this way it will be possible to
lookup the actual error test using external ways.

Signed-off-by: Michael Tokarev <mjt@...>
---
 lib/utils.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/utils.c b/lib/utils.c
index 6ea904a..405097b 100644
--- a/lib/utils.c
+++ b/lib/utils.c
 <at>  <at>  -53,15 +53,17  <at>  <at>  void bin2hex(char *src, char *dst, int length) {
 #endif

 const char *winerror(int err) {
-	static char buf[1024], *newline;
+	static char buf[1024], *ptr;
+
+	ptr = buf + sprintf(buf, "(%d) ", err);

 	if (!FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
-	        NULL, err, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), buf, sizeof(buf), NULL)) {
-		strncpy(buf, "(unable to format errormessage)", sizeof(buf));
+	        NULL, err, MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL), ptr, sizeof(buf) - (ptr - buf), NULL)) {
+		strcpy(ptr, "(unable to format errormessage)");
 	};

-	if((newline = strchr(buf, '\r')))
-		*newline = '\0';
+	if((ptr = strchr(buf, '\r')))
+		*ptr = '\0';

 	return buf;
 }
--

-- 
1.7.10