similar to: Lower tinc traffic in idle condition

Something to add. When this happened, it looks like tinc shutdown gracefully(not seg fault ..), because I can tell tinc-down script got implemented. Heng On Wed, Nov 25, 2015 at 6:00 AM, <tinc-request at tinc-vpn.org> wrote: > Send tinc mailing list submissions to > tinc at tinc-vpn.org > > To subscribe or unsubscribe via the World Wide Web, visit >

Thanks for the reply. I am running tinc (1.0.24) in an embedded linux environment, with a pretty old kernel (2.6). I have let tinc run for almost 24 hours with internet and can't reproduce the issue. Heng On Wed, Nov 25, 2015 at 6:00 AM, <tinc-request at tinc-vpn.org> wrote: > Send tinc mailing list submissions to > tinc at tinc-vpn.org > > To subscribe or

Hello, I am having troubles with the following configuration in that it produces the following errors: *Masterserver:* On the server (yea, I know) side is a Linux machine called "*masterserver*". It should have a VPN IP of 192.168.2.1 and it sits behind a pretty generic ADSL Router (with port 655 forwarded) which can be found via a dynamic host address. A small snippet of errors this

using 1.0pre5 A: tinc.conf ------------ Name = A PrivateKeyFile = /usr/local/etc/tinc/vpn/rsa_key.priv Device = /dev/tap0 ConnectTo = B A: tinc-up --------- #!/bin/sh modprobe ethertap ifconfig tap0 hw ether fe:fd:00:00:00:00 ifconfig tap0 192.168.0.3 netmask 255.255.0.0 ifconfig tap0 -arp B: tinc.conf ------------ Name = B PrivateKeyFile = /usr/local/etc/tinc/vpn/rsa_key.priv Device =

Hi there I have the following setup Home - Main Tinc server with public IP running on PfSense work - tinc client running behind a CISCO ASA firewall with public IP running on Windows 10 offsite - tinc client running on tomato router behind a double NAT Home & offsite connect & i can see all PCs & devices & connect to them easily, on either side work to Home or offsite connects

hi guys! i was using +PPP over SSH tunneling in the past to achieve a kind of VPN between two networks: A is a public network B is a private network The problem is that network B is behind a firewall that for some reasons cannot be opened whatsoever. This mean that: Network B can freely connect to network A (SSH, for example) Netowkr A cannot access network B in any way (except, trough a

I have now got the tinc demons (on network OFFICES) on BranchB and BranchA talking to each other, see below for log from BranchB. For some trouble shouting issues relating to OsX see at the end of my e-mail. However, I have not yet achieved the network connectivity/routing that I would like. The aim is: BranchB is a laptop I would like to connect it (via tinc) to my office network, so that

Hi, Does anyone here have experience running Tinc on NixOS? I'm trying to run Tinc on a NixOS machine, using the similar configuration i had for Ubuntu. My home subnet is 192.168.1.0/24 and my work is 10.16.0.0/24. However, unlike ubuntu, when I start tincd on nixos, and try to 'ifconfig $INTERFACE 192.168.1.10 netmask 255.255.255.0' in my tinc-up, I loose network access on the box

Hi guys, Second question for me today:), really appreciate the help. I have been using tinc in a linux environment, due to our need, I kept it running all the time.(i.e. several months) Recently I found out the system's memory usage is gradually going higher and higher, and eventually triggering oom-killer in the system. After disabling process one by one, I identified tinc is the reason for

Hi Guys, Say when tinc is running all good, the "server" contains all the key files of clients. If we remove the key file for client A during run, how long before does server find out the key file is gone? I see a "KeyExpire" option in the conf file, is this the time? In my own experiment, the client will still be able to connect to the tinc network even if the key file is

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 Tue, 27 Feb 2018 08:12:53 +0100, Guus Sliepen wrote: > I was thinking by setting a flag whenever we call io_del(), and checking > that flag in the for-loop in event_loop(). So basically you would store a generation number in the tree that gets incremented by a call to io_del()? Or should the flag/number be changed each time the order of the tree changes? > > Changing the order

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

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 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

Hello everybody, Here are some thoughts about the authentication scheme to be used in tinc. The current scheme (see CVS version, revision CABAL) does this: Client Server --------------------------------------- send_id(u) send_challenge(R) send_chal_reply(H) send_id(u) send_challenge(R)

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

Yes, exactly. There are lots of packages exchanged between tinc processes on port 655, accounting to 99 % of the Ethernet traffic, while the virtual interface stays almost idle. Best, Maximilian Am 20. März 2020 21:09:18 MEZ schrieb Lars Kruse <lists at sumpfralle.de>: >Hello Maximilian, > >Am Fri, 20 Mar 2020 19:43:35 +0100 >schrieb Maximilian Stein <m at steiny.biz>:

Hi maximilian, the problem of MUTproble is happened here for me, and the patch is working fine, should be helpful anyway. which mode you used? router, switch or HUB? thanks PHB -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20200402/fb3597ed/attachment.html>

Hello Maximilian, Am Fri, 20 Mar 2020 19:43:35 +0100 schrieb Maximilian Stein <m at steiny.biz>: > My current mitigation is to stop some tinc peers for ten seconds and to > start them again afterwards, that usually causes the excessive traffic > to stop without interrupting service too much. I am guessing now: the rise of traffic on the ethernet link is caused by packets being