Suspicious code in net_socket.c

[Roman S]

For my opinion, special function not needed, because at first time, oai set
to NULL, freeaddrinfo tried to free each ai, until occurance of ai_next ==
NULL.

But it works. Linux, Windows, coordinator with white IP, other nodes behind
NAT's (1 or two NAT's, only direct connections allowed).

There are some problems with MinGW make, at least - mingw-64 from Fedora 25.

1. No definition for ETH_HLEN and ETHER_TYPE_LEN (fd_device.c)
2. no "kill" function in mingw (tincctl.c)
3. curses and readline from Fedora's mingw not directly compatible with tinc
configuration scripts - i want ti check it in some days and put patch to
.spec 

For now I use dirty hacks to work around problems.

For now:
Packages for Fedora 25, Centos 7,  RHEL  and windows built and run.
I want to leave it for 72 hour with increased debug level and check
logs/journals after it.
--
Rgds!
Roman Savelyev

-----Original Message-----
From: tinc-devel [mailto:tinc-devel-bounces на tinc-vpn.org] On Behalf Of Guus
Sliepen
Sent: Tuesday, March 7, 2017 9:24 PM
To: tinc-devel на tinc-vpn.org
Subject: Re: Suspicious code in net_socket.c

On Mon, Mar 06, 2017 at 01:00:45PM +0300, Roman S wrote:

> Module - net_socket.c
> Function - get_known_addresses
> ---------------------------------------------------
> struct addrinfo *nai = xzalloc(sizeof *nai);
> if(ai)
>       ai->ai_next = nai;
> ai = nai;
> --------------------------------------------------
> For my opinion, possible causes:
> 1. Lost trails (ai_next)
> 2. ai_next not initialized
> 3. Possible segfault during "freeaddrinfo" call in 
> do_outgoing_connections

You are right about 1 and 3. I applied your patch, which fixes 1, and I
added a free_known_addresses() function to clean up the struct addrinfo
chain that we built ourselves. Please check out the latest version of the
1.1 branch in git and check if it works for you.

--
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus на tinc-vpn.org>