similar to: Tinc improvements

+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) { +//

Hello, Guus Sliepen, on Wed 02 Dec 2015 13:53:37 +0100, wrote: > That's great! It would be good though to split > handle_incoming_vpn_data() into a function that does the actual > recvfrom/mmsg() and one that processes each individual packet, to reduce > the level of indentation and make the functions a bit more readable. > Then I'll merge it :) Here it is. Samuel

Oh, goodie! I'd made a start on the send direction here: https://github.com/dtaht/tinc/commits/master Perhaps that will help. I would not just pull that as it was just some late night hacking... and it turns out the posix time calls I upgraded to to get better than second resolution are not supported on OSX. My ultimate intent was to move to not bottlenecking or dropping packets on the

Hello, Linux has a recvmmsg() system call which allows to achieve several recvfrom() at a time. The patch below makes tinc use it (patch against 1.1-pre11). Basically the patch turns the handle_incoming_vpn_data variables into arrays (of size 1 when recvmmsg is not available, and thus compiled the same as before), and makes the code index into the arrays. You may want to use interdiff -w

--- 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 there, I'm seeing quite frequent segfaults around check_dead_connections() and terminate_connection() when the tcp meta connection to a node times out (or is e.g. firewalled), usually it happens when there's heavy packet loss: Program terminated with signal 11, Segmentation fault. #0 edge_del (e=0x1b71ba0) at edge.c:96 96 avl_delete(e->from->edge_tree, e); (gdb)

We''re using tc to classify all packets currently - it avoids conflicting with other packages that want to play with the ipfilters, and up to this point has done everything we need. However now I''d like to map the four htb flows I''ve set up (and are working great on their own) to the four wireless hardware driver queues when the driver currently only has support for

10.12.2015 03:35, Samuel Thibault wrote: [] I suggest reducing ifdeffery in handle_incoming_vpn_data(), especially the error checking code. The function isn't that large now, it might be much better to have two different implementations. Like this (untested, patch attached): void handle_incoming_vpn_data(int sock) { #ifdef HAVE_RECVMMSG #define MAX_MSG 256 vpn_packet_t

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

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

I have 2 hosts, A and B. B is behind a NAT. TCP works, but when I attempt to use UDP, the following messages appears on A: Received UDP packet from unknown source x.x.x.x port 10192 This is not the port specified in the configuration, but I don't really understand why tinc should care about that. The security shouldn't depend on IP and port numbers, but on the crypto (MAC etc). So why

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.

Hi there, I run tinc with not ConnectTo, (and it can't tcp-connect to the relevant other tincd, because that tincd is behind a firewall --> that tincd usualy connects to my tincd). If I start that tincd alone (not connected at all) and do a ping some_other_ip, it gets a SIGBUS in route.c:207 in the function route_ipv4_unreachable at the line: hdr->ip_v = 4; This seems to be an

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

10.12.2015 09:20, Michael Tokarev wrote: > 10.12.2015 03:35, Samuel Thibault wrote: > [] > > I suggest reducing ifdeffery in handle_incoming_vpn_data(), especially > the error checking code. > > The function isn't that large now, it might be much better to have > two different implementations. Like this (untested, patch attached): > > void

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

On Sat, May 16, 2015 at 04:53:33PM +0100, Etienne Dechamps wrote: > I believe there is a design flaw in the way SPTPS key regeneration > works, because upon reception of the KEX message the other nodes will > send both KEX and SIG messages at the same time. However, the node > expects SIG to arrive after KEX. Therefore, there is an implicit > assumption that messages won't

While working on SPTPS UDP relaying I realized that there is one issue I didn't account for, which is that the sending node only knows the PMTU to the first relay node. It doesn't know the PMTU of the entire relay path beyond the first hop, because the relay nodes don't provide their own PMTU information over the metaprotocol. Now, in the legacy protocol this is not really an issue,

This makes it work for us: > On Jun 12, 2015, at 5:02 PM, Chris Clements <cclements at outlook.com> wrote: > > This looks like the culprit: > > http://www.tinc-vpn.org/git/browse?p=tinc;a=commit;h=7730d5f3ed9bd7c011dced5808130ffcbd74ea6b <http://www.tinc-vpn.org/git/browse?p=tinc;a=commit;h=7730d5f3ed9bd7c011dced5808130ffcbd74ea6b> > > >> On Jun 12,