[CFR] Fix sockstat's handling of closed connections

[Andre Oppermann]

Peter Pentchev wrote:
> 
> 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:

This has got me freaked out more than once alreay but I never found
time to look into it.  Good catch!

> [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 :)

The fix looks good to me.  It seems small enough so I think I can give
you the direct go-ahead to commit it.  Could you also put a comment into
the sockstat man page describing that TCP connections in TIME_WAIT state
can be looked up with netstat?

-- 
Andre


> 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
> 
>   --------------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature