[Bug] Invalid packet length

[JulianCeaser]

Describe the bug
Trying to replay a pcap using tcpreplay is generating the following error
safe_pcap_next ERROR: Invalid packet length in send_packets.c:get_next_packet() line 1068: packet length=785 capture length=801

To Reproduce
Steps to reproduce the behavior:

1. Installed tcpreplay on CentOS 7
2. sudo tcpreplay -i ens160 testing-sqli.pcap
3. Getting error message - safe_pcap_next ERROR: Invalid packet length in send_packets.c:get_next_packet() line 1068: packet length=785 capture length=801

Expected behavior
Pcap should be replayed over the network

Screenshots
If applicable, add screenshots to help explain your problem.

System (please complete the following information):

• OS: CentOS
• OS version - 7.1.1503
• Tcpreplay Version - 4.3.2-1

Pcap
Dropbox link

[skyj]

Hi,

I've got the same issue with several others captures. I think that this patch 68f67b1 is wrong. In @JulianCeaser example, if you look at the first frame in Wireshark you will see that both “Frame length” and “Capture length” are reported to be of 785 bytes and not 801 bytes. It's because in wtap_read() they truncate the “Capture length” at “Frame length”:

	/*
	 * Is this a packet record?
	 */
	if (wth->rec.rec_type == REC_TYPE_PACKET) {
		/*
		 * It makes no sense for the captured data length
		 * to be bigger than the actual data length.
		 */
		if (wth->rec.rec_header.packet_header.caplen > wth->rec.rec_header.packet_header.len)
			wth->rec.rec_header.packet_header.caplen = wth->rec.rec_header.packet_header.len;

I didn't have the time to dig more and understand why caplen could be slightly greater than framelen, but it clearly seems to be expected.

A crude workaround that worked for me:

diff --git a/src/common/utils.c b/src/common/utils.c
index 15f90a04..7194018d 100644
--- a/src/common/utils.c
+++ b/src/common/utils.c
@@ -134,6 +134,9 @@ u_char *_our_safe_pcap_next(pcap_t *pcap,  struct pcap_pkthdr *pkthdr,
             exit(-1);
         }
 
+        if (pkthdr->len && pkthdr->len < pkthdr->caplen) {
+            pkthdr->caplen = pkthdr->len;
+        }
         if (!pkthdr->len || pkthdr->len < pkthdr->caplen) {
             fprintf(stderr, "safe_pcap_next ERROR: Invalid packet length in %s:%s() line %d: packet length=%u capture length=%u\n",
                     file, funcname, line, pkthdr->len, pkthdr->caplen);

Of course I guess it could be not that simple, and truncating caplen could lead to various problem in tcpreplay. Still I hope this will help.

Regards,
Jonathan

[cgi1]

@fklassen Is there any update on this? I receive the same error in latest version:

$ sudo tcpreplay -i lo mine.pcap
safe_pcap_next ERROR: Invalid packet length in send_packets.c:get_next_packet() line 1068: 92442 is greater than maximum 65549

cgi@cgires:~$ sudo tcpreplay -V
[sudo] password for cgi: 
tcpreplay version: 4.3.2 (build git:v4.3.2)
Copyright 2013-2018 by Fred Klassen <tcpreplay at appneta dot com> - AppNeta
Copyright 2000-2012 by Aaron Turner <aturner at synfin dot net>
The entire Tcpreplay Suite is licensed under the GPLv3
Cache file supported: 04
Not compiled with libdnet.
Compiled against libpcap: 1.9.1
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Packet editing: disabled
Fragroute engine: disabled
Injection method: PF_PACKET send()
Not compiled with netmap

[fklassen]

This appears to be a corrupt capture. What generated it? Being a Linux cooked-mode capture it appears to be artificially generated.

It is easy enough apply the patch to allow an invalid capture, but why is this the first time I have seen this type of error in a pcap?

capinfos testing.pcap                                                                                                    Bug_#557_correct_some_invalid_packet_lengths ✭ ◼
File name:           testing.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Linux cooked-mode capture
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 262144 bytes
Number of packets:   12 k
File size:           6,396 kB
Data size:           6,009 kB
Capture duration:    614.300757 seconds
First packet time:   2019-05-24 12:44:26.161463
Last packet time:    2019-05-24 12:54:40.462220
Data byte rate:      9,783 bytes/s
Data bit rate:       78 kbps
Average packet size: 497.01 bytes
Average packet rate: 19 packets/s
SHA256:              30f29d8c1dd7702e388415533ca97ee842eb5aa3713fe8a1b109574c22f45896
RIPEMD160:           1f6499504bbd267c495c12296da81868e98efc65
SHA1:                ed42645c2046dccbd9cd420c80142f205151c6b2
Strict time order:   False
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Linux cooked-mode capture (25 - linux-sll)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 12092

[fklassen]

Fixed in PR #603