[Bug] safe_pcap_next ERROR: Invalid packet length in send_packets.c:get_next_packet() line 1068: 92442 is greater than maximum 65549

[cgi1]

Steps to reproduce the behavior:

1. Loading a PCAP using

$ sudo tcpreplay -i lo mine.pcap

2. results in

safe_pcap_next ERROR: Invalid packet length in send_packets.c:get_next_packet() line 1068: 92442 is greater than maximum 65549

Digging into source code, It looks like there are packages within the PCAP over the MAXPACKET variable, which is why the code fails here. I suggest upgrading MAXPACKET from 65549 to 131098 in here.

So:

#define MAXPACKET 65549         /* was 16436 linux loopback, but maybe something is bigger then
                                   linux loopback */
#define MAX_SNAPLEN 65535       /* tell libpcap to capture the entire packet */

Will become:

#define MAXPACKET 131098         /* was 16436 linux loopback, but maybe something is bigger then
                                   linux loopback */
#define MAX_SNAPLEN 131098       /* tell libpcap to capture the entire packet */

I just want to know, if you see any problems here. I am also a bit worried about the comment 16436 linux loopback, which looks like I should go with anouther type of interface to replay on.

System (please complete the following information):

• Ubuntu 18.04

cgi@cgires:~$ sudo tcpreplay -V
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

Additional context
Could provide example PCAP private.

[fklassen]

If PCAP is small enough, rename to mine.pcap.txt and drag into issue.

[zynzynack]

Also see the-tcpdump-group/tcpdump#856

[guyharris]

Also see the-tcpdump-group/tcpdump#856

Including my comment, in which tcpdump, when run by a version of tcpprep compiled and run on macOS, printed "tcpdump: unknown file format" when I handed tcpprep a pcap file written by tcpdump. (That happened both with Apple's tcpdump, which was not writing pcapng files in this case, and a built-from-tip-of-master and linked-with-libpcap-built-from-tip-of-master tcpdump writing the file.)

Configure output from tcpreplay:

##########################################################################
             TCPREPLAY Suite Configuration Results (4.3.1)
##########################################################################
libpcap:                    /usr/local (>= 0.9.6)
PF_RING libpcap             no   
libdnet:                    /usr/local   1.12
autogen:                     (unknown - man pages will not be built)
Use libopts tearoff:        yes
64bit counter support:      yes
tcpdump binary path:        /usr/sbin/tcpdump
fragroute support:          yes
tcpbridge support:          yes
tcpliveplay support:        no

Supported Packet Injection Methods (*):
Linux TX_RING:              no
Linux PF_PACKET:            no
BSD BPF:                    yes
libdnet:                    yes
pcap_inject:                yes
pcap_sendpacket:            yes **
pcap_netmap                 no
Linux/BSD netmap:           no
Tuntap device support:      no

* In order of preference; see configure --help to override
** Required for tcpbridge

configure: WARNING: Apple OS X versions prior to 10.5 (Leopard) have a serious problem!
Please see: http://tcpreplay.synfin.net/trac/ticket/142 for more details

(Note, BTW, that the tcpreplay.synfin.net link doesn't work.)

[guyharris]

Digging into source code, It looks like there are packages within the PCAP over the MAXPACKET variable

Packets within the "my.pcap" file, or packets within whatever tcpprep is piping to tcpdump?

If tcpdump can read your my.pcap file, it's probably not a problem with packets within the "my.pcap" file. Perhaps the code that's writing to the pipe to tcpdump is writing mangled output.

[fklassen]

I am starting work on this, but and finding it difficult to find a capture with a packet > 65535 bytes.

Also, the maximum packet size should be 262144 to match maximum snaplen in Wireshark. It reflects libpcap's MAXIMUM_SNAPLEN.

[fklassen]

Fixed in PR #593