similar to: thoughts on a new release?

Dear Guus, while improving the PMTU Discovery algorithm, I found the following behavior in the method "send_udppacket": 1) The code checks, whether the data size is smaller than the MTU, thus if it fits into a single UDP packet. If not, you send the packet via TCP. 2) The data is compressed, changing its size. (Usually, making it smaller, but that's not always

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

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

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

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,

+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) { +//

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

>Updated support for BSD tun/tap devices. It is broken on FreeBSD tun. tcpdump on tun, 09:05:07.458988 IP0 bad-hlen 0 On Sun, Apr 24, 2016 at 8:16 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > With pleasure we announce the release of tinc version 1.1pre12. Here is > a summary of the changes: > > * Added a "--syslog" option to force logging to syslog even if

Guus: Great job. I would love to see a library version of Tinc for linux. Kind of like an API instead of configuration files. Don't have time right now, but maybe one day I will re-factor the code for library orientation. It would have a single unix socket with a JSON API. I use Tinc on linux Ubuntu 15.10 x64 for all my vpn stuff. It allows Elastic Search and RethinkDB to survive in the

With pleasure we announce the release of version 1.0.11. Here is a summary of the changes: * Fixed potential crash when the HUP signal is sent. * Fixes handling of weighted Subnets in switch and hub modes, preventing unnecessary broadcasts. * Works around a MinGW bug that caused packets to Windows nodes to always be sent via TCP. * Improvements to the PMTU discovery code, especially

With pleasure we announce the release of version 1.0.11. Here is a summary of the changes: * Fixed potential crash when the HUP signal is sent. * Fixes handling of weighted Subnets in switch and hub modes, preventing unnecessary broadcasts. * Works around a MinGW bug that caused packets to Windows nodes to always be sent via TCP. * Improvements to the PMTU discovery code, especially

On Wed, May 10, 2017 at 03:41:46PM +0800, Bright Zhao wrote: > abc to def at x.x.x.x port 655 options d weight 540 > > How’s the 540 weight been calculated? What does it mean? How can I leverage this weight? Unless you specify it manually (by using the Weight configuration option), tinc will use the time it takes to make a connection to a peer as the weight. So peers with a higher

Hi, I get de following error messages in the logfile: var/log/tinc.ci1070300036.log:2011-08-16 14:12:54 tinc.ci1070300036[10834]: Possible node with same Name as us! Sleeping 10 seconds. I know that i don't have duplicate node names. But i see some strange node names: Al my node names start with ci but there is a node a did not create my self, and that is ca1070300036 How can i remove

Hi. I've had a chain of a sudden unexplained problems which crippled my tinc network. It looks as if UDP communication between hosts in different parts of the globe all of a sudden completely broke. While waiting for my list subscription to be accepted, I've managed to solve, (or perhaps mask) the problem by re-enabling PMTUDiscovery for all hosts involved. I still have no

On Wed, Dec 3, 2014 at 6:17 AM, David P. Reed <dpreed at reed.com> wrote: > Tor needs this stuff very badly. Tor has many, many problematic behaviors relevant to congestion control in general. Let me paste a bit of private discussion I'd had on it in a second, but a very good paper that touched upon it all was: DefenestraTor: Throwing out Windows in Tor

With pleasure we announce the release of tinc version 1.1pre12. Here is a summary of the changes: * Added a "--syslog" option to force logging to syslog even if running in the foreground. * Fixes and improvements to the DecrementTTL function. * Improved PMTU discovery and UDP keepalive probes. * More efficient relaying of UDP packets through intermediate nodes. * Improved

With pleasure we announce the release of tinc version 1.1pre12. Here is a summary of the changes: * Added a "--syslog" option to force logging to syslog even if running in the foreground. * Fixes and improvements to the DecrementTTL function. * Improved PMTU discovery and UDP keepalive probes. * More efficient relaying of UDP packets through intermediate nodes. * Improved

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

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

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