search for: do_outgoing_connections

Hello, I noticed some random crashes after sending SIGHUP to the daemon (especially when some connections are continually failling). Playing around with gdb, it seems that after SIGHUP, all the "outgoing" information of the connections is being cleared, but later on it is being used in other places while still equal to NULL. The attached patch tries to fix this by avoiding these

...----------- 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. ) ----------------------------------- dif...

Hi, I've stumbled upon a problem which I can't solve easily with the available options in tinc - at least as far as I see. If enlightenment is all I need, I'll happily accept pointers ;) I try to establish a connection between two hosts. Each host has multiple addresses assigned to it's internet interface. A stripped down list would be: Host 1: 2001:780:0:1e::1

...oc(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 / w...

...zeof *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 / wi...

Hello, I am trying 1.1 branch and I experience a segmentation fault upon ALRM signal. This looks like a race condition. I have my tincd daemon instantiated manually in if-up.d/jmuchemb (without IF_TINC_NET) and when if-up.d/tinc runs, it sends a ALRM signal that makes tincd crash. It fails here: Core was generated by `tincd -D -n jmuchemb -d -o ConnectTo srv -o srv.Address 81.x.y.z -o

Using tincd 1.0.7, if I send a SIGALRM to tincd when a host is unresolvable, it gets stuck in a nasty loop: Feb 12 19:33:02 rosalyn tinc.slamb.org[2925]: Got ALRM signal Feb 12 19:33:02 rosalyn tinc.slamb.org[2925]: Trying to connect to calvin (216.136.66.56 port 655) Feb 12 19:33:02 rosalyn tinc.slamb.org[2925]: Error looking up slamb- linux.dyn.slamb.org port 4500: Name or service not

Hello. I found that anonymous structures does not work on gcc-2.95. If you guys want to support a bit older platforms I suggest fixing it. You can check out patch I created to fix this issue. I just added 2 extra structures to remove anonymous structs inside connection_status_t and node_status_t. Patch is here: ftp://borg.uu3.net/pub/unix/tinc/tinc.patch Attaching it as well. Regards, Borg