Related command line tools
Introduction Beside the Wireshark GUI application, there are some command line tools, which can be helpful for doing some more specialized things. These tools will be described in this chapter.
<command>tcpdump</command>: Capturing with tcpdump for viewing with Wireshark There are occasions when you want to capture packets using tcpdump rather than ethereal, especially when you want to do a remote capture and do not want the network load associated with running Wireshark remotely (not to mention all the X traffic polluting your capture). However, the default tcpdump parameters result in a capture file where each packet is truncated, because tcpdump, by default, does only capture the first 68 bytes of each packet. To ensure that you capture complete packets, use the following command: tcpdump -i <interface> -s 1500 -w <some-file> You will have to specify the correct interface and the name of a file to save into. In addition, you will have to terminate the capture with ^C when you believe you have captured enough packets. Note! tcpdump is not part of the Wireshark distribution. You can get it from: http://www.tcpdump.org for various platforms.
<command>tshark</command>: Terminal-based Wireshark TShark is a terminal oriented version of ethereal designed for capturing and displaying packets when an interactive user interface isn't necessary or available. It supports the same options as ethereal. For more information on tshark, see the manual pages (man tshark).
<command>capinfos</command>: Print information about capture files Included with Wireshark is a small utility called capinfos, which is a command-line utility to print information about binary capture files. Help information available from capinfos $ capinfos -h Usage: capinfos [-t] [-c] [-s] [-d] [-u] [-a] [-e] [-y] [-i] [-z] [-h] <capfile> where -t display the capture type of <capfile> -c count the number of packets -s display the size of the file -d display the total length of all packets in the file (in bytes) -u display the capture duration (in seconds) -a display the capture start time -e display the capture end time -y display average data rate (in bytes) -i display average data rate (in bits) -z display average packet size (in bytes) -h produces this help listing. If no data flags are given, default is to display all statistics
<command>editcap</command>: Edit capture files Included with Wireshark is a small utility called editcap, which is a command-line utility for working with capture files. Its main function is to remove packets from capture files, but it can also be used to convert capture files from one format to another, as well as print information about capture files. Help information available from editcap $ editcap.exe -h Usage: editcap [-r] [-h] [-v] [-T <encap type>] [-E <probability>] [-F <capture type>]> [-s <snaplen>] [-t <time adjustment>] <infile> <outfile> [ <record#>[-<record#>] ... ] where -E <probability> specifies the probability (between 0 and 1) that a particular byte will will have an error. -F <capture type> specifies the capture file type to write: libpcap - libpcap (tcpdump, Wireshark, etc.) rh6_1libpcap - RedHat Linux 6.1 libpcap (tcpdump) suse6_3libpcap - SuSE Linux 6.3 libpcap (tcpdump) modlibpcap - modified libpcap (tcpdump) nokialibpcap - Nokia libpcap (tcpdump) lanalyzer - Novell LANalyzer ngsniffer - Network Associates Sniffer (DOS-based) snoop - Sun snoop netmon1 - Microsoft Network Monitor 1.x netmon2 - Microsoft Network Monitor 2.x ngwsniffer_1_1 - Network Associates Sniffer (Windows-based) 1.1 ngwsniffer_2_0 - Network Associates Sniffer (Windows-based) 2.00x nettl - HP-UX nettl trace visual - Visual Networks traffic capture 5views - Accellent 5Views capture niobserverv9 - Network Instruments Observer version 9 default is libpcap -h produces this help listing. -r specifies that the records specified should be kept, not deleted, default is to delete -s <snaplen> specifies that packets should be truncated to <snaplen> bytes of data -t <time adjustment> specifies the time adjustment to be applied to selected packets -T <encap type> specifies the encapsulation type to use: ether - Ethernet tr - Token Ring slip - SLIP ppp - PPP fddi - FDDI fddi-swapped - FDDI with bit-swapped MAC addresses rawip - Raw IP arcnet - ARCNET arcnet_linux - Linux ARCNET atm-rfc1483 - RFC 1483 ATM linux-atm-clip - Linux ATM CLIP lapb - LAPB atm-pdus - ATM PDUs atm-pdus-untruncated - ATM PDUs - untruncated null - NULL ascend - Lucent/Ascend access equipment isdn - ISDN ip-over-fc - RFC 2625 IP-over-Fibre Channel ppp-with-direction - PPP with Directional Info ieee-802-11 - IEEE 802.11 Wireless LAN prism - IEEE 802.11 plus Prism II monitor mode header ieee-802-11-radio - IEEE 802.11 Wireless LAN with radio information ieee-802-11-radiotap - IEEE 802.11 plus radiotap WLAN header ieee-802-11-avs - IEEE 802.11 plus AVS WLAN header linux-sll - Linux cooked-mode capture frelay - Frame Relay frelay-with-direction - Frame Relay with Directional Info chdlc - Cisco HDLC ios - Cisco IOS internal ltalk - Localtalk pflog-old - OpenBSD PF Firewall logs, pre-3.4 hhdlc - HiPath HDLC docsis - Data Over Cable Service Interface Specification cosine - CoSine L2 debug log whdlc - Wellfleet HDLC sdlc - SDLC tzsp - Tazmen sniffer protocol enc - OpenBSD enc(4) encapsulating interface pflog - OpenBSD PF Firewall logs chdlc-with-direction - Cisco HDLC with Directional Info bluetooth-h4 - Bluetooth H4 mtp2 - SS7 MTP2 mtp3 - SS7 MTP3 irda - IrDA user0 - USER 0 user1 - USER 1 user2 - USER 2 user3 - USER 3 user4 - USER 4 user5 - USER 5 user6 - USER 6 user7 - USER 7 user8 - USER 8 user9 - USER 9 user10 - USER 10 user11 - USER 11 user12 - USER 12 user13 - USER 13 user14 - USER 14 user15 - USER 15 symantec - Symantec Enterprise Firewall ap1394 - Apple IP-over-IEEE 1394 bacnet-ms-tp - BACnet MS/TP raw-icmp-nettl - Raw ICMP with nettl headers raw-icmpv6-nettl - Raw ICMPv6 with nettl headers gprs-llc - GPRS LLC juniper-atm1 - Juniper ATM1 juniper-atm2 - Juniper ATM2 redback - Redback SmartEdge rawip-nettl - Raw IP with nettl headers ether-nettl - Ethernet with nettl headers tr-nettl - Token Ring with nettl headers fddi-nettl - FDDI with nettl headers unknown-nettl - Unknown link-layer type with nettl headers mtp2-with-phdr - MTP2 with pseudoheader juniper-pppoe - Juniper PPPoE gcom-tie1 - GCOM TIE1 gcom-serial - GCOM Serial x25-nettl - X25 with nettl headers default is the same as the input file -v specifies verbose operation, default is silent A range of records can be specified as well Where each option has the following meaning: -r This option specifies that the frames listed should be kept, not deleted. The default is to delete the listed frames. -h This option provides help. -v This option specifies verbose operation. The default is silent operation. -T {encap type} This option specifies the frame encapsulation type to use. It is mainly for converting funny captures to something that Wireshark can deal with. The default frame encapsulation type is the same as the input encapsulation. -F {capture type} This option specifies the capture file format to write the output file in. The default is libpcap format. -s {snaplen} Specifies that packets should be truncated to {snaplen} bytes of data. -t {time adjustment} Specifies the time adjustment to be applied to selected packets. {infile} This parameter specifies the input file to use. It must be present. {outfile} This parameter specifies the output file to use. It must be present. [record#[-][record# ...]] This optional parameter specifies the records to include or exclude (depending on the -r option. You can specify individual records or a range of records.
<command>mergecap</command>: Merging multiple capture files into one Mergecap is a program that combines multiple saved capture files into a single output file specified by the -w argument. Mergecap knows how to read libpcap capture files, including those of tcpdump. In addition, Mergecap can read capture files from snoop (including Shomiti) and atmsnoop, LanAlyzer, Sniffer (compressed or uncompressed), Microsoft Network Monitor, AIX's iptrace, NetXray, Sniffer Pro, RADCOM's WAN/LAN analyzer, Lucent/Ascend router debug output, HP-UX's nettl, and the dump output from Toshiba's ISDN routers. There is no need to tell Mergecap what type of file you are reading; it will determine the file type by itself. Mergecap is also capable of reading any of these file formats if they are compressed using gzip. Mergecap recognizes this directly from the file; the '.gz' extension is not required for this purpose. By default, it writes the capture file in libpcap format, and writes all of the packets in both input capture files to the output file. The -F flag can be used to specify the format in which to write the capture file; it can write the file in libpcap format (standard libpcap format, a modified format used by some patched versions of libpcap, the format used by Red Hat Linux 6.1, or the format used by SuSE Linux 6.3), snoop format, uncompressed Sniffer format, Microsoft Network Monitor 1.x format, and the format used by Windows-based versions of the Sniffer software. Packets from the input files are merged in chronological order based on each frame's timestamp, unless the -a flag is specified. Mergecap assumes that frames within a single capture file are already stored in chronological order. When the -a flag is specified, packets are copied directly from each input file to the output file, independent of each frame's timestamp. If the -s flag is used to specify a snapshot length, frames in the input file with more captured data than the specified snapshot length will have only the amount of data specified by the snapshot length written to the output file. 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 frames larger than the standard Ethernet MTU, making them incapable of handling gigabit Ethernet captures if jumbo frames were used). If the -T flag is used to specify an encapsulation type, the encapsulation type of the output capture file will be forced to the specified type, rather than being the type appropriate to the encapsulation type of the input capture file. Note that 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). Help information available from mergecap $ mergecap.exe -h mergecap version 0.10.5 Usage: mergecap [-hva] [-s <snaplen>] [-T <encap type>] [-F <capture type>] -w <outfile> <infile> [...] where -h produces this help listing. -v verbose operation, default is silent -a files should be concatenated, not merged Default merges based on frame timestamps -s <snaplen>: truncate packets to <snaplen> bytes of data -w <outfile>: sets output filename to <outfile> -T <encap type> encapsulation type to use: ether - Ethernet tr - Token Ring slip - SLIP ppp - PPP fddi - FDDI fddi-swapped - FDDI with bit-swapped MAC addresses rawip - Raw IP arcnet - ARCNET arcnet_linux - Linux ARCNET atm-rfc1483 - RFC 1483 ATM linux-atm-clip - Linux ATM CLIP lapb - LAPB atm-pdus - ATM PDUs atm-pdus-untruncated - ATM PDUs - untruncated null - NULL ascend - Lucent/Ascend access equipment isdn - ISDN ip-over-fc - RFC 2625 IP-over-Fibre Channel ppp-with-direction - PPP with Directional Info ieee-802-11 - IEEE 802.11 Wireless LAN prism - IEEE 802.11 plus Prism II monitor mode header ieee-802-11-radio - IEEE 802.11 Wireless LAN with radio information ieee-802-11-bsd - IEEE 802.11 plus BSD WLAN header ieee-802-11-avs - IEEE 802.11 plus AVS WLAN header linux-sll - Linux cooked-mode capture frelay - Frame Relay frelay-with-direction - Frame Relay with Directional Info chdlc - Cisco HDLC ios - Cisco IOS internal ltalk - Localtalk pflog-old - OpenBSD PF Firewall logs, pre-3.4 hhdlc - HiPath HDLC docsis - Data Over Cable Service Interface Specification cosine - CoSine L2 debug log whdlc - Wellfleet HDLC sdlc - SDLC tzsp - Tazmen sniffer protocol enc - OpenBSD enc(4) encapsulating interface pflog - OpenBSD PF Firewall logs chdlc-with-direction - Cisco HDLC with Directional Info bluetooth-h4 - Bluetooth H4 mtp2 - SS7 MTP2 mtp3 - SS7 MTP3 irda - IrDA user0 - USER 0 user1 - USER 1 user2 - USER 2 user3 - USER 3 user4 - USER 4 user5 - USER 5 user6 - USER 6 user7 - USER 7 user8 - USER 8 user9 - USER 9 user10 - USER 10 user11 - USER 11 user12 - USER 12 user13 - USER 13 user14 - USER 14 user15 - USER 15 symantec - Symantec Enterprise Firewall ap1394 - Apple IP-over-IEEE 1394 bacnet-ms-tp - BACnet MS/TP default is the same as the first input file -F <capture type> capture file type to write: libpcap - libpcap (tcpdump, Wireshark, etc.) rh6_1libpcap - RedHat Linux 6.1 libpcap (tcpdump) suse6_3libpcap - SuSE Linux 6.3 libpcap (tcpdump) modlibpcap - modified libpcap (tcpdump) nokialibpcap - Nokia libpcap (tcpdump) lanalyzer - Novell LANalyzer ngsniffer - Network Associates Sniffer (DOS-based) snoop - Sun snoop netmon1 - Microsoft Network Monitor 1.x netmon2 - Microsoft Network Monitor 2.x ngwsniffer_1_1 - Network Associates Sniffer (Windows-based) 1.1 ngwsniffer_2_0 - Network Associates Sniffer (Windows-based) 2.00x visual - Visual Networks traffic capture 5views - Accellent 5Views capture niobserverv9 - Network Instruments Observer version 9 default is libpcap -h Prints the version and options and exits. -v Causes mergecap to print a number of messages while it's working. -a Causes the frame timestamps to be ignored, writing all packets from the first input file followed by all packets from the second input file. By default, when -a is not specified, the contents of the input files are merged in chronological order based on each frame's timestamp. Note: when merging, mergecap assumes that packets within a capture file are already in chronological order. -s Sets the snapshot length to use when writing the data. -w Sets the output filename. -T Sets the packet encapsulation type of the output capture file. -F Sets the file format of the output capture file. A simple example merging dhcp-capture.libpcap and imap-1.libpcap into outfile.libpcap is shown below. Simple example of using mergecap $ mergecap -w outfile.libpcap dhcp-capture.libpcap imap-1.libpcap
<command>text2pcap</command>: Converting ASCII hexdumps to network captures There may be some occasions when you wish to convert a hex dump of some network traffic into a libpcap file. Text2pcap is a program that reads in an ASCII hex dump and writes the data described into a libpcap-style capture file. text2pcap can read hexdumps with multiple packets in them, and build a capture file of multiple packets. text2pcap is also capable of generating dummy Ethernet, IP and UDP headers, in order to build fully processable packet dumps from hexdumps of application-level data only. Text2pcap understands a hexdump of the form generated by od -t x1. 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 - see -o), of more than two hex digits. Here is a sample dump that 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, 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 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. 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 headers before each packet. This allows Wireshark or any other full-packet decoder to handle these dumps. Help information available for text2pcap $ text2pcap.exe -h Usage: text2pcap.exe [-h] [-d] [-q] [-o h|o] [-l typenum] [-e l3pid] [-i proto] [-m max-packet] [-u srcp,destp] [-T srcp,destp] [-s srcp,destp,tag] [-S srcp,destp,tag] [-t timefmt] <input-filename> <output-filename> where <input-filename> specifies input filename (use - for standard input) <output-filename> specifies output filename (use - for standard output) [options] are one or more of the following -h : Display this help message -d : Generate detailed debug of parser states -o hex|oct : Parse offsets as (h)ex or (o)ctal. Default is hex -l typenum : Specify link-layer type number. Default is 1 (Ethernet). See net/bpf.h for list of numbers. -q : Generate no output at all (automatically turns off -d) -e l3pid : Prepend dummy Ethernet II header with specified L3PID (in HEX) Example: -e 0x800 -i proto : Prepend dummy IP header with specified IP protocol (in DECIMAL). Automatically prepends Ethernet header as well. Example: -i 46 -m max-packet : Max packet length in output, default is 64000 -u srcp,destp : Prepend dummy UDP header with specified dest and source ports (in DECIMAL). Automatically prepends Ethernet and IP headers as well Example: -u 30,40 -T srcp,destp : Prepend dummy TCP header with specified dest and source ports (in DECIMAL). Automatically prepends Ethernet and IP headers as well Example: -T 50,60 -s srcp,dstp,tag: Prepend dummy SCTP header with specified dest/source ports and verification tag (in DECIMAL). Automatically prepends Ethernet and IP headers as well Example: -s 30,40,34 -S srcp,dstp,ppi: Prepend dummy SCTP header with specified dest/source ports and verification tag 0. It also prepends a dummy SCTP DATA chunk header with payload protocol identifier ppi. Example: -S 30,40,34 -t timefmt : Treats the text before the packet as a date/time code; the specified argument is a format string of the sort supported by strptime. Example: The time "10:15:14.5476" has the format code "%H:%M:%S." NOTE: The subsecond component delimiter must be specified (.) but no pattern is required; the remaining number is assumed to be fractions of a second. -w <filename> Write the capture file generated by text2pcap to <filename>. The default is to write to standard output. -h Display the help message -d Displays debugging information during the process. Can be used multiple times to generate more debugging information. -q Be completely quiet during the process. -o hex|oct Specify the radix for the offsets (hex or octal). Defaults to hex. This corresponds to the -A option for od. -l Specify the link-layer type of this packet. Default is Ethernet(1). See 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: -l 7 for ARCNet packets. -e l3pid 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: -e 0x806 to specify an ARP packet. For IP packets, instead of generating a fake Ethernet header you can also use -l 12 to indicate a raw IP packet to Wireshark. Note that -l 12 does not work for any non-IP Layer 3 packet (e.g. ARP), whereas generating a dummy Ethernet header with -e works for any sort of L3 packet. -u srcport destport 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: -u 1000 69 to make the packets look like TFTP/UDP packets.
<command>idl2wrs</command>: Creating dissectors from Corba IDL files In an ideal world idl2wrs would be mentioned in the users guide in passing and documented in the developers guide. As the developers guide has not yet been completed it will be documented here.
What is it? As you have probably guessed from the name, idl2wrs takes a user specified IDL file and attempts to build a dissector that can decode the IDL traffic over GIOP. The resulting file is "C" code, that should compile okay as an ethereal dissector. idl2wrs basically parses the data struct given to it by the omniidl compiler, and using the GIOP API available in packet-giop.[ch], generates get_CDR_xxx calls to decode the CORBA traffic on the wire. It consists of 4 main files. README.idl2wrs This document ethereal_be.py The main compiler backend ethereal_gen.py A helper class, that generates the C code. idl2wrs A simple shell script wrapper that the end user should use to generate the dissector from the IDL file(s).
Why do this? It is important to understand what CORBA traffic looks like over GIOP/IIOP, and to help build a tool that can assist in troubleshooting CORBA interworking. This was especially the case after seeing a lot of discussions about how particular IDL types are represented inside an octet stream. I have also had comments/feedback that this tool would be good for say a CORBA class when teaching students what CORBA traffic looks like "on the wire". It is also COOL to work on a great Open Source project such as the case with "Wireshark" ( http://www.wireshark.org )
How to use idl2wrs To use the idl2wrs to generate ethereal dissectors, you need the following: Prerequisites to using idl2wrs Python must be installed. See omniidl from the the omniORB package must be available. See Of course you need ethereal installed to compile the code and tweak it if required. idl2wrs is part of the standard Wireshark distribution To use idl2wrs to generate an ethereal dissector from an idl file use the following procedure: Procedure for converting a Corba idl file into an ethereal dissector To write the C code to stdout. idl2wrs <your file.idl> eg: idl2wrs echo.idl To write to a file, just redirect the output. idl2wrs echo.idl > packet-test-idl.c You may wish to comment out the register_giop_user_module() code and that will leave you with heuristic dissection. If you don't want to use the shell script wrapper, then try steps 3 or 4 instead. To write the C code to stdout. Usage: omniidl -p ./ -b ethereal_be <your file.idl> eg: omniidl -p ./ -b ethereal_be echo.idl To write to a file, just redirect the output. omniidl -p ./ -b ethereal_be echo.idl > packet-test-idl.c You may wish to comment out the register_giop_user_module() code and that will leave you with heuristic dissection. Copy the resulting C code to your ethereal src directory, edit the 2 make files to include the packet-test-idl.c cp packet-test-idl.c /dir/where/ethereal/lives/ edit Makefile.am edit Makefile.nmake Run configure ./configure (or ./autogen.sh) Compile the code make Good Luck !!
TODO Exception code not generated (yet), but can be added manually. Enums not converted to symbolic values (yet), but can be added manually. Add command line options etc More I am sure :-)
Limitations See the TODO list inside packet-giop.c
Notes The "-p ./" option passed to omniidl indicates that the ethereal_be.py and ethereal_gen.py are residing in the current directory. This may need tweaking if you place these files somewhere else. If it complains about being unable to find some modules (eg tempfile.py), you may want to check if PYTHONPATH is set correctly. On my Linux box, it is PYTHONPATH=/usr/lib/python1.5/