Gracefully handle broken pcaps where snaplen < caplen

[aturner]

Weird bug in libpcap or wireshark or??? Basically, when the caplen != len (tcpdump didn't capture the entire packet), when you read that saved capture file via libpcap, the caplen is 14 bytes less then the value reported by Wireshark. Wireshark also seems to find valid data for those 14 bytes, so it appears the larger value reported by Wireshark is correct.

Need to track this bug down and get a fix.

[aturner]

Guy from the tcpdump-workers list has tracked down the issue. Basically:

test/test.pcap was created using RH's hacked libpcap which had a bug. The issue is basically that the snaplen < caplen, so libpcap reduces the caplen to equal the snaplen. Unfortunately, there's no good way to detect this issue using libpcap. I'm trying to work with Guy to either introduce a workaround in libpcap behind the scenes or introduce an API enhancement to increase the snaplen at runtime.

Either way, this is a real issue and I need assistance from the libpcap guys to fix it.

[ilanch]

About the above issue,
I tried to examine packets in the test/test.pcap of original data and the captured data that generated by tcpreplay, and used the packetdump of tcpstat.
In two packet dumps, if PACKET SIZE is over 130 bytes then it is suspicious, otherwise that is same. Why the 130 bytes is? What means the 130 bytes?

When I use tcpwrite, the original and output by tcpwrite were same.
If the libpcap has any problem, the output of tcpwrite also might be different.
But the result of output was same to the original packets.
Why the result was different?

[aturner]

Sent the attached patch to the libpcap guys which should work around the problem.

[aturner]

pcap_snapshot_override() patch

[aturner]

(In [1734]) tag things as rc1 refs #108 add support for pcap_snapshot_override() refs #130 check that dual nic mode both interfaces have the same dlt refs #125

[aturner]

(In [1737]) add pcap_snapshot_override refs #130 fix win32 refs #110

[aturner]

Need to add support for either:

1. official libpcap pcap_snapshot_override() support
2. ship a patched version of libpcap
3. special hacks to the libpcap API

[aturner]

This will require a complete rebuild of all the tcprewrite unit test cases.

[aturner]

(In [1751]) fix compile issue (copy&paste bug). refs #130

[aturner]

Wiating to hear from the libpcap guys... My code works assuming they accept the patch as is. Hence I'm postponing this until 3.0 and hopefully they'll accept my patch by then, but I want this off my todo list for RC1.

[aturner]

Email from Guy:

...and, after looking at various versions of the hacked libpcap, it's
obvious where the bug was coming from - the snapshot length was used in
the recvfrom() call as the count, so up to that many bytes were
received, but, if the capture was done in cooked mode, a fake Ethernet
header is prepended, so the effective snapshot length is 14 greater than
the one supplied to the program.

I've checked into the main and x.9 branches a change that sets the
pcap_t's snaplen value to 14 more than the value from the file header if
the capture was an Ethernet capture with the modified libpcap (based on
the magic number).  This isn't ideal - I'd like to do it only if the
capture was done in cooked mode - but there's no easy way to determine
whether it was a cooked-mode capture or not, so, while that means that a
raw-mode Ethernet capture will appear to have a snapshot length 14 more
than the real snapshot, that's probably the best we can do.  That
modified libpcap hasn't, as far as I know, been in any Linux
distribution for a while, so there shouldn't be many *more* of those
files showing up.

So long story short, sounds like Guy came up with an alternate fix which solves for this issue silently. Since configure.in has to detect my API enhancement, I'm not going to pull it out of my code in case Guy's fix doesn't work for me.

[aturner]

0.9.6 should be out around mid-april 2007

[aturner]

Since my patch doesn't appear that it will ever see the light of day, I'm marking this as 'wontfix'. I'll open a ticket for 3.0.0 which will remove support for this assuming that Guy's fix solves my problem.

[aturner]

(In [1810]) initial checkin used my pcap_snaplen_override() which of course nobody else has. So until 0.9.6 is released (which should fix this issue), use my broken version. fixes #64 also refs #130

[aturner]

(In [2111]) update big endian tests. refs #130