similar to: High tinc traffic on ethernet without tinc load

Hi Lars, Am 20.03.20 um 15:43 schrieb Lars Kruse: > Did you really try the nice visualizations in the "Statistics" menu? > These should allow you to see, which protocols and which peers cause the > traffic. > > I am slightly confused, that you already took a look at the traffic, but you did > not mention, which type of traffic makes up the bulk of the excessive packets

Hi, thanks for your suggestion. Am 19.03.20 um 20:15 schrieb Lars Kruse: > you could write the packets via tcpdump into a file and open this pcap later in > wireshark. Wireshark should give you a good visualization of the traffic > distribution. > Or maybe you already did this without further conclusions? Yeah, this is actually what I did: record with tcpdump, than open the files in

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>

Hallo Maximilian, Am Thu, 19 Mar 2020 16:31:57 +0100 schrieb Maximilian Stein <m at steiny.biz>: > There I learned the basic patterns of these situations (communication with > many peers on ethernet but nearly nothing on the virtual tinc link). Did you really try the nice visualizations in the "Statistics" menu? These should allow you to see, which protocols and which

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

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

Hallo, Am Thu, 19 Mar 2020 16:31:57 +0100 schrieb Maximilian Stein <m at steiny.biz>: > Do you have any idea about how to analyze the situation further? Or > about the actual reasons behind the issue? you could write the packets via tcpdump into a file and open this pcap later in wireshark. Wireshark should give you a good visualization of the traffic distribution. Or maybe you

Hello Maximilian, I think may be cause by MTU proble if you have many peer. you can run tincd with -d 5 or tincd -n "yournetname" -k INT , check the log file to see what happen. if so, you can use my patch to fix this. thanks PHB On Sat, Mar 21, 2020 at 7:00 PM <tinc-request at tinc-vpn.org> wrote: > Send tinc mailing list submissions to > tinc at tinc-vpn.org

I tried to close everything I had open and filter as best as I could.. but left random lines in just in case it helps. 172.16.5.230 is my local machine and *.33.235 is the server. This is a slow save.. 13:48:39.852340 (60) 001F5B35DB28 Broadcast UDP - Other Ports 172.16.5.93 172.16.5.255 00:04:53.922946 293.922946 13:48:39.852605 (60) 001F5B35DB28 USC-IANA

Hi, I am using dovecot: 1.0.rc15 I was upgrading Debian and installed new versions of lots of things. My mail came fine and I though there was not problem until a user called and said it was not working through webmail. I tried, it it worked fine and I realized the problem was with dovecot. I have created new users, tried different UIDs. Removed any protections but when I telnet to the

greetings All, I have been reading over the Tinc manual and have become very interested in the "4.2 Multiple Networks" section of the manual. In particular, I am wondering if I read this correctly in that by using: `-n, --net=netname' Use configuration for net netname. then I can have multiple daemons running on the same machine. If I have 3 machines A, B, and C with A being

http://bugzilla.netfilter.org/show_bug.cgi?id=795 Summary: RELATED doesn't accommodate multicast UDP solicitation resulting in unicast reply Product: netfilter/iptables Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component:

Hello, I am attempting to run tinc on a raspberry pi (version 1 B HW, 512mb ram). Tinc starts, but then the tinc daemon crashes. # cat /etc/issue Raspbian GNU/Linux 7 \n \l # cat /etc/debian_version 7.8 $ apt-cache showpkg tinc Package: tinc Versions: 1.0.19-3 (/var/lib/apt/lists/mirrordirector.raspbian.org_raspbian_dists_wheezy_main_binary-armhf_Packages) Description Language:

I suspect your /64.. try giving a single address to two seperate machine so one single addresses for each. /32 . Then check your traffic. Tinc is a mesh network. If you give it millions of addresses. Then its probably checking each one. On Thu, May 2, 2019, 2:06 PM Christopher Klinge <Christ.Klinge at web.de> wrote: > Good evening, > > all of my servers where set up fresh with no

Sound like your tincs are talking to each other over and over. Can we get some info from tinc.conf and tinc host files.. need to see some ip address configs for tinc. On Wed, May 1, 2019, 10:46 AM Christopher Klinge <Christ.Klinge at web.de> wrote: > Hi everyone, > > I am new to using tinc and currently trying to set up a full IPv6 mesh > between 4 servers of mine. Setting it

You could always run a wireshark on the line and watch the traffic directly. On Thu, May 2, 2019, 3:48 PM Christopher Klinge <Christ.Klinge at web.de> wrote: > I will test this ASAP, but can you elaborate as to why this would happen? > If there is no payload traffic in the VPN, there should be no reason to > query for IP addresses. And if tinc switches do query for addresses

Hi, I'm seeing periodic packet loss with tinc (1.0.16). I have 'ReplayWindow = 0' in config, and ping between the hosts is perfect. I suspect the packets are identified and then dropped by the Great Firewall. My question is: can it be identified by DPI? If yes, how should I improve tinc to avoid this? Thanks in advance. Roger -------------- next part -------------- An HTML

Hi, I'm seeing periodic packet loss with tinc (1.0.16). I have 'ReplayWindow = 0' in config, and ping between the hosts is perfect. I suspect the packets are identified and then dropped by the Great Firewall. My question is: can it be identified by DPI? If yes, how should I improve tinc to avoid this? Thanks in advance. Roger -------------- next part -------------- An HTML