Wireshark · Ethereal-users: RE: FW: [Ethereal-users] How to identify a runt and its source

["Johnson, Edward" <edward.johnson@xxxxxxxxxxxxxx>]

Errored packets are dropped by the NIC at the MAC layer therefore layers
above never see them unless the NIC has been specifically instructed by the
driver to pass them up.

Edward Johnson CNX #1064
WAN Engineer
Capital One
phone	804-934-7237
page	888-825-2751
cell	804-363-3150


-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxx]
Sent: Wednesday, February 21, 2001 2:52 PM
To: David Edward Shapiro
Cc: 'ethereal-users@xxxxxxxxxxxx'
Subject: Re: FW: [Ethereal-users] How to identify a runt and its source


> Well, it is as I suspected.  snoop will tell you you have dropped packets,
> but it will not show you the dropped packets, which means I have no idea
> where they came from.  Can ethereal help here?

Unlikely - the reason why snoop doesn't show you the dropped packets is
probably that they're, err, umm, dropped, i.e. the networking code drops
them before it gives them to snoop - and tcpdump and Ethereal use the
exact same networking mechanism snoop does to get packets, so they can't
see the dropped packets, either.

Note also that the dropped-packet information reported by snoop may well
be the number of packets dropped by the bufmod STREAMS module "due to
flow control or resource exhaustion", as per the bufmod(7) man page:

     Afterwards, if SB_NO_HEADER is not set,  bufmod  prepends  a
     header  to the converted message.  This header is defined as
     follows.

          struct sb_hdr {
               u_int     sbh_origlen;
               u_int     sbh_msglen;
               u_int     sbh_totlen;
               u_int     sbh_drops;
               struct    timeval   sbh_timestamp;
          };
     The sbh_origlen field gives the  message's  original  length
     before  truncation in bytes.  The sbh_msglen field gives the
     length in bytes of the message after the truncation has been
     done.  sbh_totlen gives the distance in bytes from the start
     of the truncated message in  the  current  chunk  (described
     below)  to  the  start of the next message in the chunk; the
     value reflects any padding necessary to insure correct  data
     alignment  for  the  host machine and includes the length of
     the header itself.  sbh_drops reports the cumulative  number
     of  input  messages that this instance of bufmod has dropped
     due to flow control or resource exhaustion.  In the  current
     implementation  message  dropping  due  to  flow control can
     occur only if the SB_NO_DROPS flag is not set.  (Note:  this
     accounts  only  for events occurring within bufmod, and does
     not count messages dropped  by  downstream  or  by  upstream
     modules.)   The  sbh_timestamp  field  contains  the message
     arrival time expressed as a struct timeval.

The astute reader will note a startling resemblance between the "struct
sb_hdr" data structure and the header of a packet record in RFC 1761,
"Snoop Version 2 Packet Capture File Format"; I rather doubt this
resemblance is coincidental. :-)

I.e., I suspect what snoop reports as drops come from the "sbh_drops"
field in the bufmod header, which are packets dropped by bufmod itself;
it is, I suspect, not even notified if the network card driver drops a
packet - or if the network card drops the packet itself - and that's
where runts would be dropped.

So you're out of luck, unless there's some option in the driver to set
to pass runts packets up from the driver (and, if necessary, to tell the
network card itself not to drop them); I have no idea whether such an
option exists, nor do I know how you'd find out whether such an option
exists or how to enable it.

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
 
**************************************************************************
The Information transmitted herewith is sensitive information intended only
for use to the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.