The following command-line options are used to control dumpcap's data processing and output.

■ —a Test:value Instructs dumpcap to stop writing to a file when it meets the specified test condition and value. This option mirrors the functionality of —a In TShark.

■ —b Number of ring buffer files ['.duration] Used with the —a Option, causes dumpcap to continue capturing data to successive files. This option mirrors the functionality of —b In TShark.

■ —B Buffer size Available only on Windows systems, causes dumpcap to allocate a buffer for storing packet data during a capture before writing to the disk. This option mirrors the functionality of —B In TShark.

■ —c Count Sets the default number of packets to read when capturing data. This option mirrors the functionality of —c In TShark.

■ —D Instructs dumpcap to print a list of available interfaces on the system, mirroring the functionality of —D In TShark.

■ —f Capture filter expression Allows you to set the filter expression to use when capturing data, mirroring the functionality of —f In TShark.

■ —h Prints the version of dumpcap and the help options, and then exits.

■ —i Interface Specifies the interface you want to use to capture data, mirroring the functionality of —i In TShark.

■ —L Lists the data link types that are supported by an interface and then exits, mirroring the functionality of —L In TShark.

■ —P Tells dumpcap to not put the interface in promiscuous mode, mirroring the functionality of —p In TShark.

■ —s Snaplen Allows you to set the default snapshot length to use when capturing data, mirroring the functionality of —s In TShark.

■ —v Prints the dumpcap version information and exits.

■ —w File Writes the packets to the filename specified following the option, mirroring the functionality of —w In TShark.

■ —y Type Allows you to set the data link type to use while capturing packets, mirroring the functionality of —y In TShark.

Run with no command-line arguments, dumpcap will select the first available network interface and start capturing traffic, saving the contents to a libpcap file with a randomly selected filename.

Dumpcap can be useful to leverage the flexibility of capture autostop conditions and ringbuffer output files, without the overhead associated with the Wireshark GUI or the memory and CPU requirements ofTShark. For example, dumpcap can collect traffic for five minutes before stopping, saving the contents to the named libpcap file, as shown here:

C:\>dumpcap - i 2 - a duration:300 - w eventcollection. cap

The following command-line options are used to control capinfos' output.

■ —h Prints the help options of capinfos, and then exits.

■ —t Displays the capture file type as one of the supported Wireshark capture file formats, regardless of the filename extension.

■ —c Displays the number of packets in the capture file.

■ —d Displays the total length of all the packets in the file as a number of bytes.

■ —u Displays the capture file duration in seconds.

■ —a Displays the capture start time.

■ —e Displays the capture end time.

■ —y Displays the average data rate in bytes per second.

■ —i Displays the average data rate in bits per second.

■ —h Displays the average packet size in bytes.

Capinfos can be run with only a filename as a command-line parameter, and will display all the available statistics, as shown here:

C:\>capinfos all-ml. dump File name: all-ml. dump

File type: libpcap (tcpdump, Ethereal, etc.)

Number of packets: 282905

File size: 41418290 bytes

Data size: 56143385 bytes

Capture duration: 7579.713771 seconds

Start time: Mon Sep 15 09:44:53 2003

End time: Mon Sep 15 11:51:13 2003

Data rate: 7407.06 bytes/s

Data rate: 59256.47 bits/s

Average packet size: 198.45 bytes

The beginning of each line has an offset of more than two hexadecimal, or octal, digits that is used to track the bytes in the output. If the offset is 0, this indicates the beginning of a new packet. If there are multiple packets in a file, they will be output to the packet capture file with one second between each packet. If a line doesn't have this offset, it is ignored. The text output at the end of the line is also ignored. Text files can also contain comments that begin with the # character. text2pcap has the capability to support commands and options by using the #TEXT2PCAP Command at the beginning of the line. text2pcap currently doesn't have any commands and options supported, but future development could incorporate methods to control the way the hexadecimal dump is processed.

The following command-line options are used to control text2pcap's data processing and output.

■ —h Prints the help options of text2pcap, and then exits.

■ —d Displays debugging information during the processing. Like verbose options, it can be used several times for more information.

■ —q Causes text2pcap to be quiet while processing.

■ —o h|o Specifies either hexadecimal or octal formats for the offset of the output. The default is hexadecimal.

■ —l Typenum Lets you specify the data link layer type of encapsulation for the packet. This option is used when your hexdump is a complete, encapsulated packet. The encapsulation type is specified as a number using the Typenum Parameter. A complete list of encapsulation types and their associated numbers can be found in the /libpcap-0.7.2/bpf/net/bpf. h file included in the libpcap source distribution. For example, Point-to-Point Protocol (PPP) is encapsulation type 9. The default is Ethernet, encapsulation type 1.

■ —e l3pid Allows you to include a dummy Ethernet header for each packet. You would use this option when your dump file has any type of Layer 3 header, such as IP, but no Layer 2 information.

■ —i Proto Allows you to include a dummy IP header for each packet. The Proto Parameter allows you to specify the IP protocol in decimal format. You would use this option when your dump file has complete Layer 4 information, but no Layer 3 IP information. This option will also include the necessary Ethernet information. For example, —i 88 Will set the set the protocol to Enhanced Interior Gateway Routing Protocol (EIGRP).

■ —m Max-packet Allows you to set the maximum packet length with the Max-packet Parameter. The default is 64000.

■ —u Srcport, destport Allows you to include a dummy UDP header for each packet. The Srcport And Destport Parameters allow you to specify the source and destination UDP ports in decimal format. You would use this option when your dump file does not contain any UDP Layer 4 or below information. This option will also include the necessary IP and Ethernet information.

■ —T Srcport, destport Allows you to include a dummy TCP header for each packet. The Srcport And Destport Parameters allow you to specify the source and destination TCP ports in decimal format. You would use this option when your dump file does not contain any TCP Layer 4 or below information. This option will also include the necessary IP and Ethernet information.

■ —s Srcport, destport, tag Allows you to include a dummy Stream Control Transmission Protocol (SCTP) header for each packet. The Srcport And Dest-port Parameters allow you to specify the source and destination SCTP ports in decimal format. The Tag Parameter allows you to specify a verification tag. You would use this option when your dump file does not contain any SCTP Layer 4 or below information. This option will also include the necessary IP, Ethernet, and CRC32C checksum information.

■ —S Srcport, destport, ppi Allows you to include a dummy SCTP header for each packet. The Srcport And Destport Parameters allow you to specify the source and destination SCTP ports in decimal format. The Ppi Parameter allows you to specify a payload protocol identifier for a dummy SCTP DATA chunk header. The verification tag will automatically be set to 0.You would use this option when your dump file does not contain any SCTP Layer 4 or below information. This option will also include the necessary IP, Ethernet, and CRC32C checksum information.

■ —t Timefmt Allows you to specify a time format for the text before the packet. The Timefmt Parameter follows the format of strptime(3), such as "%H:%M:%S.", which converts a character string to a time value.

The following is an example of using text2pcap to read a hexadecimal dump, Hex_sample. txt, And output it to the Libpcap_output File.

C:\Program Files\Wireshark>text2pcap hex_sample. txt libpcap_output

Input from: hex_sample. txt

Output to: libpcap_output

Wrote packet of 168 bytes at 0

Read 1 potential packets, wrote 1 packets

The next example uses text2pcap to read a file with multiple hexadecimal packets, Hex_sample2.txt, And output the format as Telnet/TCP packets to the Libpcap_output2 File.

C:\Program Files\Wireshark>text2pcap - T 1297,23 hex_sample2.txt libpcap_output2

Input from: hex_sample2.txt

Output to: libpcap_output2

Generate dummy Ethernet header: Protocol: 0x800 Generate dummy IP header: Protocol: 6

Generate dummy TCP header: Source port: 1297. Dest port: 23

Wrote packet of 62 bytes at 0

Wrote packet of 62 bytes at 62

Wrote packet of 60 bytes at 124

Wrote packet of 69 bytes at 184

Output removed

Read 76 potential packets, wrote 76 packets

The od command can also be piped into the text2pcap program. text2pcap will then read the output of the od command as standard input. The next example uses

Text2pcap to read a data stream as input, and output the format as HTTP/TCP packets to the output. pcap file. The —Ax Parameter to the od command prints the offsets as hexadecimal. The —m1460 Parameter to text2pcap specifies a maximum packet size of 1460 bytes. The maximum Ethernet packet size is 1500 bytes, minus the 20 bytes for the IP and TCP headers, leaves 1460 bytes for the data. By default, the —T Parameter will create TCP, IP, and Ethernet dummy headers. The following shows the command and associated output.

[root@localhost root]# od - Ax - tx1 input | text2pcap -m1460 - T1234,80 - output. pcap

Input from: Standard input Output to: output. pcap

Generate dummy Ethernet header: Protocol: 0x800 Generate dummy IP header: Protocol: 6

Generate dummy TCP header: Source port: 1234. Dest port: 80

Wrote packet of 1460 bytes at 0

Wrote packet of 1460 bytes at 1460

Wrote packet of 1460 bytes at 2920

Wrote packet of 788 bytes at 4380

Read 4 potential packets, wrote 4 packets

By default, editcap writes all of the packets in the capture file to the output file. If you specify a list of packet numbers on the command line, those packets will Not Be written to the output capture file. If the —r Option is specified, it will reverse the default configuration and write only the specified packets to the output capture file. You can also specify a range of packets to include or exclude in the output capture file.

The following information is the usage output for the editcap program.

C:\Program Files\Wireshark>editcap

Usage: editcap [-r] [-h] [-v] [-T <encap type>] [-E <probability>]

[-F <capture type>] [-s <snaplen>] [-t <time adjustment>] [-c <packets per file>]

<infile> <outfile> [ <record#>[-<record#>] ... ]

Where

-c <packets per file> If given splits the output to different files

-E <probability> specifies the probability (between 0 and 1) that a particular byte will have an error. - F <capture type> specifies the capture file type to write: libpcap - libpcap (tcpdump, Ethereal, 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) nseclibpcap - Nanosecond libpcap (Ethereal) 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 rf5 - Tektronix K12xx 32-bit. rf5 format 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-8 02-11-radio - IEEE 802.11 Wireless LAN with radio

Information

Ieee-8 02-11-radiotap - IEEE 802.11 plus radiotap WLAN header ieee-8 02-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

Juniper-mlppp - Juniper MLPPP

Juniper-mlfr - Juniper MLFR

Juniper-ether - Juniper Ethernet

Juniper-ppp - Juniper PPP

Juniper-frelay - Juniper Frame-Relay juniper-chdlc - Juniper C-HDLC default is the same as the input file - v specifies verbose operation, default is silent

A range of records can be specified as well

The following command-line options are used to control editcap's data translation and output.

■ —F Type Used to set the format of the output capture file. For example, if you want to save a file in the Sun snoop format so snoop can read the capture file, you would use the —F snoop Option.

■ —h Prints the help options of editcap, and then exits.

■ —r Causes the packets whose numbers are specified on the command line to be written to the output capture file. This is opposite of the default action, which is to remove the packets that are specified on the command line. Packets can only be specified as a consecutive range in the Start-end Format, or individually; they cannot be comma delimited.

■ —s Snaplen Sets the snapshot length to use when writing the data to the output capture file. Packets that are larger than the Snaplen Will be truncated. This option is helpful if you only want to save the packet headers, or if the program you will be importing the capture file into can only read packets of a certain size.

■ —t [-]seconds[.fractional seconds] Allows you to specify a time adjustment to apply to selected frames in the output capture file. The time adjustment is specified in seconds and fractions of seconds. An option of —t 3600 Will advance the timestamp on the selected frames by one hour, while the option of —t —3600 Will reduce the timestamp on the selected frames by one hour. This option is useful when you need to synchronize packet traces with other logs from different devices.

■ —T Type Sets the packet encapsulation type of the output capture file. The default type is the same encapsulation type as the input file. This option forces the encapsulation type of the output capture file to be a specified type; however, the packet headers will remain the same encapsulation type as the input capture file. This is because the encapsulation type is stored as meta-data, outside of the packet data. The encapsulation type is a single

Variable that is changed, thus allowing the packet data and headers of the original packet to remain unchanged.

■ —v Causes editcap to print various messages to the screen while it is processing files.

The following is an example of using editcap to translate the first five packets, and packets 10, 15, and 17 from a TShark libpcap capture file called Capture To a Sun snoop output file called Capture_snoop.

C:\Program Files\Wireshark>editcap - r - v -F snoop capture capture_snoop 1-5 10 15 17

File capture is a libpcap (tcpdump, Wireshark, etc.) capture file.

The next example uses editcap to copy all packets, except packets 5 through 120, from a libpcap capture file called Capture To a libpcap output file called Capture_out.

C:\Program Files\Wireshark>editcap - v capture capture_out 5-120

File capture is a libpcap (tcpdump, Wireshark, etc.) capture file.

Add_Selected: 5-120

Inclusive... 5, 120

Record: 1

Record: 2

Record: 3

Record: 4 Record: 121 Record: 122

The next example uses editcap to adjust the timestamp forward by five and a half seconds on all packets. It uses an NAI Sniffer capture file called Capture. dump As input and saves the output to a Novell LANalyzer file called Capture_out.

C:\Program Files\Wireshark>editcap - v - F lanalyzer - t 5.5 capture. dump capture_out

The next example uses editcap to save the first 35 bytes of the input capture file called Capture To the output capture file called Capture_out. This Will include the full Ethernet and IP headers in the output file.

C:\Program Files\Wireshark>editcap - v - s 35 capture capture_out File capture is a libpcap (tcpdump, Wireshark, etc.) capture file.

The next example uses editcap to translate the input capture file called Capture To the output capture file called Capture_out With an encapsulation type of IEEE 802.11 Wireless LAN.

C:\Program Files\Wireshark>editcap - v - T ieee-802-11 capture capture_out

File capture is a libpcap (tcpdump, Wireshark, etc.) capture file.

Record: 1

Record: 2

Record: 3

Record: 4

Record: 5

Record: 6

Record: 7

Record: 8

Record: 9

Record: 10

Output removed

Fortunately, TShark can collect and display statistical information for live or stored packet captures, supplying basic analysis information and detailed protocol information. By specifying the Z Flag with TShark, you can specify one or more of several supported statistics reporting options. The format of the statistics reporting options uses the following convention:

-z Major name, minor name, option(s), filter

In this example where -z Is the command-line option to TShark, instructing it to expect a statistics reporting option, and Major And Minor name Are one of several available statistics reporting options. Following the minor statistics reporting name are one or more options specific for the selected statistics option. At the end of each statistics reporting option, you can specify a filter string that will cause the statistics reporting to be applied only to the packets matching the specified filter. As of Wireshark 0.99.4, 30 unique statistics reporting options are available. We've provided detailed explanations of several of the most commonly used statistics reporting options in the following section.

Chapter 9 • Other Programs Packaged with Wireshark

A

Tip_

By default, TShark will print a one-line summary for each packet received. When examining statistical information by using the -z Option, you may want to suppress this information and show only the statistics reporting by adding the -q Option as well.

Protocol Hierarchy Statistics

Syntax: -z io, phs[,Filter]

Description: The protocol hierarchy statistics (PHS) option reports a summary of the protocols identified in the packet capture, and the number of packets and bytes for each protocol. Optionally, specify a display filter to report protocol hierarchy and traffic statistics for an identified group of frames.

Example: The following is an example of using the TShark statistics function to display a report of all bytes and frames for each protocol detected during a live capture on the first available interface, disabling name resolution and the packet summary output, and reporting the collected statistics after ending the capture by typing Ctrl + C.

C:\Program Files\Wireshark>tshark - nqz io, phs <cntrl-c>

===================================================================

Protocol Hierarchy Statistics Filter: frame

Frame eth ip

Udp dns data isakmp

Tcp http

Llc ipx

Ipxsap

Frames:560 bytes:115233 frames:560 bytes:115233 frames:558 bytes:115005 frames:53 bytes:10383 frames:21 bytes:3215 frames:8 bytes:4 96 frames:24 bytes:6672 frames:505 bytes:104622 frames:107 bytes:81798 frames:2 bytes:228 frames:2 bytes:228 frames:2 bytes:228

===================================================================

Protocol Statistics by Interval

Syntax: -z Io, stat, interval[,filter][,filter][,filter]... Description: The protocol statistics by interval option reports a summary of the number of frames and bytes recorded in the capture file for each specified interval duration. The interval must be specified in a duration of seconds as a whole or a fractional number of seconds. The output of the statistics reporting will contain one or more columns; by default, with no display filter specified, the first column will indicate the statistics for the entire contents of the packet capture. If one or more display filters are specified, the results of each will be displayed in the first and successive columns. This allows you the quickly examine the nature of traffic for the entire packet capture, and the results of one or more display filters.

The protocol statistics by interval option can also report statistics based on calculations, including count() , sum() , min() , max() , and avg() using the following convention in the place of a display filter:

Where <field> is the name of a display field you wish to apply the calculations on, and <filter> is a display filter that includes the specified field name. Note that you can only perform the calculations on fields that are integers or relative time fields, and the display filter must include the named field in the filter syntax. Example: The following example demonstrates TShark statistics by interval reporting while reading from a stored packet capture file named Kismet-Sep-06-2005.dump in five-minute (300 second) intervals for both the entire capture file (denoted with the globally matching display filter frame) and the results of the display filter ip. addr eq 10.18.129.130, while suppressing the standard display output.

C:\>tshark - r Kismet-Sep-06-2 005.dump - z io, stat,300,"frame","ip. addr eq 10.18.12 9.130" - q

IO Statistics interval: 300.000 secs Column #0: frame

Column #1: ip. addr eq 10.18.129.130

[COUNTJSUMJMINJMAX|AVG](<fleld>)<fllter>

Column #0

Column #1

Time

|frames| bytes |frames| bytes

000.000-300.000

82

5874

0

0

300.000-600.000

248

18104

8

928

Tip_

When specifying display filters using command-line tools, use the alphabetic comparison operators (eq, ne, lt, gt). This will prevent your shell from interpreting meta-characters such as the exclamation mark.

The next example of statistics interval reporting reports the average frame size (using the display filter frame. pkt_len), the smallest frame size, and the maximum frame size in five-minute intervals.

C:\>tshark - r wireless-rwc-1.cap - qz

Io, stat,300,AVG(frame. pkt_len)frame. pkt_len, MIN(frame. pkt_len )frame. pkt_len, MAX(frame. pkt_len)frame. pkt_len

IO Statistics Interval: 300.000 secs

Column #0: AVG(frame. pkt_len)frame. pkt_len Column #1: MIN(frame. pkt_len)frame. pkt_len Column #2: MAX(frame. pkt_len)frame. pkt_len

| Column #0 | Column #1 | Column #2

Time | AVG | MIN | MAX

000.000-300.000 71 58 82

300.000-600.000 73 58 116

600.000-900.000 74 54 608

Conversation Statistics

Syntax: -z conv, Type [, filter]

Description: The conversation statistics reporting option will display the conversations between stations in the capture file of the specified type, matching the specified display filter or all traffic if the display filter is omitted. Currently supported conversation types are:

■ eth Ethernet

■ fc Fiber channel

■ fddi FDDI

■ ip IP addresses

■ ipx IPX addresses

■ tcp TCP/IP socket pairs

■ tr Token ring

■ udp UDP/IP socket pairs

This option is useful to assess the conversations between stations on the net-work. This is a common technique for analyzing traffic for signs of worm activity, since an infected station will often scan large quantities of hosts to look for additional infection targets, as opposed to stations that are not infected, which typically restrict their conversations to a small number of hosts.

Example: This example reads from the capture file defcon. dump and collects statistics for IP conversations, using the display filter ip. addr eq 216.250.64.68, which will restrict the statistics to conversations from this host (output of this command has been trimmed for space).

$ tshark - r defcon. dump - nqz conv, ip,"ip. addr eq 216.250.64.68"

IPv4 Conversations Filter:ip. addr eq 216.250.64.68

| <- | | -> | | Total |

|Frames Bytes| |Frames Bytes| |Frames Bytes|

Packet Length Distribution

Syntax: -z plen, tree[,Filter]

Description: The packet length distribution reporting option will identify the distribution of frames in the capture file by 20-byte increments, identifying the rate and percentage of each packet length group. This feature can be helpful in network troubleshooting, where large quantities of small packets can place additional burden on networking equipment that leads to reduced throughput. Example: The following example reads from the dc11.dump capture file and reports the distribution of packet sizes. This particular capture has an unusually large quantity of frames between 40 and 79 bytes in length, which might warrant further analysis.

C:\>tshark - r dc11.dump - nqz plen, tree

===================================================================

Packet Length

Packet Length 0-19 20-39 40-79 80-159 160-319 320-639 640-1279 1280-2559 2560-5119 5120-

Value

Rate

664070

0 0

494456 114463 16117 13583 3597 21854 0 0

0.001293 0.000000 0.000000 0.000962 0.000223 0.000031 0.000026 0.000007 0.000043 0.000000 0.000000

Percent

0.00% 0.00% 74.46% 17.24% 2.43% 2.05% 0.54% 3.29% 0.00% 0.00%

Destinations Tree

Syntax: -z dests, tree,Filter

Description: The Destinations Tree statistics option identifies the number of frames, data rate, and transport-layer protocol information for the specified capture file. This report allows you to quickly assess the activity in the capture file, characterizing the nature of traffic to destination hosts.

Example: The following example reads from the Http. cap capture file and identifies the destination addresses, transport protocol, and the percentage of network activity by destination address.

C:\>tshark - r Http. cap - nqz dests, tree

===================================================================

Destinations

Value

Rate

Destinations 145.254.160.237 TCP 80 UDP

43 20 19 19 1

0.001415 0.000658 0.000625

0.000625 0.000033

Percent

46.51%

95.00% 100.00%

5.00%

53 1 0.000033 100.00%

65.208.228.223 18 0.000592 41.86%

TCP 18 0.000592 100.00%

3372 18 0.000592 100.00%

145.253.2.203 1 0.000033 2.33%

UDP 1 0.000033 100.00%

3009 1 0.000033 100.00%

216.239.59.99 4 0.000132 9.30%

TCP 4 0.000132 100.00%

3371 4 0.000132 100.00%

Packet Summary Columns

Syntax: -z proto, colinfo,Filter, field

Description: The packet summary columns statistics option allows you to add any Wireshark protocol field to the one-line display output. By default, TShark will display several fields in the one-line display output when processing a packet capture. If you require additional fields to be reported, you can specify additional fields to be reported as well, giving us tremendous reporting flexibility that can be sent to other scripting tools to extract and use the reported data. This parameter can be specified multiple times on the command line to add an arbitrary number of additional columns. Note that it is necessary to include the field you wish to append to the packet summary output in the display filter string.

Example: The following example reads from the Http. cap capture file and reports the standard summary output.

C:\>tshark - r Http. cap - n

1 0.000000 145.254.160.237 -> 65.208.228.223 3372 > 80 [SYN] Seq=0 Len=0 MSS=1460

2 0.911310 6 5.208.228.223 -> 145.254.160.237 80 > 3372 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1380

3 0.911310 145.254.160.237 -> 65.208.228.223 3372 > 80 [ACK] Seq=1 Ack=1 Win=9660 Len=0

The next example uses the packet summary columns feature to add the IP identification and time-to-live values to the summary output.

C:\>tshark - r Http. cap - nz proto, colinfo, ip. ttl, ip. ttl - z proto, colinfo, ip. id, ip. id

1 0.000000 145.254.160.237 -> 6 5.208.228.223 3372 > 80 [SYN] MSS=1460 ip. id == 0x0f41 ip. ttl == 128

Seq=0 Len=0

2 0.911310 65.208.228.223 -> 14 5.254.160.237 80 > 3372 [SYN, Ack=1 Win=5840 Len=0 MSS=1380 ip. id == 0x0000 ip. ttl == 47

ACK] Seq=0

3 0.911310 145.254.160.237 -> 65.208.228.223 3372 > 80 [ACK] Win=9660 Len=0 ip. id == 0x0f44 ip. ttl == 128

Seq=1 Ack=1

SIP Statistics

Syntax: -z sip, stat,Filter

Description: The Session Initialization Protocol (SIP) statistics reporting option will identify all the SIP traffic in the capture and report the number of sent and resent messages, the status codes from SIP responses, and the observed SIP messages. This reporting option is helpful to assess the activity on voice over IP (VoIP) networks that use the SIP protocol for call setup and teardown. By default, statistics are reported on all SIP activity in the capture; note that you can supply a display filter to limit the statistics reporting to a single host (such as ip. addr eq 192.168.1.1). Example: The following example reads from the sip1.dump stored capture file and reports the observed SIP statistics for all hosts:

C:\>tshark - r sip1.dump - nqz sip, stat

SIP Statistics

Number of SIP messages: 37 Number of resent SIP messages: 0

* SIP Status Codes in reply packets

SIP 407 Proxy Authentication Required : 1 Packets

SIP 200 OK : 10 Packets

SIP 100 Trying : 4 Packets

SIP 180 Ringing : 2 Packets

* List of SIP Request methods INVITE : 9 Packets BYE : 2 Packets ACK : 9 Packets

H.225 Counters

Syntax: -z h22 5,counter[,filter]

Description: VoIP networks using H.323 also use the H.225 protocol for call establishment and control (signaling) and registration, admission and status functions (RAS). The H.225 counters statistics will count H.225 messages in the capture and the reason codes associated with the messages. By default, all H.225 messages will be used for reporting, but you may optionally supply a display filter to restrict the analysis to a specified group of packets.

Example: The following example reads from the specified compressed capture file and reports observed H.225 statistics.

C:\>tshark - r rtp_example. raw. gz - nqz h225,counter

================== H225 Message and Reason Counter ==================

RAS-Messages: Call Signalling: setup : 1

CallProceeding : 1 connect : 1 alerting : 1

H.225 Service Response Time

Syntax: -z h22 5,srt[ ,/ilter]

Description: Another H.225 statistics reporting mechanism, the H.225 Service Response Time (SRT) statistics option reports the RAS message type; minimum, maximum, and average SRT metrics; the number of open requests (that have not yet received a response); discarded requests; and duplicate messages. Each of these statistics can be useful for analyzing activity on VoIP networks to identify traffic patterns and metrics that could negatively influence VoIP service.

Media Gateway Control Protocol Round Trip Delay

Syntax: -z mgcp, rtd[ ,/ilter]

Description: The Media Gateway Control Protocol (MGCP) is used in VoIP networks as an intermediary between traditional telephone circuits and data packets. Using this statistics reporting option, you can identify the response time delay (RTD) between stations and the MGCP server, and duplicate requests and responses, requests to unresponsive servers, and responses that do not match any requests.

SMB Round Trip Data

Syntax: -z smb, rtt[ ,/ilter]

Description: The Server Message Blocks (SMB) protocol is a mechanism used for networked file systems, predominately used for Microsoft Windows clients. Using the SMB Round Trip Data (RTD) statistics reporting option, we can assess the responsiveness of Windows file-sharing servers and other SMB resources (including some networked printers) to identify the responsiveness of server resources. Example: In this example, the packet capture file rtl-fileshare. dump is read using TShark to report SMB RTT statistics. Note that the Max RTT for the SMB Trans request in this output may indicate a burdened server resource that is unable to respond to the request sooner.

$ tshark - r rtl-fileshare. dump - nqz smb, rtt

SMB RTT Statistics: Filter:

SMB Security Identifier Name Snooping

Syntax: -z smb, sids

Description: Another SMB analysis feature is the capability to use security identifier (SID) snooping techniques to identify potentially sensitive SIDs and their associated account names. This feature can be useful when performing a security audit of traffic captured from a Windows network, representing information that is valuable to an attacker for impersonating a legitimate user.

Because of the sensitive nature of this feature, the SMB SID snooping feature is not enabled by default. To use this statistics reporting option on the command line, you must also enable the Snoop SID preference in Wireshark by clicking Edit | Preferences | Protocols | SMB | Snoop SID to name mappings, Or specify the preference on the command line with - o smb. sid_name_snooping:TRUE.

BOOTP Statistics

Syntax: -z bootp, stat,[fiilter]

Description: TShark can report statistics for the BOOTP protocol used by DHCP, including the DHCP message and the number of packets for each type. This can be helpful to troubleshoot DHCP server problems, or to diagnose rogue (e. g., unauthorized) DHCP servers that may exist on your network.

Example: The following example reads from a stored capture file and identifies the BOOTP statistics in the file, identifying the DHCP server message types and packet counts. Note that the tailing comma after the Stat Keyword is required, even though a display filter is not specified in this example.

$ tshark - nqr rtl-fileshare. dump - z bootp, stat,

===================================================================

BOOTP Statistics with filter BOOTP Option 53: DHCP Messages Types: DHCP Message Type Packets nb

Inform 74 ACK 2 75 Release 10 NAK 82 Decline 25 Request 1255 Discover 1811 Offer 279

===================================================================

HTTP Statistics

Syntax: -z http, stat,[fiilter]

Description: TShark can report statistics for the HTTP transactions, identifying the status response codes and request methods observed in the capture file. This feature can be useful to quickly identify how a particular Web server is being used, identifying errors being returned from the server.

Example: The following example reads from a stored capture file and identifies the observed HTTP statistics. Note that the tailing comma after the Stat Keyword is required, even though a display filter is not specified in this example.

$ tshark - r Kismet-Aug-01-2 002-2.dump - nqz http, stat,

===================================================================

HTTP Statistics

* HTTP Status Codes in reply packets

* List of HTTP Request methods SEARCH 336 GET 1447 POST 8 HEAD 2

===================================================================

HTTP Tree Statistics

Syntax: -z http, tree[,Filter]

Description: In addition to the HTTP statistics reporting feature, TShark can also present a tree-like view of HTTP activity, identifying the types of request and response packets, the quantities of each type, data rates, and overall percentages of all request and response types. This feature is also helpful at identifying how a Web

Server is being used, and can even identify potentially malicious activity with unsupported or broken HTTP requests or responses.

Example: The following example reads from a stored capture file and reports HTTP statistics in the tree-like view.

C:\>tshark - r Kismet-Aug-01-2 002-2.dump - nqz http, tree

===================================================================

HTTP/Packet Counter

Value

Rate

Percent

Total HTTP Packets HTTP Request Packets SEARCH GET POST HEAD

HTTP Response Packets

8067 1793 336 1447 8 2

1296

0

121 121

689 685 4

479 452 24 3

7

4 1 2

0

4978

0.001504 0.000334 0.000063 0.000270 0.000001 0.000000 0.000242 0.000000 0.000023

0.000023 0.00012 8 0.000128 0.000001 0.00008 9 0.000084 0.000004 0.000001 0.000001 0.000001 0.000000 0.000000 0.000000 0.000928

22.23% 18.74% 8 0.70% 0.45% 0.11% 16.07% 0.00% 9.34% 100.00% 53.16% 99.42% 0.58% 3 6.96% 94.36% 5.01% 0.63% 0.54% 57.14% 14.2 9% 28.57% 0.00% 61.71%

===================================================================

HTTP Request Statistics

Syntax: -z http_req, tree[,Filter]

Description: If you wish to get more detailed reporting of activity with an HTTP server, you can use TShark's HTTP Request statistics reporting option, which will identify all the HTTP request URLs for each HTTP server in the packet capture, including the number of frames, data rate, and request percentage. This is useful to identify popular requests for a specific server (the HTTP requests that are most popular will have the highest percentage values for each server). This option is often used with a display filter to assess the activity for one or more hosts, but can also be used without a display filter to identify the servers and URLs requests by client systems within your organization.

Example: The following example reads from a stored capture file and reports HTTP request statistics in the tree-like format, limiting the analysis to traffic to or from the host at 66.207.160.150.

C:\>tshark - r Kismet-Aug-01-2 002-2.dump - nqz http_req, tree,"ip. addr eq 66.207.60.150"

Notes from the Underground...

XML Compatible Protocol Dissection

A new feature to TShark in version 0.10.0 is the ability to display output in PDML format by using the -T pdml Option. The Politecnico Di Torino group, known for Analyzer and WinPcap, created the PDML specification. PDML is a simple language to format information related to packet decodes. The PDML data TShark produces differs slightly from the specification and is not readable by Analyzer. The TShark PDML output contains the following flags:

■ <pdml> This PDML file is delimited by the <pdml> and </pdml> tags. This tag does not have any attributes.

Example: <pdml version="0" creator="Wireshark/0.10.0">

■ <packet> A PDML file can contain multiple packets by using the <packet> element. This tag does not have any attributes.

■ <proto> A packet can contain multiple protocols, designated by the <proto> element. The <proto> tag can have the following attributes:

■ name The display filter name for the protocol.

■ showname The label used to describe this protocol in the protocol tree.

■ pos The starting offset within the packet data where this protocol starts.

■ size The number of octets in the packet data this protocol covers.

Example: <proto name="ip" showname="Internet Protocol, Src Addr: 192.168.100.132

(192.168.100.132), Dst Addr: 192.168.129.201 (192.168.129.201)" size="20" pos="14">

■ <field> A protocol can contain multiple fields, designated by the <field> element. The <field> tag can have the following attributes:

■ name The display filter name for the field.

■ showname The label used to describe this field in the protocol tree.

■ pos The starting offset within the packet data where this field starts.

Continued

■ size The number of octets in the packet data this field covers.

■ value The actual packet data, in hex, this field covers.

■ show The representation of the packet data as it appears in a display filter.

Example: <field name="ip. version" showname="Version: 4" size="1"

Pos="14" show="4" value="45"/>

Two tools are provided in the Wireshark-0.10.0a/tools directory to assist with PDML output parsing. WiresharkXML. py is a Python module used to read a PDML file and call a specified callback function. msnchat is a sample program that uses WiresharkXML to parse PDML output for MSN chat conversations. It takes one or more capture files as input, invokes TShark with a specified read filter, and produces HTML output of the conversations. The usage output for msnchat is as follows:

[root@localhost tools]# ./msnchat - h msnchat [OPTIONS] CAPTURE_FILE [...]

-o FILE name of output file

-t TSHARK location of TShark binary

-u USER name for unknown user

The following command can be used to read and parse a saved capture file called msn_test1.

[root@localhost tools]# ./msnchat - o outfile msn_test1

When viewed with a Web browser, the HTML outfile looks like this:

---- New Conversation @ Dec 30, 2003 14:21:08 ----

(14:21:08) Luke: hello

(14:21:22) Unknown: how are you?

(14:21:53) Luke: are we meeting at noon?

(14:22:03) Unknown: yes, at the secret location.

(14:22:11) Luke: great, see you then

(14:22:17) Unknown: ok

(14:22:18) Unknown: bye

You can add a name for the Unknown user by typing the command:

[root@localhost tools]# ./msnchat - o outfile - u Leia msn_test1

The HTML output would then look like this:

Continued

---- New Conversation @ Dec 30, 2003 14:21:08 ----

The msnchat code will give you a good idea of how to write your own scripts to parse capture files, manipulate the PDML data, and print the output in HTML format.

The following information is the usage output for the TShark program. Notice the various types of formats in which TShark can save files by using the —F option:

$ tshark - h

TShark 0.99.4 (SVN Rev 19507) Dump and analyze network traffic.

See Http://www. wireshark. org for more information

Copyright 1998-2006 Gerald Combs <Gerald@wireshark. org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Usage: tshark [options] ...

Capture interface:

-i <interface> name or idx of interface (def: first non-loopback)

-f <capture filter> packet filter in libpcap filter syntax

-s <snaplen> packet snapshot length (def: 65535)

-p don't capture in promiscuous mode

-y <link type> link layer type (def: first appropriate)

-D print list of interfaces and exit

-L print list of link-layer types of iface and exit

Capture stop conditions: - c <packet count> - a <autostop cond.>

Capture output:

-b <ringbuffer opt.>

Input file: - r <infile>

Stop after n packets (def: infinite) duration:NUM - stop after NUM seconds filesize:NUM - stop this file after NUM KB files:NUM - stop after NUM files

Duration:NUM - switch to next file after NUM secs filesize:NUM - switch to next file after NUM KB files:NUM - ringbuffer: replace after NUM files

Set the filename to read from (no pipes or stdin!)

Processing:

-R <read filter> packet filter in Wireshark display filter syntax

-n disable all name resolutions (def: all enabled)

-N <name resolve flags> enable specific name resolution(s): "mntC"

-d <layer_type>==<selector>,<decode_as_protocol> ...

"Decode As", see the man page for details Example: tcp. port==8888,http

Output:

-w <outfile|->

-F <output file type>

-V - x

-T pdml|ps|psml|text

-t ad|a|r|d first)

-l

-q

Statistics)

-X <key>:<value> - z <statistics>

Set the output filename (or '-' for stdout) set the output file type, default is libpcap an empty "-F" option will list the file types add output of packet tree (Packet Details)

Add output of hex and ASCII dump (Packet Bytes) output format of text output (def: text) output format of time stamps (def: r: rel. to

Flush output after each packet

Be more quiet on stdout (e. g. when using

EXtension options, see the man page for details various statistics, see the man page for details

Miscellaneous:

-h display this help and exit

-v display version info and exit

-o <name>:<value> ... override preference setting

The following command-line options are used to control TShark's data capture and output:

■ Capture Interface Options

■ —i Interface Specifies the interface you want to use to capture data. The —D option can be used to find out the names of your network inter-faces. You can use the number or the name as a parameter to the —i Option. If you run TShark without the —i option, it will search the list of interfaces and choose the first non-loopback interface it finds. If it doesn't find any non-loopback interfaces, it will use the first loopback interface. If this doesn't exist, TShark will exit with an error.

■ —f Capture filter expression Allows you to set the filter expression to use when capturing data. For example, Tshark - f tcp port 80 Will only capture incoming and outgoing HTTP packets.

■ —s Snaplen Allows you to set the default snapshot length to use when capturing data. The parameter Snaplen Specifies the length, in bytes, of each network packet that will be read or saved to disk. The default Snaplen Is 65535 bytes, which should be large enough to capture the entire frame contents for all data link types.

■ —p Tells TShark to not put the interface in promiscuous mode. This will cause TShark to only read traffic sent to and from the system on which TShark is running, broadcast traffic, and multicast traffic.

■ —y Type Allows you to set the data link type to use while capturing packets. You can use the —L Option to lists the data link types that are supported by an interface.

■ —D Instructs TShark to print a list of available interfaces on the system. It will print the interface number, name, and description and then return to the command prompt. You can then supply the number or the name to the —i Flag to specify an interface on which to capture data. Specifying this option causes TShark to open and attempt to capture on each interface it finds. It will only display the

Interfaces on which this was successful. Also, if you need to be logged in as root to run TShark but are not, this option will not display any available interfaces.

■ —L Lists the data link types that are supported by an interface and then exits. You can specify an interface to use, or TShark will choose the first one it finds as stated in the —i Option information.

■ Capture Stop Options

■ —c Count Sets the default number of packets to read when capturing data. For example, if you only want to capture 100 packets you would specify —c 100.

■ —a Test:value Used when capturing to a file. It specifies to TShark when to stop writing to the file. The criterion is in the form Test:value, Where test is either Duration Or File size. Duration will stop writing to a file when the specified number of seconds have elapsed, and file size will stop writing to a file after a size of Value Kilobytes has been reached.

■ Capture Output Option

■ —b Number of ring buffer files ['.duration] Used with the —a Option, and causes TShark to continue capturing data to successive files. This is known as Ring buffer Mode and will keep saving files up to the number specified within the option. When the first file reaches the maximum size, as specified with the —a Option, TShark will begin writing to the next file. When all files are full, it will continue to write new files as it removes the older ones. However, if the Number of files Is specified as 0, the number of files TShark writes to will be unlimited, and will only be restricted to the size of the hard disk. An optional duration parameter can also be specified so TShark will switch to the next file when the instructed number of seconds has elapsed. This will happen even if the current file is not yet full. The filenames created are based on the number of the file and the creation date and time. You can only save files in the libpcap format when this option is used.

■ Capture Input Option

■ —r File Reads and processes a saved capture file.

■ Capture Processing Options

■ —RFilter Causes a read filter to be applied before displaying or writing the packets to a file. Packets that do not match the filter will be discarded.

■ —n Used to disable network object name resolution, such as host names and port names.

■ —N Resolving flags Used to enable name resolving for specified address types and port numbers. The M Flag enables MAC address resolution, the N Flag enables network address resolution, and the T Flag enables transport-layer port number resolution. The C Flag enables concurrent (asynchronous) Domain Name System (DNS) lookups ifTShark is compiled with Asynchronous DNS (ADNS).The —N Option overrides the —n Option.

■ —d Layer type==selector, decode-as protocol Allows you to specify the way in which traffic is decoded. The parameters denote that if the layer type has a specified value, packets should be decoded as the specified protocol. For example, —d tcp. port==8080, http Would decode all traffic to and from Transmission Control Protocol (TCP) port 8080 as HyperText Transfer Protocol (HTTP) traffic. This is valuable for applications that allow you to run services on nonstan-dard ports.

■ —B Buffer size Available only on Windows systems, causing TShark to allocate a buffer size in MB (default is 1MB) to use for storing packet data during a capture before writing to the disk. This option is useful if your packet capture is dropping frames due to the overhead associated with writing to the disk.

■ Capture Output Options

■ —w File Writes the packets to the filename specified following the option. If the option specified is -, standard output is used. This option suppresses the packet display decoding unless the S Option is also specified.

■ —F Type Used to set the format of the output of the capture file. For example, if you want to save a file in the Sun snoop format so snoop can read the capture file, you would use the —F snoop Option.

■ —V Displays the capture in protocol tree form instead of the default summary packet form.

■ —S Decodes and displays the contents of packets even when writing to a file.

■ —x Displays the capture in a hexadecimal and ASCII dump format along with the summary or protocol tree view.

■ —T pdml|ps|text Allows you to set the display format to use when viewing packet data. When using the Packet Details Markup Language (PDML) option, the protocol data tree is always displayed. If the desired format is omitted, "text" is used as the default.

■ —t format Allows you to set the format of the packet timestamp that is displayed on the summary line. The format parameter will specify the method used to display the data. Relative time is specified by the R Parameter and displays the time elapsed between the first packet and the current packet. Absolute time is specified by the A Parameter and is the actual time the packet was captured. The absolute date and time are specified by the Ad Parameter and are the actual time and date the packet was captured. The delta time is specified by the D Parameter and displays the time since the previous packet was captured. By default, the time is specified as relative.

■ —l Flushes the standard output buffer after each packet is printed instead of waiting until it fills up. It is normally used when piping a capture to a script so that the output for each packet is sent as soon as it is read and dissected.

■ —q Allows you to turn off the packet count when capturing network packets to a file. The count will still be displayed at the end of the capture. On some systems, such as various BSD systems, that support the SIGINFO signal, typing Control-T Will cause the current count status to be displayed.

■ —X Allows the user to specify an option that will be passed to a TShark module. Currently, this option is used to specify additional analysis functionality using Lua scripts with the syntax Lua_script:filename.

■ —z Statistics Causes TShark to collect various types of statistics about the data being captured. The results will be displayed after reading the capture file.

■ Miscellaneous Options

■ —h Prints the version of TShark and the help options and then exits.

■ —V Prints the TShark version information and then exits.

■ —o Prefname:value Allows you to set a preference value that will override any default value or value read from a preference file. The parameter to this option is in the format of Prefname:value, Where Prefname Is the name of the preference as it would appear in the preference file, and Value Is the value to which it should be set.

By default, TShark will display packets to the screen in summary line form. These are the same lines that are displayed in the Wireshark summary pane. However, it does not print the Frame number Field when capturing and displaying real time. The —V Option can be used to print detailed information about the packets instead of just a summary. TShark can also read saved data capture files, and print the information in either summary (default) or detailed form (—V). This method will display the frame numbers with the saved packets. Finally, the —x Command will cause TShark to print a hexadecimal and ASCII dump of the packet data with either the summary line or detailed protocol tree. TShark has a very strong display filter language and can use the TCPDump filter syntax as well. These can be used to narrow the type of traffic you want to capture.

When using TShark to write a capture to a file, the file will be written in libpcap format by default. It will write all the packets and all the detail about the packets to the output file; thus, the —V And the —x Options aren't necessary. Since TShark and Wireshark are compatible with many other sniffers, you can also write the output in several different formats. The —F Option can be used to specify a format in which to write the file.

The following is a basic example of using TShark to perform a capture and display the output in a protocol tree view along with the associated hexadecimal and ASCII output.

C:\Program Files\Wireshark>tshark - V - x

Capturing on \Device\NPF_{A3 02C81E-256D-4C92-8A72-866F2E1ED55F}

Frame 1 (114 bytes on wire, 114 bytes captured)

Arrival Time: Nov 28, 2003 22:14:16.221349000

Time delta from previous packet: 0.000000000 seconds

Time since reference or first frame: 0.000000000 seconds

Frame Number: 1

Packet Length: 114 bytes

Capture Length: 114 bytes

IEEE 802.3 Ethernet

Destination: ff:ff:ff:ff:ff:ff (Broadcast)

Source: 00:05:5d:ee:7e:53 (D-Link_ee:7e:53)

Length: 100 Logical-Link Control

DSAP: NetWare (0xe0)

IG Bit: Individual

SSAP: NetWare (0xe0)

CR Bit: Command

Control field: U, func = UI (0x03)

000. 00.. = Unnumbered Information

......11 = Unnumbered frame

Internetwork Packet eXchange Checksum: 0xffff Length: 96 bytes Transport Control: 0 hops Packet Type: PEP (0x04)

Destination Network: 0x00000000 (00000000) Destination Node: ff:ff:ff:ff:ff:ff (Broadcast) Destination Socket: SAP (0x0452) Source Network: 0x00000000 (00000000) Source Node: 00:05:5d:ee:7e:53 (D-Link_ee:7e:53) Source Socket: Unknown (0x4008) Service Advertisement Protocol General Response

Server Name: TARGET1!!!!!!!!A5569B20ABE511CE9CA400004C762832

Server Type: Microsoft Internet Information Server (0x064E)

Network: 00 00 00 00

Node: 00:05:5d:ee:7e:53

Socket: Unknown (0x4000)

Intermediate Networks: 1

0000 ff ff ff ff ff ff 00 05 5d ee 7e 53 00 64 e0 e0 ........].~S. d..

0010 03 ff ff 00 60 00 04 00 00 00 00 ff ff ff ff ff ...........

0020 ff 04 52 00 00 00 00 00 05 5d ee 7e 53 40 08 00 ..R......].~S@..

0030 02 06 4e 54 41 52 47 45 54 31 21 21 21 21 21 21 ..NTARGET1!!!!!! 0040 21 21 41 35 35 36 39 42 32 30 41 42 45 35 31 31 !!A5569B20ABE511 0050 43 45 39 43 41 34 30 30 30 30 34 43 37 36 32 38 CE9CA400004C7628

0060 33 32 00 00 00 00 00 00 05 5d ee 7e 53 40 00 00 32 .......].~S@..

0070 01 01

The following is an example of using TShark to capture traffic on interface 4 and output the data to a file called Output..The output files will have a maximum file size of 5 kilobytes each, and when they are full, a new output file will be created. This will continue to a maximum of 10 output files. The following example is the command used to perform this capture.

C:\Program Files\Wireshark>tshark - i4 - a filesize:5 - b 10 - w output

The output files generated are appended with the file number, date, and times-tamp. You will see the following 10 output files start at number 43 because they have begun to drop the oldest file as they create new files, so a maximum of 10 files exists at all times.

Output_00043_20031128212900 output_00044_20031128212900 output_00045_20031128212900 output_00046_20031128212900 output_00047_20031128212901 output_00048_20031128212903 output_00049_20031128212958 output_00050_20031128213045 output_00051_20031128213211 output_00052_20031128213316

The following is an example of using a TShark capture filter to capture all traffic except packets to and from HTTP port 80.

C:\Program Files\Wireshark>tshark - f "tcp port!80"

Capturing on \Device\NPF_{A302C81E-256D-4C92-8A72-866F2E1ED55F}

0.000000 D-Link_ed:3b:c6 -> Broadcast ARP Who has 192.168.100.40? Tell 192.168.100.5

0.000026 D-Link_ee:7e:53 -> D-Link_ed:3b:c6 ARP 192.168.100.40 is at 00:05:5d:ee:7e:53

0.000066 D-Link_ee:7e:53 -> D-Link_ed:3b:c6 ARP 192.168.100.40 is at 00:05:5d:ee:7e:53

10.089720 00000000.00055dee7e53 -> 00000000.ffffffffffff IPX SAP General Response

10.089763 00000000.00055dee7e53 -> 00000000.ffffffffffff IPX SAP General Response

The following is an example of using a TShark read filter to output the Telnet data packets from a file called Capture.

The following is an example of using TShark to read a libpcap capture file called Capture2 And output it to a file called Netmon_output In the Microsoft Network Monitor 2.x Format; this command generates no output. Note that the Editcap Command can also be used to perform this function, as we'll see later in this chapter.

C:\Program Files\Wireshark>tshark - r capture2 - w netmon_output - F netmon2

■ TShark

■ editcap

■ mergecap

■ text2pcap

■ capinfos

■ dumpcap

0 Summary

0 Solutions Fast Track

0 Frequently Asked Questions

You can compile and build your plug-in and then copy the binary to the plug-ins directory under the name of your plug-in. Wireshark ships with a number of plug-ins and each can be loaded or unloaded depending on whether they are installed prior to launching Wireshark. The plug-in interface mimics the dissector interface. In fact, plug-ins are first developed as a normal dissector. Then, additional code is added to make the dissector a plug-in. This procedure changed starting with Ethereal version 0.10.10. Making your Packet-xxx Protocol dissector a plug-in is a multi-step process, which includes the creation of a source code directory to house the plug-in and it's support files, as well as modifications to the Makefiles In the root of the source code distribution. The README. plugins File located in the Doc Directory outlines the steps you need to take to generate a plug-in dissector for Wireshark.

■ Expert

■ Conversations

■ Endpoints

■ SRT

There are a number of examples for each of these types of TAPs. Protocol dissectors define and register the TAPs that they will be providing information too. To register a TAP, the following process must be added to your dissectors Proto_register_xxx Function:

My_srt_tap=register_tap("my_srt");

Inside of the protocol dissection process you should call the Tap_queue_packet Function with the necessary information needed by the TAP:

Tap_queue_packet(my_srt_tap, pinfo, pointer_to_my_tap_data);

Note that Pointer_to_my_tap_data Can be a pointer to any data that you want to pass to your specific TAP implementation. However, it is important when adding TAPs for already established interfaces like, conversations, endpoints, and so on, that you verify that your new TAP will pass a pointer to the correct information required by that TAP interface.

Now that the protocol dissector is registering the TAP, you can create a conversation, endpoint, or SRT statistic option to use the information the TAP provides. The first step in writing the code to manage the information is to create a new file in the Gtk Directory for the specific TAP data type. The file naming convention used for each type of statistic source code file is:

■ Gtk/conversations_myprot Conversations

■ Gtk/myprot_stat SRTs

■ Hostlist_myprot Endpoints

Note that the TAP modules for Tshark are located in the Root Directory of the source code distribution. These files are typically named Tap-myprot.

First we create the standard header and includes. We will need different includes depending on the type of statistic we are processing. In this example we are using the SRT statistics:

/* mysrt_stat. c * mysrt_stat 2006 My_Name

* $Id: mysrt_stat. c 00000 2006-01-01 00:00:00Z xxx $

*

* Wireshark - Network traffic analyzer

* By Gerald Combs <Gerald@wireshark. org>

* Copyright 1998 Gerald Combs

*

* This program is free software; you can redistribute it and/or

* modify it under the terms of the GNU General Public License

* as published by the Free Software Foundation; either version 2

* of the License, or (at your option) any later version.

*

* This program is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of

* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

* GNU General Public License for more details.

*

* You should have received a copy of the GNU General Public License

* along with this program; if not, write to the Free Software

* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */

#ifdef HAVE_CONFIG_H

# include "config. h" #endif

#ifdef HAVE_SYS_TYPES_H

# include <sys/types. h> #endif

#include <string. h>

#include <gtk/gtk. h>

#include <epan/packet_info. h>

#include <epan/epan. h>

#include <epan/value_string. h>

#include <epan/tap. h>

#include "service_response_time_table. h"

#include "../stat_menu. h"

#include "../tap_dfilter_dlg. h"

#include "gtkglobals. h"

We now need a structure to store our SRT statistics in:

/* used to keep track of the statistics for an entire program interface */ typedef struct _mysrtstat_t {

GtkWidget *win;

Srt_stat_table my_srt_table; } mysrtstat_t;

We must register our new SRT statistics option with Wireshark. This registration process will add the new option to the SRT statistical menu and add this statistic as a sub-option of the SRT menu item or as a tab in the tabbed/notebook view:

Static tap_dfilter_dlg mysrt_stat_dlg = { "My Protocol SRT Statistics", "mysrt, srt", gtk_mysrtstat_init, -1

};

Void

Register_tap_listener_gtkmysrtstat(void) {

Register_dfilter_stat(&mysrt_stat_dlg, "MYSRT", REGISTER_STAT_GROUP_RESPONSE_TIME);

}

The main registration function (register_dfilter_stat(J) Passes the parameters, points to the function to call when a user selects the item (mysrt_stat_dlg), And names the display in the menu (MYSRT) And the statistical menu item we are adding this item too (REGISTER_STAT_GROUP_RESPONSE_TIME).

The function called when the user selects the new SRT menu option (mysrt_stat_dlg()) Passes the information to the initialization function (gtk_mysrtstat_init).

The first process in the initialization function (gtk_mysrtstat_init) Is to create the GTK window that will hold our statistical information.

Static void

Gtk_mysrtstat_init(const char *optarg, void *userdata _U_) {

/* Define a pointer to our structure */

Mysrtstat_t *ss;

Const char *filter=NULL;

/* Allocate memory for our table */ ss=g_malloc(sizeof(mysrtstat_t));

/* Get the current filter passed */ if(!strncmp(optarg,"mysrt, srt,",8)){

Filter=optarg+8; } else {

Filter=NULL;

}

/* Create the main window */

Ss->win=window_new(GTK_WINDOW_TOPLEVEL, "mysrt-stat"); gtk_window_set_default_size(GTK_WINDOW(ss->win), 300, 400); vbox=gtk_vbox_new(FALSE, 3);

Gtk_container_add(GTK_CONTAINER(ss->win), vbox); gtk_container_set_border_width(GTK_CONTAINER(vbox), 12);

/* Print a label on the menu to describe this statistic */ label=gtk_label_new("My Protocol Service Response Time Statistics"); gtk_box_pack_start(GTK_BOX(vbox), label, TRUE, TRUE, 0);

/* Display the current display filter */

G_snprintf(filter_string,255,"Filter:%s",filter? filter:""); label=gtk_label_new(filter_string);

Gtk_box_pack_start(GTK_BOX(vbox), label, FALSE, FALSE, 0);

/* Let's create a notebook view */ main_nb = gtk_notebook_new();

Gtk_box_pack_start(GTK_BOX(vbox), main_nb, TRUE, TRUE, 0); temp_page = gtk_vbox_new(FALSE, 6); label = gtk_label_new("Groups");

Gtk_notebook_append_page(GTK_NOTEBOOK(main_nb), temp_page, label); /* Create a Close button row. */

Bbox = dlg_button_row_new(GTK_STOCK_CLOSE, NULL); gtk_box_pack_end(GTK_BOX(vbox), bbox, FALSE, FALSE, 0);

Close_bt = OBJECT_GET_DATA(bbox, GTK_STOCK_CLOSE);

Window_set_cancel_button(ss->win, close_bt, window_cancel_button_cb);

/* Tell GTK what functions to call when a delete or destroy is detected */

SIGNAL_CONNECT(ss->win, "delete_event", window_delete_event_cb, NULL); SIGNAL_CONNECT(ss->win, "destroy", win_destroy_cb, ss);

Gtk_widget_show_all(ss->win); window_present(ss->win);

Inside the initialization function, after creating the window for the data, we must register a listener for the TAP information.

/* Register the tap listener */

Error_string=register_tap_listener("my_srt", ss, filter,

Mysrt_reset, mysrt_packet, mysrt_draw); if(error_string){

Simple_dialog(ESD_TYPE_ERROR, ESD_BTN_OK, error_string->str);

G_string_free(error_string, TRUE);

G_free(ss);

Return;

}

When you register the TAP listener, you pass the TAP name as parameters (my_srt), The pointer to the local Srt_stat_table Variable/structure (SS), the current filter (if used; otherwise pass NULL), the function to call when a reset signal is detected by GTK (mysrt_reset), The function to call when a new packet/event is detected (mysrt_packet), And the function to call when GTK performs a refresh (mysrt_draw).

At this point, most of the TAP listener applications will initiate a retap/redissect process so that the information will again be passed to the TAP channel. There are two methods available to initiate this process:

Cf_redissect_packets(&cfile); or

Cf_retap_packets(&cfile, FALSE);

The main difference between these two calls is that the Cf_redissect_packets Forces Wireshark to do a complete reload and dissection of the current trace, including recreation of the GUI items, whereas, the Cf_retap_packets Forces Wireshark to reload and rescan the packet data. The Retap Function is preferred, if possible, because it takes less time for Wireshark to complete and is less intensive. However, in cases where dissector information requires a re-dissection process including the GUI items, you

May need to perform the Cf_redissect_packets Instead. Developers should weigh the benefit vs. cost prior to implementing a full re-dissection of the packet trace.

The remaining code for handling conversations, endpoints, or SRT statistics, varies depending on the implementation. In our example, we now need to compose our functions to handle the reset, packet, and draw conditions:

Static void

Mysrtstat_reset(void *pss) {

Mysrtstat_t *ss=(mysrtstat_t *)pss;

/* Call the global SRT function to reset the table data */ reset_srt_table_data(&ss->my_srt_table);

}

Static int

Mysrtstat_packet(void *pss, packet_info *pinfo, epan_dissect_t *edt _U_, const void *prv)

{

Mysrtstat_t *ss=(mysrtstat_t *)pss;

Const my_dissectors_tap_data_type *request_val=prv;

/* if we haven't seen the request, just ignore it */ if(!request_val){ return 0;

}

/* Call the global SRT function to add the new packet data */ add_srt_table_data(&ss->my_srt_table, request_val->command, &request_val->req_time, pinfo);

Return 1;

}

Static void

Mysrtstat_draw(void *pss) {

Mysrtstat_t *ss=(mysrtstat_t *)pss;

/* Call the global SRT function to draw the window */ draw_srt_table_data(&ss->my_srt_table);

}

It is also important to remember to clean up the memory when your application ends. Therefore, we also need to define our cleanup function if the window is just closed by the user:

Void protect_thread_critical_region(void); void unprotect_thread_critical_region(void); static void

Win_destroy_cb(GtkWindow *win _U_, gpointer data) {

Mysrtstat_t *ss=(mysrtstat_t *)data;

Protect_thread_critical_region();

Remove_tap_listener(ss);

Unprotect_thread_critical_region();

}

Free_srt_table_data(&ss->my_srt_table); g_free(ss);

It is recommended that you utilize one or more of the currently available sources for any new additions. Inside the Gtk Directory are a number of examples for all of the defined types of TAPs. Although our example was for the service response time statistics, the coding for conversations and endpoints are basically the same.

Notes from the Underground...

Development Note

It is important to note that even though the expert info is a TAP, you do not have to implement any type of utility code to process the expert info as you do with conversations, SRT, and endpoints statistics. As mentioned previously, you modify your dissector to call the expert TAP directly.

The Item Factory

The main menu for Wireshark is created via a GTK item factory. The following information is extracted from the Gtk/menu. c Source file included in the Wireshark source code distribution:

/* This is the GtkItemFactoryEntry structure used to generate new menus.

Item 1: The menu path. The letter after the underscore indicates an accelerator key once the menu is open.

Item 2: The accelerator key for the entry Item 3: The callback function.

Item 4: The callback action. This changes the parameters with which the function is called. The default is 0.

Item 5: The item type, used to define what kind of an item it is. Here are the possible values:

(optional)

NULL

"<Title>" "<Item>" "<ImageItem>" "<StockItem>" "<CheckItem>" "<ToggleItem>" "<RadioItem>" <path>

"<Separator>" "<Tearoff>" "<Branch>"

"<LastBranch>"

-> "<Item>"

-> "<Item>"

-> create a title item

-> create a simple item

-> create an item holding an image (gtk2) -> create an item holding a stock image (gtk2)

-> create a check item

-> create a toggle item

-> create a radio item

-> path of a radio item to link against

-> create a separator

-> create a tearoff separator (gtk2)

-> create an item to hold sub items

-> create a right justified branch

Item 6: extra data needed for ImageItem and StockItem (gtk2)

*/

ITEM_FACTORY_ENTRY("/Copy", NULL, copy_selected_plist_cb, 0, NULL, NULL), ITEM_FACTORY_ENTRY("/<separator>", NULL, NULL, 0, "<Separator>", NULL),

ITEM_FACTORY_ENTRY("/Expand Subtrees", NULL, expand_tree_cb, 0, NULL, NULL),

ITEM_FACTORY_ENTRY("/Expand All", NULL, expand_all_cb, 0, NULL, NULL),

ITEM_FACTORY_ENTRY("/Collapse All", NULL, collapse_all_cb, 0, NULL, NULL),

When the item factory option is selected, the function listed in Item 3 is called. In GTK, callback functions are called when an item is selected.

The Set_menu_sensitivity Function enables and disables the availability of menu items based on a specified condition:

/* make parent menu item sensitive only, if we have any valid files in the list */

Set_menu_sensitivity(main_menu_factory, MENU_RECENT_FILES_PATH, cnt);

Generally, you only need to modify the Wireshark menu if you are creating a tool or making a change to some other portion of the GUI.

Using GTK

When an item is selected, GTK passes a handle to the active selection, which are called Widgets.

Void

My_widget(GtkWidget *w _U_, gpointer d _U_) {

GtkWidget *main_vb

GtkTooltips *tooltips; #if GTK_MAJOR_VERSION < 2

GtkAccelGroup *accel_group; #endif

Notes from the Underground...

Development Note

Note the _U_ Value being defined in the My_widget Function. The _U_ Represents an undefined parameter. These values are not used within the function. The process of defining them as _U_ Allows the compiler to not issue a warning on the function due to undefined variables.

Function Names

It is important to understand that the GTK functions used within the Wireshark GUI code are not always the original GTK function name. Most GTK functions are globally defined within the Wireshark source code include file Gtk/compat_macros. h. It may sometimes be necessary to consult this file prior to looking up specific information on the GTK Web site.

When our menu item is selected, GTK passes the GTK widget pointer and data structure to us. We then create a new GTK widget for our window.

The GtkTooltips Is a structure that allows you to store information about a widget that is displayed when the user places his or her mouse pointer over the GTK item. For example, suppose you have a button on our window that (when clicked) changes the current display filter to one of our choosing. Although the size

Of the button only allows us to label it "Filter," we can define a tool tip that provides a more detailed description of the button's function.

The GtkAccelGroup Is necessary for GTK version 1.2. It allows for accelerator keys to be used on the keyboard to access menu items:

/* First check to see if the window already exists. If so make it active. */ if (mywindow_w!= NULL) {

/* There's already a "My Window" dialog box; reactivate it. */

Reactivate_window(mywindow_w);

Return;

}

/* Create our new window */

Mywindow = dlg_window_new("Wireshark: My Window");

/* Register our callback function to clean up memory if the window is closed */

SIGNAL_CONNECT(mywindow_w, "destroy", mywindow_destroy_cb, NULL); /* Start the tooltips */ tooltips = gtk_tooltips_new ();

#if GTK_MAJOR_VERSION < 2

/* Accelerator group for the accelerators (or, as they're called in

Windows and, I think, in Motif, "mnemonics"; Alt+<key> is a mnemonic, Ctrl+<key> is an accelerator). */ accel_group = gtk_accel_group_new();

Gtk_window_add_accel_group(GTK_WINDOW(mywindow_w), accel_group); #endif

We first check to make sure the window is not already open. If it is, we reactivate it. If it is not, we create a new dialog window. When creating the new window, you should create a callback handler to take care of the window being closed, by the user clicking the EXIT Button in the upper right-hand corner of the dialog box. The SIGNAL_CONNECT Function tells GTK what to do when the specified signal occurs. In this case, we are trapping for the destroy signal.

Finally, we initialize the Tooltips. Notice that we only perform the accelerator group for GTK versions older then GTK 2.x. Accelerator keys in GTK 2.x are defined when creating the item:

/* Container for each row of widgets */ main_vb = gtk_vbox_new(FALSE, 3);

Gtk_container_border_width(GTK_CONTAINER(main_vb), 5);

Gtk_container_add(GTK_CONTAINER(mywindow_w), main_vb); gtk_widget_show(main_vb);

The first step is to create our main window. Next, we create a box on the new window. The Gtk_vbox_new Creates the new box that we will add to our window. The Gtk_container_border_width Defines the border for our window. The Gtk_container_add Now adds our new box to the main window. Finally, the Gtk_widget_show Forces GTK to paint the information to the screen. The following demonstrates the creation of an OK Button on the Main_vb Window.

/* Button row: OK button */ bbox = gtk_hbutton_box_new();

Gtk_button_box_set_layout (GTK_BUTTON_BOX (bbox), GTK_BUTTONBOX_END); gtk_button_box_set_spacing(GTK_BUTTON_BOX(bbox), 5); gtk_container_add(GTK_CONTAINER(main_vb), bbox); gtk_widget_show(bbox);

#if GTK_MAJOR_VERSION < 2

Ok_bt = gtk_button_new_with_label ("OK"); #else

Ok_bt = gtk_button_new_from_stock(GTK_STOCK_OK); #endif

SIGNAL_CONNECT(ok_bt, "clicked", capture_prep_ok_cb, cap_open_w); GTK_WIDGET_SET_FLAGS(ok_bt, GTK_CAN_DEFAULT); gtk_box_pack_start (GTK_BOX (bbox), ok_bt, TRUE, TRUE, 0); gtk_widget_grab_default(ok_bt); gtk_widget_show(ok_bt);

The first section of this code creates a new horizontal button box, adds it to the Main_vb Window, and forces GTK to paint the new box.

We then check the GTK version and create the new button depending on the version of GTK. Note that GTK version 2.x allows us to specify the icon used for this button. This is how you create custom icons and incorporate them into Wireshark. We register the callback function for GTK to use when the button is clicked, register the button as the default button, and paint the button on the screen. Note that it is not necessary to force GTK to draw each time the window is updated or a new item is added. You can build your dialog window and then call Gtk_widget_show() To have GTK draw the window and all of it's attached components.

You can also register widget data to a widget so that when it is selected, the data associated to the widget is passed to the calling function (e. g., in the Gtk/find_dlg. c File, a number of defines are set to identify the buttons within the find window):

/* Capture callback data keys */

Next, the keys are registered as data to the dialog with the Object_set_data Function.

OBJECT_SET_DATA(find_frame_w, E_FIND_FILT_KEY, filter_text_box); OBJECT_SET_DATA(find_frame_w, E_FIND_BACKWARD_KEY, backward_rb);

Values of the attached buttons by calling the Object_get_data Function:

Filter_te = (GtkWidget *)OBJECT_GET_DATA(parent_w, E_FIND_FILT_KEY); backward_rb = (GtkWidget *)OBJECT_GET_DATA(parent_w, E_FIND_BACKWARD_KEY);

The GTK Web site contains many examples and a window builder tool that you can download and experiment with. To program in GTK, you must know the static defines for predefined items like GTK_STOCK_XXX And GTK_CAN_DEFAULT.

Wireshark Implements a TAP system to allow for real-time statistics during packet captures. These can also be used by statistical information tools that register to the TAP interface and command Wireshark to re-dissect a saved packet capture file. Examples of this type of use of the TAP system include conversation lists, endpoints, expert TAP, and so on. The TAP system is documented in the README. tapping Document located in the Doc Directory. Also in the main source code directory you will find a number of Tap-xxx Files that you can use for a reference on the TAP interface. The Gtk/endpoint_talkers_table. c File can be used as an example of how to implement a TAP inside of an included statistics menu option.

The TAP interface is implemented in two steps. The first step is to install the TAP into the protocol dissector you want to get information from. The second step is to add the TAP listener to your new application. Many of the protocol dissectors included in Wireshark already contain TAPs. Most likely you will only need to create your TAP listener and perform the work you need to do. If you find that a TAP is not installed in the protocol you need, adding the TAP is simple through the use of a few lines of code. Refer to the README. tapping For more information.

#define E_FIND_FILT_KEY #define E_FIND_BACKWARD_KEY

"find_filter_te" "find_backward"

Finally, when the Find_frame_w Is selected, the callback function can access the