[stunnel-users] Effect of SIGHUP on connections

Sat Feb 13 12:17:18 CET 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12.02.2016 23:39, Philippe Anctil wrote:
> Well, that's because the situation is happening when the program
> loops somewhere else, most likely in daemon_loop.

This is not how BSD sockets work.  The interface between applications
and the kernel resembles function calls, but kernel is nothing like a
library.  When you call listen(2), the TCP state machine in the kernel
starts accepting new connections.  The kernel keeps an internal
backlog queue of the *successfully established connections*.  The size
of this queue is specified as the second parameter of listen(2).  A
file descriptor of a newly established connection can then be read
from the backlog queue with accept(2).  The simplest way to wait for a
new connection is to execute a blocking accept(2).  This is however
*not* the way stunnel does it.  Instead, stunnel awaits incoming
connections on multiple accepting sockets using poll(2), and only then
it retrieves the file descriptors of the newly established connections.

Normally, accepting a new connection works as follows:
(initial connection state: closed)
 - The kernel receives a SYN packet.
 - The kernel sends the SYN+ACK reply.
(new connection state: half-open)
 - The kernel receives the final ACK packet.
(new connection state: open)
 - The kernel signals that a new connection is available on the
listening socket.
 - stunnel function poll(2) returns indicating a new open connection.
 - stunnel retrieves the file descriptor with accept(2).

In your case:
(initial connection state: closed)
 - The kernel receives a SYN packet.
 - The kernel sends the SYN+ACK reply.
(new connection state: half-open)
 - stunnel closes the listening socket, invalidating any half-open
connections.
(new connection state: closed)
 - The kernel receives the final ACK packet.
 - The kernel sends back RST, because the ACK packet does not match
any connection known to the kernel's TCP state machine.

I guess the part that confused you is that the server's TCP handshake
is only complete after *receiving* the final ACK, while the client's
TCP handshake is complete after *sending* the final ACK.
Consequently, while your client reports the connection as opened and
quickly reset, the server's connection is never opened (the server's
handshake is never completed).

Best regards,
	Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJWvxC+AAoJEC78f/DUFuAUKM4P/3T6AcvF8JXRoVU+qqHWVPao
kxvnn5toZaut3TMWI/4YAUnLVj7AYV9OWlIkaD8C2pHhPse+4E969WJK0j5gX7gT
fK51K1lclemhK6CAOW2cD9my+Ek1jcT0Xw+/mMOuj5m6oWKZuuvQrJ0SWRLCYAY+
TnaiOGr1SNwZN39+KLw6Kg0mupWYI0rvKQ4ChG7HqECVL7ARWzD3mEBrAoJPnH1s
cx+PNLV1B/uioDn0YT0q64TkUxKuJ4wiHQZ7HPDkKa7dk+pWTzJsV6PFB0F31i7V
0USpJ7OLH9NbFZQ209w8qf7wGibSlWyQ+TyNmgqGn8wYuuPLsnpbAGynb6XVp1F8
a/QMPt/PaL8843OT9DUsuwue7Qr+lWxH3tBA5c8r/+YadQUQtZaf1mSt1Xs8bmbh
vth71M3wR3i4/45xmSX3uOaoZkfWcjTYXvBR8slcb8Ns5QKmO/SKZ6/+PfffsxoW
DSMlKLqm1XsijR5vqjJp2JYueISUF9yRI1DTAp9KE6RGR/a6PCVwH378V3I+3Sne
BqTveH4fgrpveRBvbhRvNyPMXS9a3yeG6tJciknk3MzNFaVbzpOtbcL0kxUfipo/
+7VpyyQIHmbudX34s3f+i7jGYKUv14fuaAI8YmxYqmi5Tdh8F+NKSCwoFvHXMaR/
agqhp6AG/JN7JWqdVp/A
=wr9v
-----END PGP SIGNATURE-----