Re: "snaplen of 0" when reading pcap-ng data

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

On Apr 25, 2012, at 5:12 PM, Andrew Daviel wrote:

> I just built libpcap-1.2.1 and tcpdump-4.2.1 on Centos 6.2.
>
> If I read a pcap-ng capture file from the Hone project, or one written by Wireshark 1.7.2 on XP with the default 
> filter, I get a message "snaplen of 0 rejects all packets" and tcpdump displays no  packets.
>
> If I capture data with Wireshark with a maximum packet length of 65535, or shorter, and save it as pcapng, I can read 
> it in tcpdump.
>
> I can't capture data from Hone, even with -s (tcpdump -r /dev/hone -s 500)
> and I can't build a Wireshark that supports pcapng on RHEL 6 (glib in latest release is too old)
>
> Is there a way around this problem ?

There are multiple problems here:

        1) the pcap-ng spec:

                http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionidb

           neither says that the snapshot length field in an Interface Description Block must be non-zero nor what 
should be done if you don't have a snapshot length ("TODO: Is there a need to signal "no limit"?")

        2) honeevent.c in Hone:

                https://github.com/HoneProject/Linux-Sensor

           is defaulting to a snapshot length of 0, meaning "no snapshot length", and writing that out in the Interface 
Description Block;

        3) Wireshark 1.7.2 appears to be writing out capture files with a snapshot length of 0 in the Interface 
Description Block, at least with the default snapshot length setting (the filter is irrelevant here);

        4) libpcap is not accepting 0 as meaning "no snapshot length" in several places, including the BPF compiler 
(where it should presumably make 2^32-1 be the return value of the RET instruction - 0 in the RET instruction means 
"reject the packet", hence the warning from tcpdump) *AND* in the savefile reading code (which allocates a buffer big 
enough for the specified snapshot length; it'd need to pick some appropriate size initially, and grow the buffer if a 
larger packet size is seen).

The right long-term fix is probably to:

        have libpcap treat the snapshot length as a hint, and grow the buffer as necessary - this will also be 
necessary when APIs to fully support pcap-NG are added, as there might be different Interface Description Blocks in a 
file, with different snapshot lengths, and an IDB could appear *after* packets are seen (obviously not an IDB for those 
packets, but for an additional interface);

        have the specs for both pcap and pcap-ng say that the snapshot length can, in theory, be zero, but that this 
isn't recommended, as older versions of libpcap will not be able to handle it;

        fix Wireshark to make sure it supplies a non-zero value in the Interface Description Block for all interfaces.

A short-term workaround might be to run the file through Wireshark's editcap utility, with "-s 65535"; that might 
forcibly set the snapshot length in the IDBs to 65535, in which case libpcap (1.1.0 or later, as that's when pcap-ng 
support was added) should be able to read them.  (You'll lose the Hone-specific pcap-ng extensions, as Wireshark's 
Wiretap capture-file-reading library currently doesn't know about them and currently doesn't offer APIs that let 
applications pass unknown pcap-ng blocks through to an output file, but tcpdump would ignore them anyway, as libpcap 
also doesn't know about them.)-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.