editcap (1) - Linux Manuals
editcap: Edit and/or translate the format of capture files
NAME
editcap - Edit and/or translate the format of capture files
SYNOPSIS
editcap [
editcap
By default, it reads all packets from the infile and writes them to the
outfile in pcap file format.
An optional list of packet numbers can be specified on the command tail;
individual packet numbers separated by whitespace and/or ranges of packet
numbers can be specified as start-end, referring to all packets from
start to end. By default the selected packets with those numbers will
not be written to the capture file. If the -r flag is specified, the
whole packet selection is reversed; in that case only the selected packets
will be written to the capture file.
Editcap can also be used to remove duplicate packets. Several different
options (-d, -D and -w) are used to control the packet window
or relative time window to be used for duplicate comparison.
Editcap is able to detect, read and write the same capture files that
are supported by Wireshark.
The input file doesn't need a specific filename extension; the file
format and an optional gzip compression will be automatically detected.
Near the beginning of the DESCRIPTION section of wireshark(1) or
<http://www.wireshark.org/docs/man-pages/wireshark.html>
is a detailed description of the way Wireshark handles this, which is
the same way Editcap handles this.
Editcap can write the file in several output formats. The -F
flag can be used to specify the format in which to write the capture
file; editcap -F provides a list of the available output formats.
This is useful for chopping headers for decapsulation of an entire capture or
in the rare case that the conversion between two file formats leaves some random
bytes at the end of each packet.
The use of the option -D 0 combined with the -v option is useful
in that each packet's Packet number, Len and MD5 Hash will be printed
to standard out. This verbose output (specifically the MD5 hash strings)
can be useful in scripts to identify duplicate packets across trace
files.
The <dup window> is specified as an integer value between 0 and 1000000 (inclusive).
NOTE: Specifying large <dup window> values with large tracefiles can
result in very long processing times for editcap.
This option is meant to be used for fuzz-testing protocol dissectors.
This may be useful if the program that is
to read the output file cannot handle packets larger than a certain size
(for example, the versions of snoop in Solaris 2.5.1 and Solaris 2.6
appear to reject Ethernet packets larger than the standard Ethernet MTU,
making them incapable of handling gigabit Ethernet captures if jumbo
packets were used).
The <strict time adjustment> value represents relative seconds
specified as [-]seconds[.fractional seconds].
As the capture file is processed each packet's absolute time is
possibly adjusted to be equal to or greater than the previous
packet's absolute timestamp depending on the <strict time
adjustment> value.
If <strict time adjustment> value is 0 or greater (e.g. 0.000001)
then only packets with a timestamp less than the previous packet
will adjusted. The adjusted timestamp value will be set to be
equal to the timestamp value of the previous packet plus the value
of the <strict time adjustment> value. A <strict time adjustment>
value of 0 will adjust the minimum number of timestamp values
necessary to insure that the resulting capture file is in
strict chronological order.
If <strict time adjustment> value is specified as a
negative value, then the timestamp values of all
packets will be adjusted to be equal to the timestamp value
of the previous packet plus the absolute value of the
<lt>strict time adjustment<gt> value. A <strict time
adjustment> value of -0 will result in all packets
having the timestamp value of the first packet.
This feature is useful when the trace file has an occasional
packet with a negative delta time relative to the previous
packet.
This feature is useful when synchronizing dumps
collected on different machines where the time difference between the
two machines is known or can be estimated.
Note: this merely
forces the encapsulation type of the output file to be the specified
type; the packet headers of the packets will not be translated from the
encapsulation type of the input capture file to the specified
encapsulation type (for example, it will not translate an Ethernet
capture to an FDDI capture if an Ethernet capture is read and '-T
fddi' is specified). If you need to remove/add headers from/to a
packet, you will need od(1)/text2pcap(1).
Use of -v with the de-duplication switches of -d, -D or -w
will cause all MD5 hashes to be printed whether the packet is skipped
or not.
The <dup time window> is specified as seconds[.fractional seconds].
The [.fractional seconds] component can be specified to nine (9) decimal
places (billionths of a second) but most typical trace files have resolution
to six (6) decimal places (millionths of a second).
NOTE: Specifying large <dup time window> values with large tracefiles can
result in very long processing times for editcap.
NOTE: The -w option assumes that the packets are in chronological order.
If the packets are NOT in chronological order then the -w duplication
removal option may not identify some duplicates.
To shrink the capture file by truncating the packets at 64 bytes and writing it as Sun snoop file use:
To delete packet 1000 from the capture file use:
To limit a capture file to packets from number 200 to 750 (inclusive) use:
To get all packets from number 1-500 (inclusive) use:
or
To exclude packets 1, 5, 10 to 20 and 30 to 40 from the new file use:
To select just packets 1, 5, 10 to 20 and 30 to 40 for the new file use:
To remove duplicate packets seen within the prior four frames use:
To remove duplicate packets seen within the prior 100 frames use:
To remove duplicate packets seen equal to or less than 1/10th of a second:
To display the MD5 hash for all of the packets (and NOT generate any
real output file):
or on Windows systems
To advance the timestamps of each packet forward by 3.0827 seconds:
To insure all timestamps are in strict chronological order:
To introduce 5% random errors in a capture file use:
HTML versions of the Wireshark project man pages are available at:
<http://www.wireshark.org/docs/man-pages>.
DESCRIPTION
Editcap is a program that reads some or all of the captured packets from the
infile, optionally converts them in various ways and writes the
resulting packets to the capture outfile (or outfiles).
OPTIONS
EXAMPLES
To see more detailed description of the options use:
editcap -h
editcap -s 64 -F snoop capture.pcap shortcapture.snoop
editcap capture.pcap sans1000.pcap 1000
editcap -r capture.pcap small.pcap 200-750
editcap -r capture.pcap first500.pcap 1-500
editcap capture.pcap first500.pcap 501-9999999
editcap capture.pcap exclude.pcap 1 5 10-20 30-40
editcap -r capture.pcap select.pcap 1 5 10-20 30-40
editcap -d capture.pcap dedup.pcap
editcap -D 101 capture.pcap dedup.pcap
editcap -w 0.1 capture.pcap dedup.pcap
editcap -v -D 0 capture.pcap /dev/null
editcap -v -D 0 capture.pcap NUL
editcap -t 3.0827 capture.pcap adjusted.pcap
editcap -S 0 capture.pcap adjusted.pcap
editcap -E 0.05 capture.pcap capture_error.pcap
NOTES
Editcap is part of the Wireshark distribution. The latest version
of Wireshark can be found at <http://www.wireshark.org>.
AUTHORS
Original Author
-------- ------
Richard Sharpe <sharpe[AT]ns.aus.com>
Contributors
------------
Guy Harris <guy[AT]alum.mit.edu>
Ulf Lamping <ulf.lamping[AT]web.de>
SEE ALSO
pcap(3), wireshark(1), tshark(1), mergecap(1), dumpcap(1), capinfos(1),
text2pcap(1), od(1), pcap-filter(7) or tcpdump(8)