similar to: Option UDPOnly missing?

Hello. Im running tinc from long time, but recently I noticed that tinc TCP connections are not closed correctly (timeout). They seem to linger around like this: Proto Recv-Q Send-Q Local Address Foreign Address State tcp 80 0 xxx.x.x.xx:58801 xx.xxx.xxx.xx:*** ESTABLISHED tcp 515 0 xxx.x.x.xx:45422 xx.xxx.xxx.xxx:*** ESTABLISHED

Okey, this is new and better version. Now we handle wait up to hardcoded (for now) value. After wait (IP stack reconf or timeout) we launch 'tinc-up' script. To handle initial TAP device traffic, script is now launched in separate thread. This version works 100% for me under Win2003. ---------- Original message ---------- From: borg at uu3.net To: tinc-devel at tinc-vpn.org Subject: Re:

Hello. Yet again I fight with tinc-up script on windows. Long time ago I added hastly commit to fix it: f61fd437ca36ff03cd669726894a09ae4e128427 Unfortunately, its not enough.. So I decided to change aproach. Here it is: git://borg.uu3.net/OEM/tinc.git branch: tap_wait Im using iphlpapi to wait for windows IP stack to settle with newly initialized device. After that, when tinc-up is called, you

Okey, after more extensive R&D and testing I came up with 2 final solutions: 1) external tool: wipchg 2) internal tincd: wait_device(int secs) Both solution works 100% time (tested on Win2003). I publish them here, so interested parties can do they own testing. 1) ftp://borg.uu3.net/home/borg/tmp/wipchg.tgz You need Mingw compiler to build this. 2)

Well. I want to test subnet propagation, alternate paths, etc... Do this, I would use Imunes because im very familiar with it.. I want to build small test network around 10 nodes with different connectivity between them and then lay-out tinc network on it. Then I can just set BER=1 to kill links and see how things happen etc.. Nice spot about ng_eiface indeed. I'll check it out.. As for

Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes. When the server does not receive a PMTU request back from one of the clients even when the packet size is very small (say 164), then it reverts to TCP. Should i turn off PMTUDiscovery or should it be ok to leave on? It takes a very long time to do simple pings (1 second or so), so i wonder what else i can do?

There are few reasons why I stick to older OSes. In case of FreeBSD its my customized Imunes platform for network simulations... Anyway, back to root problem: gcc -std=gnu99 -DHAVE_CONFIG_H -DCONFDIR=\"/etc\" -DLOCALSTATEDIR=\"/var\" -DFORTIFY_SOURCE=2 -g -O2 -MT tincd.o -MD -MP -MF $depbase.Tpo -c -o tincd.o tincd.c &&\ mv -f $depbase.Tpo $depbase.Po

Hi. I have issues building tincd-1.0.26 on FreeBSD 4.11 Seems commit 68f4ca711593416d0defd81199b176ba604c6cb1 that "modernizes" build system was a bad idea after all? Not sure why merging lib/ to src/ was done. Most software I see contains directories like compat/ to aid building for older or broken environments.. This makes clear difference between software sources itself (src) and

Hello. I wonder if someone here performe such large scale tinc-vpn tests.. There are platforms like Imunes or CORE to do generic Ethernet and IP testing and routing, but I found that at least on Imunes it is problematic to start TAP iface on vimage on FreeBSD (at least 4.11 with I use). To fix that, I think about coding in BSD NetGraph support to tinc. But first I need to do testing if actualy

Dear all, we have a very strange problem, - we have 3 VPN endpoints - all are in one NETWORK - all daemons come up and connect without any problem and normally we have no problem working through the VPN but in some cases the connection does not work because the traffic leaves the TAP interface on one VPN endpoint but never arrives on the other end, the similarities between the packages seem to

Aloha! I am new to tinc and I like to figure out my own issues before asking but I am not sure of my next step here. I am not sure if the problem is the VPN configuration or in my network. I will try to be as through as possible. I have two computers that are CentOS with the latest tinc from their respective repositories. Server A is behind a Sophos XG and Server B is behind a Ubiquiti Edge

Well this has had me stumped for days now. For months I've been using tinc in TCPOnly because I always received the unknown host error when using UDP. On Monday, i set the flag IndirectData = yes in my host files, and removed the TCPOnly line. Initially, everything worked great. My throughput increased from 600KB/sec to 2MB/sec between the sites. However, I also did some testing with

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

> Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes. Hello, these features were introduced in 1.0.13 correct ?? I also understand that the two settings are by default "yes" if not explictly set to "no" in the config file. what may happen if I have a network with mixed versions from 1.0.11 and 1.0.13, where the older daemons do not implement that feature

Hello, all! I have many questions about tap device architecture. What is a right way to calc mtu on TAP device to avoid fragmentation on real eth device? I suppose TAP MTU = 1500-8(UDP)-20(IP)-18(Ethernet) = 1454. So I'd set 1454 for tap device: "ip link set mtu 1454 dev eth0" I'm not shure about what is the exact size of ethernet frame header, which tap device use in switch

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.

I've noticed some inconsistent performance with some of my tunnels and thought I would take some of the spare free time I have over the holidays to try to figure out what the cause of that may be. My environment in this case is my home LAN. Please forgive my use of the terms "server" and "client" in this email, I only use these terms to simply explanation. I statically

Hello. I have some doubts about this commit: 09d60499af3acef2ba9bd7be15e8d1c44249f8d5 Always call res_init() before getaddrinfo(). Im not sure if this is really a good idea to call res_init() so often. In UNIX, resolv.conf does NOT really change.. and if it changes ever.. its not a problem to restart affected processes. Does anyone think about any ill-effects res_init() can do when called

Hello! I have 3 PCs - Windows, FreeBSD and Ubuntu. FreeBSD runs as a tinc server as it has a real IP. Ubuntu runs as a tinc client as it has a dynamically changing public IP. Windows has not tinc installed yet. Therefore I use Putty ssh client to ssh to FreeBSD machine (as it has real IP) and then from there I ssh to the Ubuntu box using its virtual IP. The connection establishes well, I can ping

Hi, thank for getting back. I'll answer the questions, but I've already gave up on tinc and switch to zerotier-one. On 2020-07-27 5:10 p.m., borg at uu3.net wrote: > Hi. I have few questions out of curiosity.. Cant help for now with > your problem... > > What version is crashing? 1.1 or 1.0 ? 1.1 is crashing > > How your network is segmented..? > I use tinc myself