similar to: What's the weight means in the dump of edge info from USR2?

Thank you, that is very helpful. And actually I do have a few further questions regarding this: 1. This weight is not the one specified in Subnet, this should be something related to the host, where can I manually configure this? 2. The weight value is ONLY take round trip latency as the measurement, or including CPU power and other factors into consideration? 3. I don't know how this

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

On Thu, May 11, 2017 at 08:03:02AM +0800, Bright Zhao wrote: > 1. This weight is not the one specified in Subnet, this should be something related to the host, where can I manually configure this? Either in tinc.conf, then it applies to all connections made, or in individual host config files, then it applies only to connections with that host. > 2. The weight value is ONLY take round

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

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,

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'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

Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes. When the server does not receive a PMTU request back from one of the clients even when the packet size is very small (say 164), then it reverts to TCP. Should i turn off PMTUDiscovery or should it be ok to leave on? It takes a very long time to do simple pings (1 second or so), so i wonder what else i can do?

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

Hi, I upgraded some of my Tinc nodes from 1.0.8 recently and found something strange. All of a sudden, the vpn would not work as a full-mesh. Certain nodes were not contactable. I re-generated my rsa-keys, and checked my configuration. My vpn uses the following in tinc.conf, as I am routing both ipv4 and v6. === name = node1 mode = switch AddressFamily = any PMTU = 1280 PMTUDiscovery = yes

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

I have long included tinc in the cerowrt project as a lighter weight, meshy alternative to conventional vpns. I sat down a few days ago to think about how to make vpn connections work better through fq_codel, and decided I should maybe hack on a vpn to do the job. So I picked up tinc's source code for the first time, got it working on IPv6 as a switch in a matter of minutes between two

Hi, how does tinc decide where to route a packet? I know default weight is 10. Does tinc add all weights and choose the lowest? Will 3 hops with weight 10 prefered before one hop wih weight 50 ? ALBI...

Hello! I have 3 PCs - Windows, FreeBSD and Ubuntu. FreeBSD runs as a tinc server as it has a real IP. Ubuntu runs as a tinc client as it has a dynamically changing public IP. Windows has not tinc installed yet. Therefore I use Putty ssh client to ssh to FreeBSD machine (as it has real IP) and then from there I ssh to the Ubuntu box using its virtual IP. The connection establishes well, I can ping

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

On Fri, Dec 30, 2016 at 11:38:51AM +0100, Etienne Dechamps wrote: > I believe the reason why you're experiencing this problem is because tinc > does not use the connection TCP port to determine which port to send UDP > packets to. Instead, it uses the port that is *advertised* by the other > node. That's correct, at least for the initial PMTU probes. If it receives packets

I mean exactly the same configuration, including the pub-pri key. Sent from iPhone

Hi All, Sorry for disturbing you if the issues has been discussed earlier but I cannot find clear explanation of my problem. Tracing the tinc logs (a debug level) I have found that the MTU value of the connection is determined and chosen at the beginning of the tunnel setup. My question is following: is the MTU value renegotiated / rechecked after the tunnel is established? The question