search for: replaywindow

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

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

...oblem. 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 = TincKnoten1 GraphDumpFile = /tmp/tinc-graph LocalDiscovery = yes ClampMSS = yes PMTU = 1400 #DirectOnly=yes #IndirectData=yes Cipher=AES-128-CBC #TCPOnly=yes mac:10.0.0.20 (1gig directly to our backbone via mpls from out office-vlan) Name=TincKnoten20 AddressFamily = ipv4 Devic...

Hello all, 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 to send out high-prio (VoIP) packets first. Could this create a problem on the

...tinc.ninux[15152]: Lost 168 packets from GREG1 (151.28.100.141 port 655) 1307284072 tinc.ninux[15152]: Lost 146 packets from GREG1 (151.28.100.141 port 655) where GREG1 is one of my VPN clients. I had similar lines for many other clients. I'm running a tincd network of about 60 nodes. setting ReplayWindow = 0 will help me get rid of this ? >From the change log I don't understand if it is better to have it very big or none. Question 2: I don't understand how I can have date and time in my log lines instead of thos long numbers :) Has it to do with tincd options or with syslog options ?...

...ordered using these queues to > send out high-prio (VoIP) packets first. > Could this create a problem on the receiving tincd? > I guess the sequence number is checked here, right? Tinc checks the sequence number, but allows reordering up to a certain number of packets. Have a look at the ReplayWindow configuration option in the manual: http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-ReplayWindow -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... N...

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 based on their dhcp-client-identifier which is unique for each node....

...queues to send >> out high-prio (VoIP) packets first. Could this create a problem on the >> receiving tincd? I guess the sequence number is checked here, right? > > Tinc checks the sequence number, but allows reordering up to a certain > number of packets. Have a look at the ReplayWindow configuration option > in the manual: > > http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-Re playWindow we > didn't change that setting, so the default is 16. What exactly will happen if tinc gets a packet which should have arrived 20 packtes before (be...

...ith hundreds of flush....would block messages. All hosts are running latest tinc-1.0 stable. The server is configured as a bridge and is relaying multicasts continuously. Below is the server configuration. Name = tserver AddressFamily = ipv4 BindToAddress = 192.168.21.254 30000 KeyExpire = 28800 ReplayWindow = 0 DeviceStandby = no DeviceType = tap DirectOnly = yes Mode = hub ProcessPriority = high ClampMSS = yes Cipher = none Digest = none MACLength = 0 PMTUDiscovery = yes I have taken out what I believe is performance sapping options in an effort to boost performance. All clients (Windows 7) configu...

...e v1.0.31. Two use v1.0.24 and a single old one is still at v1.0.19. (Debian stable, oldstable and oldoldstable) The tinc daemon I restarted was using v1.0.31. The setup is running unchanged (besides a few nodes being added from time to time) for a few years. The only non-default setting is "ReplayWindow 32". I am quite confident (due to the age and stability of the setup), that this was just a rare occasion, that will likely never happen again. But maybe someone has an idea, whether this is a tinc related issue and if there is something that could be done to prevent such a situation. Thank...

...to initiate ARP resolution, while the central node does not. Any points as to why the central tinc is not doing / able to do the ARP request? tinc.conf on the central node: Device = /dev/tap1 Name = centralnode Mode = switch DirectOnly = yes TunnelServer = yes PingInterval = 60 PingTimeout = 15 ReplayWindow = 0 BindToAddress = 192.168.50.82 BindToAddress = 192.168.50.84 BindToAddress = 192.168.50.83 tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> ether 42:00:00:00:00:00 inet 192.168.51.1 netmask 0xffffff00 broadcast 192.168.51.255...

...to see my end2end connections modified during the path so I decided to set up a tinc network to transfer all the Internet data until one of my servers placed in somewhere of Internet. I'm using the following values for the layer3 tinc network: Compression=11 PMTU=1480 Cipher=none ClampMSS=no ReplayWindow=32 The DNS are not routed using the tinc overlay, here you can check my "tinc-up" script [1]. To test the difference between using tinc and using the raw connection I have made a little script [2] which uses "httping" to calculate the time needed to get a web site. I have take...

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

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 is 129 pa...

...t a broadcast packet. If possible, upgrade to a newer version of Debian. If that's not possible, try installing tinc 1.0.24 from wheezy-backports. > The setup is running unchanged (besides a few nodes being added from time to > time) for a few years. The only non-default setting is "ReplayWindow 32". That is quite certainly not the cause of this issue. > I am quite confident (due to the age and stability of the setup), that this was > just a rare occasion, that will likely never happen again. > But maybe someone has an idea, whether this is a tinc related issue and if >...

...achary <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 window for each remote node, in bytes. +This is the size of the replay tracking window for each remote node, in bytes. The window is a bitfield which tracks 1 packet per bit, so for example the default setting of 16 will track up to 128...

...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 ConnectTo = $remote_node_name_here ConnectTo = $remote_node2_name_here ConnectTo = $remote_node3_name_here ConnectTo = $remote_node4_name_here ConnectTo = $remote_node5_name_here ConnectTo = $remote_node6_name_here Sadly, I'm out of ideas on how to improve the performance here. I've...

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