similar to: Node problems.

Hi there, I am experiencing an annoying but not critical issue with (I think) tinc's internal routing. My setup is this: HostA (local. ConnectTo = HostC) HostB (geographically close. ConnectTo = HostC) HostC (far away. ConnectTo = nothing) Without tinc, pings from HostA to HostB take around 10ms, and from HostA/B to HostC around 200ms. With tinc, pings from HostA to HostB take nearly

Hi, I've got a relatively simple tinc setup. I've got two "servers" that are on the public internet that act as routers for three "clients" that are behind NATs. Those servers are called aaaaa and bbbbb the clients are xxxxx, yyyyy and zzzzz Unfortunatly the servers have problems accepting a connection from the clients syslog on aaaaa: Sep 29 18:28:58 schuerrer

Hi Guus and List, Since the CVE-2013-1428 was announced, I followed the recommendation to update my windows machines to tinc1.1pre7. I've had connectivity issues since upgrading. I've done some debugging but I can't figure out when or why its happening. All machines on the network are running Windows 7 or Windows 2008R2 Enterprise server and tinc 1.1pre7. I've got one master

Hi, I'm sometimes getting a failure of connecting 2 nodes when Tinc is started and configured in a LAN. In the logs, there are some unexpected dropped packets with very high or negative seq. I can reproduce this issue ~2% of the time. When this happens, the 2 nodes can no longer ping or ssh each other through the tunnel interface but using eth0 works fine. The connection can recover after at

Hi all, I have two nodes, connected to a switch, using Tinc 1.1 from git. They connect each other with sptps, and to other nodes in the Internet with old protocol because they have Tinc 1.0. There is no problem with remote nodes, but between my 2 local nodes, they see 1518 PMTU. But local network is 1500 MTU !!! So nodes can ping each other but larger data does not go. test1=sllm1 test2=sllm2

Hello, I'm running a tinc network including dozens of nodes in switch mode. Some are running stable branch 1.0, while a small set of nodes are running 1.1 with ed25519 support. I discovered some routing issue between two nodes: (names are hidden) A (1.1): ConnectTo = B ConnectTo = C IndirectData = yes Mode = Switch B (1.0): Mode = Switch C (1.1 but only with RSA key): Mode = Switch

On Thu, May 14, 2015 at 10:12:40AM +0200, Florent B wrote: > > I have no experience with Ubuntu, but I find it hard to believe it would > > block ICMP Fragmentation Needed packets out of the box. > > I can confirm you that this is the case. Ubuntu ignores those ICMP > packets... :( (rp_filter settings) > > You can see it here : https://mellowd.co.uk/ccie/?p=5662

The server has a 1G symmetrical fibre line. It has been speedtested to various local servers to be close to 800-900M. When there is only a single client, there isn't much problem and as soon as the connection is made, the ping time through to tunnel is a respectable 30ms. As soon as a few more clients are connected, ping time degrades to hundreds and sometimes seconds and with dropped packets.

Hi everyone, you can find the current version of my enhanced tinc using subversion: svn://tardyon.mon-clan.de/tinc I allowed anonymous read access, so feel free to download the sources. Unfortunately, my enhancements are based on a rather old git-checkout from Guus. The version should run under windows and Debian/Ubuntu. Best, Daniel -----Original Message----- From: folkert [mailto:folkert

While working on SPTPS UDP relaying I realized that there is one issue I didn't account for, which is that the sending node only knows the PMTU to the first relay node. It doesn't know the PMTU of the entire relay path beyond the first hop, because the relay nodes don't provide their own PMTU information over the metaprotocol. Now, in the legacy protocol this is not really an issue,

Cipher is enabled with the default setting (Blowfish CBC) Digest is disabled Compression is disabled MACLength is the default (4 if I remember correctly) I suspect that the issue is related to the encryption. I tried disabling encryption and the issue wasn?t reproduced during an automated test run of 400 reconnections. Regards, Alexandre Beaulieu > On Nov 22, 2014, at 3:19 PM, Guus Sliepen

Hi Guus, while checking the source code, I stumbled upon PMTU Discovery. I've got a question regarding the process of sending/receiving PMTU packets. As I understand, the packet flow is like this: 1 .Tinc creates a packet with a specific payload length to send it as an PMTU probe. (The data part is just some random bytes.) 2. This packet gets compressed and sent

Dear Guus, I've attached my first git commit to your repository. It does not contain any new functionalities, but it is a first try to interact with your git copy. Could you please verify, if you can push this commit to your repository? If it works, I'll send you the rest of my work, which contains: 1) some small improvements in logging (using flags instead of counters) 2) the

On Wed, May 13, 2015 at 04:41:30PM +0200, Florent B wrote: > I have MTU problems when all these conditions are true: > - a client is running Ubuntu (ICMP messages about PMTUd are ignored on > it by default) I have no experience with Ubuntu, but I find it hard to believe it would block ICMP Fragmentation Needed packets out of the box. > - a client is accessing us from a particular

+0100 From: Daniel Schall <tinc-devel at mon-clan.de> Date: Thu, 6 Jan 2011 17:00:35 +0100 Subject: [PATCH] Improved PMTU discovery diff --git a/lib/dropin.c b/lib/dropin.c index 52fb5b8..2b803b1 100644 --- a/lib/dropin.c +++ b/lib/dropin.c @@ -165,8 +165,8 @@ #endif =20 #ifdef HAVE_MINGW -int usleep(long usec) { - Sleep(usec / 1000); - return 0; -} +//int usleep(long usec) { +//

Well this has had me stumped for days now. For months I've been using tinc in TCPOnly because I always received the unknown host error when using UDP. On Monday, i set the flag IndirectData = yes in my host files, and removed the TCPOnly line. Initially, everything worked great. My throughput increased from 600KB/sec to 2MB/sec between the sites. However, I also did some testing with

Hello, if you need clampmss then it is highly probable there is a PMTU discovery problem. The clampmss does not work for UDP. I probably counted the size incorrectly. So you are able to ping with size 1464 and not with 1466. How about trying same ping sizes from the internet towards your site? I mean trying to ping from sites with higher MTU than yours without lower MTU links in the path. You

Hi, I believe I have found a bug with regard to the LocalDiscovery feature. This is on tinc-1.1pre7 between two Windows nodes. Steps to reproduce: - Get two nodes talking using LocalDiscovery (e.g. put them on the same LAN behind a NAT with no metaconnection to each other) - Make one ping the other. Expected result: - The two nodes should ping each other without any packet loss, hopefully at

Try removing all MTU related settings from both sides. Allow tinc to learn on its own. " PMTU = 1436 ClampMSS = yes PMTUDiscovery = yes" in the config, " Address Family = ipv4" is likely not necessary, i would recommend removing it. " Device = /dev/net/tun" should not be used, unless tinc is having issues locating the tun device. however " DeviceType =

Am 23.06.2020 08:43, schrieb Luca Bertoncello: And another thing, I discovered right now... > Could you suggest me something to restrict the problem? > Currently, I think the problem can be: > > 1) on Asterisk > 2) on my Gateway/Firewall A couple of years ago I added this entry in my firewall: /sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS