<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-02-12 11:52 GMT-05:00 Michal Trojnara <span dir="ltr"><<a href="mailto:Michal.Trojnara@stunnel.org" target="_blank">Michal.Trojnara@stunnel.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<span class=""><br>
On 11.02.2016 21:10, Philippe Anctil wrote:<br>
> My test is simple. I try to establish 10 connections at 1 second<br>
> interval. At the same time, I generate a lot of sighup signals.<br>
<br>
</span>I presume you were only sending the signals to the main process.  Right?<br></blockquote><div><br></div><div>Correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> At least one connection fails every time. 30 2016-02-10<br>
<span class="">> 12:07:14.305001 0.000014    142.168.66.111 142.168.148.114<br>
> TCP      66     4443→56572 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0<br>
> MSS=1460 SACK_PERM=1 WS=128 31 2016-02-10 12:07:14.312908 0.007907<br>
> 142.168.148.114 142.168.66.111        TCP      60     56572→4443<br>
> [ACK] Seq=1 Ack=1 Win=66560 Len=0 32 2016-02-10 12:07:14.312918<br>
> 0.000010    142.168.66.111 142.168.148.114       TCP      54<br>
> 4443→56572 [RST] Seq=1 Win=0 Len=0<br>
<br>
</span>So it sends RST 0.01ms after it received the final ACK of the TCP<br>
handshake.  My theory is that it is caused by the listening socket<br>
being momentarily closed in the middle of the TCP handshake, i.e.,<br>
before the kernel informs the userspace (stunnel in this case) about<br>
the newly established TCP connection.<br></blockquote><div><br></div><div>I think you are right.  </div><div><br></div><div>I thought the tcp connection was established during the call to accept(). Because of this I concentrated my research around that call and I simply could not understand why none of the traces put around it were triggered.</div><div><br></div><div>Well, that's because the situation is happening when the program loops somewhere else, most likely in daemon_loop. For instance, after receiving a signal or after accepting one connection. Because the socket is still listening, the OS lets a new tcp connection come in. If a sighup signal is about to be pulled from signal_pipe, it is entirely possible the socket gets closed right after the new tcp connection is established and before it can be accept()ed by the program. The socket is closed without checking if there are pending connections. And so there can't be any indication of that in the log. </div><div><br></div><div>Note I am not making any claim that situation could or should be detected. I was mostly interested in understanding . </div><div><br></div><div>Thanks for your input!  </div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Philippe Anctil</div></div>
</div></div>