similar to: Will tinc try go re-negotiate to UDP if failed to TCP at beginning?

I mean, if I changed pingtimeout on tinc.conf, -kHUP will force the tinc to re-read that parameter into effective? If no, any other ways to make it effective other that kill the process? for tinc 1.0.

I don't know why, but for my case, I reduced the tinc topology from a complex one(which provide layered redundancy) to a very simpled one(one connection), and that connection drop disappeared. Later, let me draw the topology and share the config to you to see if there's any findings of the cause. Guus Sliepen <guus at tinc-vpn.org>于2017年9月14日 周四上午3:20写道： > On Wed, Sep 13, 2017

Hi, All Recently, one of my tinc client always suffer connection drop, I was suspect the connection was not stable to cause this issue, and BTW, I’ve set the PingTimeout to 10 seconds already, but this situation still happens a lot sometimes, but when the connection drop happens, the connection recovery pretty fast, normally in a minutes. In order to deep dive into the cause, or proven the

I agree with the in-effective of TCP transmission, but I wonder if the the UDP packet is dropped, the tinc VPN itself wouldn’t retransmit, and if the upper level application doesn’t handle the packet loss well, will this be the problem? Or the upper level application have very limited tolerance to packet loss(like RDP application, I guess if the packet loss go to certain threshold, the connection

On 7 December 2015 at 17:20, Florent B <florent at coppint.com> wrote: > I have a cluster of 5 nodes, running Proxmox 4, and Tinc as "virtual > switch" for my nodes : on each node, a bridge "vmbr1" where Tinc is > connected, provides me a secured network for my VMs (connected to that > bridge). > > When I move (hot move) a VM from a host to another, I

If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP?

On Tue, Apr 10, 2018 at 03:36:08PM +0200, Hans de Groot wrote: > hosta  <--> hostb  <-->  hostc > > Hosta and hostc are not directly connected via tinc. But both are conncted > via hostb (I called my network tincnet). This works fine I can ssh from > hosta to hostc and vice versa without any problems. > > hostc is in a whitelisted iprange at some service

We knew the TCP-BBR developed by google and try to optimize the transport efficiency of TCP, I’m wondering will this be beneficial if we put tinc in TCP mode plus the TCP-BBR?

I am using tinc to connect together VPCs in AWS across multiple regions and accounts to provide secure communication. For the most part, it works great. A few times, I have seen issues where something got into an unstable state that didn't seem to resolve itself. Shutting down tinc on all hosts and restarting seemed to do the trick, but I'd like to see if there is something that I can

An very interesting test did yesterday that, LAN1 and LAN2 setup an tinc VPN which is quite simple(the physical link between tinc nodes are quite stable/fast), and no any application traffic to go through the tinc. Later, I setup smokeping which LAN1 initial 20 ping to LAN2 on a per-minute basis, but as you saw from the below picture, it had packet drop. But if I perform a constantly ping from

Hi maximilian, the problem of MUTproble is happened here for me, and the patch is working fine, should be helpful anyway. which mode you used? router, switch or HUB? thanks PHB -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20200402/fb3597ed/attachment.html>

I understand the concern of uncertain for TCP-over-TCP by BBR, as the BBR is natively designed to optimize TCP, instead of TCP-over-TCP, but could you articulate a bit more about the beneficial of “sending host when there is a UDP tinc tunnel” in the middle”? > On 30 Sep 2017, at 11:23 AM, Ryan Mounce <ryan at mounce.com.au> wrote: > > I'm not aware that BBR claims nor

Hi, At my provider (xs4all) I've got an ipv6 tunnel working. Now I would like to distribute ipv6 via the tinc tunnel. My tinc.conf: ------------ Name=server AddressFamily=ipv4 Device=/dev/net/tun PrivateKeyFile=/etc/tinc/fvhglobalnet/rsa_key.priv GraphDumpFile=|/usr/bin/dot -Tpng -o /var/www/htdocs.keetweej.vanheusden.com/stats/tinc-fvh-network-graph.png Mode=switch KeyExpire=299

Hi All, I am trying to setup the site-to-site VPN with TINC for connect my home network to company network. Here is the IP allocation and configuration for your reference. Home PC (192.168.1.2) ?-----? Home (OPENWRT Router, 192.168.1.1, 10.0.0.1) ?----------------? INTERNET ?-------------? COMPANY (Windows 7 PC,192.168.2.1, 10.0.0.2) ?------------? COMPANY (SERVER ZONE) ?----? SERVER A

> On 18 Jun 2017, at 15:44 , Bright Zhao <startryst at gmail.com> wrote: > > I agree with the in-effective of TCP transmission, but I wonder if the the UDP packet is dropped, the tinc VPN itself wouldn’t retransmit, and if the upper level application doesn’t handle the packet loss well, will this be the problem? > > Or the upper level application have very limited tolerance

Hi, we are using Tinc in our Freifunk Network in Oldenburg for internode connections over the internet. So Tinc is running on OpenWrt 10.03 on Dlink Dir-300 Routers. We all have enough internet bandwith (1,6 MB/sec and more) but we only get a maximum speed of ~350KB/sec between two tinc nodes because then tinc uses 99% of the cpu. Is it possible to get more Speed with tinc on this machines?

Hello list, I use tinc with QOS, and since some weeks I got problem with tunnel disconnection because the default "Pingtimeout" of 5 sec is reach. I think it happens because of the QOS shappe the tinc traffic (data here) to let some BP for VOIP, but whate is very strange is that the ICMP protocol is not include in the shapping, so tinc would never 'see' latency on the link,

Hi, we use a tinc network of about 400 nodes, all of them linux servers, partly in different datacenters (but generally low latency). Usually this is working very well (for weeks without a problem). >From time to time the whole network goes down though. This happened when we restarted a larger number of servers or when there was a connectivity issue between datacenters or some (short)

The only time I can think off, that you’ll *want* to use TCP, is when UDP doesn’t work through the firewalls/NATting. > On 18 Jun 2017, at 14:53 , Bright Zhao <startryst at gmail.com> wrote: > > If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP? The problem with TCP, is that TCP,

>> We use tincd over VSAT connections, and if the contract has been reduced to a bare minimum -and- the ship is moving, latency reaches 2 - 5 seconds (yes, seconds). Generally this is not a problem if you are patient (and most smart phones are), but tincd is slightly too fast in deciding that it is not going to work. We also use the tinc connection to check whether any traffic is possible.