similar to: Packet reordering problem?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Guus, On 04/30/2015 03:42 PM, Guus Sliepen wrote: > On Thu, Apr 30, 2015 at 02:55:59PM +0200, Armin Schindler wrote: > >> we are using tinc 1.0.24 with 6 hosts (endpoints). Quality of service >> is used with prio qdisc on all network interfaces. This means depending >> on the TOS value of the IP header IP-packets will

Hi, I'm seeing periodic packet loss with tinc (1.0.16). I have 'ReplayWindow = 0' in config, and ping between the hosts is perfect. I suspect the packets are identified and then dropped by the Great Firewall. My question is: can it be identified by DPI? If yes, how should I improve tinc to avoid this? Thanks in advance. Roger -------------- next part -------------- An HTML

Hi, I'm seeing periodic packet loss with tinc (1.0.16). I have 'ReplayWindow = 0' in config, and ping between the hosts is perfect. I suspect the packets are identified and then dropped by the Great Firewall. My question is: can it be identified by DPI? If yes, how should I improve tinc to avoid this? Thanks in advance. Roger -------------- next part -------------- An HTML

Hi, I´m using Tinc for several years, but I didn´t fix a performance problem. There a about 20 nodes in this network. Master: 10.0.0.12 (dedicated host in a datacenter, debian, 100mBit port) tinc.conf: Name = TincKnoten12 AddressFamily = ipv4 Interface = tun ProcessPriority=high mode = router #DirectOnly = no Compression=0 PMTUDiscovery = yes #IndirectData = yes #ReplayWindow = 64 #ConnectTo

Hello, I'm upgrading to 1.0.14 I did some manual tricks in my Gentoo Portage because seems that upstream Gentoo did not update the portage yet, does anybody know how to Contact Gentoo Linux to have the package updated ? Question 1: I notice in my log file I had many entries like this with 1.0.13: 1307284053 tinc.ninux[15152]: Lost 251 packets from GREG1 (151.28.100.141 port 655)

--- doc/tinc.conf.5.in | 3 +++ src/linux/device.c | 7 +++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/doc/tinc.conf.5.in b/doc/tinc.conf.5.in index 2bfd5fe..01f7f81 100644 --- a/doc/tinc.conf.5.in +++ b/doc/tinc.conf.5.in @@ -255,6 +255,9 @@ a lookup if your DNS server is not responding. This does not affect resolving hostnames to IP addresses from the host

We run tinc in a linux environment in which it sits there waiting for connections from the clients. All clients are configured to only have one ConnectTo which points to this server. We're seeing in the server log that as soon as a client's connection is activated, a whole bunch of "Flushing x bytes to that host would block" is logged and the whole vpn is bogged down and has

Hi, We've been running tinc for a while now but, have started hitting a bottleneck where the number of packets/sec able to be processed by our Tinc nodes is maxing out around 4,000 packets/sec. Right now, we are using the default cipher and digest settings (so, blowfish and sha1). I've been testing using aes-256-cbc for the cipher and seeing ~5% increases across the board. Each Tinc node

Hello, I am a happy user of tinc in multiple environments. It is beautiful - thank you! Today I noticed that a network of around 20 nodes suffered from a flood of packages like the following: IP6 fe80::e4eb:74b6:57e0:c3e1 > ff02::2: ICMP6, router solicitation, length 8 For the first ten hours these nodes (even the usually completely idle ones) have seen incoming traffic of around 1 MBit/s

Hello. I'm living in the country side where the communications are very very poor. My only choice is Satellite connection throw the French company Eurona which uses the network deployed by Skylogicnet. In general the latency is very bad (~800ms) and the network is very unstable. I have been investigating in the ISP routers which are in my path and there are many hops which are done in a

On Thu, Apr 30, 2015 at 02:55:59PM +0200, Armin Schindler wrote: > we are using tinc 1.0.24 with 6 hosts (endpoints). > Quality of service is used with prio qdisc on all network > interfaces. This means depending on the TOS value of the IP header > IP-packets will get a priority queue on the network interface. > > Packets from TINC (UDP 655) maybe reordered using these queues

Hi! I have som problems with my vpn tunnel. I have 6 nodes in the network. Three of them is running tinc 1.1pre5 Three of them is running tinc 1.0.19 I also have vlan tagging between the nodes running tinc 1.1pre5 The problem is that get a bunch of errors in the log like the messages below (logs is attached in the email): Got late or replayed packet from JOTPOS ("internal ip" port

On Mon, May 18, 2015 at 12:08:53PM +0200, Armin Schindler wrote: > We didn't change that [ReplayWindow] setting, so the default is 16. > What exactly will happen if tinc gets a packet which should have arrived > 20 packtes before (because of the TOS prio queues)? With the default setting of 16, up to 128 packets can be arbitrarily reordered without problems. If a packet arrives that

Hi All, I currently have the following setup. One central node called BackBone with the following conf: Name = Backbone Mode = switch AddressFamily = ipv4 ReplayWindow=64 Compression=10 I also have approximately 440 nodes connected to this node with the following setup: Name = xxxxxx Mode = switch ConnectTo = Backbone Compression = 10 There is dnsmasq on Backbone that serves ips to the nodes

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.

Folks, We have a setup where each mobile node connects with 1 or more tinc instances (over different links) to a central node. tinc is running in switch mode. The link is chosen by setting the IP address on the active link's interface, and the central node sees this after the first packet on the link, and moves the MAC address to a different 'ethernet port' (link). This works really

Signed-off-by: Loic Dachary <loic at dachary.org> --- doc/tinc.conf.5.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/tinc.conf.5.in b/doc/tinc.conf.5.in index 7196392..00e4674 100644 --- a/doc/tinc.conf.5.in +++ b/doc/tinc.conf.5.in @@ -416,7 +416,7 @@ and are available. .El .It Va ReplayWindow Li = Ar bytes Pq 16 -vhis is the size of the replay tracking

On Fri, Dec 14, 2018 at 11:13:55PM +0100, Lars Kruse wrote: > I am a happy user of tinc in multiple environments. It is beautiful - thank you! > > Today I noticed that a network of around 20 nodes suffered from a flood of > packages like the following: > IP6 fe80::e4eb:74b6:57e0:c3e1 > ff02::2: ICMP6, router solicitation, length 8 [...] > Most of the tinc nodes use v1.0.31.

Hi, Terribly sorry about the duplicated message. I've completed the upgrade to Tinc 1.0.31 but, have not seen much of a performance increase. The change looks to be similar to switching to both aes-256-cbc w/ sha256 (which are now the default so, that makes sense). Out tinc.conf is reasonably simple: Name = $hostname_for_node Device = /dev/net/tun PingTimeout = 60 ReplayWindow = 625

Guus, Below a segment of a log file. I am trying to analyse why the satellite link goes down and up all the time (sometimes 10 to 15 times an hour, sometimes not for a day. My guess is that this indicates packet loss on the satelllite link and tinc not really recovering from that. Where I inserted an empty line the log basically stopped and was silent for I guess for 14 minutes? Would setting