similar to: Improving packets/sec and data rate - v1.0.24

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

Hi Jared, I've seen the same while testing on digital ocean, I think it's the context switching that happens when sending a packet. I've done some testing with wireguard and that has a lot better performance but it's still changing quite a lot and only does a subset of what tinc does so probably not a stable solution. Martin On Wed, 17 May 2017 at 18:05 Jared Ledvina <jared at

Niklas - Thanks! Yeah, your Github issue was very useful for me to understand what is probably causing our issue (the syscall chain done on every UDP packet). Very interesting that you're able to see around 90% of a Gig line on bare metal. Were you ever able to make any further progress on adjusting Tinc based on the investigation in https://github.com/gsliepen/tinc/issues/110 ? Martin -

I noticed a large performance boost both on bare metal and in vps instances by turning on kernel routing in the tinc config, and using full host declerations for routs rather than dumping things to the tun interface ambiguously. "Forwarding = kernel" ip route add 1.2.3.4 via 4.3.2.1 dev tun -instead of- ip route add 1.2.3.4 dev tun On May 17, 2017 3:10 PM, "Niklas Hambüchen"

On 17/05/17 21:50, Jared Ledvina wrote: > Were you ever able to make any further > progress on adjusting Tinc based on the investigation in > https://github.com/gsliepen/tinc/issues/110 ? Hi Jared, No, not yet. I list a few ways for potential improvements in the ticket, but the one that I suspect would do most on the type of virtualisation that DigitalOcean does is to add a feature to

I once filed this issue and did an investigation on high CPU load on cloud instances that might be relevant to this topic: https://github.com/gsliepen/tinc/issues/110 If I remember correctly I found that AWS EC2 instances have this problem less than DigitalOcean instances. On bare metal machines with tinc 1.0 and aes-128-cbc, I can get 90% of gigabit line speed over tinc. On 17/05/17 19:17,

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

Multiple questions here, thinking one email is less annoying (sorry if not). Running tinc 1.0.31 1. Could anyone give an explanation (or point to documentation) of the differences between Connections, Nodes, and Edges in the USR1/2 logging, and the various information in there? 2. Connections appears to match the list of ConnectTo hosts in the main config file -- does this mean this node can

Hi, Guus I noticed th default reconnect for the first time is 5s, if failed the timer will be increase, I would like to know if this timer can be adjusted? The Max Timeout you mentioned seems not exactly the one, from the description below, it looks to me it is the total time for connect to be re-established, if not it trying other tinc daemon? Different tinc deamons have nothing related to

On 2017-02-21 16:39, Tomasz Chmielewski wrote: > tshark shows "TCP Spurious Retransmission" for cases where curl is not > able to fetch any data. > > > Both tinc servers are running Ubuntu 16.04 (64 bit) with tinc 1.0.26. > > DC1 is Europe (Hetzner); DC2 is in USA (Amazon AWS). > > > > What's interesting, I don't have these timeouts when I

Hello, After upgrading my client system from Debian jessie to Debian stretch (which includes an update from tinc 1.0.24 to tinc 1.0.31), I am having trouble with my VPN: As long as I let tinc connect directly (no "Proxy" configuration option on the client), everything works fine: # tincd -n rath -D -d tincd 1.0.31 starting, debug level 1 /dev/net/tun is a Linux tun/tap device (tun

Hi Team, I admit that I am not familiar with Tinc very well, but have Tinc running at approximately 20 sites and functioning as a mesh vpn/network. I am having issues adding an additional site as it will not communicate with the rest. I have taken the firmware of one and flashed it on another router to make it duplicate and then tested it working but when I change the hostname, and IP to what we

On my system, tinc is started on bootup. If the Network cable is not connected, tincd hangs forever after these messages: 2017-02-13 11:34:01 tinc.XXX[403]: tincd 1.0.31 starting, debug level 5 2017-02-13 11:34:01 tinc.XXX[403]: /dev/net/tun is a Linux tun/tap device (tun mode) 2017-02-13 11:34:01 tinc.XXX[403]: Executing script tinc-up 2017-02-13 11:34:02 tinc.XXX[403]: Listening on 0.0.0.0 port

I have a use case where my tinc.conf ConnectTo can go upto 20 + hosts. I am planning to automate a periodic cleanup of ConnectTo in the tinc.conf file, the issue is I am not able to figure out which ConnectTo is been used and which are stale, say NOT used in last 2 to 3 days. I want to remove those ConnectTo which are no longer actively used. Is it possible to find which ConnectTo are not used.

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)

Hi Guus Thanks for clarifying. Some follow up questions: - How do we patch 1.1pre14 with this fix? Or will there be a 1.1pre15 to upgrade to? - What is the workaround until we patch with this fix? Using a combination of AutoConnect and ConnectTo? - When we use ConnectTo, is it mandatory to have a cert file in the hosts/* dir with an IP to ConnectTo ? -nirmal On Tue, Aug 22, 2017 at 12:10

Hi, I have successfully connected a network of about 60 nodes (many of which are virtual machines) with tinc 1.0 but encounter a severe bug when physical connectivity between two major locations is lost and then reconnected. From what I gathered, many nodes attempt to connect to many other nodes, causing 100% CPU load on all nodes, taking down the whole network with no node succeeding connecting

Hi, Tinc experts I’m on-boarding for Tinc for just quite a few days, and trying to setup the connection between one client to multiple server, where multiple vpn tunnels from the client to different server. From the documentation, it indicate the tinc.conf can support multiple ConnecTo, also the tinc can support multiple netname, like /etc/tinc/net1, /etc/tinc/net2. My question is, for my above

I have a use case where I have to add new "ConnectTo=host" in tinc.conf and reload tinc. This is to make sure existing connections do not get disconnected. I use ... /usr/local/sbin/tinc --pidfile /var/run/tinc.vpn.pid -n vpn reload this works for most part, however, I am now seeing instance where I have to do a restart instead of reload. New connection works after a restart. Is there a

I have the following tinc setup: client -- tinc DC1 -- tinc DC2 -- 10.1.2.0/24 subnet It generally works well, however, there is one issue I'm not able to solve: *sometimes*, connectivity to *some* destinations does not work for the first few seconds. To demonstrate: $ mongo mongo.example.com:27017 MongoDB shell version: 3.2.12 connecting to: mongo.example.com:27017/test