forked from osmocom/wireshark
212 lines
8.2 KiB
Text
212 lines
8.2 KiB
Text
|
|
=head1 NAME
|
|
|
|
text2pcap - Generate a capture file from an ASCII hexdump of packets
|
|
|
|
=head1 SYNOPSYS
|
|
|
|
B<text2pcap>
|
|
S<[ B<-h> ]>
|
|
S<[ B<-d> ]>
|
|
S<[ B<-q> ]>
|
|
S<[ B<-o> hex|oct|dec ]>
|
|
S<[ B<-l> E<lt>typenumE<gt> ]>
|
|
S<[ B<-e> E<lt>l3pidE<gt> ]>
|
|
S<[ B<-i> E<lt>protoE<gt> ]>
|
|
S<[ B<-m> E<lt>max-packetE<gt> ]>
|
|
S<[ B<-u> E<lt>srcportE<gt>,E<lt>destportE<gt> ]>
|
|
S<[ B<-T> E<lt>srcportE<gt>,E<lt>destportE<gt> ]>
|
|
S<[ B<-s> E<lt>srcportE<gt>,E<lt>destportE<gt>,E<lt>tagE<gt> ]>
|
|
S<[ B<-S> E<lt>srcportE<gt>,E<lt>destportE<gt>,E<lt>ppiE<gt> ]>
|
|
S<[ B<-t> E<lt>timefmtE<gt> ]>
|
|
E<lt>I<infile>E<gt>|-
|
|
E<lt>I<outfile>E<gt>|-
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
B<Text2pcap> is a program that reads in an ASCII hex dump and writes the
|
|
data described into a B<libpcap> capture file. B<text2pcap> can
|
|
read hexdumps with multiple packets in them, and build a capture file of
|
|
multiple packets. B<text2pcap> is also capable of generating dummy
|
|
Ethernet, IP and UDP, TCP, or SCTP headers, in order to build fully
|
|
processable packet dumps from hexdumps of application-level data only.
|
|
|
|
B<Text2pcap> understands a hexdump of the form generated by I<od -Ax -tx1>.
|
|
In other words, each byte is individually displayed and
|
|
surrounded with a space. Each line begins with an offset describing
|
|
the position in the file. The offset is a hex number (can also be
|
|
octal or decimal - see B<-o>), of more than two hex digits.
|
|
Here is a sample dump that B<text2pcap> can recognize:
|
|
|
|
000000 00 e0 1e a7 05 6f 00 10 ........
|
|
000008 5a a0 b9 12 08 00 46 00 ........
|
|
000010 03 68 00 00 00 00 0a 2e ........
|
|
000018 ee 33 0f 19 08 7f 0f 19 ........
|
|
000020 03 80 94 04 00 00 10 01 ........
|
|
000028 16 a2 0a 00 03 50 00 0c ........
|
|
000030 01 01 0f 19 03 80 11 01 ........
|
|
|
|
There is no limit on the width or number of bytes per line. Also the
|
|
text dump at the end of the line is ignored. Bytes/hex numbers can be
|
|
uppercase or lowercase. Any text before the offset is ignored,
|
|
including email forwarding characters '>'. Any lines of text between
|
|
the bytestring lines is ignored. The offsets are used to track the
|
|
bytes, so offsets must be correct. Any line which has only bytes
|
|
without a leading offset is ignored. An offset is recognized as being
|
|
a hex number longer than two characters. Any text after the bytes is
|
|
ignored (e.g. the character dump). Any hex numbers in this text are
|
|
also ignored. An offset of zero is indicative of starting a new
|
|
packet, so a single text file with a series of hexdumps can be
|
|
converted into a packet capture with multiple packets. Multiple
|
|
packets are read in with timestamps differing by one second each. In
|
|
general, short of these restrictions, B<text2pcap> is pretty liberal
|
|
about reading in hexdumps and has been tested with a variety of
|
|
mangled outputs (including being forwarded through email multiple
|
|
times, with limited line wrap etc.)
|
|
|
|
There are a couple of other special features to note. Any line where
|
|
the first non-whitespace character is '#' will be ignored as a
|
|
comment. Any line beginning with #TEXT2PCAP is a directive and options
|
|
can be inserted after this command to be processed by
|
|
B<text2pcap>. Currently there are no directives implemented; in the
|
|
future, these may be used to give more fine grained control on the
|
|
dump and the way it should be processed e.g. timestamps, encapsulation
|
|
type etc.
|
|
|
|
B<Text2pcap> also allows the user to read in dumps of
|
|
application-level data, by inserting dummy L2, L3 and L4 headers
|
|
before each packet. The user can elect to insert Ethernet headers,
|
|
Ethernet and IP, or Ethernet, IP and UDP/TCP headers before each
|
|
packet. This allows Wireshark or any other full-packet decoder to
|
|
handle these dumps.
|
|
|
|
=head1 OPTIONS
|
|
|
|
=over 4
|
|
|
|
=item -h
|
|
|
|
Displays a help message.
|
|
|
|
=item -d
|
|
|
|
Displays debugging information during the process. Can be used
|
|
multiple times to generate more debugging information.
|
|
|
|
=item -q
|
|
|
|
Be completely quiet during the process.
|
|
|
|
=item -o hex|oct|dec
|
|
|
|
Specify the radix for the offsets (hex, octal or decimal). Defaults to
|
|
hex. This corresponds to the C<-A> option for I<od>.
|
|
|
|
=item -l
|
|
|
|
Specify the link-layer type of this packet. Default is Ethernet
|
|
(1). See I<net/bpf.h> for the complete list of possible
|
|
encapsulations. Note that this option should be used if your dump is a
|
|
complete hex dump of an encapsulated packet and you wish to specify
|
|
the exact type of encapsulation. Example: I<-l 7> for ARCNet packets.
|
|
|
|
=item -e E<lt>l3pidE<gt>
|
|
|
|
Include a dummy Ethernet header before each packet. Specify the L3PID
|
|
for the Ethernet header in hex. Use this option if your dump has Layer
|
|
3 header and payload (e.g. IP header), but no Layer 2
|
|
encapsulation. Example: I<-e 0x806> to specify an ARP packet.
|
|
|
|
For IP packets, instead of generating a fake Ethernet header you can
|
|
also use I<-l 12> to indicate a raw IP packet to Wireshark. Note that
|
|
I<-l 12> does not work for any non-IP Layer 3 packet (e.g. ARP),
|
|
whereas generating a dummy Ethernet header with I<-e> works for any
|
|
sort of L3 packet.
|
|
|
|
=item -i E<lt>protoE<gt>
|
|
|
|
Include dummy IP headers before each packet. Specify the IP protocol
|
|
for the packet in decimal. Use this option if your dump is the payload
|
|
of an IP packet (i.e. has complete L4 information) but does not have
|
|
an IP header. Note that this automatically includes an appropriate
|
|
Ethernet header as well. Example: I<-i 46> to specify an RSVP packet
|
|
(IP protocol 46).
|
|
|
|
=item -m E<lt>max-packetE<gt>
|
|
|
|
Set the maximum packet length, default is 64000.
|
|
Useful for testing various packet boundaries when only an application
|
|
level datastream is available. Example:
|
|
|
|
I<od -Ax -tx1 stream | text2pcap -m1460 -T1234,1234 - stream.pcap>
|
|
|
|
will convert from plain datastream format to a sequence of Ethernet
|
|
TCP packets.
|
|
|
|
=item -u E<lt>srcportE<gt>,E<lt>destportE<gt>
|
|
|
|
Include dummy UDP headers before each packet. Specify the source and
|
|
destination UDP ports for the packet in decimal. Use this option if
|
|
your dump is the UDP payload of a packet but does not include any UDP,
|
|
IP or Ethernet headers. Note that this automatically includes
|
|
appropriate Ethernet and IP headers with each packet. Example: I<-u
|
|
1000,69> to make the packets look like TFTP/UDP packets.
|
|
|
|
=item -T E<lt>srcportE<gt>,E<lt>destportE<gt>
|
|
|
|
Include dummy TCP headers before each packet. Specify the source and
|
|
destination TCP ports for the packet in decimal. Use this option if
|
|
your dump is the TCP payload of a packet but does not include any TCP,
|
|
IP or Ethernet headers. Note that this automatically includes
|
|
appropriate Ethernet and IP headers with each packet.
|
|
Sequence numbers will start a 0.
|
|
|
|
=item -s E<lt>srcportE<gt>,E<lt>destportE<gt>,E<lt>tagE<gt>
|
|
|
|
Include dummy SCTP headers before each packet. Specify, in decimal, the
|
|
source and destination SCTP ports, and verification tag, for the packet.
|
|
Use this option if your dump is the SCTP payload of a packet but does
|
|
not include any SCTP, IP or Ethernet headers. Note that this
|
|
automatically includes appropriate Ethernet and IP headers with each
|
|
packet. A CRC32C checksum will be put into the SCTP header.
|
|
|
|
=item -S E<lt>srcportE<gt>,E<lt>destportE<gt>,E<lt>ppiE<gt>
|
|
|
|
Include dummy SCTP headers before each packet. Specify, in decimal, the
|
|
source and destination SCTP ports, and a verification tag of 0, for the
|
|
packet, and prepend a dummy SCTP DATA chunk header with a payload
|
|
protocol identifier if I<ppi>. Use this option if your dump is the SCTP
|
|
payload of a packet but does not include any SCTP, IP or Ethernet
|
|
headers. Note that this automatically includes appropriate Ethernet and
|
|
IP headers with each packet. A CRC32C checksum will be put into the
|
|
SCTP header.
|
|
|
|
=item -t E<lt>timefmtE<gt>
|
|
|
|
Treats the text before the packet as a date/time code; I<timefmt> is a
|
|
format string of the sort supported by strptime(3).
|
|
Example: The time "10:15:14.5476" has the format code "%H:%M:%S."
|
|
|
|
B<NOTE:> The subsecond component delimiter must be specified (.) but no
|
|
pattern is required; the remaining number is assumed to be fractions of
|
|
a second.
|
|
|
|
B<NOTE:> Date/time fields from the current date/time are
|
|
used as the default for unspecified fields.
|
|
|
|
=back
|
|
|
|
=head1 SEE ALSO
|
|
|
|
od(1), tcpdump(8), pcap(3), wireshark(1), tshark(1), dumpcap(1), mergecap(1),
|
|
editcap(1), strptime(3).
|
|
|
|
=head1 NOTES
|
|
|
|
B<Text2pcap> is part of the B<Wireshark> distribution. The latest version
|
|
of B<Wireshark> can be found at L<http://www.wireshark.org>.
|
|
|
|
=head1 AUTHORS
|
|
|
|
Ashok Narayanan <ashokn[AT]cisco.com>
|