similar to: TCPOnly obsolete? Maybe not

Folks, Does any of you have a sensible way of monitoring tinc? I haven?t tried anything yet, sorry for that. I?d like to avoid log spamming like the check_ssh plugin does (?10+ preauth' warnings a day). check_tcp is an option, but I was wondering whether anyone cooked up something more sensible. Met vriendelijke groet, Nick Hibma -- AnyWi Technologies BV E: nick at anywi.com T: +31 (0)71

Guus The mdoc warnings (on FreeBSD 8) are getting a little bit annoying at times: anywi at lcrproxy:/usr/ports/security/tinc/work/tinc-1.0.19/doc % man tinc.conf 2>&1 | head -5 mdoc warning: Empty input line #6 mdoc warning: Empty input line #10 mdoc warning: Empty input line #15 mdoc warning: Empty input line #22 mdoc warning: Empty input line #30 There are hundreds. Ctrl-L refreshes

Hi, We set up tinc tunnels over 3G when the connection becomes available. It is a mobile environment so connections come and go frequently. We send tinc an ALRM signal to retry a connection, but somehow this fails once in a while. Is there a way to influence the retry interval for connections that are down and the interval increment? We would like to be able to set this to 1 minute after ALRM.

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

Guus, Below a segment of a log file. I am trying to analyse why the satellite link goes down and up all the time (sometimes 10 to 15 times an hour, sometimes not for a day. My guess is that this indicates packet loss on the satelllite link and tinc not really recovering from that. Where I inserted an empty line the log basically stopped and was silent for I guess for 14 minutes? Would setting

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 everyone, Today is exactly 10 years ago that tinc 1.0 was released. I would have hoped to celebrate this by releasing 1.0.22 and 1.1pre8 today, but this will instead happen in one week. Tinc 1.1 is close to becoming stable, and I hope to release 1.1.0 before the end of the year. The main features of tinc 1.1 are the improved security over tinc 1.0, and a much nicer interface that makes it

Hello everyone, Today is exactly 10 years ago that tinc 1.0 was released. I would have hoped to celebrate this by releasing 1.0.22 and 1.1pre8 today, but this will instead happen in one week. Tinc 1.1 is close to becoming stable, and I hope to release 1.1.0 before the end of the year. The main features of tinc 1.1 are the improved security over tinc 1.0, and a much nicer interface that makes it

Hi, I've successfully running tinc1.0pre4 between two locations on SuSE Linux 7.1 in a special masquerading Firewall environment, so that I'm using the TCPonly keyword in the host files to get a connection. Otherwise I would get the message 'Received UDP packet on port 655 from unknown source <ipaddress in hex:port>'. After upgrading to 1.0pre5 I'm getting this message

Hi there! Today I've tried a FTP connection (me with TCPOnly send file to another no TCPOnly), but the upload bandwidth was about 20 kb/s, while connecting to the other directly (I upload a file to him via FTP) the connection was about 5 times faster... what's wrong? thanks

Hi there! Today I've tried a FTP connection (me with TCPOnly send file to another no TCPOnly), but the upload bandwidth was about 20 kb/s, while connecting to the other directly (I upload a file to him via FTP) the connection was about 5 times faster... what's wrong? thanks

If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP?

The only time I can think off, that you’ll *want* to use TCP, is when UDP doesn’t work through the firewalls/NATting. > On 18 Jun 2017, at 14:53 , Bright Zhao <startryst at gmail.com> wrote: > > If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP? The problem with TCP, is that TCP,

> On 18 Jun 2017, at 15:44 , Bright Zhao <startryst at gmail.com> wrote: > > I agree with the in-effective of TCP transmission, but I wonder if the the UDP packet is dropped, the tinc VPN itself wouldn’t retransmit, and if the upper level application doesn’t handle the packet loss well, will this be the problem? > > Or the upper level application have very limited tolerance

Hey, Tinc developers! I'm not sure if anyone else has brought this up, but we've got a rather good reason for using TCP, even though UDP will actually form a working connection. Anyone on Comcast's "small business" service is forced to use an SMC cable modem/router. Its NAT implementation is capable of letting tinc's UDP tunnels work fine, but they limit a single UDP

I agree with the in-effective of TCP transmission, but I wonder if the the UDP packet is dropped, the tinc VPN itself wouldn’t retransmit, and if the upper level application doesn’t handle the packet loss well, will this be the problem? Or the upper level application have very limited tolerance to packet loss(like RDP application, I guess if the packet loss go to certain threshold, the connection

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

hi guys! i was using +PPP over SSH tunneling in the past to achieve a kind of VPN between two networks: A is a public network B is a private network The problem is that network B is behind a firewall that for some reasons cannot be opened whatsoever. This mean that: Network B can freely connect to network A (SSH, for example) Netowkr A cannot access network B in any way (except, trough a

Dear C?dric, If I am using windows version of tinc, how can I check the connection list? Regards, Eric -----Original Message----- From: tinc-bounces at tinc-vpn.org [mailto:tinc-bounces at tinc-vpn.org] On Behalf Of tinc-request at tinc-vpn.org Sent: Wednesday, April 18, 2012 6:00 PM To: tinc at tinc-vpn.org Subject: tinc Digest, Vol 90, Issue 17 Send tinc mailing list submissions to tinc at

This question involves Rook, but I think the answer will be general enough that it pays to post here. At any rate, I don't know enough to know whether this is a Rook only issue or a general R issue. Here's what I'd like to do (and indeed, have code that should do this): 1. Start R, Rook 2. Start an analysis via a HTTP request to Rook. This analysis uses .Call() to some compiled C