Integers

Integer fields hold numeric values. The numeric values are integers, or whole numbers without fractional parts. Integers can be expressed in decimal, octal, or hexadecimal notation. The octal notation requires an initial “0” (zero), while hexadecimal notation requires an initial “0x” (zero x). Table 5.13 shows examples of how to write the same integer in decimal, octal, and hexadecimal representations.

Integer fields are categorized as signed or unsigned, and as 8-bit, 16-bit, 24-bit, 32-bit, or 64-bit in width. These two categories describe how the integers are stored in a computer’s memory. The categories determine the range of values that the integer can be (see Table 5.14).

Some integer fields also have labels representing specific values that the field can be. For example, the Systems Network Architecture (SNA) Transmission Group Segmenting Field, or sna.th.tgsf, can have four distinct values, as shown in Table 5.15.

In these cases, either the integer value or the label can be used when testing for values of sna.th.tgsf. These display filters are equivalent:

sna.th.tgsf == 2
 sna.th.tgsf == "First segment"

This example also shows one instance of how text (or, in programmer jargon, strings) can be represented in a display filter. Note that the label is enclosed by double quotes. More ways of representing strings will be discussed in the section about string fields.

You can use the Filter Expression dialog box, described later in this chapter, to look at the possible values for fields that have label values. You can also use the tables in the Appendix of this book, or the HTML pages in the /filters directory on the accompanying CD-ROM to find the same information.

Some integer fields are of a type called frame number. This is a special integer type within Ethereal that acts like a 32-bit unsigned integer type, but if you right-click on such a field in the GUI, the pop-up menu will have an option called Go to Corresponding Frame which brings you to the frame mentioned by the field. This is used for protocols that make use of request/response packet pairs. For example, the Server Message Block (SMB) and NetWare Core Protocol (NCP) protocols make use of frame-number fields. Figure 5.4 shows an SMB response packet with a field smb.response_to, which gives the frame number of the request packet. Being able to jump to the request packet by clicking on a field in the reply packet can be handy when debugging network problems.

Figure 5.4: SMB Response

Booleans

Boolean fields are fields that have a true or false value. They can be compared against the strings True and False, in lower-case, upper-case, or any combination of case, or against the values 1 and 0, which are Ethereal’s internal representation of True and False, respectively. In some cases, boolean fields, like integer fields, have labels that better describe the 1 or 0 value. For example, the sna.rh.sdi field, the SNA Sense Data Included field, is a boolean field that has the labels Included and Not Included, which describe its values more accurately than True or False. These display filters are equivalent:

sna.rh.sdi == 0
 sna.rh.sdi == "Not Included"
 sna.rh.sdi == false

Floating Point Numbers

Floating point numbers are different from integer numbers in that they contain fractional parts. Even if the number to the right of the decimal point is 0 (or decimal comma, if your locale uses commas instead of periods), it’s still a fractional part of the number. Floating point numbers can be positive or negative. Ethereal provides two types of floating point numbers: regular floating point numbers, and double-precision floating point numbers. The difference between the two is that double-precision floating point numbers can more accurately represent numbers than regular floating point numbers because more digits can be stored. In practice, all of Ethereal’s floating point numbers are of the double-precision type.

Floating point numbers, either regular or double-precision, are not frequently found in protocols, but they do exist. For example, the who protocol, which is the format of the messages sent by the rwhod program on UNIX systems announcing load averages and current logins, has floating point numbers. Some example display filters are:

who.loadav_5 > 3.5
 who.loadav_10 <= 10
 who.loadav_10 <= 10.0

Strings

Some fields hold text values. Sequences of characters are called strings in programming jargon and in Ethereal. If the string you want to represent has no spaces and is not the same as the name of a field, you can use the string directly in your display filter:

sna.rh.csi == ASCII

However, if the string has a space in it, or is the same as the name as a field, the string will have to be enclosed in double quotes:

sna.rh.sdi == "Not included"

If the string you’re providing has a double quote in it, you need to use a backslash followed by a double-quote to embed that double quote in the string. The following display filter looks for a double-quote, followed by Y, E, S, followed by another double-quote.

http contains "\"Yes\""

The backslash also allows you to embed 8-bit unsigned integers, that is, single bytes, inside the string by using either hexadecimal or octal notation:

frame contains "\0777"
 frame contains "\xff"

And if you’re really looking for a backslash, then you use a backslash followed by another backslash. To look for \begin, the display filter would look like:

http contains "\\begin"

Ethereal’s display filter syntax currently only allows you to look for ASCII (American Standard Code for Information Interchange) strings. While the Edit | Find Packet GUI option allows you to search for ASCII and Unicode strings, the display filter language doesn’t allow you to search any other string-encoding, including Unicode or EBCDIC (Extended Binary Coded Decimal Interchange Code) strings. Hopefully, a future version of Ethereal will provide an extension to the display filter language to allow you to denote the character encoding you want when looking for a string. Similarly, be aware that all string comparisons are case-sensitive. In the display filter language, searching for GOOD will not uncover good, as the former is in uppercase, while the latter is in lowercase. Once again, perhaps a future modification to Ethereal will add the ability to perform case-insensitive comparisons.

The matches operator lets you search for text in string fields using a regular expression. The operator is named after the Perl match operator (m//), and in fact, the regular expressions supported by Ethereal are the same regular expressions that Perl uses. Ethereal manages this by using the Perl Compatible Regular Expressions (PCRE) library, which other popular applications also use. This is helpful because you don’t need to learn an Ethereal-specific regular expression syntax if you already happen to know regular expressions from Perl, Python, PHP (a recursive acronym which stands for “PHP: Hypertext Preprocessor”), Apache, Exim, or many other applications.

The best documentation for Perl regular expressions comes from the Perl regular expression manual page, available on-line at www.perldoc.com/perl5.8.0/pod/perlre.html. The Python documentation at www.python.org/doc/current/lib/re-syntax.html also provides a useful summary of regular expression syntax. An entire book could be written on regular expressions, but in short, by using a special syntax, you can search for patterns of strings, instead of just simple strings, in a string field. For example, if you want to look for a directory name with a numeric digit in NetWare Core Protocol’s ncp.directory_name field, you would use:

ncp.directory_name matches "\d"

If you wanted directory names that start with an “f” or an “F”, and have numeric digits, the display filter would be:

ncp.directory_name matches "^[Ff].*\d"

As you can see, regular expression syntax is cryptic if you haven’t practiced it. But once you learn it, regular expressions are powerful tools that can help you find just about anything.

Byte Sequences

Sequences of bytes, including Ethernet addresses, are represented by a sequence of hexadecimal digits, in upper-case or lower-case, separated by colons, periods, or dashes. For example, the broadcast Ethernet address ff:ff:ff:ff:ff:ff can be also be represented as ff.ff.ff.ff.ff.ff or as ff-ff-ff-ff-ff-ff.

Ethernet addresses are byte sequences, but are special because names can be assigned to them via an ethers file that you create. On UNIX, the global file is /etc/ethers, and the personal file is $HOME/.ethereal/ethers. On Windows, the global ethers file would be placed in the Ethereal installation directory, and the personal file would be created as %APPDATA%\Ethereal\ethers, or if %APPDATA% doesn’t exist, then %USERPROFILE%\Application Data\Ethereal\ethers. The ethers file has the format of one hardware address and one name per line, separated by any amount of spaces or tabs:

00:09:f6:01:cc:b3   picard
 01:1a:e3:01:fe:37   worf
 

When a name exists for an Ethernet address, the name can be used in the display filter:

eth.src == 00:09:f6:01:cc:b3
 eth.src == picard

Internally, Ethereal treats protocols as a special field type, but in one aspect, protocols act like byte sequence fields. The contains operator can be used to search through the bytes that belong to each protocol in the packet. The bytes in a packet that are specific to a protocol are treated as belonging to that protocol in the display filter language. The exception is the special frame pseudo-protocol. At the top of every protocol tree, Ethereal places a pseudo-protocol that contains metadata about the packet, including the arrival time and the length of packet. These fields don’t actually appear in the packet data, but are relevant to the packet. Ethereal regards all the bytes in the packet as belonging to the frame pseudo-protocol. Therefore, you can use the contains operator to search for any bytes or ASCII text within the entire packet by checking if the frame protocol contains the bytes or text.

frame contains "POST"
 frame contains 50:4f:53:54

You can, of course, limit your search to a more specific protocol if you know that the text should appear there. For example, to search for GET in the http protocol, use:

http contains "GET"

Addresses

You’ve already seen an example of an address field in the discussion about hardware address fields in the Byte Sequences section. Address fields have the distinction of being represented by either a numeric value or a name. The Ethernet address field is both an address field and a byte-sequence field. The other address fields are the IPv4 address, IPv6 address, and IPX network fields.

IPv4 address fields can be compared against the dotted-quad format of IPv4 addresses, or hostnames and DNS names. The dotted-quad notation is four numbers separated by periods, or dots. In this example, the source IP address field name is ip.src, while the destination IP address field name is ip.dst:

ip.src == 192.168.1.1
 ip.dst == wizard
 ip.dst == www.ethereal.com

If you want to test if either the source IP address or the destination IP address is wizard, you can use the logic or operator to combine two tests:

ip.src == wizard or ip.dst == wizard

But Ethereal provides another field, ip.addr, which stands for either ip.src or ip.dst:

ip.addr == wizard

You will find that most of the fields that have a concept of source and destination will provide a third field that tests for either source or destination, to help you write succinct display filters.

To test if an IPv4 address is within a certain subnet, the == operator and classless interdomain routing (CIDR) notation can be used, which works with dotted-quad notation, hostnames, or DNS names. In CIDR notation, the IPv4 address or hostname is followed by a slash and the number of bits that make up the network portion of the IPv4 address.

ip.addr == 192.168.1.0/24
 ip.addr == wizard/24

IPv6 address fields are similar in name to their IPv4 counterparts: ipv6.src for the source address, ipv6.dst for the destination address, and ipv6.addr to test either source or destination address. For example,

ipv6.dst == 2::8100:2:30a:c392:fc5a or ipv6.dst == 2::8100:2:30a:c392:fc5a
 ipv6.addr == 2::8100:2:30a:c392:fc5a

IPX addresses are comprised of two parts, the network address and the node address. This is comparable to an IPv4 address, where part of the 32-bit IPv4 address is the network portion, and the other part refers to a specific host on that IPv4 network. In IPX, however, the network and node (that is, the host) are separate fields instead of being combined into a single value.

The IPX node fields are hardware-address type fields, but the IPX network fields are unsigned 32-bit integer fields. Ethereal treats IPX network fields differently than normal integer fields in that Ethereal allows you to give names to IPX network numbers. This is useful if you need to analyze IPX packets in an environment where there are many different IPX networks; names are easier to remember than numbers. To define the IPX network names, you create a file called ipxnets. On UNIX, you can create a global ipxnets file in /etc/ipxnets, and a personal file, whose values override the global values, in $HOME/.ethereal/ipxnets. On Windows, the global file is the ipxnets file in the Ethereal installation directory, while the personal file is %APPDATA%\Ethereal\ipxnets, or if %APPDATA% doesn’t exist, then %USERPROFILE%\Application Data\Ethereal\ipxnets. The format of the ipxnets file is the same as the ethers file, except that the hexadecimal bytes representing the IPX network number can be separated by periods, dashes, colons, or nothing. Here is an example from the Ethereal man page:

C0.A8.2C.00              HR
 c0-a8-1c-00              CEO
 00:00:BE:EF              IT_Server1
 110f                     FileServer3

Given this ipxnets file, these two display filters are equivalent:

ipx.src.net == 0xc0a82c00
 ipx.src.net == HR

Time Fields

There are two types of time fields in Ethereal. While they are related to each other, they are represented very differently. An absolute time is a timestamp that combines a date and a time in order to specify a specific moment in time. A relative time is just a floating point number; it’s the number of seconds (including fractional seconds) between two absolute times.

Absolute times are represented as strings of the format

Month Day, Year Hour:Minute:Seconds

They can include fractions of a second, with nanosecond resolution

Month Day, Year Hour:Minute:Seconds.Nsecs

To look at packets that arrived before December 31st, 2003, at 5:03AM, the display filter would be:

frame.time < "Dec 31, 2003 05:03:00"

Ethereal provides the frame.time_delta field to record the difference in arrival times between a packet and its immediate predecessor. Currently, the only way to represent this relative time is with a floating point number that indicates seconds with nanosecond resolution:

frame.time_delta > 0.02

Maybe in the future Ethereal will allow the use of units, such as “1 min 5.3 secs”.

Other Field Types

Some fields have no values associated with them. They don’t have an integer value, string value, or any other value. You can test for the existence of these fields, but they don’t have a value that you can check with ==, <, >, or any other relation. These no-value fields are generally used by the protocol dissector to place text or a branch in a protocol tree.

If you inspect the protocol trees in your packet captures, you’ll eventually discover that some of the items in the protocol tree don’t have any display-filter field associated with them. In some cases, protocol dissectors merely add text to the protocol tree, without labeling the text as belonging to a field. Figure 5.5 shows how the HTTP protocol dissector does this for the HTTP headers. It places the User-Agent field in the protocol tree without giving it a display-filter field name.

Figure 5.5: HTTP Headers as Text

Unfortunately, you cannot create a display filter to search for these types of text labels. However, if the text is found in the packet data, the contains operator can be used to search for the text in a protocol, or even the entire packet by using the frame pseudo-protocol. To find HTTP packets where the User-Agent is “Mozilla”, as in Figure 5.5, use contains:

http contains "User-Agent: Mozilla"

Ranges

The string, byte sequence, and protocol field types have something in common besides being searchable by the contains operator - they are all sequences of bytes. Strings are sequences of characters, but characters are really just bytes. The other field types - integers, floating points, times, etc., - can be thought of as single values rather than sequences of anything. Sometimes it is useful to take a portion of a string, byte sequence, or protocol, that is, slice the data into a smaller section, and compare it against a value. You can slice a sequence by using the ranges functionality of Ethereal’s display filter language. The ranges syntax uses square brackets: [ and ].

To obtain a single byte from a sequence, use the offset of that byte in square brackets. The offset is the position of the byte starting at the beginning of the named field. As typical for computer languages, Ethereal’s display filter language offsets begin at 0. To compare the very first byte in an Ethernet address to the hexadecimal value 0xaa, use:

eth.addr[0] == aa

The hexadecimal byte value aa is not interpreted as the string “aa”, nor can you provide a integer value by typing 0xaa.

Since 0 is the offset of the first byte, 1 is the offset of the second byte. To compare the second byte of the bytes in the telnet portion of the packet to the hexadecimal value 0xff, use:

telnet[1] == ff

A sample of a full hexadecimal table can be found at: www.cookwood.com/_cookwood/html4_examples/4files/colorhex/hexchart.html

Ranges can do more for you than extracting single bytes. You can extract actual ranges of bytes from the fields. Use a colon to separate the offset from the number of bytes in the brackets. To compare the first three bytes of a token-ring address to 00:06:29, type the length of the slice after the colon. The length is 3 because we are comparing three bytes:

tr.addr[0:3] == 00:06:29

If you would rather provide ranges of offsets rather than offset/length pairs, then a hyphen in the brackets can be used. This display filter also compares the first three bytes of a token-ring address to 00:06:29, but by slicing the tr.addr field from offset 0 up to, and including, byte 2.

tr.addr[0-2] == 00:06:29

When using the colon notation to give byte offset and range length, you can choose not to provide either the offset or the length, yet keep the colon.

eth[:2] == ff:ff
 http[10:] contains 00:01:02

When the offset is not provided, as in the eth[:2] case, then the offset is assumed to be zero. When the length is not provided, as in the http[10:] case, then the range includes all the bytes until the end of the field or protocol mentioned.

Within the brackets, you can use commas to concatenate, or combine, multiple ranges of the same field. For example, if you wish to look at the first byte (offset = 0) and third byte (offset = 2) of the token-ring protocol, then you can either create two ranges, combining them with the and logical operator, or simply combine the ranges into one range using a comma inside the square brackets:

tr[0] == ff and tr[2] == ee
 tr[0,2] == ff:ee

The comma operator can combine any number of ranges, so the following monstrosity is entirely legal:

tr[0-2,4:3,7,9] == 01:02:03:04:05:06:07:08

Table 5.16 is a summary of the range syntax options.

Logical Operations

You’ve already seen many examples of combining multiple relations in the same display filter with the and operator. The and logical operator tests that the two relations it combines are true. To filter for a specific source IP address and a specific destination IP address, use and.

ip.src == 192.168.1.1 and ip.dst == 192.168.2.2

The or logical operator tests if either, or both, of the two relations that it joins is true. If you wanted to test an IP address to see if it was one of two values, you use or.

ip.addr == 192.168.3.3 or ip.addr == 192.168.4.4

The not logical operator reverses the sense of the relation. To find NetWare Core Protocol packets that have an ncp.directory_name field which does not contain the string “System”, you would use this display filter:

not ncp.directory_name contains "System"

Parentheses are used to group relations according to how not, and, and or, should combine them. These two display filters are not the same, due to the presence of parenthesis.

not eth.dst eq ff:ff:ff:ff:ff:ff and ip.len gt 1000
 not (eth.dst eq ff:ff:ff:ff:ff:ff and ip.len gt 1000)

In the first example, not negates the meaning of the eq. In the second example, not negates the meaning of the grouped expression, which is an and expression.

Multiple Occurrences of Fields

Some protocols occur more than once per packet. This can happen when you’re looking at encapsulated or tunneled protocols. For example, Protocol Independent Multicast (PIM) can run on top of IPv6 and at the same time send other IPv6 data. Thus, you can have two instances of IPv6 in a single packet by using PIM. More commonly, the same field can occur more than once in a single protocol. Some protocols have repeated fields, like the ring/bridge pairs in source-routed token-ring packets.

In other cases where the protocol does not normally have multiple occurrences of fields, Ethereal will create multiple occurrences of fields to enhance the filtering. As mentioned in the discussion about address fields, there are many fields that have a source version and a destination version. In those cases, the protocol dissector adds two generic (non-source, non-destination) versions of the field so that a display filter can test both the source and destination fields in one statement. Table 5.17 shows some examples of those fields.

Care must be given when testing fields that occur more than once in a packet. For example, if you have a packet capture that has a lot of HTTP traffic in it, as does the example in Figure 5.6, and want to use a display filter to hide the HTTP traffic because you’re not interested in it, you might be tempted to use this display filter, where 80 is the TCP port for HTTP:

tcp.port != 80

Figure 5.6: TCP Ports for HTTP Traffic

Unfortunately, this doesn’t work. Why? This display filter is saying “show me all the packets which have a tcp.port that does not equal 80.” Take a look at Figure 5.6; one tcp.port, the destination port, is 80, while the other tcp.port, the source port, is 43,466. This packet does pass the tcp.port != 80 filter, because it has one tcp.port which is not equal to 80.

What you want to say instead is “show me all the packets where none of the tcp.port values are equal to 80.” Or equivalently, “show me the packets which do not have at least one tcp.port equal to 80.” In the correct display filter language, this is:

not tcp.port == 80

It takes some getting used to, but once you understand what the display filter language is doing, you will become more comfortable with it.

Tools & Traps…
Other Uses of Display Filters

Display filters are used for other reasons in Ethereal besides limiting which packets are shown to you in Ethereal’s main window. Ethereal allows you to use them any time it would like you to select packets. The View | Coloring Rules facility for colorizing packet summaries lets you use display filters to select which packets to colorize. The Analyze | Statistics | IO reports allow you to select packets with display filters. And the File | Open dialog box allows you to supply a display filter for use when reading a capture file from disk. This facility is unique among the various uses of display filters. While reading a capture file, if a packet does not match the display filter, the packet is skipped and is not loaded into Ethereal’s memory. In this way, this read display filter acts like a capture filter, in that it limits the packets that are loaded into Ethereal’s memory. But of course, it uses the display filter syntax, not the capture filter syntax.

Hidden Fields

If you look closely at some protocols in the protocol dissection tree, you might start to notice that some fields that should be present simply are not visible. For example, if you look at the Ethernet portion of a protocol tree in Figure 5.7, you’ll find the Ethernet Source address (eth.src) and the Ethernet Destination address (eth.dst), but you’ll never find a field labeled “Source or Destination Address”, which is the description for the eth.addr field. This is because eth.addr was placed in the protocol tree as a hidden field to aid in writing display filters. You can use the hidden fields in display filters, but you never see them in the protocol tree. Ethereal does this for convenience, and to keep the protocol tree from having duplicate information. Unfortunately, there is no option to make Ethereal display hidden fields. Maybe in the future there will be.

Figure 5.7: Ethernet Source and Destination Address Fields

Notes from the Underground…
Undocumented Glossary Option

Ethereal and Tethereal have an undocumented command line switch that produces a glossary of protocol and field names. The -G switch causes both programs to output the glossary, then quit. Even the format of the output is undocumented, but you can look at the epan/proto.c file in the Ethereal source code. Search for proto_registrar_dump_fields. This comment is the function that documents the format.

/* Dumps the contents of the registration database
  * to stdout. An indepedent
  * program can take this output and format it into
  * nice tables or HTML or
  * whatever.
  *
  * There is one record per line. Each is either a
  * protocol or a header
  * field, differentiated by the first field.
  * The fields are tab-delimited.
  *
  * Protocols
  * ---------
  * Field 1 = 'P'
  * Field 2 = protocol name
  * Field 3 = protocol abbreviation
  *
  * Header Fields
  * -------------
  * Field 1 = 'F'
  * Field 2 = field name
  * Field 3 = field abbreviation
  * Field 4 = type ( text representation of the ftenum type )
 * Field 5 = parent protocol abbreviation
  */
 

You can see this glossary by running ethereal –G or tethereal –G. The –G option can also take a parameter. The –G protocols option makes ethereal or tethereal show the glossary only for protocols. The –G fields option shows both protocols and non-protocol fields, just like the –G option with no additional parameter. You can also look at doc/Makefile.am (or doc/Makefile.nmake, for Windows) and doc/dfilter2pod.pl in the Ethereal source distribution to see how the Ethereal build system uses the -G switch to produce the ethereal-filter manual page.

Writing Capture Filters

• Capture filters operate quickly and are good for limiting the number of packets captured by Ethereal.

• The capture filter language has keywords for comparing host names and addresses, hardware addresses, ports, and protocols.

• Tcpdump can dissect many protocols and fields, but only a handful of those protocols and fields are available in the tcpdump filter (or “capture filter”) language.

• To test individual fields in a bit-field correctly, you must use the bitwise AND operator: &.

Writing Display Filters

• Display filters are slower than capture filters, but allow you to test almost any field or protocol that Ethereal knows how to dissect.

• Display filter fields are typed; each type of field can hold only certain types of values.

• The contains operator searches for text; the matches operator searches using regular expressions.

• Take care when testing fields that occur multiple times in a packet; the way you might think to test these fields may be the wrong way.

• The Capture Filter and Display Filter dialog boxes let you save your filters.

• The Filter Expression dialog box lets you create display filters by pointing and clicking.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form. You will also gain access to thousands of other FAQs at ITFAQnet.com.

Часть 6: Другие программы , идущие в пакете с Ethereal

Introduction

Most people who are familiar with Ethereal tend to use the Ethereal Graphical User Interface (GUI). However, when Ethereal is installed it also comes with several other supporting programs: the command line version of Ethereal, called Tethereal, and three other programs to assist you in manipulating capture files; editcap, mergecap, and text2pcap. These supporting programs can be used together to provide very powerful capture file manipulation. For example, files can be captured with Tethereal, edited with editcap, and merged into a single packet capture file with mergecap. They can then be viewed with Tethereal or Ethereal. As you read this chapter you will see the vast capabilities and the granular control these supporting programs give you when manipulating capture files.

Tethereal

Tethereal is the command line version of Ethereal. It can be used to capture, decode, and print to screen live packets from the wire or to read saved capture files. Some of the same features apply to both Tethereal and Ethereal as they use the same capture library, libpcap, and most of the same code. Tethereal can read all of the same packet capture formats as Ethereal, and will automatically determine the type. If Tethereal is compiled with the zlib library, it can automatically uncompress and read files that have been compressed with gzip. The advantage to using Tethereal is that it is highly scriptable.

The following information is the usage output for the Tethereal program, also notice the various types of formats in which Tethereal can save files by using the –F option:

[root@localhost ethereal-0.10.0a]# tethereal -h
 This is GNU tethereal 0.10.0a
 Compiled with GLib 2.2.1, with libpcap 0.7.2, with libz 1.1.4, 
 with libpcre 4.5,with Net-SNMP 5.0.9, with ADNS.
 Running with libpcap (version unknown) on Linux 2.4.20-6
 tethereal [ -vh ] [ -DlLnpqSVx ] [ -a <capture autostop condition> ] ...
         [ -b <number of ring buffer files>[:<duration>] ] [ -c <count> ]
         [ -d <layer_type>==<selector>,<decode_as_protocol> ] ...
 		[ -f <capture filter> ] [ -F <output file type> ] [ -i <interface> ]
         [ -N <resolving> ] [ -o <preference setting> ] ... [ -r <infile> ]
         [ -R <read filter> ] [ -s <snaplen> ] [ -t <time stamp format> ]
         [ -T pdml|ps|text ] [ -w <savefile> ] [ -y <link type> ]
         [ -z <statistics string> ]
 Valid file type arguments to the "-F" flag:
         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)
         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

The following command line options are used to control Tethereal’s data capture and output:

• –a test:value This option is used when capturing to a file. It specifies to Tethereal when to stop writing to the file. The criterion is in the form of 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 have been reached.

• –b number of ring buffer files [:duration] This option is used with the –a option, and causes Tethereal to continue capturing data to successive files. This is known as ring buffer mode and it 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, Tethereal 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 that Tethereal writes to will be unlimited, and will only be restricted to the size of the partition. An optional duration parameter can also be specified so that Tethereal 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 file names that are 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.

• –c count This option 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.

• –d layer type==selector, decode-as protocol This option allows you to specify the way in which traffic is decoded. The parameters denote that if the layer type has a specified value then 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 non-standard ports.

• –D This option instructs Tethereal 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 Tethereal to actually open and attempt to capture on each interface that 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 Tethereal but are not, this option will not display any available interfaces.

• –f capture filter expression This option allows you to set the filter expression to use when capturing data. For example tethereal -f tcp port 80 will only capture incoming and outgoing HTTP packets.

• –F type This option is 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 that snoop can read the capture file, you would use the –F snoop option.

• –h This option prints the version of Tethereal in use and the help options, then exits.

• –i interface This option specifies the interface that you want to use to capture data. The –D option can be used to find out the names of your network interfaces. You can use the number or the name as a parameter to the –i option. If you run Tethereal without the –i option it will search the list of interfaces and choose the first non-loopback interface that it finds. If it doesn’t find any non-loopback interfaces, it will use the first loopback interface. If this doesn’t exist ether, Tethereal will exit with an error.

• –l This option flushes the standard output 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.

• –L This option lists the data link types that are supported by an interface and then exits. You can specify an interface to use or Tethereal will choose the first one it finds as stated in the –i option information.

• –n This option is used to disable network object name resolution, such as host names and port names.

• –N resolving flags This option is 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 if Tethereal is compiled with Asynchronous DNS (ADNS). The –N option overrides the –n option.

• –o prefname:value This option 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.

• –p This option tells Tethereal to not put the interface in promiscuous mode. This will cause Tethereal to only read traffic sent to and from the system on which Tethereal is running, broadcast traffic, and multicast traffic.

• –q This option 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.

• –r file This option reads and processes a saved capture file.

• –R filter This option 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.

• –s snaplen This option 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.

• –t format This option 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 is specified by the ad parameter and is 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.

• –T pdml|ps|text This option 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.

• –v This option prints the Tethereal version information and then exits.

• –V This option displays the capture in protocol tree form instead of the default summary packet form.

• –w file This option writes the packets to the file name specified following the option. If the option specified is - then standard output is used.

• –x This option displays the capture in a hexadecimal and ASCII dump format along with the summary or protocol tree view.

• –y type This option 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.

• –z statistics This option will enable Tethereal to collect various types of statistics about the data that is being captured. The results will be displayed after reading the capture file.

By default, Tethereal will display packets to the screen in summary line form. These are the same lines that are displayed in the Ethereal 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. Tethereal 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 Tethereal to print a hexadecimal and ASCII dump of the packet data with either the summary line or detailed protocol tree. Tethereal has a very strong display filter language and can also use the TCPDump filter syntax as well. These can be used to narrow down the type of traffic that you want to capture.

When using Tethereal to write a capture to a file, the file will be written in libpcap format by default. It will write all of the packets and all of the detail about the packets to the output file, thus the –V and the –x options aren’t necessary. Since Tethereal and Ethereal 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 Tethereal to perform a capture and display the output in a protocol tree view along with the associated hexadecimal and ASCII output:

C:\Program Files\Ethereal>tethereal -V -x
 Capturing on \Device\NPF_{A302C81E-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 Tethereal 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 up to a maximum of 10 output files. The following example is the command used to perform this capture:

C:\Program Files\Ethereal>
 tethereal -i4 -a filesize:5 -b 10 -w output

The output files generated are appended with the file number, date, and timestamp. 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 that a maximum of 10 files exist 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 Tethereal capture filter to capture all traffic except packets to and from HTTP port 80:

C:\Program Files\Ethereal>tethereal -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 Tethereal read filter to output the Telnet data packets from a file called capture:

C:\Program Files\Ethereal>tethereal -r capture -R "telnet"
   7  10.071157 192.168.100.122 -> 192.168.100.132 TELNET Telnet Data ...
   8  10.071464 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...
   9  10.071515 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...
  11  10.076114 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...
  12  10.076155 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...
  14  10.089546 192.168.100.122 -> 192.168.100.132 TELNET Telnet Data ...
  15  10.089672 192.168.100.132 -> 192.168.100.122 TELNET Telnet Data ...

The following is an example of using Tethereal 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; editcap can also be used to perform this function:

C:\Program Files\Ethereal>tethereal -r capture2 -w netmon_output -F netmon2

The following is an example of using the Tethereal statistics function to display a report of all bytes and frames for each protocol detected during the capture, the statistics will display after you end the capture by typing Ctrl + C:

C:\Program Files\Ethereal>tethereal –z io,phs
 <cntrl-c>
 ===================================================================
 Protocol Hierarchy Statistics
 Filter: frame
 frame                                    frames:560 bytes:115233
   eth                                    frames:560 bytes:115233
     ip                                   frames:558 bytes:115005
       udp                                frames:53 bytes:10383
         dns                              frames:21 bytes:3215
         data                             frames:8 bytes:496
         isakmp                           frames:24 bytes:6672
       tcp                                frames:505 bytes:104622
         http                             frames:107 bytes:81798
     llc                                  frames:2 bytes:228
       ipx                                frames:2 bytes:228
         ipxsap                           frames:2 bytes:228
 ===================================================================

The following is an example of using the Tethereal statistics function to display a report of all TCP conversations that take place during the capture, the statistics will display after you end the capture by typing Ctrl + C:

C:\Program Files\Ethereal>tethereal –z conv,tcp
 <cntrl-c>
 ============================================================================
 TCP Conversations
 Filter:<No Filter>
                                                |       <-      | |       ->
  | |     Total     |
                                            | Frames  Bytes | | Frames  Bytes
  | | Frames  Bytes |
 192.168.100.40:2077  <-> 64.12.26.97:http      18      1934      36      368
 4      54      5618
 192.168.100.40:2078  <-> 205.188.1.95:http      4       216       8       48
 0      12       696
 ============================================================================

Tethereal Statistics

Included are some additional examples and supplementary information to the following Tethereal man (short for manual) page statistics information:

COMMAND -z dcerpc,rtt,uuid,major.minor[filter]

DESCRIPTION Collect call and reply Response Time Test (RTT) data for Distributed Computing Environment Remote Procedure Call (DCE RPC) interface uuid, version major.minor. Data collected is the number of calls for each procedure, MinRTT, MaxRTT and AvgRTT. If the optional filterstring is provided, the statistics will only be calculated on those calls

that match that filter. Current supported DCE RPC programs are: ATSVC, BOSSVR, BUTC, CDS_CLERK, CONV, DEC_DFS, DFS, DNSSERVER, DRSUAPI, DTSPROVIDER, DTSSTIME_REQ, EPM, FLDB, FTSERVER, INITSHUTDOWN, KRB5RPC, LSA, LSA_DS, MAPI, MGMT, Messenger, NSPI, OXID, REMACT, REP_PROC, RPC_Browser, RPC_NETLOGON, RS_ACCT, RS_ATTR_RS_BIND, RS_PGO, RS_REPADM, RS_REPLIST, RS_UNIX, SAMR, SECIDMAP, SPOOLSS, SRVSVC, SVCCTL, TAPI, TKN4lnt, UBIKDISK, UBIKVOTE, WINREG, WKSSVC, cds_solicit, cprpc_server, dce_update, roverride, rpriv, re_misc, rsec_login.

EXAMPLE 1 -z dcerpc,rtt,12345778-1234-abcd-ef00-0123456789ac,1.0 will collect data for the Microsoft Security Account Manager (SAMR) interface.

EXAMPLE 2 _-z dcerpc,rtt,12345778-1234-abcd-ef00-0123456789ac,_1.0ip.addr==192.168.100.40 will collect SAMR RTT statistics for the host 192.168.100.40. Notice that there is no comma between the major.minor and filter. The Tethereal man page example shows that a comma is placed between these parameters, however this will cause Tethereal to report an error and exit.

NOTES This option can be used multiple times on the command line.

COMMAND -z io,phs[,filter]

DESCRIPTION Creates protocol hierarchy statistics listing both number of frames and bytes. If no filter is specified the statistics will be calculated for all frames. If a filter is specified, statistics will be only calculated for those packets that match the filter.

EXAMPLE 1 -z io,phs will generate statistics for all traffic.

EXAMPLE 2 -z io,phs,ip.addr==192.168.100.40 will generate statistics for all traffic to and from the host 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z io,stat,interval[,filter][,filter][,filter]...

DESCRIPTION Collects frame and bytes statistics for the capture in intervals of interval seconds. Intervals can be specified either as whole or fractional seconds. Interval can be specified in microsecond (ms) resolution. If no filter is specified the statistics will be calculated for all frames. If one or more filters are specified, statistics will be calculated for all filters and presented with one column of statistics for each filter. io,stat can also calculate COUNT() SUM() MIN() MAX() and AVG() using a slightly different filter syntax: [COUNT|SUM|MIN|MAX|AVG](<field>)<filter>. One important thing to note here is that the field that the calculation is based on must also be part of the filter string or else the calculation will fail. Also, be aware that a field can exist multiple times inside the same packet and will then be counted multiple times in those packets. COUNT(<field>) can be used on any type which has a display filter name. It will count how many times this particular field is encountered in the filtered packet list. SUM(<field>) can only be used on named fields of integer type. This will sum together every occurrence of this field’s value for each interval. MIN/MAX/AVG(<field>) can only be used on named fields that are either integers or relative time fields. This will calculate the maximum, minimum or average that is seen in each interval. If the field is a relative time field the output will be presented in seconds and three digits after the decimal point. The resolution for time calculations is 1ms; anything smaller will be truncated.

EXAMPLE 1 -z io,stat,1,ip.addr==192.168.100.40 will generate 1 second statistics for all traffic to and from host 192.168.100.40.

EXAMPLE 2 -z io,stat,0.001,“http&&ip.addr==192.168.100.40” will generate 1ms statistics for all HTTP frames to and from host 192.168.100.40.

EXAMPLE 3 -z io,stat,0.010,AVG(smb.time)smb.time will calculate the average time for Server Message Block (SMB) frames during each 10ms interval.

EXAMPLE 4 -z io,stat,0.010,COUNT(http.request)http.request will count the total number of HTTP requests seen in each 10ms interval.

EXAMPLE 5 -z io,stat,0.010,SUM(frame.pkt_len)frame.pkt_len will report the total number of bytes seen in all the frames within a 10ms interval.

EXAMPLE 6 -z io,stat,0.010,“smb.time&&ip.addr_==192.168.100.40”,MIN(smb.time) “smb.time&&ip.addr==_192.168.100.40”,MAX(smb.time)“smb.time&&ip.addr==192.168.100.40”,AVG(smb.time)“smb.time&&ip.addr==192.168.100.40” will calculate statistics for all SMB response times we see to and from host 192.168.100.40 in 10ms intervals. The output will be displayed in 4 columns; number of frames/bytes, minimum response time, maximum response time, and average response time.

NOTES This option can be used multiple times on the command line.

COMMAND -z conv,type[,filter]

DESCRIPTION Creates a table that lists all conversations that could be seen in the capture. type specifies which type of conversation we want to generate the statistics for, currently the supported ones are “eth” Ethernet, “fc” Fibre Channel, “fddi” FDDI, “ip” IP addresses, “ipx” IPX addresses, “tcp” TCP/IP socketpairs, “tr” TokenRing, and “udp” UDP/IP socketpairs. Both IPv4 and IPv6 are supported. If the optional filter string is specified, only those packets that match the filter will be used in the calculations. The table is presented with one line for each conversation and displays number of frames/bytes in each direction as well as total number of frames/bytes. The table is sorted according to total number of bytes.

EXAMPLE -z conv,ip,ip.addr==192.168.100.40 will list IP conversations for host 192.168.100.40.

NOTES None.

COMMAND -z proto,colinfo,filter,field

DESCRIPTION Appends all field values for the packet to the COL_INFO information line. This feature can be used to append arbitrary fields to the COL_INFO line in addition to the normal content of the COL_INFO line. field is the display filter name of a field which

value should be placed on the COL_INFO line. filter is a filter string that controls for which packets the field value will be presented on COL_INFO line. field will only be presented on the COL_INFO line for the packets which match filter. In order for Tethereal to be able to extract the field value from the packet, field MUST be part of the filter string. If not, Tethereal will be unable to extract its value.

EXAMPLE 1 -z proto,colinfo,tcp.len,tcp.len will add the TCP segment length, “tcp.len”, field to COL_INFO for all packets containing the “tcp.len” field.

EXAMPLE 2 _-z proto,colinfo,“tcp.len&&ip.src==192.168.100.40”,tcp.len will put “tcp.len” on COL_INFO but only for packets coming from host 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z rpc,rtt,program,version[,filter]

DESCRIPTION Collects call and reply RTT data for program/version. The data collected is the number of calls for each procedure, MinRTT, MaxRTT and AvgRTT. If the optional filter string is provided, the statistics will only be calculated on those calls that match that filter.

EXAMPLE 1 -z rpc,rtt,100003,3 will collect data for Network File System (NFS) v3.

EXAMPLE 2 -z rpc,rtt,100003,3,nfs.fh.hash==0x12345678 will collect NFS v3 RTT statistics for a specific file.

NOTES This option can be used multiple times on the command line.

COMMAND -z rpc,programs

DESCRIPTION Collects call and reply RTT data for all known ONC-RPC programs/versions. Data collected is the number of calls for each protocol/version, MinRTT, MaxRTT and AvgRTT.

EXAMPLE -z rpc,programs will collect data for all known ONC-RPC programs/versions.

NOTES This option can only be used once on the command line.

COMMAND -z smb,rtt[,filter]

DESCRIPTION Collects call and reply RTT data for SMB. The data collected is the number of calls for each SMB command, MinRTT, MaxRTT and AvgRTT. The data will be presented as separate tables for all normal SMB commands, all Transaction2 commands and all NT Transaction commands. Only those commands that are seen in the capture will have its statistics displayed. Only the first command in a “xAndX” command chain will be used in the calculation. So for common “SessionSetupAndX + TreeConnectAndX” chains, only the “SessionSetupAndX” call will be used in the statistics. This is a flaw that might be fixed in the future. If the optional filter string is provided, the stats will only be calculated on those calls that match that filter.

EXAMPLE 1 -z smb,rtt will collect all SMB statistics.

EXAMPLE 2 -z smb,rtt,ip.addr==192.168.100.40 will only collect statistics for SMB packets exchanged by the host at IP address 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z smb,sids

DESCRIPTION When this feature is used Tethereal will print a report with all the discovered Security Identifiers (SIDs) and account name mappings. Only those SIDs where the account name is known will be presented in the table. For this feature to work you will need to either to enable “Edit|Preferences|Protocols|SMB|Snoop SID to name mappings” in the preferences or you can override the preferences by specifying –o smb.sid_name_snooping:TRUE on the Tethereal command line.

EXAMPLE -o smb.sid_name_snooping:TRUE -z smb,sids will enable the mapping preference and report all discovered SMB SIDs.

NOTES The current methods used by Tethereal to find the SID. Name mapping is relatively restricted but is hoped to be expanded in the future.

COMMAND -z mgcp,rtd[,filter]

DESCRIPTION Collects requests and response Response Time Delay (RTD) data for Media Gateway Control Protocol (MGCP). This is similar to -z smb,rtt. The data collected is the number of calls for each known MGCP Type, MinRTD, MaxRTD and AvgRTD. Additionally you get the number of duplicate requests/responses, unresponded requests, responses that don’t match with any request. If the optional filter string is provided, the stats will only be calculated on those calls that match that filter.

EXAMPLE 1 -z mgcp,rtd will collect all statistics for all MGCP traffic.

EXAMPLE 2 -z mgcp,rtd,ip.addr==192.168.100.40 will collect statistics for MGCP packets exchanged by the host at IP address 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z h225,counter[,filter]

DESCRIPTION Count ITU-T H.225 messages and their reasons. The first column provides a list of H.225 messages and H.225 message reasons, which occur in the current capture file. The second column displays the number of occurrences of each message or reason.

EXAMPLE 1 -z h225,counter will collect all H.225 messages and their reasons.

EXAMPLE 2 -z h225,counter,ip.addr==192.168.100.40 will collect statistics for H.225 packets exchanged by the host at IP address 192.168.100.40.

NOTES This option can be used multiple times on the command line.

COMMAND -z h225,srt[,filter]

DESCRIPTION Collect request and response SRT (Service Response Time) data for ITU-T H.225 RAS. The data collected is number of calls of each ITU-T H.225 RAS Message Type, Minimum SRT, Maximum SRT, Average SRT, Minimum in Frame, and Maximum in Frame. Additionally it displays the number of Open Requests (Unresponded Requests), Discarded Responses (responses without matching requests), and Duplicate Messages.

EXAMPLE 1 -z h225,srt will collect all SRT data for all ITU-T H.225 RAS traffic.

EXAMPLE 2 -z h225,srt,ip.addr==192.168.100.40 will collect SRT statistics for ITU-T H.225 RAS packets exchanged by the host at IP address 192.168.100.40.

NOTES This option can be used multiple times on the command line.

Notes from the Underground…
XML Compatible Protocol Dissection

A new feature to Tethereal 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 that Tethereal produces differs slightly from the specification and is not readable by Analyzer. The Tethereal 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=”ethereal/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 that 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.

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

  value The actual packet data, in hex, that 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 ethereal-0.10.0a/tools directory to assist with PDML output parsing. EtherealXML.py is a Python module used to read a PDML file and call a specified callback function. Msnchat is a sample program that uses EtherealXML to parse PDML output for MSN chat conversations. It takes one or more capture files as input, invokes Tethereal 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 TETHEREAL  location of tethereal 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 the following:

---- 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 following command:

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

The HTML output would then look like the following:

 ---- New Conversation @ Dec 30, 2003 14:21:08 ----
 (14:21:08) Luke: hello
 (14:21:22) Leia: how are you?
 (14:21:53) Luke: are we meeting at noon?
 (14:22:03) Leia: yes, at the secret location.
 (14:22:11) Luke: great, see you then
 (14:22:17) Leia: ok
 (14:22:18) Leia: bye

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.

Editcap

Editcap is a program used to remove or select packets from a file and to translate the format of captured files. It doesn’t capture live traffic; it only reads data from a saved capture file and then saves some or all of the packets to a new capture file. Editcap can read all of the same types of files that Ethereal can, and by default writes to libpcap format. Editcap can also write captures to standard and modified versions of libpcap, Sun snoop, Novell LANalyzer, Networks Associate’s Sniffer, Microsoft Network Monitor, Visual Network traffic capture, Accellent 5Views capture, and Network Instruments Observer version 9 captures. Editcap can determine the file type that it is reading, and is also capable of reading files that are compressed with gzip.

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\Ethereal>editcap -h
 Usage: editcap [-r] [-h] [-v] [-T <encap type>] [-F <capture type>]
                [-s <snaplen>] [-t <time adjustment
                <infile> <outfile> [ <record#>[-<record#>] ... ]
   where -r specifies that the records specified should be kept, not deleted,
                            default is to delete
         -v specifies verbose operation, default is silent
         -h produces this help listing.
         -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
             ieee-802-11-radio - IEEE 802.11 Wireless LAN with radio information
             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
             prism - IEEE 802.11 plus Prism II monitor mode header
             pflog-old - OpenBSD PF Firewall logs, pre-3.4
             hhdlc - HiPath HDLC
             docsis - Data Over Cable Service Interface Specification
             cosine - CoSine L2 debug log
             wlan - IEEE 802.11 plus AVS WLAN monitor header
             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
             default is the same as the input file
         -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)
             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
         -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
             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 This option is 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 that snoop can read the capture file, you would use the –F snoop option.

• –h This option prints the help options of editcap, then exits.

• –r This option will cause 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 This option will set 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] This option will allow 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 This option 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 This option will cause 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, plus packets 10, 15, and 17 from a tethereal libpcap capture file called capture to a Sun snoop output file called capture_snoop:

C:\Program Files\Ethereal>editcap -r -v -F snoop capture capture_snoop 1-5 10 15 17
 File capture is a libpcap (tcpdump, Ethereal, etc.) capture file.
 Add_Selected: 1-5
 Inclusive ... 1, 5
 Add_Selected: 10
 Not inclusive ... 10
 Add_Selected: 15
 Not inclusive ... 15
 Add_Selected: 17
 Not inclusive ... 17
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 10
 Record: 15
 Record: 17

The next example uses editcap to translate 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\Ethereal>editcap -v capture capture_out 5-120
 File capture is a libpcap (tcpdump, Ethereal, 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 Pro capture file called capture.dump as input and saves the output to a Novell LANalyzer file called capture_out:

C:\Program Files\Ethereal>editcap -v -F lanalyzer -t 5.5 capture.dump capture_out
 File capture is a libpcap (tcpdump, Ethereal, 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
 

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\Ethereal>editcap -v -s 35 capture capture_out
 File capture is a libpcap (tcpdump, Ethereal, 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
 

The next example uses editcap to translate 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\Ethereal>editcap -v -T ieee-802-11 capture capture_out
 File capture is a libpcap (tcpdump, Ethereal, 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
 

Mergecap

Mergecap is used to combine multiple saved capture files into a single output file. Mergecap can read all of the same types of files that Ethereal can, and by default writes to libpcap format. Mergecap can also write the output capture file to standard and modified versions of libpcap, Sun snoop, Novel LANalyzer, NAI Sniffer, Microsoft Network Monitor, Visual Network traffic capture, Accellent 5Views capture, and Network Instruments Observer version 9 captures. Mergecap can determine the file type that it is reading, and is also capable of reading files that are compressed with gzip. By default, the packets from the input files are merged in chronological order based on each packet’s timestamp. If the –a option is specified, packets will be copied directly from each input file to the output file regardless of timestamp.

The following information is the usage output for the mergecap program:

C:\Program Files\Ethereal>mergecap -h
 mergecap version 0.10.0
 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
              ieee-802-11-radio - IEEE 802.11 Wireless LAN with radio _          information
              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
              prism - IEEE 802.11 plus Prism II monitor mode header
              pflog-old - OpenBSD PF Firewall logs, pre-3.4
              hhdlc - HiPath HDLC
              docsis - Data Over Cable Service Interface Specification
              cosine - CoSine L2 debug log
              wlan - IEEE 802.11 plus AVS WLAN monitor header
              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
              default is the same as the first input file
         -F <capture type> 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)
              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

The following command line options are used to control Editcap’s data translation and output:

• –a This option will ignore the timestamps in the input capture files and merge the capture files one after the other. When this option is omitted the packets in the input files are merged in chronological order based on the packet timestamps.

• –F type This option is used to set the format of the output capture file. For example, if you want to merge capture files and save them in the Sun snoop format so that snoop can read the output file, you would use the –F snoop option.

• –h This option prints the help options of mergecap, then exits.

• –s snaplen This option will set 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 type This option sets the packet encapsulation type of the output capture file. The default type is the same encapsulation type as the input files, if they are all the same. If the input files do not all have the same encapsulation type, the encapsulation type of the output file will be set to WTAP_ENCAP_PER_PACKET. However, libpcap and other capture formats do not support this type of encapsulation. The –T 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.

• –v This option will cause mergecap to print various messages to the screen while it is processing files.

• –w file This option writes the packets to the file name specified following the option. This option is required for mergecap to merge files.

The following is an example of using mergecap to merge the first 35 bytes of each of the four capture files (capture1, capture2, capture3, and capture4) into a single Sun snoop output file called merge_snoop in chronological order by packet timestamp, it will keep reading packets until the end of the last file is reached:

C:\Program Files\Ethereal>mergecap -s 35 -v -F snoop -w merge_snoop capture1 capture2 capture3 capture4
 mergecap: capture1 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture2 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture3 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture4 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: opened 4 of 4 input files
 mergecap: selected frame_type Ethernet (ether)
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10
 output removed
 

The following is an example of using mergecap to merge four capture files (capture1, capture2, capture3, and capture4) into a single output file called merge_file regardless of packet timestamp, it will write all of the packets of capture1, followed by capture 2, and so on:

C:\Program Files\Ethereal>mergecap -v -a -w merge_file capture1 capture2 capture3 capture4
 mergecap: capture1 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture2 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture3 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture4 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: opened 4 of 4 input files
 mergecap: selected frame_type Ethernet (ether)
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10
 output removed
 

The following is an example of an attempt to use mergecap to merge three capture files with different encapsulation types (capture1, capture2, and capture3) into a single output file called merge_encap The merge will attempt to set the default encapsulation type and then report an error because libpcap does not understand that type of encapsulation:

C:\Program Files\Ethereal>mergecap -v -w merge_encap capture1 capture2 capture3
 mergecap: capture1 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture2 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture3 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: opened 3 of 3 input files
 mergecap: multiple frame encapsulation types detected
           defaulting to WTAP_ENCAP_PER_PACKET
           capture1 had type (null) ((null))
           capture2 had type Ethernet (ether)
 mergecap: selected frame_type (null) ((null))
 mergecap: Can't open/create merge_encap:
           That file format doesn't support per-packet encapsulations

The following is an example of an attempt to use mergecap to merge three capture files with different encapsulation types (capture1, capture2, and capture3) into a single output file called merge_encap, the –T option is used to force an Ethernet encapsulation type for the output file:

C:\Program Files\Ethereal>mergecap -v -T ether -w merge_encap capture1 capture2 capture3
 mergecap: capture1 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture2 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: capture3 is type libpcap (tcpdump, Ethereal, etc.).
 mergecap: opened 3 of 3 input files
 Record: 1
 Record: 2
 Record: 3
 Record: 4
 Record: 5
 Record: 6
 Record: 7
 Record: 8
 Record: 9
 Record: 10
 output removed
 

Text2pcap

Text2pcap generates capture files by reading ASCII hexadecimal dump captures and writing the data to a libpcap output file. It is capable of reading a hexdump of single or multiple packets, and building capture files from it. Text2pcap can also read hexdumps of application level data only, by creating dummy Ethernet, IP, and User Datagram Protocol (UDP) or TCP headers so Ethereal and other sniffers can read the full data. The user can specify which of these headers to add.

Text2pcap uses the octal dump (od) format of hexadecimal output. Octal dump is a UNIX command that is used to output a file or standard input to a specified form, such as octal, decimal, or hexadecimal format. The format is specified by the parameters given to the –t option. The command od –t x1 will generate output that text2pcap can understand (the x1 describes the format of hexadecimal). The following is an example of the type of hexadecimal dump that text2pcap can read:

0000  00 05 5d ee 7e 53 08 00 20 cf 5b 39 08 00 45 00   ..].~S.. .[9..E.
 0010  00 9a 13 9e 40 00 3c 06 e0 70 c0 a8 64 7a c0 a8   ....@.<..p..dz..
 0020  64 84 00 17 05 49 0e a9 91 43 8e d8 e3 6a 50 18   d....I...C...jP.
 0030  c1 e8 ba 7b 00 00 4c 61 73 74 20 6c 6f 67 69 6e   ...{..Last login
 0040  3a 20 53 75 6e 20 4e 6f 76 20 20 32 20 31 37 3a   : Sun Nov  2 17:
 0050  30 36 3a 35 33 20 66 72 6f 6d 20 31 39 32 2e 31   06:53 from 192.1
 0060  36 38 2e 31 30 30 2e 31 33 32 0d 0a 53 75 6e 20   68.100.132..Sun
 0070  4d 69 63 72 6f 73 79 73 74 65 6d 73 20 49 6e 63   Microsystems Inc
 0080  2e 20 20 20 53 75 6e 4f 53 20 35 2e 39 20 20 20   .   SunOS 5.9
 0090  20 20 20 20 47 65 6e 65 72 69 63 20 4d 61 79 20       Generic May
 00a0  32 30 30 32 0d 0a 23 20                           2002..#

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 ability 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 is the usage output for the text2pcap program:

Usage: text2pcap [-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.

The following command line options are used to control text2pcap’s data processing and output:

• –h This option prints the help options of text2pcap, then exits.

• –d This option displays debugging information during the processing. Like verbose options it can be used several times for more information.

• –q This option causes text2pcap to be quiet while processing.

• –o h|o This option specifies either hexadecimal or octal formats for the offset of the output. The default is hexadecimal.

• –l typenum This option 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 This option 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 This option 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 This option will allow you to set the maximum packet length with the max-packet parameter. The default is 64000.

• –u srcport, destport This option 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 has does not contain any UDP layer 4 or below information. This option will also include the necessary IP and Ethernet information.

• –T srcport, destport This option 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 has 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 This option allows you to include a dummy Stream Control Transmission Protocol (SCTP) header for each packet. The srcport and destport 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 has 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 This option 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 has 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 This option 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\Ethereal>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\Ethereal>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 each the IP and TCP header, 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

Summary

As we have shown in this chapter, Ethereal is more than the GUI; it is a suite of programs that provide command line capturing, formatting, and manipulating capabilities. The programs can be used together to provide even more processing capabilities, while output from one program can be piped as input to another. Since these programs are command line, they also provide powerful scripting capabilities.

Tethereal provides just about all of the same processing capabilities as Ethereal, without the GUI functionality. Editcap, although used primarily for removing packets from a capture file, can also be used to translate capture files into various formats. Mergecap provides the ability to merge various capture files together, even from different network analyzers. This is a great resource when you’re performing audits or incident response and you need to combine captures from various source such as sniffers, IDS, and logs. Text2pcap allows you to translate hexadecimal data streams to sniffer readable packet captures. You can even add dummy Layer 2-4 data when you only have an application output stream.

Solutions Fast Track

Tethereal

• Tethereal can read packets from the network or from a packet capture file.

• Tethereal can decode and print the captured packets to screen or save them to a file.

• One of the best advantages to using Tethereal is that it is highly scriptable.

• Tethereal can apply both capture filters and display filters to the packet captures.

• Tethereal can collect various types of statistic about the data that is being captured.

• Like editcap, Tethereal can be used to translate capture file formats.

Editcap

• Editcap can be used to remove packets from a capture file or to translate the format of capture files.

• The –t option in editcap is used to apply a time adjustment to the timestamps of the packets.

• The snapshot length can be specified with the –s option to decrease the size of each packet.

• Editcap can specify an encapsulation type for the packets in the output file with the –T option.

Mergecap

• Mergecap can merge several packet capture files into a single output file.

• Mergecap can read capture files of various formats and output them to a single format.

• By default, the packets from the input files are merged in chronological order based on each packets timestamp, however if the –a option is specified, packets will be copied directly from each input file to the output file regardless of timestamp.

• Mergecap can merge capture files with different encapsulation types into a single output file by using the –T option to force the output encapsulation type.

Text2pcap

• Text2pcap reads ASCII hexadecimal dump captures and writes the data to a libpcap output file.

• Text2pcap can insert dummy Ethernet, IP, and UDP or TCP headers.

• The command od –t x1 will generate output that text2pcap can understand.

• An offset of 0 indicates the beginning of a new packet.

• Text2pcap options give you a lot of control over the dummy headers, timestamps, and encapsulation type for each packet.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form. You will also gain access to thousands of other FAQs at ITFAQnet.com.

1.	What is the difference between using Tethereal and editcap to translate the format of capture files?
2.	Can mergecap combine gzipped files?
3.	What types of things can I do to make scripting with Tethereal faster?
4.	Can I use filters to specify what packets to remove with editcap?

Answers

1.	Nothing - they both perform the same function. However, editcap would be a more efficient method of converting files because Tethereal contains a lot of code for protocol dissection, whereas editcap is a smaller program with only a few functions. You can also use the Ethereal GUI to do the same thing by choosing Save As from the File menu.
2.	Yes, mergecap can automatically uncompress, read, and merge gzip files.
3.	One way to make scripting faster with Tethereal is to use the –l option to flushes the standard output after each packet is printed instead of waiting until it fills up. This way each packet is sent as soon as it is read and dissected. You can also use the –n option to disable network object name resolution to make the process faster.
4.	No, editcap does not have the capability to use filters. You must know the packet numbers that you want to include or exclude from the output capture file. You can use Tethereal to read a capture file, apply filters, and output the results to a new capture file.

Оставьте свой комментарий !
Ваше имя: Комментарий: Оба поля являются обязательными  Автор   Комментарий к данной статье