similar to: Self-DoS

On Wed, Dec 30, 2015 at 05:26:38PM +0000, Pierre Beck wrote: > 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,

Options given on the command line have precedence over configuration from files. This can be useful, for example, for a roaming node, for which 'ConnectTo' and <host>.Address depends on its location. --- This patch is against stable branch. Merging this patch to the 1.1 branch is trivial. I use this patch on my Debian for several weeks. Here is the ifupdown script I use (some

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?

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

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)

Hello, I am trying 1.1 branch and I experience a segmentation fault upon ALRM signal. This looks like a race condition. I have my tincd daemon instantiated manually in if-up.d/jmuchemb (without IF_TINC_NET) and when if-up.d/tinc runs, it sends a ALRM signal that makes tincd crash. It fails here: Core was generated by `tincd -D -n jmuchemb -d -o ConnectTo srv -o srv.Address 81.x.y.z -o

I know i'm new to the list but i'd like to propose something for tincd daemon. I'd like to mark all sockets established by a tincd process with a mark passed as an argument in the command line. What could be the purpose of this new option? The goal of this option is to be able to have several tincd process running at the same time using the same port but using different ip. In

Hello All, How are you all doing today? Good i hope. I am wondering if some one could please comment on the scalability limitations of Tinc as far as bandwidth usage and connections? Thinking about the documentation on Tinc suggests that if it is always trying to maintain a full mesh topology and if there would be many nodes, e.g. more than about 100 or so active at a give time, then Tinc

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

Hi there, 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.

Hello, We're suffering from sporadic network blockage(read: unable to ping other nodes) with 1.1-pre17. Before upgrading to the 1.1-pre release, the same network blockage also manifested itself in a pure 1.0.33 network. The log shows that there are a lot of "Got ADD_EDGE from nodeX (192.168.0.1 port 655) which does not match existing entry" and it turns out that the mismatches

(Second try to send this. I wonder if the first one gotten eaten by a spam filter; I'll link to patches instead of attaching them.) Here are the tincctl patches I've been working on. They apply to http://www.tinc-vpn.org/svn/tinc/branches/1.1@1545. I intend to commit them once the crypto stuff's fixed. Since they're basically done, I'm emailing them now for review and in case

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

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

On Mon, Dec 08, 2014 at 11:02:24PM -0500, md at rpzdesign.com wrote: > The self contained example is tricky because I created 4 ip-address on > the eth0 device (192.168.1.30/31/32/33) so I could test a 4 node VPN > that lives entirely within a single server. That's quite hard to do, it's far easier to run four instances of tinc on four different ports on the same machine. >

Howdy Folks, I've got a 5 node setup here. My server "home" is the primary server that all other servers connect to. The configs on all the servers look like this: # cat /etc/tinc/home/hosts/node1 Subnet = 10.2.0.0/16 Address = 192.168.2.1 <RSA KEY> # cat /etc/tinc/home/hosts/node2 Subnet = 10.3.0.0/16 Address = 192.168.3.1 <RSA KEY> Etc. All the hosts are setup

Hi, All Here is the case: A, B, C, D all configured with "IndirectData = yes”, so connection only happens when there’s a “ConnectTo” in tinc.conf. Arrow indicate the “ConnectTo” direction Everything works fine earlier as below: 1. A connect to C, D connect to C 2. C is the transit node where only forward traffic between A and C 3. D advertise 0.0.0.0/0#2 4. A can access internet from D

Hi there, I would need some help with my configuration. I have tried a long time, but did not find my error. Thus I would really appreciate your help. There are three hosts: 1. h181 2. h182: Should ConnectTo h181 3. h183: Should ConnectTo h181 *Files under /etc/tinc/vpn0/hosts* [h181:] Address = 94.130.108.xxx Subnet = 172.16.1.1/32 -----BEGIN RSA PUBLIC KEY----- *** -----END RSA PUBLIC

I've got tinc running happily on a couple linux and win computers, but no luck on OS X. I'm on Yosemite 10.10.5, and I think I followed the OS X tutorial exactly, but no luck. Here's my error message: > sudo tincd -n dpsf -D -d3 tincd 1.0.21 (Feb 3 2015 20:09:36) starting, debug level 3 Could not open /dev/tun0: No such file or directory Terminating And here's the contents

Hi, Saw the below config from tinc’s manual: UDPRcvBuf = bytes (OS default) Sets the socket receive buffer size for the UDP socket, in bytes. If unset, the default buffer size will be used by the operating system. UDPSndBuf = bytes (OS default) Sets the socket send buffer size for the UDP socket, in bytes. If unset, the default buffer size