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