From owner-freebsd-bugs@FreeBSD.ORG  Fri Apr 27 01:50:09 2007
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
X-Original-To: freebsd-bugs@hub.freebsd.org
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 26A0216A400
	for <freebsd-bugs@hub.freebsd.org>;
	Fri, 27 Apr 2007 01:50:09 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40])
	by mx1.freebsd.org (Postfix) with ESMTP id BE6E813C45B
	for <freebsd-bugs@hub.freebsd.org>;
	Fri, 27 Apr 2007 01:50:08 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1])
	by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3R1o8dh093317
	for <freebsd-bugs@freefall.freebsd.org>; Fri, 27 Apr 2007 01:50:08 GMT
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3R1o84W093316;
	Fri, 27 Apr 2007 01:50:08 GMT (envelope-from gnats)
Date: Fri, 27 Apr 2007 01:50:08 GMT
Message-Id: <200704270150.l3R1o84W093316@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.org
From: Christoph Weber-Fahr <wefa2@gmx.de>
Cc: 
Subject: Re: bin/112126: [patch] netstat(1) segfaults on unusual ICMP
	statistics
X-BeenThere: freebsd-bugs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Christoph Weber-Fahr <wefa2@gmx.de>
List-Id: Bug reports <freebsd-bugs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2007 01:50:09 -0000

The following reply was made to PR bin/112126; it has been noted by GNATS.

From: Christoph Weber-Fahr <wefa2@gmx.de>
To: Maxim Konovalov <maxim@macomnet.ru>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/112126: [patch] netstat(1) segfaults on unusual ICMP statistics
Date: Fri, 27 Apr 2007 03:50:05 +0200

 Hello,
 
 Maxim Konovalov wrote:
 > On Thu, 26 Apr 2007, 00:00+0200, Chris wrote:
 >>> +static  const char *icmpnames[ICMP_MAXTYPE + 1] = {
 >> with this he actually avoids the crash in case of an
 >> out of sync kernel interface (assumed the array gets
 >> automatically zeroed at allocation time - does it ? )
 >>
 >> But this still produces a very funny netstat output
 >> with just numbers and no labels. I continue to prefer
 >> my suggestion.
 > 
 > I see:
 > 
 >         Output histogram:
 >                 echo reply: 41
 >                 destination unreachable: 495
 > [...]
 >         Input histogram:
 >                 echo reply: 12
 >                 destination unreachable: 1
 >                 echo: 41
 >                 #20: 7
 >                 icmp traceroute: 16
 >                 mobile registration req: 25
 >                 #37: 31
 
 Actually, you don't see that. You'd see:
 
           Input histogram:
                   echo reply: 12
                   destination unreachable: 1
                   echo: 41
                   #20: 7
                   icmp traceroute: 16
                   mobile registration req: 25
                   #37: 31
 		 8
                   15
 
 Note the last two untagged values. They
 are created when the kernel, which in
 the meantime has a ICM_MAXTYPE at, say, 49,
 has logged 8 packets of type 44, and 15 of type 47.
 
 > What is yours?
 
 My variant would produce:
 
           Input histogram:
                   echo reply: 12
                   destination unreachable: 1
                   echo: 41
                   #20: 7
                   icmp traceroute: 16
                   mobile registration req: 25
                   #37: 31
 		 unknown ICMP #44: 8
                   unknown ICMP #47: 15
 
 This is preferable because it both gives more
 information (you still get the type number) and
 doesn't break the tag: value format that many
 monitoring setups use for simple parsing.
 
 Regards
 
 Christoph Weber-Fahr