tcpdump mailing list archives
Re: "snaplen of 0" when reading pcap-ng data
From: Guy Harris <guy () alum mit edu>
Date: Thu, 26 Apr 2012 11:33:17 -0700
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.
Current thread:
- "snaplen of 0" when reading pcap-ng data Andrew Daviel (Apr 25)
- Re: "snaplen of 0" when reading pcap-ng data Guy Harris (Apr 26)