Good afternoon!
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
May be I don't understand logic?
If no misunderstandings, please, test fix before commiting.
Sorry, but I don't have enough time for complete testing, but fixed module
works well on Linux and Windows (1.14pre crashed under Windows after 1-600
sec. )
-----------------------------------
diff net_socket.c ~/tincn/tinc-1.1-7a54fe5/src/net_socket.c
573d572
< struct addrinfo *oai = NULL;
589,590c588,591
< oai=ai;
< ai = xzalloc(sizeof *ai);
---> struct addrinfo *nai = xzalloc(sizeof *nai);
> if(ai)
> ai->ai_next = nai;
> ai = nai;
597,599d597
< ai->ai_next = oai;
< }
-----------------------------------
--
Rgds!
Roman Savelyev
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_connectionsYou 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 at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20170307/1b823626/attachment.sig>
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 at tinc-vpn.org] On Behalf Of Guus Sliepen Sent: Tuesday, March 7, 2017 9:24 PM To: tinc-devel at 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_connectionsYou 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 at tinc-vpn.org>