Wireshark-dev: Re: [Wireshark-dev] "File has packet larger than file's snapshot length." warnin
On Jul 10, 2013, at 10:09 AM, "Turney, Cal" <cal.turney@xxxxxxx> 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.
