similar to: [PATCH 1/4] Experimental IFF_ONE_QUEUE support for Linux

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

Dear Guus, I've attached my first git commit to your repository. It does not contain any new functionalities, but it is a first try to interact with your git copy. Could you please verify, if you can push this commit to your repository? If it works, I'll send you the rest of my work, which contains: 1) some small improvements in logging (using flags instead of counters) 2) the

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

I know i'm new to the list but i'd like to propose something for tincd daemon. I'd like to mark all sockets established by a tincd process with a mark passed as an argument in the command line. What could be the purpose of this new option? The goal of this option is to be able to have several tincd process running at the same time using the same port but using different ip. In

(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 have a simple pair of nodes set up, connected wirelessly, with tincd 1.0.16 running in switch mode. Setting Cipher and Digest to "none", and Compression to 0, the bridge is still CPU-bound, with most of tincd's CPU time spent in libcrypto. I narrowed it down to this line in net_setup.c: myself->connection->outcipher = EVP_bf_ofb(); It looks as though all outgoing data is

Hey, I have this setup on my small test tinc-vpn. HostA (runs on a server and is publicly accessible) HostB (runs on my laptop (behind firewall) sometimes and connects to HostA) HostC (runs on a Amazon AWS server (behind firewall) to test long uptime and connects to HostA) This setup allows me to communicate from HostB to HostC thru HostA without any issues. Everything works great, but I

Hello Mentors, I am currently finding bug in Local Function related optimization due to which runtime failures are observed in some test cases, as those test cases are containing very large function with recursion and object oriented code so I am not able to find a pattern which is causing failure. So I tried following simple case to understand expected behavior from this optimization. Consider

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,

Dear readers, Today i checked out a fresh copy of tinc from svn (rev 1432) and got the following: tinc[32605]: Got fatal signal 11 (Segmentation fault) tinc[32605]: Got another fatal signal 11 (Segmentation fault): not restarting. I've got two nodes set up in switch mode which work fine with tinc-1.0.2 (not with 1.0.3 due to the broadcast packet issue) gdb backtrace: Program received

Hi! here a little patch for darknet functionality, i hope it does what its intended for sufficiently ... but it seems to work :). what should it do? imagine your friend-network. A trusts B and C. B trusts D and E, D trust F, C trusts G. All trust relationships are mutal A <---> C <---> G ^ \ \-----> B <---> D <---> F ^ \ \---> E

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

If running without `--net', the (global) variable `netname' is NULL. This creates a segmentation fault because this NULL-pointer is passed to strdup: Program terminated with signal 11, Segmentation fault. #0 0xb7d30463 in strlen () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7d30463 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7d30175 in strdup () from

Tinc replaces non-alphanumeric characters in the `Name` field of tinc.conf by '_' (see [1] and [2]). This includes hyphens ('-'), which are often used in host names. That is quite surprising, and can easily lead to misconfigurations, especially because there doesn't seem to be a warning if you configure `Name = node-1`, and on the other machines the host file

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

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

A while back I expressed interest in trying to add additional compression formats (XZ, ZPAQ-derived). What would be the best way for me to try these with the 1.1 codebase? And can 1.1 be used with 1.0.x nets out-of-box? http://en.wikipedia.org/wiki/Xz http://mattmahoney.net/dc/zpaq.html -------------- next part -------------- An HTML attachment was scrubbed... URL:

aG93IHRvIGNoZWNrb3V0IHRoZSBsYXN0IGRldmVsb3AgdGluYz8gKENWUyxjb21wbGllIGFibGUp DQo= Tinc: Discussion list about the tinc VPN daemon Archive: http://mail.nl.linux.org/lists/ Tinc site: http://tinc.nl.linux.org/

I am trying to get tinc to use aes-128-cbc for it's encryption algorythm for network traffic. So far, I'm not having any luck. I've tried putting it into the tinc.conf file, and it turns out that tinc is ignoring that code completely. I'm using tinc 1.0.4 (in TCP mode). Openssl version 0.9.7d. I've made some initial investigation into the source, and in net_setup.c I