similar to: GitHub clone of tinc

On 6 September 2017 at 10:47, Guillermo Bisheimer <gbisheimer at bys-control.com.ar> wrote: > Hi Etienne, > > I will try to reproduce the issue, as it not always happen. Just sometimes. Right, that matches my experience. > The TAP driver I have installed in the Tinc folder is version 9.0.0.8 > according to the .inf file included. > > Should I test with driver 9.0.0.9?

Hi Guillermo, Yes, I've also noticed there are still issues with resuming from standby on Windows, despite the latest fixes that I wrote (which are included in 1.1pre15). I think my fixes covered some of the causes of tinc misbehaving on standby, but not all of them. Are you able to reproduce the issue reliably? If so, can you please file an issue at https://github.com/gsliepen/tinc/issues

Hi Guillermo, Yes, I've also noticed there are still issues with resuming from standby on Windows, despite the latest fixes that I wrote (which are included in 1.1pre15). I think my fixes covered some of the causes of tinc misbehaving on standby, but not all of them. Are you able to reproduce the issue reliably? If so, can you please file an issue at https://github.com/gsliepen/tinc/issues

Hi Marc, A number of bugs have been found and fixed in the code that deals with Windows devices in tinc 1.1: https://github.com/gsliepen/tinc/pull/169 https://github.com/gsliepen/tinc/pull/173 https://github.com/gsliepen/tinc/pull/174 https://github.com/gsliepen/tinc/pull/181 https://github.com/gsliepen/tinc/pull/182 Unfortunately, these fixes have not made it in a tinc 1.1 release yet, but

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

Thanks Guus. Appreciate the help. What's the purpose of SUBNET msg? Is it even useful in switch mode? I tweaked the code to disable SUBNET msg, because I thought they weren't useful when it comes to switch mode. Which caused the UDP connection got blocked apparently. If I re-enable SUBNET msg, the udp connection starts to work fine. I don't see any forwarding traffic any more. On

Thank you, I will gladly try this. For your information I did do: sudo apt-get install autoconf-archive I got this from: http://stackoverflow.com/questions/30412576/autotools-syntax-error-with-ax-check-compile-flag That did not make any difference. -----Oorspronkelijk bericht----- Van: tinc-devel [mailto:tinc-devel-bounces at tinc-vpn.org] Namens Guus Sliepen Verzonden: dinsdag 27 september

Yes, it means exactly that. See https://github.com/gsliepen/tinc/pull/26 for details. On Sun, Dec 28, 2014 at 5:57 PM, Pedro C?rte-Real <pedro at pedrocr.net> wrote: > On Sat, Dec 27, 2014 at 8:41 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: >> * LocalDiscovery now uses local address learned from other nodes, and >> is enabled by default. > > Does this mean

Thanks for the update! I've been testing Tinc 1.1pre14 for a while in linux and windows, and it's working very well. But I'm having some trouble with Windows machines (mostly Win8 and Win10) when resuming from suspended state or hibernation the tinc daemon just stop responding. I have to shut down the process and start it back up to be able to connect to the VPN. The first line on

Thanks for the update! I've been testing Tinc 1.1pre14 for a while in linux and windows, and it's working very well. But I'm having some trouble with Windows machines (mostly Win8 and Win10) when resuming from suspended state or hibernation the tinc daemon just stop responding. I have to shut down the process and start it back up to be able to connect to the VPN. The first line on

Hi Etienne, Am 20.05.2018 um 10:58 schrieb Etienne Dechamps: > Hi Marc, > > A number of bugs have been found and fixed in the code that deals with > Windows devices in tinc 1.1: > > https://github.com/gsliepen/tinc/pull/169 > https://github.com/gsliepen/tinc/pull/173 > https://github.com/gsliepen/tinc/pull/174 > https://github.com/gsliepen/tinc/pull/181 >

Thanks Guus for the quick answer, I will give a try now. Рысь, In my case we don't want to restart tinc "server" at all, therefore what might happen is that the client is still connected to server while its public key was already removed from server. I will try the signal approach. Heng On Mon, Jul 25, 2016 at 12:42 PM, <tinc-request at tinc-vpn.org> wrote: > Send tinc

On Mon, Apr 16, 2018 at 09:10:02AM +1000, Hamish Moffatt wrote: > I have a bunch of Debian stretch machines with systemd where I find that > tinc starts too early during boot, and fails to work. > > Typically it is running, but printing out > > Apr 14 00:53:41 db7 tinc[3077]: Can't write to Linux tun/tap device (tun > mode) /dev/net/tun: Input/output error [...] >

Hi, Guus I referre to the two separate tinc process/network(received same subnet), not Sunbet selection within one tinc process/network. My understanding is if different tinc process comes with exact subnet, as they are not related with each other(they have no idea regarding weights with each other), I guess the routing depends on the host's main routing table, for specific route it depends

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

On Thu, Sep 24, 2015 at 05:51:30PM +0300, R?zvan Sandu wrote: > Taking into account that both Red Hat and Debian (8.x) families now use > systemd, there is, IMHO, one small. but important correction to be done: > tinc's initialization. > > IMHO, we need: > > 1. A proper tinc.service file, included by default (prepackaged) in the > stock .deb and .rpm packages in

On Fri, Jan 22, 2016 at 02:12:20PM +0100, Maximilian H. wrote: > I am using tinc's feature to dump a graph of the vpn extensively to view > the machines which are currently part of the vpn. > > I would love to have the ip addresses of the vpn ips of the tinc nodes > in that graph, e.g. if one tinc node is called office00, then I would > like the graph to not only show

On Tue, Sep 27, 2016 at 11:00:38AM +0000, Henk wrote: > ./configure: line 5272: syntax error near unexpected token `AX_APPEND_FLAG' > ./configure: line 5272: `AX_REQUIRE_DEFINED(AX_APPEND_FLAG)' > make: *** No targets specified and no makefile found. Stop. [...] > I would like to have a build procedure I can repeat, like the tinc.sh from snip2code. Can somebody tell how to

On Mon, Oct 24, 2016 at 09:04:49PM +0200, borg at uu3.net wrote: > Okey, after more extensive R&D and testing I came up with 2 > final solutions: > > 1) external tool: wipchg > 2) internal tincd: wait_device(int secs) > > Both solution works 100% time (tested on Win2003). > I publish them here, so interested parties can do they own testing. > > 1)

On Sun, May 17, 2015 at 07:46:45PM +0100, Etienne Dechamps wrote: > I sent you a pull request that addresses the general issue, at least > for the short term: https://github.com/gsliepen/tinc/pull/83 Merged. > > You are right. The main issue with the SPTPS datagram protocol is that > > it actually doesn't handle any packet loss or reordering during > > authentication