dect
/
libpcap
Archived
13
0
Fork 0
Code Releases Activity

Work around a bug in some older versions of libpcap, where the snapshot 

length value in the file header is 14 less than the actual maximum
packet length.
This commit is contained in:
guy 2007-04-01 17:06:47 +00:00
parent 83a6a8ab27
commit 266d42352f
1 changed files with 23 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
savefile.c
View File

@ -30,7 +30,7 @@
#ifndef lint
static const char rcsid[] _U_ =
"@(#) $Header: /tcpdump/master/libpcap/savefile.c,v 1.150 2007-01-29 20:08:06 guy Exp $ (LBL)";
"@(#) $Header: /tcpdump/master/libpcap/savefile.c,v 1.151 2007-04-01 17:06:47 guy Exp $ (LBL)";
#endif
#ifdef HAVE_CONFIG_H
@ -959,6 +959,28 @@ pcap_fopen_offline(FILE *fp, char *errbuf)
p->tzoff = hdr.thiszone;
p->snapshot = hdr.snaplen;
p->linktype = linktype_to_dlt(hdr.linktype);
if (magic == KUZNETZOV_TCPDUMP_MAGIC && p->linktype == DLT_EN10MB) {
/*
* This capture might have been done in raw mode or cooked
* mode.
*
* If it was done in cooked mode, p->snapshot was passed
* to recvfrom() as the buffer size, meaning that the
* most packet data that would be copied would be
* p->snapshot. However, a faked Ethernet header would
* then have been added to it, so the most data that would
* be in a packet in the file would be p->snapshot + 14.
*
* We can't easily tell whether the capture was done in
* raw mode or cooked mode, so we'll assume it was
* cooked mode, and add 14 to the snapshot length. That
* means that, for a raw capture, the snapshot length will
* be misleading if you use it to figure out why a capture
* doesn't have all the packet data, but there's not much
* we can do to avoid that.
*/
p->snapshot += 14;
}
p->sf.rfile = fp;
#ifndef WIN32
p->bufsize = hdr.snaplen;