similar to: subnet flooded with lots of ADD_EDGE request

On Tue, Dec 11, 2018 at 02:36:18PM +0800, Amit Lianson wrote: > 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 >

Hallo, Another strange and difficult to understand thing - seems like all the easy bugs in 1.1 are gone ;) waehring (1.1) | +-------------------+--------------+ | | | vpnhub1 (1.1) igor (1.1) turing (1.0) | | | +-------------------+--------------+ | tokamak Whenever another node outside of the graph connects to vpnhub or igor

> > Maybe I should allow the reachable keyword for the dump graph command as > well, so you can do: > > tincctl -n <netname> dump reachable graph > > ...and not see any nodes which are unreachable. Is that what you want? This would help since dead nodes do not clutter the visual representation. What are the effects, if any, of dead nodes in the hosts/ dir? Thanks

Hi We have several stale nodes in our tinc network and I'd like to remove these. These nodes show up in graph dumps as red nodes, indicating they are unreachable. We run: tinc -n <vpn-name> purge Nothing happens. If we tail the logs at /var/log/syslog, we dont see an ack or message concerning the purge either. The dead nodes still show up in the graphs and their certs are still

Hi! here a little patch for darknet functionality, i hope it does what its intended for sufficiently ... but it seems to work :). what should it do? imagine your friend-network. A trusts B and C. B trusts D and E, D trust F, C trusts G. All trust relationships are mutal A <---> C <---> G ^ \ \-----> B <---> D <---> F ^ \ \---> E

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 Fri, May 15, 2015 at 10:26:46PM +0200, Sven-Haegar Koch wrote: > Another strange and difficult to understand thing - seems like all the > easy bugs in 1.1 are gone ;) [...] > Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for haegar_tokamak > -> igor which does not match existing entry (Local address 2.3.4.5 > != unknown) > > What I think may happen is that the

On Fri, 15 May 2015, Guus Sliepen wrote: > On Fri, May 15, 2015 at 10:26:46PM +0200, Sven-Haegar Koch wrote: > > > Another strange and difficult to understand thing - seems like all the > > easy bugs in 1.1 are gone ;) > [...] > > Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for haegar_tokamak > > -> igor which does not match existing entry (Local

(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

On Sat, May 16, 2015 at 12:09:52AM +0200, Sven-Haegar Koch wrote: > This change is not so good: > > Connection with aaa_vpnhub1 (1.2.3.4 port 443) activated > Error while translating addresses: ai_family not supported > > (And then the tinc process exists) Hm, I couldn't reproduce it, but I committed a fix anyway that makes sockaddr2str() handle AF_UNSPEC addresses. It

On Sat, 16 May 2015, Guus Sliepen wrote: > On Sat, May 16, 2015 at 12:09:52AM +0200, Sven-Haegar Koch wrote: > > > This change is not so good: > > > > Connection with aaa_vpnhub1 (1.2.3.4 port 443) activated > > Error while translating addresses: ai_family not supported > > > > (And then the tinc process exists) > > Hm, I couldn't reproduce

First off, thanks to all who have made tinc possible and continue to work developing it. I hope perhaps in time I can become a useful part of this community. :) I'm having an interesting issue with tincctl and was hoping someone could shed some light on it. Everything seems to work correctly when I build for OSX; however on linux and windows builds, I always receive connection

c:\APPS\TINC\tincd.exe --mlock --net=mynet --config=C:\APPS\tinc\mynet Without --mlock, the service starts OK. With --mlock, the service fails to start.

On Fri, Jan 13, 2017 at 12:33 PM, Gary Stainburn <gary at ringways.co.uk> wrote: > > > Also, it was suggested that I use nmcli in a cronjob to re-activate it if > it > drops. I can check to see if it's still active by 'grep'ing the IP > address, > but I don't know the nmcli to re-activate an existing WIFI connection. > > Can anyone help here too,

All, The attached script is causing the following error message ... bash-3.00# ./zmon_bug.d dtrace: error on enabled probe ID 2 (ID 4394: fbt:genunix:copen:entry): invalid address (0xfd91747f) in predicate at DIF offset 120 dtrace: error on enabled probe ID 2 (ID 4394: fbt:genunix:copen:entry): invalid address (0xfef81a3f) in predicate at DIF offset 120 Any ideas? thxs Joe --

Hi Today our Tinc network saw a network partition when we took one tinc node down. We knew there was a network partition since the graph showed a split. This graph is not very helpful but its what I have at the moment: http://i.imgur.com/XP2PSWc.png - (ignore node labeled ignore, since its a dead node anyways) - node R was shutdown for maintenance - We saw a network split - we brought node R

Hi Guus Following your suggestion we reconfigured our tinc network as follows. Here is a new graph and below is our updated configuration: http://imgur.com/a/n6ksh - 2 Tinc nodes (yellow labels) have a public external IP and port 655 open. They both have ConnectTo's to each other and AutoConnect = yes - The remainder tinc nodes (blue labels) have their tinc.conf set up as follows:

Thanks Guss, some comments and questions: If you make the yellow nodes ConnectTo all other nodes, and not have > AutoConnect = yes, and the other nodes just have AutoConnect = yes but > no ConnectTo's, then you will get the desired graph. The reason this approach is not desirable is because it fails at automation. It requires us to add a new line of AutoConnect = <new node that

Hi All, I see an unexpected beahviour from NetworkManager on CentOS 7.1. Using nmcli tool, I create a bond with two slaves as explained in the Red Hat 7.1 Networking guide. I enable slaves and master; bond works as expected. When I restart NetworkManager, it creates a new bond with the same name but not connected to any device. Two bonds with the same name is confusing for my other monitoring

You could say the same thing about computers in general: I hate them, they automated many tasks in life and took many jobs out of the market!. Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer at ngtech.co.il -----Original Message----- From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of Gary Stainburn Sent: Monday, January 16, 2017