search for: directons

Hi, Etienne I took a look for the below host configuration parameter (IndirectData), the default is no. For the below example: A ConnectTo B, B ConnectTo C: If IndirectData = no (default), then A wouldn’t establish direct connection with C, but will be forwarded by B. If IndirectData = yes, then A will try to establish direct connection with C, even though A don’t have the statement of

Hi, I´m using Tinc for several years, but I didn´t fix a performance problem. There a about 20 nodes in this network. Master: 10.0.0.12 (dedicated host in a datacenter, debian, 100mBit port) tinc.conf: Name = TincKnoten12 AddressFamily = ipv4 Interface = tun ProcessPriority=high mode = router #DirectOnly = no Compression=0 PMTUDiscovery = yes #IndirectData = yes #ReplayWindow = 64 #ConnectTo

Dear all, I like tinc and am using it widely in the company I work for. Currently I'm experimenting with 'switch' mode & have a problem with packets being forwarded. I've tried possible combinations with next parameters: a) Broadcast = direct b) Forwarding = kernel c) DirectOnly = yes From the documentation, it looks like (a) should be enough to stop packet forwarding

Hello, I am tying to create tinc vpn for the ~1000 nodes and was thinking why meta connections are needed at all if I only need static configuration where every node knows addresses of other hosts and due to the amount of traffic any indirect connections will not work, so DirectOnly=yes is a must and then passing around routing information is not needed, right? Currently I have 10 nodes

Hi, I'm using Tinc v1.0.11 on Ubuntu 10.04 and seeing high CPU usage (up to 30%) on what I wouldn't consider high traffic levels. The traffic is application server to database server connections and multicast communication for session-replication on the application server. I'm running the tinc daemons in switch mode, to support the multicast. I have tried settings: TunnelServer =

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, Etienne In addition, is there any option or switch can turn of the automatic direct connection? For the example below, even A has the route to C and can establish UDP connection directly, but I need the traffic to go through B, how can I achieve that easily? (instead of remove something from A’s routing table, or manually block the connection between A and C) > On 1 May 2017, at 6:28 PM,

The server has a 1G symmetrical fibre line. It has been speedtested to various local servers to be close to 800-900M. When there is only a single client, there isn't much problem and as soon as the connection is made, the ping time through to tunnel is a respectable 30ms. As soon as a few more clients are connected, ping time degrades to hundreds and sometimes seconds and with dropped packets.

*You should repeat this for all nodes you ConnectTo, or which ConnectTo you. However, remember that you do not need to ConnectTo all nodes in the VPN; it is only necessary to create one or a few meta-connections, after the connections are made tinc will learn about all the other nodes in the VPN, and will automatically make other connections as necessary. * The above is from the docs. Assuming

Ok so I'm up and riding with Icecast2 and ices2, thanks for all of you who pointed me in the right directon. I can stream fine without reencoding but when I change the nominal-bitrate tag its not happy. Comments in the xml file say: <!-- Live encoding/reencoding: Currrently, the parameters given here for encoding MUST match the input data for channels and sample rate. That restriction

On Tue, Jun 21, 2016 at 01:04:31PM +0200, Hendrik Schumacher wrote: > 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) maintenance on the network > infrastructure. The problem was already described in the mailing list (for > example here:

Thank you for the helpful advice. We will try to group the servers with different ConnectTo servers first. If this does not help we will look at the TunnelServer solution. Just to make sure we understand TunnelServer correctly: do you need to specify every host as ConnectTo that the host should be able to communicate with or is it sufficient to just provide the hosts files? Thanks, Hendrik

On Mon, 4 May 2020 18:45:19 +0200 (CEST) Sven-Haegar Koch <haegar at sdinet.de> wrote: > On Mon, 4 May 2020, Pallinger Péter wrote: > > > ------- TL;DR ------- > > > > Performance seems slow (around 300-400Mbit peak). > > How to improve? > > Not sure if that could be the case for you, my links are not that > fast: > > Make sure to disable

Hi, We have a tinc network of about ~200 hosts and in the full mesh configuration we've had a lot of problems with the edge propagation storms taking the entire network down. Recently we had a setup with a small number of "hubs" to which all the other nodes connected to, which limited the number of meta connections, but that didn't help much with the edge propagation issues.

Folks, We have a setup where each mobile node connects with 1 or more tinc instances (over different links) to a central node. tinc is running in switch mode. The link is chosen by setting the IP address on the active link's interface, and the central node sees this after the first packet on the link, and moves the MAC address to a different 'ethernet port' (link). This works really

We run tinc in a linux environment in which it sits there waiting for connections from the clients. All clients are configured to only have one ConnectTo which points to this server. We're seeing in the server log that as soon as a client's connection is activated, a whole bunch of "Flushing x bytes to that host would block" is logged and the whole vpn is bogged down and has

Hi Guus, I am wondering why MACExpire was introduced in: ,---- | commit 14979f835df4214a7c2510852f7ffedc9e08c2c0 | Author: Guus Sliepen <guus at tinc-vpn.org> | Date: Fri Mar 1 14:09:31 2002 +0000 | | - Global time_t now, so that we don't have to call time() too often. | - MAC addresses expire after a time configurable by MACExpire (default 600 | seconds) `---- Is

On Tue, 5 May 2020 10:56:01 +0200 Pallinger Péter <pallinger at dsd.sztaki.hu> wrote: > On Mon, 4 May 2020 18:45:19 +0200 (CEST) > Sven-Haegar Koch <haegar at sdinet.de> wrote: > > On Mon, 4 May 2020, Pallinger Péter wrote: > > > > Make sure to disable compression, that is a known CPU hog. > > Compression was disabled. I've successfully slowed

Hello, I am using tinc in a lot of contexts related to servers and general infrastructure. Recently another potential use-case appeared: providing a VPN for remote devices (located at customer sites and maybe not exclusively under our control). The tinc configuration allows to restrict the direct traffic between such remote devices easily: DirectOnly = yes Forwarding = off TunnelServer = no

With pleasure we announce the release of version 1.0.13. Here is a summary of the changes: * Allow building tinc without LZO and/or Zlib. * Clamp MSS of TCP packets in both directions. * Experimental StrictSubnets, Forwarding and DirectOnly options, giving more control over information and packets received from/sent to other nodes. * Ensure tinc never sends symbolic names for ports