Skip to content

Commit dc95138

Browse files
committed
Add the dropped packet count to the received packet count, so that the
counts work similarly to the way they work in BPF and 2.4 and later Linux (and so that we don't run the risk of the dropped packet count being bigger than the received packet count, which can result in dropped packet percentages > 100).
1 parent e00313a commit dc95138

File tree

1 file changed

+22
-9
lines changed

1 file changed

+22
-9
lines changed

pcap-dlpi.c

+22-9
Original file line numberDiff line numberDiff line change
@@ -62,7 +62,7 @@
6262

6363
#ifndef lint
6464
static const char rcsid[] _U_ =
65-
"@(#) $Header: /tcpdump/master/libpcap/pcap-dlpi.c,v 1.102 2004-04-23 05:19:04 guy Exp $ (LBL)";
65+
"@(#) $Header: /tcpdump/master/libpcap/pcap-dlpi.c,v 1.103 2004-05-21 09:22:16 guy Exp $ (LBL)";
6666
#endif
6767

6868
#ifdef HAVE_CONFIG_H
@@ -186,15 +186,19 @@ pcap_stats_dlpi(pcap_t *p, struct pcap_stat *ps)
186186
/*
187187
* "ps_recv" counts packets handed to the filter, not packets
188188
* that passed the filter. As filtering is done in userland,
189-
* this does not include packets dropped because we ran out
190-
* of buffer space.
189+
* this would not include packets dropped because we ran out
190+
* of buffer space; in order to make this more like other
191+
* platforms (and to keep from confusing applications that,
192+
* for example, compute packet drop percentages), we also make it
193+
* count packets dropped by "bufmod" (otherwise we might run
194+
* the risk of the packet drop count being bigger than the
195+
* received-packet count).
191196
*
192-
* "ps_drop" counts packets dropped inside the DLPI service
193-
* provider device device because of flow control requirements
194-
* or resource exhaustion; it doesn't count packets dropped by
195-
* the interface driver, or packets dropped upstream. As
196-
* filtering is done in userland, it counts packets regardless
197-
* of whether they would've passed the filter.
197+
* "ps_drop" counts packets dropped by "bufmod" because of
198+
* flow control requirements or resource exhaustion; it doesn't
199+
* count packets dropped by the interface driver, or packets
200+
* dropped upstream. As filtering is done in userland, it counts
201+
* packets regardless of whether they would've passed the filter.
198202
*
199203
* These statistics don't include packets not yet read from
200204
* the kernel by libpcap, but they may include packets not
@@ -307,6 +311,15 @@ pcap_read_dlpi(pcap_t *p, int cnt, pcap_handler callback, u_char *user)
307311
#endif
308312
sbp = (struct sb_hdr *)bp;
309313
p->md.stat.ps_drop = sbp->sbh_drops;
314+
/*
315+
* On at least some other platforms (Linux 2.4 and later,
316+
* BSDs with BPF), "ps_recv" counts packets that were
317+
* received but dropped due to running out of buffer
318+
* space; we do that here, so that applications that
319+
* compute packet drop percentages don't see more packets
320+
* dropped than received.
321+
*/
322+
p->md.stat.ps_recv += sbp->sbh_drops;
310323
pk = bp + sizeof(*sbp);
311324
bp += sbp->sbh_totlen;
312325
origlen = sbp->sbh_origlen;

0 commit comments

Comments
 (0)