1
votes

i use tcprewrite to rewrite my raw pcap files (change MAC address and then change the IP) from CAIDA dataset. I came across this problem. command use as follows:

sudo tcprewrite --infile=xxx.pcap --dlt=enet --outfile=yyy.pcap --enet-dmac=00:00:00:03 --enet-smac=00:00:00:1f 

the error

pcap was captured using a snaplen of 65000 bytes.  This may mean you have truncated packets.

I tried to search for the solutions from web and unfortunately i cannot solve it. According to this thread http://sourceforge.net/p/tcpreplay/mailman/tcpreplay-users/?viewmonth=201201 the error rise because of the packet is not captured since the beginning.

Does anyone has an idea how to solve this problem?

1

1 Answers

3
votes

pcap was captured using a snaplen of 65000 bytes. This may mean you have truncated packets.

Or it may not and, in fact, it probably doesn't mean you have truncated packets.

The packet capture mechanism on some systems requires that some maximum packet length be specified, but it can be something sufficiently large that, in practice, no packets will be larger than the maximum and thus no packets will be truncated.

65535 was often used as such a maximum - Wireshark's done so even before it was renamed Wireshark, and tcpdump was first changed so that "-s 0" would use 65535 and then changed to default to 65535. tcpreplay is treating any maximum packet length < 65535 as "not trying to capture the entire packet", but warning about, for example, 65534 is a bit silly.

Tcpdump and Wireshark recently boosted the limit to 262144 to handle some USB captures.

(The limit is chosen not to be too big - the pcap and pcap-ng file formats allow up to 2^32-1, but some software might, when reading such a file, try to allocate a 2^32-1-byte buffer and fail.)

So, don't worry about it, but also don't explicitly specify a snapshot length of 65000 - explicit snapshot lengths are useful only if you want to capture only part of the packet or if you have an old tcpdump (or ANCIENT Ethereal) that defaults to 68 or 96 bytes, and, in the latter case, you might as well go with a value >= 65535.