Bug 133032 - abnormal network events need to be counted (e.g., dropped UDP packets)
Summary: abnormal network events need to be counted (e.g., dropped UDP packets)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: net-tools
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vokál
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-20 23:55 UTC by Kurtis D. Rader
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-26 09:01:35 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Kurtis D. Rader 2004-09-20 23:55:12 UTC
Customer is migrating from SunOS to Linux and is concerned about the
lack of network related event counters important to their environment.
Customer is primarily concerned with lack of counters for TCP SYN
packets being dropped due to the listen queue being full and UDP
packets being dropped due to the receive queue being full.

I found that a full listen queue is counted and exported via
/proc/net/netstat but  netstat(1) does not report that metric.
Customer would like to see this metric reported by netstat(1).

Note that in general any abnormal event should be counted and that
information made available via standard tools (e.g., netstat(1)) as
well as SNMP. On DYNIX/ptx for example the following UDP related
metrics are available, many of which have no Linux analogue:

UDP Statistics (/dev/udp):
 137299446 datagrams received
         0 datagrams caused pcb cache miss
         0 datagrams dropped: packet shorter than header
         0 datagrams dropped: checksum error
         0 datagrams dropped: data len longer than packet
     44091 datagrams dropped: no local port
        80 broadcast datagrams dropped: due to no local port
         0 datagrams not delivered: input queue full
 137068521 datagrams sent

Comment 1 David Miller 2004-09-21 00:33:51 UTC
Try netstat -s, it prints out things like:

    1 times the listen queue of a socket overflowed
    1 SYNs to LISTEN sockets ignored

among others.

We report and provide every statistics required by the RFC
MIBs.  Therefore I'm closing this.


Comment 2 Kurtis D. Rader 2004-09-22 00:00:35 UTC
After looking at the source for netstat I understand why we're not
seeing this data. On my system and the system the customer looked at
the values are zero.

For the record: I consider the current behavior to be broken. The
variables with custom formatting strings are only displayed if the
value is greater than zero. In contrast to the variables without
custom formatting strings which are displayed even if the value is
zero. The current behavior is inconsistent.

Regarding the second part of my defect report. Just because something
isn't required by a RFC doesn't mean it isn't useful. But given your
response I can see there is no point in my filing a separate defect
report just for that issue.

Comment 3 Ernie Petrides 2004-09-22 02:50:25 UTC
Hello, Kurtis.  It sounds like you'd prefer that netstat displays
statistics for all fields whether or not they're non-zero.  Assuming
that's the crux of this bug report, let me reopen it and assign it
to the net-tools package maintainer.

(If DaveM thinks I'm doing the wrong thing, he can reclose this bug.)


Comment 4 Radek Vokál 2004-10-05 20:01:43 UTC
The problem of netstat -s is that the part from /proc/net/netstat is
not yet documented and that's why the format strings are missing. I
agree that displaing both files are not very good-looking.
Possibilities are either to wait for IBM from whom I've got promise to
document all these items or the drop the second part and keep just
items in which I'm 100% sure about their meaning or to add a new
option for --even_more_verbose netstat -s which will show all items in
raw form. 

Comment 5 Radek Vokál 2005-04-26 09:01:35 UTC
New statistics included in net-tools-1.60-52


Note You need to log in before you can comment on or make changes to this bug.