netdev - Re: [PATCH v2 net-next] tcp: introduce a new MIB for CLOSE-WAIT sockets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 29 May 2024 17:42:27 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: dsahern@...nel.org, kuba@...nel.org, pabeni@...hat.com, 
	davem@...emloft.net, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>, Yongming Liu <yomiliu@...cent.com>, 
	Wangzi Yong <curuwang@...cent.com>
Subject: Re: [PATCH v2 net-next] tcp: introduce a new MIB for CLOSE-WAIT sockets

On Wed, May 29, 2024 at 5:31 AM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> From: Jason Xing <kernelxing@...cent.com>
>
> CLOSE-WAIT is a relatively special state which "represents waiting for
> a connection termination request from the local user" (RFC 793). Some
> issues may happen because of unexpected/too many CLOSE-WAIT sockets,
> like user application mistakenly handling close() syscall. It's a very
> common issue in the real world.
>
> We want to trace this total number of CLOSE-WAIT sockets fastly and
> frequently instead of resorting to displaying them altogether by using:
>
>   ss -s state close-wait
>
> or something like this. They need to loop and collect required socket
> information in kernel and then get back to the userside for print, which
> does harm to the performance especially in heavy load for frequent
> sampling.
>
> That's the reason why I chose to introduce this new MIB counter like
> CurrEstab does. With this counter implemented, we can record/observe the
> normal changes of this counter all the time. It can help us:
> 1) We are able to be alerted in advance if the counter changes drastically.
> 2) If some users report some issues happening, we will particularly
> pay more attention to it.
>
> Besides, in the group of TCP_MIB_* defined by RFC 1213, TCP_MIB_CURRESTAB
> should include both ESTABLISHED and CLOSE-WAIT sockets in theory:
>

We (Neal and myself) prefer to fix TCP_MIB_CURRESTAB to include
CLOSE_WAIT sockets.
We do not think it will annoy anyone, please change tcp_set_state() accordingly.

Rationale is that adoption of a new MIB in documentations and various
products will take years.

Also make a similar change for mptcp.

Thank you.