Re: kern/56346: Listening socket instantly closes if TCP_KEEPALIVE options are set on the server side

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/56346; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56346: Listening socket instantly closes if TCP_KEEPALIVE options are set on the server side
Date: Mon, 02 Aug 2021 22:32:26 +0700

     Date:        Mon,  2 Aug 2021 07:55:01 +0000 (UTC)
     From:        szilard.parrag%gmail.com@localhost
     Message-ID:  <20210802075501.0B90F1A923B%mollari.NetBSD.org@localhost>
 
 
 For accept() POSIX is going to say:
 	It is implementation-defined which socket options, if any, on
 	the accepted socket will have a default value determined by a
 	value previously customized by setsockopt( ) on socket, rather than
 	the default value used for other new sockets.
 
 [...]
 
 APPLICATION USAGE
 [...]
             Many socket options are described as having implementation-defined
 	    default values, which may differ according to the protocol in use
 	    by the socket. Existing practice differs on whether socket options
 	    such as SO_SNDBUF that were customized on the original listening
 	    socket will impact the corresponding option on the newly returned
 	    socket. Implementations are permitted to allow inheritance of
 	    customized settings where it makes sense, although the most portable
 	    approach for applications is to limit setsockopt( ) customizations
 	    to only the accepted socket.
 
 ... in the next version.   The current standard just says "a new socket..."
 with no option inheritance at all, I believe the change was made to allow
 what linux does to be acceptable ... but code that takes advantage of that
 is not portable, and cannot be expected to work on different systems
 (what "implementation-defined" means).
 
 But that's not the ultimate cause of the problem, of setsockopt() POSIX
 says:
 	The setsockopt( ) function shall set the option specified by the
 	option_name argument, at the protocol level specified by the level
 	argument, to the value pointed to by the option_value argument for
 	the socket associated with the file descriptor specified by the
 	socket argument.
 
 If you turn on keepalive on a listening socket (an insane thing to do)
 that option applies to that socket (and is allowed to be inherited by
 accept()'d sockets, though that's not guaranteed).   But unless something
 is replying to the keepalive packets on the listening socket (and what could
 that possibly be, it is not connected anywhere) that socket will be shut
 down just as any other socket which fails to successfully keepalive.
 
 That's what is happening to your test program.
 
 If linux is not doing that it is broken.
 
 There is no bug here, nothing to fix (except the code assuming this behaviour).
 
 kre
 
 ps: it does not close "instantly", it closes after the keepalive fails, which
 for me typically takes 0.5 seconds for that test program.   All the sockets
 here are "server side", the client would be the code that connects to port
 4442, and there's none of that here.