Opened 11 years ago

Closed 9 years ago

#130 closed defect (wontfix)

Gracefully handle broken pcaps where snaplen < caplen

Reported by: aturner Owned by: aturner
Priority: high Milestone: 3.0.RC1
Component: tcpreplay Version: 3.0.beta12
Keywords: libpcap Cc:
Operating System: all Add to FAQ?: yes
Hardware: All
Output of tcpreplay -V:

Description

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.

Attachments (1)

pcap_snapshot_override.patch (4.7 KB) - added by aturner 11 years ago.
pcap_snapshot_override() patch

Download all attachments as: .zip

Change History (19)

comment:1 Changed 11 years ago by aturner

  • Keywords libpcap added
  • Operating System set to all

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.

comment:2 Changed 11 years ago by 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?

comment:3 Changed 11 years ago by aturner

  • Status changed from new to assigned

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

Changed 11 years ago by aturner

pcap_snapshot_override() patch

comment:4 Changed 11 years ago by 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

comment:5 Changed 11 years ago by aturner

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

comment:6 Changed 11 years ago by aturner

  • Summary changed from caplen - 14 bytes where caplen != len to add support for pcap_snapshot_override()

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

comment:7 Changed 11 years ago by aturner

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

comment:8 Changed 11 years ago by aturner

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

comment:9 Changed 11 years ago by aturner

  • Milestone changed from 3.0.RC1 to 3.0.0

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.

comment:10 Changed 11 years ago by aturner

  • Add to FAQ? unset

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.

comment:11 Changed 11 years ago by aturner

  • Add to FAQ? set

comment:12 Changed 11 years ago by aturner

  • Milestone changed from 3.0.0 to 3.0.RC1

0.9.6 should be out around mid-april 2007

comment:13 Changed 11 years ago by aturner

  • Resolution set to wontfix
  • Status changed from assigned to closed

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.

comment:14 Changed 11 years ago by aturner

  • Summary changed from add support for pcap_snapshot_override() to Gracefully handle broken pcaps where snaplen < caplen

comment:15 Changed 11 years ago by 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

comment:16 Changed 9 years ago by aturner

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:17 Changed 9 years ago by aturner

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

comment:18 Changed 9 years ago by aturner

  • Resolution set to wontfix
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.