[CFR] Fix sockstat's handling of closed connections

Peter Pentchev roam at ringlet.net
Wed Aug 25 08:32:41 PDT 2004


Hi,

I first came across this a couple of months ago, but today I finally
took the time to look into it.

Basically, if a program has recently closed a TCP connection or three
and they are currently in CLOSED or TIME_WAIT state, sockstat(1) will
report them as active connected sockets and link them to completely
bogus programs and file descriptors.  Here's a demonstration, taken
immediately after a completed fetchmail poll of three POP3 servers:

[roam at straylight ~/fbsd/r/src/usr.bin/sockstat]> sockstat -4c
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
www      httpd      5408  3  tcp4   217.75.134.254:58889  217.75.134.1:110
roam     ssh        939   3  tcp4   192.168.11.36:55794   192.168.9.48:22
www      httpd      604   3  tcp4   217.75.134.254:58889  217.75.134.1:110
nobody   dictd      596   26 tcp4   217.75.134.254:58889  217.75.134.1:110
qmails   tcpserver  548   0  tcp4   217.75.134.254:58889  217.75.134.1:110
[roam at straylight ~/fbsd/r/src/usr.bin/sockstat]> ./sockstat -4c
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
roam     ssh        939   3  tcp4   192.168.11.36:55794   192.168.9.48:22
[roam at straylight ~/fbsd/r/src/usr.bin/sockstat]> netstat -n | egrep '^tcp.*110'
tcp4       0      0  217.75.134.254.49857   195.24.32.2.110        TIME_WAIT
tcp4       0      0  217.75.134.254.54159   217.75.128.9.110       TIME_WAIT
tcp4       0      0  217.75.134.254.58889   217.75.134.1.110       TIME_WAIT
[roam at straylight ~/fbsd/r/src/usr.bin/sockstat]>

The first 'sockstat' run was the "real" sockstat(1) from FreeBSD
5.3-BETA1 as of today; as you can see, it reports the three TIME_WAIT
sockets as very much active and attributes them to totally unrelated
processes.  I must admit this gave me quite a scare the first time I saw
this: what in the name of $DEITY are all those servers doing opening
*outgoing* connections, or, alternatively and even worse, why are they
listening on high ports?

Luckily, the fix is simple, or at least so it seems to me.  It turns out
that those connections have a xt_socket->xso_so set to NULL, and the
false positive comes from sockstat's matching them to a similarly NULL
xf_data members of 'kern.files'.  What do people think about the
following patch?  I could commit it if nobody has any objections, but
being a ports/doc committer, I would need an explicit approval to do
that :)

G'luck,
Peter

Index: src/usr.bin/sockstat/sockstat.c
===================================================================
RCS file: /home/ncvs/src/usr.bin/sockstat/sockstat.c,v
retrieving revision 1.9
diff -u -r1.9 sockstat.c
--- src/usr.bin/sockstat/sockstat.c	19 Jul 2003 06:23:56 -0000	1.9
+++ src/usr.bin/sockstat/sockstat.c	25 Aug 2004 15:14:24 -0000
@@ -494,6 +494,8 @@
 	    "LOCAL ADDRESS", "FOREIGN ADDRESS");
 	setpassent(1);
 	for (xf = xfiles, n = 0; n < nxfiles; ++n, ++xf) {
+		if (xf->xf_data == NULL)
+			continue;
 		hash = (int)((uintptr_t)xf->xf_data % HASHSIZE);
 		for (s = sockhash[hash]; s != NULL; s = s->next)
 			if ((void *)s->socket == xf->xf_data)

-- 
Peter Pentchev	roam at ringlet.net    roam at cnsys.bg    roam at FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
.siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040825/9d82d8b2/attachment.bin


More information about the freebsd-net mailing list