search for: kwinch

...shows something like below: 2017-06-01T09:00:29.558712+08:00 C tincd: 0.0.0.0/0#1 owner B (That’s the reason, why C received the packet from A forward to B even A is not connected to B, in this case I have to stop the tinc daemon on B in order to make traffic goes back to D) After tincd -n myvpn -kWINCH on A/C/D, then all the old unreachable info is gone. So questions here: 1. Why in the my case, the traffic will go A>C>B path even A is not connect to B? 2. Why the unreachable info and the related advertised subnet info still exist in C even the A remove the ConnectTo statement to B(all In...

Hello, I have removed a nod from my tinc network, but his informations (owned subnet and ip address) are still present in the internal routing table. I think that even if the node is not reachable anymore (his ip is, but not the tinc daemon on it), his routing information "lives" beetween nodes. Is this possible or do i need to sleep a bit !? ;-) Do i need to stop all nodes, then

Hello all, this is just a minor nuisance but nevertheless I would not dislike a solution for it. I run a mixed 1.0/1.1 VPN. Some time ago I've removed a node from the VPN (wiped the disk, so deleting the private keys). Over the time I've removed the corresponding public keys (among with all the infos related to the node) from the other nodes. All nodes have been restarted more than

Hello, i have observed a Bug in Graph Dump (think). tinc build fine Graph dumps. Inside the dump is a tinc node which no longer tinc used. Connection not inside of dump for this node. This tinc network is used for backbone network in Chemnitz, Germany. We use tinc Versions 1.0.14 and 1.0.13 on PC (Linux) and router (OpenWrt). In the attachment is the graph dump. On this dump is name of node