similar to: SegFault when using TunnelServer=yes

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

Hi. I have few questions out of curiosity.. Cant help for now with your problem... What version is crashing? 1.1 or 1.0 ? How your network is segmented..? I use tinc myself here a lot too (1.0) but my network is very segmented. I use switch mode and handle routing myself, so mesh links arent large.. I would NOT go beyond 30 nodes for full auto-mesh.. its already like 435 edges... Regards,

Thanks for answers. I think its now flaw.. but design.. Tinc auto-mesh is very very handy. You just need to avoid flat networks. There is also IndirectMode w/ forces nodes to be switched by intermediate node... but I would be cautionus how its used. I use it myself for certain nodes behind NATs where they cannot be connected to, so always connect node handles switching for them. You noticed it

--- doc/tinc.conf.5.in | 3 +++ src/linux/device.c | 7 +++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/doc/tinc.conf.5.in b/doc/tinc.conf.5.in index 2bfd5fe..01f7f81 100644 --- a/doc/tinc.conf.5.in +++ b/doc/tinc.conf.5.in @@ -255,6 +255,9 @@ a lookup if your DNS server is not responding. This does not affect resolving hostnames to IP addresses from the host

Hi, We want to deploy a tinc VPN, with more than 50 sites connected all arround the world. But we cannot trust all our sites with the same level, so the tinc solution (automatic full mesh) is "too automatic" for us : *any* node can add a new node which will be connected directly to others. A solution could be TLS (signing public keys), but create a PKI is another issue for us.

On command: #kill -9 `cat /var/run/sshd.pid` sshd leave pid file ! sshd.c code: =============== .... /* * Arrange to restart on SIGHUP. The handler needs * listen_sock. */ signal(SIGHUP, sighup_handler); signal(SIGTERM, sigterm_handler); signal(SIGQUIT, sigterm_handler); .... =============== Missing line is : signal(SIGKILL, sigterm_handler);

If one is using the pidfile as an indicator of sshd's status, it is possible to kill sshd before the sigterm handler gets installed, since the pidfile is written out before the signal handlers are setup. The solution is to simply write the pidfile after the signal handlers are setup. Here's the patch. Rob --- sshd.c.orig Fri Jun 22 11:16:41 2001 +++ sshd.c Fri Jun 22 11:18:32 2001 @@

+0100 From: Daniel Schall <tinc-devel at mon-clan.de> Date: Thu, 6 Jan 2011 17:00:35 +0100 Subject: [PATCH] Improved PMTU discovery diff --git a/lib/dropin.c b/lib/dropin.c index 52fb5b8..2b803b1 100644 --- a/lib/dropin.c +++ b/lib/dropin.c @@ -165,8 +165,8 @@ #endif =20 #ifdef HAVE_MINGW -int usleep(long usec) { - Sleep(usec / 1000); - return 0; -} +//int usleep(long usec) { +//

Attached is a patch to be applied with GNU patch -p0, notice that configure needs to be regenerated. The patch addresses the following annoyances: * On AIX there is a signal called SIGDANGER which is sent to all processes when the machine runs low on virtual memory. This patch makes sure that this signal is ignored, because the default on older AIX releases is to kill the running process

Hello. I found that anonymous structures does not work on gcc-2.95. If you guys want to support a bit older platforms I suggest fixing it. You can check out patch I created to fix this issue. I just added 2 extra structures to remove anonymous structs inside connection_status_t and node_status_t. Patch is here: ftp://borg.uu3.net/pub/unix/tinc/tinc.patch Attaching it as well. Regards, Borg

Hello, should the cvs trunk compile? a configure first gave me errors. I had to replace any appearance of "[config.h]" to config.h in the Makefile. Then a make did not finish: make[2]: Entering directory `/usr/src/tinc/lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/tinc/lib' Making all in src make[2]: Entering directory

Hi, I've got the following error when tried to compile tinc-1.0.24: gcc -g -O2 -pie -L/opt/local/lib -o tincd avl_tree.o conf.o connection.o dropin.o dummy_device.o edge.o event.o fake-getaddrinfo.o fake-getnameinfo.o getopt.o getopt1.o graph.o list.o logger.o meta.o multicast_device.o net.o net_packet.o net_setup.o net_socket.o netutl.o node.o pidfile.o process.o protocol.o

Hello, Last night there appears to have been a loop in the network of my colocation provider. Somehow this loop/packet flood caused tinc to crash. I guess that, even though it seems to have restarted, it did not manage to reconnect/re-open the tap device/something else went wrong; the machine itself was communicating with the internet but I could not access it over the VPN. The most

(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

I'm looking over the tinc-1.1 branch again. I'm getting some errors that I haven't been able to track down yet. tinc sometimes crashes either on its own (I think after a timeout has fired?) or when I hit ctrl-C. I've seen a few different behaviors in particular, as reported by valgrind. Dumps below. I suspected the bufferevent changes, but I haven't gotten any revision before

Hello ! I've installed tinc on debian (2.6.24.2 kernel) and it is running perfectly except some troubles occurring randomly. You can found the log below. Does anyone know more details about this crash ? In advance, thnx a lot for your help. rezec. --------log----------- tincd 1.0.8 (Jul 4 2008 13:24:07) starting, debug level 0 Sep 21 18:29:38 tinc.vpn[11682]: /dev/net/tun is a Linux

https://bugzilla.netfilter.org/show_bug.cgi?id=915 Summary: segfault in error case : expr_evaluate_payload not checking payload->payload.desc being null Product: nftables Version: unspecified Platform: x86_64 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: nft

Hi tinc list members, There were some problems with Ivo's email adresses (both zarq@iname.com and zarq@spark.icicle.dhs.org) so I resent the stuff to the mailling list. ============================================= Hi Ivo, Hier is een oplossing voor een bugje in flush_queue(), en ook wat andere troepjes zoals een tincd scheduler. Dit werkt wat beter, omdat de

I got the file that was sent to me the other day. Unfortunitly it did not solve my problems. After a lot of hacking I have been able to get release 1.0 to almost compile. I have finally gotten all of the dependancies worked out under OpenBSD 3.2. This next error has me stumped. I can tell that it is looking for a file but have no idea how to create the file. This is the output of the the

https://bugzilla.mindrot.org/show_bug.cgi?id=2158 Bug ID: 2158 Summary: Race condition in receiving SIGTERM Product: Portable OpenSSH Version: 6.2p1 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org