similar to: Plan for 1.1 release

Are you sure it is enabled by default? On Fri, Mar 16, 2018 at 4:07 PM, Todd C. Miller <Todd.Miller at sudo.ws> wrote: > On Fri, 16 Mar 2018 14:37:58 -0700, al so wrote: > > > Is SPTPS protocol enabled in 1.1 by default? Or we need to manually > enable > > it. > > It is enabled by default. You can disable it by setting > ExperimentalProtocol = no in

I am surprised this experimental protocol is enabled by default. On Wed, Mar 21, 2018 at 3:07 PM, Todd C. Miller <Todd.Miller at sudo.ws> wrote: > On Wed, 21 Mar 2018 14:54:07 -0700, al so wrote: > > > Are you sure it is enabled by default? > > Yes. > > See the description of ExperimentalProtocol in the tinc.conf manual > for details. If you don't believe

On Wed, 21 Mar 2018 19:28:05 -0600, "Todd C. Miller" wrote: > Note that it will only be used if you generate ed25519 keys to use > with it. The new protocol is one of the main reasons to run 1.1. Also, tinc 1.1 can still interoperate with tinc 1.0 nodes using the legacy protocol. You can read more about sptps in the tinc 1.1 manual in the security section. - todd

Hi Todd, I did some tests with NDIS 6 TAP-Windows about three years ago. The outcome of that was https://github.com/gsliepen/tinc/pull/73/commits/ 0c010ff9fe50b4046b5c7977bafac3e74037f075 It was a long time ago and I don't remember the details, but I remember I was quite confused because I couldn't explain why OpenVPN did not seem to exhibit any performance issues on the same driver,

On Mon, Feb 26, 2018 at 03:18:15PM -0700, Todd C. Miller wrote: > > The problem is not the order of the events, the problem is that in the > > Windows version of the event loop, we only handle one event in each loop > > iteration. The select() loop handles all events that have accumulated so > > far, so regardless of the order it handles them, it never starves fd. At >

On Fri, Feb 23, 2018 at 03:04:24PM -0700, Todd C. Miller wrote: > I've noticed that on Windows during large transfers (such as an > iperf run), the receiving end sometimes fails to respond to a PING. > When this happens, the sender closes the connection and both ends > have to renegotiate. > > My theory is that, due to the properties of the splay tree, the TAP > device

On Mon, 26 Feb 2018 23:01:29 +0100, Guus Sliepen wrote: > The problem is not the order of the events, the problem is that in the > Windows version of the event loop, we only handle one event in each loop > iteration. The select() loop handles all events that have accumulated so > far, so regardless of the order it handles them, it never starves fd. At > least, that was what I

On Fri, Feb 16, 2018 at 02:26:36PM -0700, Todd C. Miller wrote: > > Thanks for reporting this bug! Indeed, that code is wrong. It should > > free cache->ai instead of cache->aip. Even if it didn't crash on Linux, > > it was a memory leak. A fix is now in the git repository. > > The fix leads to a use after free bug which is visible on macOS. > It doesn't

With pleasure we announce the release of tinc version 1.1pre16. Here is a summary of the changes in tinc 1.1pre16: * Fixed building with support for UML sockets. * Documentation updates and spelling fixes. * Support for MSS clamping of IP-in-IP packets. * Fixed parsing of the -b flag. * Added the ability to set a firemall mark on sockets on Linux. * Minor improvements to the build system.

With pleasure we announce the release of tinc version 1.1pre16. Here is a summary of the changes in tinc 1.1pre16: * Fixed building with support for UML sockets. * Documentation updates and spelling fixes. * Support for MSS clamping of IP-in-IP packets. * Fixed parsing of the -b flag. * Added the ability to set a firemall mark on sockets on Linux. * Minor improvements to the build system.

On Mon, Jan 22, 2018 at 09:51:33AM -0700, Todd C. Miller wrote: > On Windows, freeaddrinfo(NULL) will result in a segv. In > get_recent_address(), there is the following block of code: > > if(cache->aip) { > sockaddr_t *sa = (sockaddr_t *)cache->aip->ai_addr; > cache->aip = cache->aip->ai_next; > >

On Tue, Feb 27, 2018 at 11:23:54AM -0700, Todd C. Miller wrote: > Here's a diff to call WSAWaitForMultipleEvents() repeatedly to check > for events other than the first one returned. I've also added a > map of io_t to events[] index so avoid the need for splay_search(). That's great, less changes to the tree are good. > The value of event_count will change if a callback

Unfortunately, my fix exposed a problem in reset_address_cache() could call free_known_addresses() on a struct addrinfo * that was returned by getaddrinfo(). This results in heap corruption on Windows (and a crash). It seems safest to just make a copy of the addresses returned by getaddrinfo() so it can always use free_known_addresses() instead of trying to determine whether or not we need to

Is SPTPS protocol enabled in 1.1 by default? Or we need to manually enable it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180316/2360e357/attachment.html>

I noticed that the base64 functions in util.c don't produce the same results as other versions that implement RFC 1421 (and its successors). This results in PEM files that can only be decoded by tinc itself. Is this intentional? Below is a diff to make tinc's base64 functions match what everyone else does. This will break existing key files, though, which is unfortunate. - todd diff

On Mon, 22 Jan 2018 18:08:22 +0100, Guus Sliepen wrote: > Thanks for reporting this bug! Indeed, that code is wrong. It should > free cache->ai instead of cache->aip. Even if it didn't crash on Linux, > it was a memory leak. A fix is now in the git repository. The fix leads to a use after free bug which is visible on macOS. It doesn't seem to be much of a problem on most

While I'm aware that tinc is known to have problems with the latest Windows TAP driver (NDIS 6), we want to run tinc on Windows server 2016 which doesn't support NDIS 5 drivers. Since using the old version of the TAP driver is not an option, I'd like to better understand the issues with tinc and the NDIS 6 TAP driver. Can anyone point me to a discussion of the known issues? From

Hi Paul, I've been using various 1.1pre versions on Windows, Linux, and Freetz (embedded OS for routers, similar to OpenWRT) for years, and I can't complain. The tinc 1.1 branch is pretty stable and that's where the majority of development happens. Why do you want to wait for an official release? Regards, Daniel -----Original Message----- From: tinc-devel <tinc-devel-bounces at

On Tue, Jan 16, 2018 at 03:00:03PM -0700, Todd C. Miller wrote: > Thanks for the info, that is very helpful. It does look like that > change got back-ported to master, albeit in a different form. Hm, there's indeed some differences between the two versions, even apart from the fact that one uses a thread and the other the event system. It seems that in write_packet(), tinc 1.0 does a

Hi all, TL;DR: when Tinc 1.1 release? I plan to use Tinc for my GSoC project which basically simplifies setup of a Tinc mesh providing IPv6 to nodes in community mesh networks. As I'm new to Tinc I don't know it's history and the changes from 1.0 to 1.1, but it seems to have at least a different syntax in some cases. To make and keep it simple for users, I'd like to stick