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.
