Date: Tue, 20 Jan 1998 12:07:33 -0500 (EST) From: parris@cs.unc.edu To: FreeBSD-gnats-submit@FreeBSD.ORG Cc: parris@topsecret.cs.unc.edu Subject: kern/5532: Dropped packet counts inaccurate Message-ID: <199801201707.MAA26308@topsecret.cs.unc.edu>
next in thread | raw e-mail | index | archive | help
>Number: 5532
>Category: kern
>Synopsis: Dropped packet counts are inaccurate (drops are not recorded.)
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Jan 20 09:20:00 PST 1998
>Last-Modified:
>Originator: Mark Parris
>Organization:
University of North Carolina
>Release: FreeBSD 2.2.2-RELEASE i386
>Environment:
FreeBSD 2.2.2-RELEASE #12: Mon Jan 19 16:24:11 EST 1998
parris@topsecret.cs.unc.edu:/usr/home/parris/src/work/sys/compile/CS
CPU: Pentium Pro (199.43-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x619 Stepping=9
Features=0xf9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,<b11>,MTRR,PGE,MCA,CMOV>
>Description:
Packets are dropped in ip_output but their drops are not recorded in
the ipstat.ips_odropped field or ifq_dropped field of the ifq
structure. This occurs in sys/netinet/ip_output.c. The lines follow:
/*
* Verify that we have any chance at all of being able to queue
* the packet or packet fragments
*/
if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >=
ifp->if_snd.ifq_maxlen) {
error = ENOBUFS;
goto bad;
}
The result is that although many packets can be dropped when the interface queue is full (or nearly full), these drops are unrecorded.
As a result, commands like 'netstat -i -w 1 -d' and 'netstat -p ip'
erroneously report low dropped packet counts. I have not been able
to confirm that this bug causes all drops to go unrecorded but I have
never seen a dropped packet recorded. (My research involves
generating congestion to force queues to build up on routers so I
should be seeing a lot of drops.
>How-To-Repeat:
Generate enough congestion on the outbound side of the device to force
a queue to build up and send a datastream through the router. Note
that 'netstat -i -w 1 -d' reports on drops even though the data stream
is experiencing loss.
>Fix:
I added a new variable, int frag_count in ip_output and modified
the lines in sys/net/ip_output.c above to look like this:
/*
* Verify that we have any chance at all of being able to queue
* the packet or packet fragments
*/
if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >=
ifp->if_snd.ifq_maxlen) {
/* Record the drop of the packet. */
s = splimp();
for ( frag_count = 0; frag_count < ip->ip_len / ifp->if_mtu + 1; frag_count ++ ) {
IF_DROP(&(ifp->if_snd)); /* MAP 1-19-98 */
}
splx(s);
ipstat.ips_odropped++;
error = ENOBUFS;
goto bad;
}
I imagine I should only be doing one or the other of IF_DROP or
incrementing ipstat.ips_odropped; but I wasn't sure which one since
if this short-circuit weren't here the code would be fragmented and
dropped.
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801201707.MAA26308>