Tinc sudden spike in traffic usage

[Naemr .]

This usualy happens if for any reason tinc releases, or loses control of,
the tun/tap interface it is trying to use.
this can be caused by many many things on debian, anything from openvpn (if
openvpn tries to use the same tun interface and fails, it will actually
uncreate it and recreate it to try to "fix" it)
to tinc being restarted and not cleaning up entirely before coming back up
again.

One thing that can solve this issue, is to use the " tunctl -n -t" command
to permanently create the interface needed, tinc can easaly attach to an
existing tun interface,
ex " tunctl -n -t tun0"
note the above command makes a tun interface, in tun mode, i assume this is
desired based on your log snippet, as tinc is attempting to use the
interface in tun mode.

Another thing is any scripts you have that may be restarting tinc for any
reason. adjust them to instead stop tinc, wait 10 seconds, and then start
tinc.
when tinc comes down the tinc-down script is not the only one proccessed on
debian systems. there are many hooks in both the networking AND tun/tap
stack that come to life when tinc, or any vpn using tun/tap for that matter
spins down, and time needs to be given to accommodate those scripts in the
event one takes longer then expected.

If you have no scripts restarting tinc, I RECOMEND YOU MAKE ONE...

Tinc is great, but not perfect, and it ocasionaly needs to refresh itself.
a simple bash script to stop, wait, start, set as a daily cronjob during
times when a 10second drop of one node, staggered so each node does this at
a slightly different time, can help things run a lot smoother.

On Thu, Apr 11, 2019 at 5:11 PM Daniel Lo Nigro <lists at d.sb> wrote:

> I just encountered a weird issue on my servers - Tinc was using a constant
> 10-50% CPU on several servers, and these servers were also receiving a
> constant ~3 Mb/s of data over the Tinc interface, which is usually
> otherwise pretty quiet.
>
> Example: https://d.sb/2019/04/firefox_11-15.54.22.png
> Grafana dashboard:
> https://dash.d.sb/dashboard/snapshot/6nWZqagpgxzxUrybDZkNbF6JSflLlKmO?orgId=1
>
> This seems to have all been coming from one system, as I noticed that a
> single system was using ~18 Mb/s outbound:
> https://d.sb/2019/04/firefox_11-15.55.30.png. As soon as I restarted Tinc
> on this server, all the traffic stopped.
>
> The only relevant thing I see in the logs is a lot of these messages:
>
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
> Apr 11 15:35:20 host tinc.vpn[6223]: Can't write to Linux tun/tap device
> (tun mode) /dev/net/tun: Input/output error
>
> Any ideas what could cause this, or how to debug what Tinc was doing?
>
> Most systems are Debian Testing with Tinc 1.0.35, and one is Windows
> Server 2016 with Tinc 1.0.35.
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190415/bec651e5/attachment.html>