Idle connections via accept_filter(9)

[hiren panchasara]

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) which
> 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 sockets:
>  * so_incomp for connections in progress and so_comp for connections already
>  * made and awaiting user acceptance.  As a protocol is preparing incoming
>  * connections, it creates a socket structure queued on so_incomp by calling
>  * sonewconn().  When the connection is established, soisconnected() is
>  * called, and transfers the socket structure to so_comp, making it available
>  * 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20150427/18263002/attachment.sig>