On Nov 30, 2006, at 1:08 PM, Aaron Turner wrote:
I guess I can understand why libpcap takes the min of snaplen &
caplen, but it would be nice if libpcap returned the actual captured
data rather then truncating it.
Unfortunately, I don't know where or how these pcap files were
generated, so I don't know what's causing this to happen or how
widespread it is. Could this of been a bug in earlier versions of
libpcap??
I don't know - it might have come from some vendor-"improved" version
of libpcap, or the bug might have been in the underlying packet
capture mechanism that libpcap used on whatever platform the packet
was captured, or it might have been written by something other than
libpcap.
Reading savefile.c I see a reference to a Solaris 2.3 bug,
but I'd guess this isn't the issue.
Probably not.
However, that bug is presumably the reason why libpcap *doesn't* treat
the caplen as correct, boost the buffer size, and return all the data
- in the case of the Solaris 2.3 captures, it's presumably *not*
correct.
I'd suggest writing a small program to fix the snapshot length in
those captures. It could, for example, scan through the file, find
the maximum caplen, and then open the file for writing and write out
the maximum of the snaplen value and the maximum caplen, in the right
byte order, in the snaplen field.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.