B<Ethereal> is a GUI network protocol analyzer. It lets you
interactively browse packet data from a live network or from a
-previously saved capture file. Ethereal knows how to read B<libpcap>
-capture files, including those of B<tcpdump>. In addition, Ethereal can
+previously saved capture file. B<Ethereal> knows how to read B<libpcap>
+capture files, including those of B<tcpdump>. In addition, B<Ethereal> can
read capture files from B<snoop> (including B<Shomiti>) and B<atmsnoop>,
B<LanAlyzer>, uncompressed B<Sniffer>, Microsoft B<Network Monitor>,
AIX's B<iptrace>, B<NetXray>, B<Sniffer Pro>, B<RADCOM>'s WAN/LAN
analyzer, B<Lucent/Ascend> router debug output, HP-UX's B<nettl>, and
the dump output from B<Toshiba's> ISDN routers. There is no need to
-tell Ethereal what type of file you are reading; it will determine the
-file type by itself. Ethereal is also capable of reading any of these
-file formats if they are compressed using gzip. Ethereal recognizes
+tell B<Ethereal> what type of file you are reading; it will determine the
+file type by itself. B<Ethereal> is also capable of reading any of these
+file formats if they are compressed using gzip. B<Ethereal> recognizes
this directly from the file; the '.gz' extension is not required for
this purpose.
-Like other protocol analyzers, B<Ethereal>'s main window shows 3 views of a packet. It
-shows a summary line, briefly describing what the packet is. A protocol tree is shown, allowing
-you to drill down to exact protocol or field that you interested in. Finally, a hex dump
+Like other protocol analyzers, B<Ethereal>'s main window shows 3 views
+of a packet. It shows a summary line, briefly describing what the
+packet is. A protocol tree is shown, allowing you to drill down to
+exact protocol or field that you interested in. Finally, a hex dump
shows you exactly what the packet looks like when it goes over the wire.
In addition, B<Ethereal> has some features that make it unique. It can
assemble all the packets in a TCP conversation and show you the ASCII
(or EBCDIC) data in that conversation. Display filters in B<Ethereal>
-are very powerful; more fields are filterable in Ethereal than in other
+are very powerful; more fields are filterable in B<Ethereal> than in other
protocol analyzers, and the syntax you can use to create your filters is
-richer. As Ethereal progresses, expect more and more protocol fields to
+richer. As B<Ethereal> progresses, expect more and more protocol fields to
be allowed in display filters.
-Packet capturing is performed with the pcap library. The capture filter syntax follows
-the rules of the pcap library. This syntax is different from the display filter syntax.
+Packet capturing is performed with the pcap library. The capture filter
+syntax follows the rules of the pcap library. This syntax is different
+from the display filter syntax.
-Compressed file support uses (and therefore requires) the zlib library. If the zlib
-library is not present, Ethereal will compile, but will be unable to read compressed files.
+Compressed file support uses (and therefore requires) the zlib library.
+If the zlib library is not present, B<Ethereal> will compile, but will
+be unable to read compressed files.
=head1 OPTIONS
=item Capture:Start
-Initiates a live packet capture (see L<"Capture Preferences"> below).
-A temporary file will be created to hold the capture. The location of the
+Initiates a live packet capture (see L<"Capture Preferences"> below). A
+temporary file will be created to hold the capture. The location of the
file can be chosen by setting your TMPDIR environment variable before
-starting ethereal. Otherwise, the default TMPDIR location is system-dependent,
-but is likely either /var/tmp or /tmp.
+starting B<Ethereal>. Otherwise, the default TMPDIR location is
+system-dependent, but is likely either /var/tmp or /tmp.
=item Display:Options
=item Preferences
-The I<Preferences> dialog lets you select the output format of packets
-printed using the I<File:Print Packet> menu item.
+The I<Preferences> dialog lets you control various personal preferences
+for the behavior of B<Ethereal>.
=over 6
=item Printing Preferences
The radio buttons at the top of the I<Printing> page allow you choose
-between printing the packets as text or PostScript, and sending the
-output directly to a command or saving it to a file. The I<Command:> text
-entry box is the command to send files to (usually B<lpr>), and the
-I<File:> entry box lets you enter the name of the file you wish to save
-to. Additinally, you can select the I<File:> button to browse the file
-system for a particular save file.
+between printing packets with the I<File:Print Packet> menu item as text
+or PostScript, and sending the output directly to a command or saving it
+to a file. The I<Command:> text entry box is the command to send files
+to (usually B<lpr>), and the I<File:> entry box lets you enter the name
+of the file you wish to save to. Additionally, you can select the
+I<File:> button to browse the file system for a particular save file.
=item Column Preferences
an attribute from the "Set:" menu and use the color selector to get the
desired color. The new text colors are displayed in a sample window.
-=back
-
=item GUI Preferences
The I<GUI> page is used to modify small aspects of the GUI to your own
be dissected by a plugin (see L<"DISPLAY FILTER SYNTAX"> below). This
filter can be modified.
-=back
-
=head1 CAPTURE FILTER SYNTAX
See manual page of tcpdump(8).
=head1 DISPLAY FILTER SYNTAX
-Display filters help you remove the noise from a packet trace and let you see only
-the packets that interest you. If a packet meets the requirements expressed in your
-display filter, then it is displayed in the list of packets. Display filters let
-you compare the fields within a protocol against a specific value, compare fields
-against fields, and to check the existence of specified fields or protocols.
+Display filters help you remove the noise from a packet trace and let
+you see only the packets that interest you. If a packet meets the
+requirements expressed in your display filter, then it is displayed in
+the list of packets. Display filters let you compare the fields within
+a protocol against a specific value, compare fields against fields, and
+to check the existence of specified fields or protocols.
-The simplest display filter allows you to check for the existence of a protocol or
-field. If you want to see all packets which contain the IPX protocol, the filter would be
-"ipx". (Without the quotation marks) To see all packets that contain a
-Token-Ring RIF field, use "tr.rif".
+The simplest display filter allows you to check for the existence of a
+protocol or field. If you want to see all packets which contain the IPX
+protocol, the filter would be "ipx". (Without the quotation marks) To
+see all packets that contain a Token-Ring RIF field, use "tr.rif".
-Fields can also be compared against values. The comparison operators can be expressed
-either through C-like symbols, or through English-like abbreviations:
+Fields can also be compared against values. The comparison operators
+can be expressed either through C-like symbols, or through English-like
+abbreviations:
eq, == Equal
ne, != Not equal
String (text)
Double-precision floating point number
-An integer may be expressed in decimal, octal, or hexadecimal notation. The following
-three display filters are equivalent:
+An integer may be expressed in decimal, octal, or hexadecimal notation.
+The following three display filters are equivalent:
frame.pkt_len > 10
frame.pkt_len > 012
frame.pkt_len > 0xa
-Boolean values are either true or false. However, a boolean field is present in a
-protocol decode only if its value is true. If the value is false, the field is not presence.
-You can therefore check the truth value of a boolean field by simply checking for its
-existence, that is, by naming the field. For example, a token-ring packet's source route
-field is boolean. To find any source-routed packets, the display filter is simply:
+Boolean values are either true or false. However, a boolean field is
+present in a protocol decode only if its value is true. If the value is
+false, the field is not presence. You can therefore check the truth
+value of a boolean field by simply checking for its existence, that is,
+by naming the field. For example, a token-ring packet's source route
+field is boolean. To find any source-routed packets, the display filter
+is simply:
tr.sr
! tr.sr
-Ethernet addresses, as well as a string of bytes, are represented in hex digits. The hex
-digits may be separated by colons, periods, or hyphens:
+Ethernet addresses, as well as a string of bytes, are represented in hex
+digits. The hex digits may be separated by colons, periods, or hyphens:
fddi.dst eq ff:ff:ff:ff:ff:ff
ipx.srcnode == 0.0.0.0.0.1
eth.src == aa-aa-aa-aa-aa-aa
-If a string of bytes contains only one byte, then it is represented as an unsigned integer.
-That is, if you are testing for hex value 'ff' in a one-byte byte-string, you must compare
-it agains '0xff' and not 'ff'.
+If a string of bytes contains only one byte, then it is represented as
+an unsigned integer. That is, if you are testing for hex value 'ff' in
+a one-byte byte-string, you must compare it agains '0xff' and not 'ff'.
-IPv4 addresses can be represented in either dotted decimal notation, or by using the hostname:
+IPv4 addresses can be represented in either dotted decimal notation, or
+by using the hostname:
ip.dst eq www.mit.edu
ip.src == 192.168.1.1
-IPv4 address can be compared with the same logical relations as numbers: eq, ne, gt,
-ge, lt, and le. The IPv4 address is stored in host order, so you do not have to worry
-about how the endianness of an IPv4 address when using it in a display filter.
+IPv4 address can be compared with the same logical relations as numbers:
+eq, ne, gt, ge, lt, and le. The IPv4 address is stored in host order,
+so you do not have to worry about how the endianness of an IPv4 address
+when using it in a display filter.
-Classless InterDomain Routing (CIDR) notation can be used to test if an IPv4 address
-is in a certain subnet. For example, this display filter will find all packets
-in the 129.111 Class-B network:
+Classless InterDomain Routing (CIDR) notation can be used to test if an
+IPv4 address is in a certain subnet. For example, this display filter
+will find all packets in the 129.111 Class-B network:
ip.addr == 129.111.0.0/16
-Remember, the number after the slash represents the number of bits used to represent
-the network. CIDR notation can also be used with hostnames, in this example of finding
-IP addresses on the same Class C network as 'sneezy'
+Remember, the number after the slash represents the number of bits used
+to represent the network. CIDR notation can also be used with
+hostnames, in this example of finding IP addresses on the same Class C
+network as 'sneezy':
ip.addr eq sneezy/24
-The CIDR notation can only be used on IP addresses or hostnames, not in variable names.
-So, a display filter like "ip.src/24 == ip.dst/24" is not valid. (yet)
+The CIDR notation can only be used on IP addresses or hostnames, not in
+variable names. So, a display filter like "ip.src/24 == ip.dst/24" is
+not valid. (yet)
-IPX networks are represented by unsigned 32-bit integers. Most likely you will be using
-hexadecimal when testing for IPX network values:
+IPX networks are represented by unsigned 32-bit integers. Most likely
+you will be using hexadecimal when testing for IPX network values:
ipx.srcnet == 0xc0a82c00
-A substring operator also exists. You can check the substring (byte-string) of any protocol
-or field. For example, you can filter on the vendor portion of an ethernet address (the first
-three bytes) like this:
+A substring operator also exists. You can check the substring
+(byte-string) of any protocol or field. For example, you can filter on
+the vendor portion of an ethernet address (the first three bytes) like
+this:
eth.src[0:3] == 00:00:83
-Or more simply, since the number of bytes is inherent in the byte-string you provide, you
-can provide just the offset. The previous example can be stated like this:
+Or more simply, since the number of bytes is inherent in the byte-string
+you provide, you can provide just the offset. The previous example can
+be stated like this:
eth.src[0] == 00:00:83
-In fact, the only time you need to explicitly provide a length is when you don't provide
-a byte-string, and are comparing fields against fields:
+In fact, the only time you need to explicitly provide a length is when
+you don't provide a byte-string, and are comparing fields against
+fields:
fddi.src[0:3] == fddi.dst[0:3]
-If the length of your byte-string is only one byte, then it must be represented in the
-same way as an unsigned 8-bit integer:
+If the length of your byte-string is only one byte, then it must be
+represented in the same way as an unsigned 8-bit integer:
llc[3] == 0xaa
-You can use the substring operator on a protocol name, too. And remember, the "frame" protocol
-encompasses the entire packet, allowing you to look at the nth byte of a packet regardless
-of its frame type (ethernet, token-ring, etc.).
+You can use the substring operator on a protocol name, too. And
+remember, the "frame" protocol encompasses the entire packet, allowing
+you to look at the nth byte of a packet regardless of its frame type
+(Ethernet, token-ring, etc.).
token[0:5] ne 0.0.0.1.1
ipx[0:2] == ff:ff
llc[3:1] eq 0xaa
-Offsets for byte-strings can also be negative, in which case the negative number indicates
-the number of bytes from the end of the field or protocol that you are testing. Here's how
-to check the last 4 bytes of a frame:
+Offsets for byte-strings can also be negative, in which case the
+negative number indicates the number of bytes from the end of the field
+or protocol that you are testing. Here's how to check the last 4 bytes
+of a frame:
frame[-4] == 0.1.2.3
frame[-4:4] == 0.1.2.3
-All the above tests can be combined together with logical expressions. These too are expressable
-in C-like syntax or with English-like abbreviations:
+All the above tests can be combined together with logical expressions.
+These too are expressable in C-like syntax or with English-like
+abbreviations:
and, && Logical AND
or, || Logical OR
xor, ^^ Logical XOR
not, ! Logical NOT
-Expressions can be grouped by parentheses as well. The following are all valid display filter
-expression:
+Expressions can be grouped by parentheses as well. The following are
+all valid display filter expression:
tcp.port == 80 and ip.src == 192.168.2.1
not llc
(ipx.srcnet == 0xbad && ipx.srnode == 0.0.0.0.0.1) || ip
tr.dst[0:3] == 0.6.29 xor tr.src[0:3] == 0.6.29
-A special caveat must be given regarding fields that occur more than once per packet. "ip.addr"
-occurs twice per IP packet, once for the source address, and once for the destination address.
-Likewise, tr.rif.ring fields can occur more than once per packet. The following two expressions
-are not equivalent:
+A special caveat must be given regarding fields that occur more than
+once per packet. "ip.addr" occurs twice per IP packet, once for the
+source address, and once for the destination address. Likewise,
+tr.rif.ring fields can occur more than once per packet. The following
+two expressions are not equivalent:
ip.addr ne 192.168.4.1
not ip.addr eq 192.168.4.1
-The first filter says "show me all packets where an ip.addr exists that does not equal 192.168.4.1".
-That is, as long as one ip.addr in the packet does not equal 192.168.44.1, the packet passes
-the display filter. The second filter "don't show me any packets that have at least one ip.addr
-field equal to 192.168.4.1". If one ip.addr is 192.168.4.1, the packet does not pass. If B<neither>
-ip.addr fields is 192.168.4.1, then the packet passes.
+The first filter says "show me all packets where an ip.addr exists that
+does not equal 192.168.4.1". That is, as long as one ip.addr in the
+packet does not equal 192.168.44.1, the packet passes the display
+filter. The second filter "don't show me any packets that have at least
+one ip.addr field equal to 192.168.4.1". If one ip.addr is 192.168.4.1,
+the packet does not pass. If B<neither> ip.addr fields is 192.168.4.1,
+then the packet passes.
-It is easy to think of the 'ne' and 'eq' operators as having an implict "exists" modifier
-when dealing with multiply-recurring fields. "ip.addr ne 192.168.4.1" can be thought of as
-"there exists an ip.addr that does not equal 192.168.4.1".
+It is easy to think of the 'ne' and 'eq' operators as having an implict
+"exists" modifier when dealing with multiply-recurring fields. "ip.addr
+ne 192.168.4.1" can be thought of as "there exists an ip.addr that does
+not equal 192.168.4.1".
Be careful with multiply-recurring fields; they can be confusing.
-The following is a table of protocol and protocol fields that are filterable in Ethereal.
-The abbreviation of the protocol or field is given. This abbreviation is what you use in
-the display filter. The type of the field is also given.
+The following is a table of protocol and protocol fields that are
+filterable in B<Ethereal>. The abbreviation of the protocol or field is
+given. This abbreviation is what you use in the display filter. The
+type of the field is also given.
=insert_dfilter_table
=head1 FILES
-B</etc/ethers> is consulted to correlate 6-byte hardware addresses to names. If an address is not
-found in B</etc/ethers>, the B<$HOME/.ethereal/ethers> file is consulted next. Each line
-contains one hardware address and name, separated by whitespace.
-The digits of the hardware address are separated by either a colon (:), a dash (-), or
-a period (.). The following three lines are valid lines of an ethers file:
+B</etc/ethers> is consulted to correlate 6-byte hardware addresses to
+names. If an address is not found in B</etc/ethers>, the
+B<$HOME/.ethereal/ethers> file is consulted next. Each line contains
+one hardware address and name, separated by whitespace. The digits of
+the hardware address are separated by either a colon (:), a dash (-), or
+a period (.). The following three lines are valid lines of an ethers
+file:
ff:ff:ff:ff:ff:ff Broadcast
c0-00-ff-ff-ff-ff TR_broadcast
00.00.00.00.00.00 Zero_broadcast
-B</usr/local/etc/manuf> matches the 3-byte vendor portion of a 6-byte hardware address with
-the manufacturer's name. The format of the file is the same as the B</etc/ethers> file,
-except that each address is three bytes instead of six.
+B</usr/local/etc/manuf> matches the 3-byte vendor portion of a 6-byte
+hardware address with the manufacturer's name. The format of the file
+is the same as the B</etc/ethers> file, except that each address is
+three bytes instead of six.
-B</etc/ipxnets> and B<$HOME/.ethereal/ipxnets> correlate 4-byte IPX network numbers to names.
-The format is the same as the B</etc/ethers> file, except that each address if four bytes
-instead of six. Additionally, the address can be represented a single hexadecimal number,
-as is more common in the IPX world, rather than four hex octets. For example, these four
-lines are valid lines of an ipxnets file.
+B</etc/ipxnets> and B<$HOME/.ethereal/ipxnets> correlate 4-byte IPX
+network numbers to names. The format is the same as the B</etc/ethers>
+file, except that each address if four bytes instead of six.
+Additionally, the address can be represented a single hexadecimal
+number, as is more common in the IPX world, rather than four hex octets.
+For example, these four lines are valid lines of an ipxnets file.
C0.A8.2C.00 HR
c0-a8-1c-00 CEO
=head1 NOTES
-The latest version of B<ethereal> can be found at
+The latest version of B<Ethereal> can be found at
B<http://ethereal.zing.org>.
=head1 AUTHORS