tinc - Nov 2018 - tinc disconnects

Hi,

I am trying tinc using the versions found in ubuntu bionic and debian stretch.  
To begin, I am trying to get two test machines, both of which are on the same 
subnet in the same office, in a vpn with tinc.

Unfortunately, I am encountering issues. Tinc seems to start properly, but every
few hours it disconnects.


The following happens:

In the system log of host A I get:

Metadata socket read error for <host B> Connection reset by peer

After that, it looks like tinc periodically tries to reconnect. However, it 
fails and on the system logs it produces entries like

Error looking up <host B> port 655: System error

this goes on every few minutes. Note that the host B is perfectly resolvable by 
the nameserver and perfectly contactable via ping.

At the same time in the system log of host B I just see a couple of lineswith

<host A> didn't respond to PING in 5 seconds
Closing connection with <host A>

If I restart tinc on host A at this point, it reconnects perfectly and itkeepw 
working for some time.

System A is ubuntu bionic, with tinc 1.0.33

System B is debian stretch with tinc 1.0.31

On both systems, tinc is run in a chroot as debian derivatives suggest.

What can the problem be? Is there anything I can try for a diagnosis?

Thanks

Sergio

On Mon, Nov 12, 2018 at 1:17 AM Sergio Callegari
<sergio.callegari at gmail.com> wrote:
> Error looking up <host B> port 655: System error
>
> this goes on every few minutes. Note that the host B is perfectly
resolvable by
> the nameserver and perfectly contactable via ping.
> On both systems, tinc is run in a chroot as debian derivatives suggest.
Do programs running inside the chroot environment know how to contact
the nameservers?
> What can the problem be? Is there anything I can try for a diagnosis?
Replace host names with IP addresses and see what happens?

-Parke

On 13/11/18 00:35, Parke wrote:
> On Mon, Nov 12, 2018 at 1:17 AM Sergio Callegari
> <sergio.callegari at gmail.com> wrote:
>> Error looking up <host B> port 655: System error
>>
>> this goes on every few minutes. Note that the host B is perfectly
resolvable by
>> the nameserver and perfectly contactable via ping.
>> On both systems, tinc is run in a chroot as debian derivatives suggest.
> Do programs running inside the chroot environment know how to contact
> the nameservers?
Looks like they do, otherwise I guess that they would not be able to set upthe 
tinc VPN from the beginning. However, I have noticed that the mechanism forthe 
dns queries in the system is not as simple as it used to be. I have a systemd 
resolved daemon in the middle that is said to do caching. I am now wondering if 
the resolution from the chroot may be influenced by this (e.g. succeed in case 
the name is hit in the cache, fail in some other case). I am not sure of how 
this hypothesis can be tested.
>
>> What can the problem be? Is there anything I can try for a diagnosis?
> Replace host names with IP addresses and see what happens?
I will try this.  Thanks,

Sergio