Re: "File has packet larger than file's snapshot length." warnings

[Guy Harris <guy () alum mit edu>]

On Jul 10, 2013, at 10:09 AM, "Turney, Cal" <cal.turney () emc com> wrote:

> The patch for Bug 8808 causes a console warning to be displayed if the snaplen (wth->snapshot_length) in the global 
> header of the capture file does not match the packet size (hdr->hdr.incl_len).  We are seeing thousands of "File has 
> packet larger than file's snapshot length." warnings because of a bug in our company's hybrid tcpdump app used for 
> capturing traffic directly on the customer's NAS equipment.  The snaplen option of the app is functional but it 
> hard-codes a snaplen of 1516 in the global header.

So is this on non-Ethernet hardware that has a maximum packet length > 1516, is it on Ethernet hardware doing jumbo 
frames, or is it on Ethernet hardware where the captured data includes the FCS (hence 1518 bytes)?

>  This bug has been around for at least five years and possibly forever. 
>  
> Just curious.  Does anyone know of an app that uses or pays attention to the global snaplen value?  Wireshark prior 
> to r49999, UN!X tcpdump, and MS Netmon do not.

tcpdump/WinDump use libpcap/WinPcap to read capture files, and the pcap-reading code in libpcap/WinPcap does some hacks 
to work around an old ("old" as in "2.3") Solaris bug and ends up throwing out whatever packet data goes past the 
global snaplen.

There might also be other libpcap/WinPcap-based applications that take the snaplen seriously and allocate buffers of 
that length and don't just treat the snaplen as a hint and grow the buffer as needed (hopefully, they don't do 
something careless such as *assuming* no packet will be bigger than that, and, instead, either report an error).

> The bug in our code will be fixed but our customers are very slow to upgrade their software so we will continue to 
> see these warnings for at least two years.  Would anyone object to my adding an option in Preferences>Protocols>Frame 
> to ignore these mismatches but set the default to NOT ignore them?        

Well, libwiretap doesn't bother trying to deal with the Solaris 2.3 bug in question, so I'm not sure there's any harm 
in not bothering to report the problem and just returning the entire packet.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe