Writing Display Filters

 < Day Day Up > 



Ethereal’s display filter mechanism is designed differently than tcpdump’s filters. Tcpdump is a packet analyzer that knows how to decode many protocols, but it relies on libpcap’s filtering engine. Libpcap is a separate library that does not know how to parse many protocols, so libpcap’s filter language is poor in relation to tcpdump’s ability in this respect.

In Ethereal, the protocol-dissection mechanism is intertwined with the display filter mechanism. For almost every item you see in the protocol tree in the middle pane of Ethereal’s GUI, Ethereal has a field name that you can use in a display filter. The Appendix of this book has a list of some commonly used display-filter field names that Ethereal defines, while the CD-ROM that accompanies this book provides HTML pages that show all the display-filter field names for Ethereal version 0.10.0a. These HTML pages are in the /filters directory on the CD-ROM. You can also use the Help | Supported Protocols | Display Filter Fields option in Ethereal to see a similar list. Perhaps the easiest way to find the display-filter name of a field that you’re interested in is to highlight that field in the Ethereal GUI. When highlighted, Ethereal will provide the display-filter field name in the right-hand side of the status bar at the bottom of the GUI. Figure 5.2 shows that ip.len is the name of the IP Total Length field. The ip.len field name is shown in parentheses in the status bar on the bottom right of the Ethereal window.

click to expand
Figure 5.2: Display Filter Name for IP Total Length

Even the protocol names themselves have display-filter names. Figure 5.3 shows that the ip field name represents the IP protocol.

click to expand
Figure 5.3: Display Filter Name for IP

Writing Expressions

To test for the existence of a protocol or a field, the display filter is simply the display-filter field name of that protocol or field. To show all IP packets, use:

ip

This shows all packets where the IP protocol is present. You could also show all packets where a field is present:

ip.len

Because IP packets always have a total length (ip.len) field, this is functionally equivalent to testing merely for ip. But some protocols, like TCP, can vary the fields that are present in a protocol header. TCP has optional fields, one of which is MSS option, represented by the tcp.options.mss_val field name. To find all packets that have the tcp.options.mss_val field, just name the field in the display filter:

tcp.options.mss_val

Display-filter fields in Ethereal are typed. This means that depending on its type, a field can hold only certain values. The types in the display filter language are shown in Table 5.11.

Table 5.11: Display Filter Field Types

Display Filter Field Types

Possible Values

Unsigned Integer

Non-negative integers. Can be 8-, 16-, 24-, 32, or 64-bits wide

Signed Integer

Integers. Can be 8-, 16-, 24-, 32-, or 64-bits wide

Boolean

True or False

Frame Number

Like a 32-bit Unsigned Integer, but with special behaviors

Floating Point

Decimal number, i.e., real numbers

Double-precision

Floating point number that can store more Floating Point digits

String

Sequence of characters

Byte String

A sequence of hexadecimal digits

Hardware Address

A six-byte long Byte String with name-lookup capabilities

IPv4 Address

IPv4 address with name-lookup capabilities

IPv6 Address

IPv6 address with name-lookup capabilities

IPX Network

4-byte IPX network number with name-lookup capabilities

Absolute Time

Date/time stamp

Relative Time

Number of seconds between two absolute times

None

A field that holds no value and is used only as a label or placeholder

Protocol

Protocol keywords

The operators that can be used to compare values are shown in Table 5.12.

Table 5.12: Operators Used to Compare Values

Operators

Meanings

> or gt

Greater Than

>= or ge

Greater Than or Equal To

< or lt

Less Than

<= or le

Less Than or Equal To

== or eq

Equal To

!= or ne

Not Equal To

contains

A string or byte string is found within another

matches

A regular expression matches a string

Multiple relations can be combined with the logical operators and and or. You can negate the logical meanings with not. Parenthesis can be used to group logical operations correctly.

Note 

The matches operator only works if your copy of Ethereal was compiled with support for the Perl Compatible Regular Expressions (PCRE) library. Perl is a very popular scripting language which has regular expression built into its syntax, giving programmers a powerful way to search for strings. The PCRE library, available at www.pcre.org, enables other programs, like Ethereal, to use regular expressions that are in the same syntax as those provided by Perl. Furthermore, the matches operator was introduced to Ethereal in version 0.10.0, and only works with string fields. During the development of this book, the matches operator has been extended to work on byte sequences and protocols, just like the contains operator. When Ethereal 0.10.1 is released, the matches operator will work on all the same fields that the contains operator currently supports.

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.

Table 5.13: Different Representations for the Same Integer

Display Filter

Integer Notation

eth.len > 1500

Decimal

eth.len > 02734

Octal

eth.len > 0x5dc

Hexadecimal

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).

Table 5.14: Range of Values According to Integer

Bit Width

Signed Range

Unsigned Range

8-bit

-27 to 27-1
-128 to 127

0 to 28-1
0 to 255

16-bit

-215 to 215-1
-32,768 to 32,767

0 to 216-1
0 to 65,535

24-bit

-223 to 223-1
-8,388,608 to 8,388,607

0 to 224-1
0 to 16,777,215

32-bit

-231 to 231-1
-2,147,483,648 to
2,147,483,647

0 to 232-1
to
4,294,967,295

64-bit

-263 to -263-1

0 to 264-1

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.

Table 5.15: SNA Transmission Group Segmenting Field

Integer Field/Value

Label

0

Not Segmented

1

Last segment

2

First segment

3

Middle segment

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.

click to expand
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
Note 

Storing hardware addresses in an /etc/ethers file used to be common practice on UNIX systems, but many UNIX systems these days no longer come with an /etc/ethers file. However, the /etc/ipxnets file has no such history. It is a file unique to Ethereal. Don’t expect to find an intalled /etc/ipxnets file on a UNIX system, even if that system comes with an /etc/ethers file.

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.

click to expand
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.

Table 5.16: Range Syntax

Range Syntax

Meaning

[ offset ]

Slice a single byte at “offset”

[ offset : length ]

Slice “length” bytes starting at “offset”

[ offset1 – offset2 ]

Slice bytes from “offset1” to “offset2”, inclusive

[ : length ]

Slice “length” bytes starting at offset 0

[ offset : ]

Slice bytes from “offset” to end of field

[ range , range ]

Combine any range syntax with another

Note 

The Ethereal documentation states that you are supposed to be able to use negative numbers as offsets. Negative offsets indicate the offset counting backwards from the end of the field. But, in our testing this doesn’t work as advertised. It is extremely likely that this will be fixed in a future version of Ethereal.

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.

Table 5.17: Generic Versions of Source and Destination Fields

Source Field

Destination Field

Generic Version

eth.src

eth.dst

eth.addr

fddi.src

fddi.dst

fddi.addr

ip.src

ip.dst

ip.addr

ipx.src.net

ipx.dst.net

ipx.net

ipx.src.node

ipx.dst.node

ipx.node

tcp.srcport

tcp.dstport

tcp.port

tr.src

tr.dst

tr.addr

udp.srcport

udp.dstport

udp.port

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

click to expand
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.

start sidebar
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.

end sidebar

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.

click to expand
Figure 5.7: Ethernet Source and Destination Address Fields

start sidebar
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.

end sidebar

/* 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.

Filter List Dialog Boxes

Ethereal allows you to save both capture filters and display filters, and use them again in the future by selecting from a menu. This is nice when you have complicated filters or many filters that you use often. Ethereal maintains two distinct lists of filters, one for capture filters and another for display filters. The user interfaces for both lists of filters are almost identical, so they will be explained together.

The Capture | Start menu item presents the Capture Options user interface, shown in Figure 5.8. Next to the text entry box where you can type in a capture filter, there is a button labeled Filter:. Clicking this button brings up the Capture Filter user interface. Another way to open the Capture Filter dialog box is to select the Capture | Capture Filters menu item.

click to expand
Figure 5.8: Capture Options Dialog Box

As shown in Figure 5.9, at the bottom of the main Ethereal window is the text entry box where you can type in a display filter. Next to this box is a button labeled Filter:. Clicking this button brings up the Display Filter user interface. The Display Filter user interface can also be opened from the Analyze | Display Filters menu option.

click to expand
Figure 5.9: Ethereal Main Window and Filter Button

You’ll notice that the Capture Filter window in Figure 5.10 and the Display Filter window in Figure 5.11 are nearly identical. The only functional differences are the existence of an Add Expression button and an Apply button in the Display Filter window, unless the Display Filter window was opened via Analyzer | Display Filters. The Add Expression button brings up a user interface to create display filters by pointing and clicking. The Apply button applies the display filter to a currently loaded capture file, thereby possibly changing the packets that are displayed in the main Ethereal GUI. The Capture Filter window does not have an Apply button because capture filters do not affect the currently-loaded capture file.

click to expand
Figure 5.10: Capture Filter Dialog Box

click to expand
Figure 5.11: Display Filter Dialog Box

To add a new filter to the list, enter a meaningful name in the Filter name text entry box and enter the filter itself in the Filter string text entry box. Then click the New button. This adds the named filter to the list, as shown in Figure 5.12.

click to expand
Figure 5.12: Display Filter Dialog After Clicking New

To change either the name or the contents of a filter, highlight the name of the filter in the list of filters by clicking on it. The name of the filter you just clicked on and its contents should now appear in the Filter name and Filter string text-entry boxes. Clicking on the text in either or both of these will allow you to modify the filter name and contents. When you are ready to save the modification, click the Change button.

To create a new filter based on a currently saved filter, highlight the name of the filter you wish to copy. The filter’s name and contents should appear in the Filter name and Filter string text entry boxes. Click the Copy button and a new filter will be created and put into the list of filters. The new filter will be named “Copy of ...”, where “...” is the name of the filter you highlighted. The contents will be an exact replica of the contents of the original filter, as shown in Figure 5.13. At this point, you can modify the name or contents of the new filter as you would any other filter. Of course, be sure to click the Change button after changing your new copy, otherwise the changes won’t be saved.

click to expand
Figure 5.13: Display Filter Dialog After Clicking Copy

To delete a filter from the filter list, highlight the name of the filter, and ensure that its name and contents appear in the Filter name and Filter string text entry boxes. Click the Delete button and it will disappear.

Clicking the OK button in the Display Filter or Capture Filter window will do two things: it will save your filter modifications in memory, but not to disk, and if you have a filter currently highlighted, it will place that filter in the text entry box from which the Display Filter or Capture Filter window was opened. For Capture Filters, the filter is placed in the Capture Options window, the Capture Filter window is closed, and you can continue to modify your options for capturing packets. For Display Filters, the filter is placed in the text entry box at the bottom of the main Ethereal window and is applied to the currently loaded capture file. At this point, if you quit the Ethereal program, your modifications to the display or capture filter list will be lost.

If you want to save your modifications to the filter lists, you must press the Save button in the Display Filter and Capture Filter windows.

The Close button in the Display Filter and Capture Filter windows also saves your modifications in memory only, and closes the filter window, but unlike the OK button, does not apply your filter to the Capture Options window or the main Ethereal window.

Filter Expression Dialog Box

It’s impossible to remember all the field names that are available in Ethereal’s display filter language because there are over 15,000 of them. Ethereal comes with a manual page named ethereal-filter, which lists all the fields. This book comes with a CD-ROM with HTML pages, in the /filters directory, that provide a searchable index of all the fields, and the Appendix has the same tables from some of the more commonly used protocols. The Ethereal program itself, however, provides a user interface which lets you peruse the protocols and fields they contain and construct a display filter.

start sidebar
Notes from the Underground…
Exchanging Filters With Your Friends

Do you need an easy way to exchange your extensive collection of capture filters or display filters with your friends? Ethereal saves your capture filters in a file names cfilters, and your display filters in a file name dfilters. On a UNIX system, those files are in your $HOME/.ethereal directory, while on a Windows system those files are in %APPDATA%\Ethereal, or if %APPDATA% isn’t defined, in %USERPROFILE%\Application Data\Ethereal. These two files, cfilter and dfilter, are simple text files, with one record per line. You can paste new entries into these files and the next time you start Ethereal, the new filters will be available in Ethereal.

end sidebar

From the Display Filter window, click the Add Expression button. The Filter Expression window, shown in Figure 5.14, appears.

click to expand
Figure 5.14: Filter Expression Dialog Box

On the left is a list of all protocols. Each protocol that has fields, which is most of them, can be opened by clicking on the square next to the protocol’s name, thereby presenting a list of the protocol’s fields. When a field name is selected in the list, the relations that apply to that field are shown in the Relation list. The relations are: is present, ==, !=, >, <, >=, <=, and contains. The matches keyword does not appear in this list; this is an oversight that surely will be fixed in a future version of Ethereal. Not all the relations apply to all field types, so only the applicable relations for the selected field are shown.

The default relation is is present, which does not require any other value to compare against. But if you select another relation, one that does require a comparison value, then a Value text entry box appears to the right of the relation list. This is shown in Figure 5.15. If the field can be sliced into ranges, then a Range text entry box appears under the Relation list.

click to expand
Figure 5.15: Filter Expression Dialog With Operation That Accepts Values

If the selected field has labels that represent its possible values, the list possible values will appear under the Value text entry box. An example is shown in Figure 5.16.

click to expand
Figure 5.16: Filter Expression With Field That Has Labeled Values

The text you type into the Value and Range text entry boxes are the same that you would type into a normal display filter. If you’re happy with the selections you have made, click the Accept button. Ethereal will put the display filter in the Filter string text entry box of the Display Filter dialog box at the current location of your cursor. In this way, after creating one display filter, you could manually type a logical operator (and or or) into the Filter string text entry box and click Add Expression again. When you accept the second display filter, it is appended to your display filter in the Filter string text entry box, as that’s where your cursor is.



 < Day Day Up > 



Ethereal Packet Sniffing
Ethereal Packet Sniffing (Syngress)
ISBN: 1932266828
EAN: 2147483647
Year: 2004
Pages: 105
Authors: Syngress

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net