From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:19:33 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 897B1E7; Mon, 27 Apr 2015 16:19:33 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B1EC19D8; Mon, 27 Apr 2015 16:19:33 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 7DAE3104837; Mon, 27 Apr 2015 09:19:32 -0700 (PDT) Date: Mon, 27 Apr 2015 09:19:32 -0700 From: hiren panchasara To: Adrian Chadd Cc: FreeBSD Net , Jason Wolfe , alfred@FreeBSD.org Subject: Re: Idle connections via accept_filter(9) Message-ID: <20150427161932.GW28632@strugglingcoder.info> References: <20150410040834.GG61327@strugglingcoder.info> <20150427092236.GV28632@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="63tCqOYFH7xKgZE5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:19:33 -0000 --63tCqOYFH7xKgZE5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/27/15 at 09:10P, Adrian Chadd wrote: > ask alfred? :) Thanks! CCing him. >=20 >=20 > -a >=20 >=20 > On 27 April 2015 at 02:22, hiren panchasara = wrote: > > Wanted to see if someone with understanding of accept_filter can > > comment. > > > > cheers, > > Hiren > > On 04/09/15 at 09:08P, hiren panchasara wrote: > >> If a connections comes on a socket with accf_data(9) (for example) but > >> never sends any data, it'll occupy resources via staying forever in > >> listen queue of partial unaccepted connections (socket->so_incomp) whi= ch > >> can be seen as incqlen in 'netstat -Lan'. > >> Kernel will never pass this connection down to the application as > >> the filter criteria hasn't been met (no data) and application > >> would never know about this connection. > >> > >> What I am not sure is what would be the state of the connection > >> and state of the socket when in this situation. We do come here after > >> finishing 3WHS but before handing this over to the application i.e. > >> before the accept(). > >> > >> From uipc_socket.c: > >> > >> * From the passive side, a socket is created with two queues of socke= ts: > >> * so_incomp for connections in progress and so_comp for connections a= lready > >> * made and awaiting user acceptance. As a protocol is preparing inco= ming > >> * connections, it creates a socket structure queued on so_incomp by c= alling > >> * sonewconn(). When the connection is established, soisconnected() is > >> * called, and transfers the socket structure to so_comp, making it av= ailable > >> * to accept(). > >> > >> So, it looks like the connection would be in ESTABLISHED state but > >> socket would be stuck in the so_incomp queue. Other than this special > >> condition of accpet_filter, can such a situation occur? > >> > >> Any insight/help into understanding this scenario and a way to cleanup > >> these connections would be great. > >> > >> (I know tcp doesn't care/worry about idle sitting connections; we have > >> keepalives to check the health of the connection but that's it, afaik) > >> > >> Cheers, > >> Hiren > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --63tCqOYFH7xKgZE5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVPmGUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/luncH/iEfBcL0GJ1DgC/mUnYeyLys FX/fSLs+SGE/BxXxRbg9kAg5om1QwtbyDMP2/RIfU6OmyXKS/DwxlpL2G46hlhCr 3P9kgOuJbcQI9ivIoozbN2fCSHWFiEClAJMlb8QjEIgqrr7rjDQ5Q/UZJle7WywY 7L1PYTfPg0AnN5Cl7X8kbrs3xeQdNfhGlJFqMMNdnFRLWFJakNWg8OrxL/WHGcQj EoLglgxIkhxMNFnG40lgLSA3OetIIAGoUBZGhinR0qjCopHrg+ATZzwMCvg2vJTP dY8uvEKJ41u7m7rFlx0f4soU6El2FzIPzfai7z6DWhXvlZ8tOEzvn32cMJVy7NE= =HJ12 -----END PGP SIGNATURE----- --63tCqOYFH7xKgZE5--