=head1 DESCRIPTION
-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 read capture files from B<snoop> (including
-B<Shomiti>), 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,
-and HP-UX's B<nettl>.
-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 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
+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. 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>, the dump output from B<Toshiba's> ISDN routers, and
+B<i4btrace> from the ISDN4BSD project. There is no need to 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
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 data in that conversation. Display
-filters in B<Ethereal> are very powerful; more fields are filterable in 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 be allowed in display filters.
+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 B<Ethereal> than in other
+protocol analyzers, and the syntax you can use to create your filters is
+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 -i
-Sets the name of the interface to use for live packet capture. It
-should match one of the names listed in "B<netstat -i>" or "B<ifconfig -a>".
+Sets the name of the network interface to use for live packet capture.
+It should match one of the names listed in "B<netstat -i>" or
+"B<ifconfig -a>".
=item -k
-Starts the capture session immediately; this option requires
-the B<-i> and B<-w> parameters.
+Starts the capture session immediately. If the B<-i> flag was
+specified, the capture uses the specified interface. Otherwise,
+B<Ethereal> searches the list of interfaces, choosing the first
+non-loopback interface if there are any non-loopback interfaces, and
+choosing the first loopback interface if there are no non-loopback
+interfaces; if there are no interfaces, B<Ethereal> reports an error and
+doesn't start the capture.
=item -m
filter is applied to all packets read from the file, and packets not
matching the filter are discarded.
+=item File:Save, File:Save As
+
+Save the current capture, or the packets currently displayed from that
+capture, to a file. A check box lets you select whether to save all
+packets, or just those that have passed the current display filter, and
+an option menu lets you select (from a list of file formats in which at
+particular capture, or the packets currently displayed from that
+capture, can be saved), a file format in which to save it.
+
=item File:Print
-Prints, for all the packets in the current capture, the packet number,
-followed by a description of each protocol header found in the packet,
-followed by the packet data itself. Printing options can be set with the
+Prints, for all the packets in the current capture, either the summary
+line for the packet or the protocol tree view of the packet; when
+printing the protocol tree view, the hex dump of the packet can be
+printed as well. Printing options can be set with the
I<Edit:Preferences> menu item, or in the dialog box popped up by this
item.
=item File:Print Packet
-Print a description of each protocol header found in the packet, followed
-by the packet data itself. Printing options can be set with the
-I<Edit:Preferences> menu item.
+Print a fully-expanded protocol tree view of the currently-selected
+packet. Printing options can be set with the I<Edit:Preferences> menu
+item.
=item File:Quit
Exits the application.
+=item Edit:Find Frame
+
+Allows you to search forward or backward, starting with the currently
+selected packet (or the most recently selected packet, if no packet is
+selected), for a packet matching a given display filter.
+
+=item Edit:Go To Frame
+
+Allows you to go to a particular numbered packet.
+
=item Edit:Preferences
-Sets the packet printing and filter options (see L<"Preferences"> below).
+Sets the packet printing, column display, TCP stream coloring, and GUI
+options (see L<"Preferences"> below).
+
+=item Edit:Filters
+
+Edits the saved list of filters, allowing filters to be added, changed,
+or deleted, and lets a selected filter be applied to the current
+capture, if any.
=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 Display:Match Selected
Creates and applies a display filter based on the data that is currently
-highlighted in the protocol tree. The display filter is based on absolute
-offset within the packet, so could be unreliable if the packet contains
-protocols with variable-length headers, like source-routed token-ring.
+highlighted in the protocol tree. If that data is a field that can be
+tested in a display filter expression, the display filter will test that
+field; otherwise, the display filter will be based on absolute offset
+within the packet, and so could be unreliable if the packet contains
+protocols with variable-length headers, such as a source-routed
+token-ring packet.
=item Display:Colorize Display
Expands all branches of the protocol tree.
+=item Tools:Plugins
+
+Allows you to use and configure dynamically loadable modules (see
+L<"Plugins"> below).
+
=item Tools:Follow TCP Stream
-If you have a TCP packet selected, it will display the contents of the TCP
-data stream in a separate window. This has the side-effect of leaving
-the list of packets in a filtered state; only those packets that make up
-the TCP stream are shown. You can revert to your old view by pressing
-ENTER in the display filter text box, thereby invoking your old
-display filter (or resetting it back to no display filter).
+If you have a TCP packet selected, it will display the contents of the
+data stream for the TCP connection to which that packet belongs, as
+text, in a separate window, and will leave the list of packets in a
+filtered state, with only those packets that are part of that TCP
+connection being displayed. You can revert to your old view by pressing
+ENTER in the display filter text box, thereby invoking your old display
+filter (or resetting it back to no display filter).
+
+The window in which the data stream is displayed lets you select whether
+the data being displayed is to be treated as ASCII or EBCDIC text, and
+lets you print the text, using the same print options that are used for
+the I<File:Print Packet> menu item.
=back
destination addresses, protocol, and description are printed for each
packet. An effort is made to display information as high up the protocol
stack as possible, e.g. IP addresses are displayed for IP packets, but the
-MAC layer address is displayed for unknown packet types.
+MAC layer address is displayed for unknown packet types. The right
+mouse button can be used to pop up a menu of operations.
The middle pane contains a I<protocol tree> for the currently-selected
-packet. The tree displays each field and its value in each protocol header
-in the stack.
+packet. The tree displays each field and its value in each protocol
+header in the stack. The right mouse button can be used to pop up a
+menu of operations.
The lowest pane contains a hex dump of the actual packet data.
Selecting a field in the I<protocol tree> highlights the corresponding
Selecting the I<Filter:> button lets you choose from a list of named
filters that you can optionally save. Pressing the Return or Enter
keys will cause the filter to be applied to the current list of packets.
+Selecting the I<Reset> button clears the display filter so that all
+packets are displayed.
=item Preferences
-The I<Preferences> dialog lets you select the output format of packets
-printed using the I<File:Print Packet> menu item and configure
-commonly-used filters.
+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 Filter Preferences
+=item Column Preferences
-The I<Filters> page lets you create and modify filters, and set the
-default filter to use when capturing data or opening a capture file.
+The I<Columns> page lets you specify the number, title, and format
+of each column in the packet list.
-The I<Filter name> entry specifies a descriptive name for a filter, e.g.
-B<Web and DNS traffic>. The I<Filter string> entry is the text that
-actually describes the filtering action to take, as described above.The
-dialog buttons perform the following actions:
+The I<Column title> entry is used to specify the title of the column
+displayed at the top of the packet list. The type of data that the column
+displays can be specified using the I<Column format> option menu. The row
+of buttons on the left perform the following actions:
=over 6
=item New
-If there is text in the two entry boxes, it creates a new associated list
-item.
+Adds a new column to the list.
=item Change
-Modifies the currently selected list item to match what's in the entry
-boxes.
-
-=item Copy
-
-Makes a copy of the currently selected list item.
+Modifies the currently selected list item.
=item Delete
Deletes the currently selected list item.
+=item Up / Down
+
+Moves the selected list item up or down one position.
+
=item OK
-Sets the currently selected list item as the active filter. If nothing
-is selected, turns filtering off.
+Currently has no effect.
=item Save
-Saves the current filter list in F<$HOME/.ethereal/filters>.
+Saves the current column format as the default.
=item Cancel
=back
-=item Column Preferences
+=item TCP Stream Preferences
-The I<Columns> page lets you specify the number, title, and format
-of each column in the packet list.
+The I<TCP Streams> page can be used to change the color of the text
+displayed in the TCP stream window. To change a color, simply select
+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.
-The I<Column title> entry is used to specify the title of the column
-displayed at the top of the packet list. The type of data that the column
-displays can be specified using the I<Column format> option menu. The row
-of buttons on the left perform the following actions:
+=item GUI Preferences
+
+The I<GUI> page is used to modify small aspects of the GUI to your own
+personal taste. The vertical scrollbars in the three panes can be
+set to be either on the left or the right. The selection bar in the
+packet list and protocol tree can have either a "browse" or "select"
+behavior. If the selection bar has a "browse" behavior, the arrow keys
+will move an outline of the selection bar, allowing you to browse
+the rest of the list or tree without changing the selection
+until you press the space bar. If the selection bar has a "select"
+behavior, the arrow keys will move the selection bar and change
+the selection to the new item in the packet list or protocol tree.
+
+=back
+
+=item Filters
+
+The I<Filters> dialog lets you create and modify filters, and set the
+default filter to use when capturing data or opening a capture file.
+
+The I<Filter name> entry specifies a descriptive name for a filter, e.g.
+B<Web and DNS traffic>. The I<Filter string> entry is the text that
+actually describes the filtering action to take, as described above.The
+dialog buttons perform the following actions:
=over 6
=item New
-Adds a new column to the list.
+If there is text in the two entry boxes, it creates a new associated list
+item.
=item Change
-Modifies the currently selected list item.
+Modifies the currently selected list item to match what's in the entry
+boxes.
+
+=item Copy
+
+Makes a copy of the currently selected list item.
=item Delete
Deletes the currently selected list item.
-=item Up / Down
+=item Apply
-Moves the selected list item up or down one position.
+Sets the currently selected list item as the active filter, and applies
+it to the current capture, if any.
+(The currently selected list item must be a display filter, not a
+capture filter.) If nothing is selected, turns filtering off.
=item OK
-Currently has no effect.
+Sets the currently selected list item as the active filter. If nothing
+is selected, turns filtering off.
=item Save
-Saves the current column format as the default.
+Saves the current filter list in F<$HOME/.ethereal/filters>.
=item Cancel
=back
-=back
-
=item Capture Preferences
The I<Capture Preferences> dialog lets you specify various parameters for
capturing live packet data.
The I<Interface:> combo box lets you specify the interface from which to
-capture packet data. The I<Count:> entry specifies the number of packets
-to capture. Entering 0 will capture packets indefinitely. The I<Filter:>
-entry lets you specify the capture filter using a tcpdump-style filter
-string as described above. The I<File:> entry specifies the file to save
-to, as in the I<Printer Options> dialog above. You can specify the
-maximum number of bytes to capture per packet with the I<Capture length>
-entry, and can specify that the display should be updated as packets are
-captured with the I<Update list of packets in real time> check box.
+capture packet data. The I<Count:> entry specifies the number of
+packets to capture. Entering 0 will capture packets indefinitely. The
+I<Filter:> entry lets you specify the capture filter using a
+tcpdump-style filter string as described above. The I<File:> entry
+specifies the file to save to, as in the I<Printer Options> dialog
+above. You can specify the maximum number of bytes to capture per
+packet with the I<Capture length> entry, can specify that the display
+should be updated as packets are captured with the I<Update list of
+packets in real time> check box, can specify whether in such a capture
+the packet list pane should scroll to show the most recently captured
+packets with the I<Automatic scrolling in live capture> check box, and
+can specify whether addresses should be translated to names in the
+display with the I<Enable name resolution> check box.
=item Display Options
the list should automatically scroll to show the most recently captured
packets or not.
-=back
+=item Plugins
+
+The I<Plugins> dialog lets you view and configure the plugins available
+on your system.
+
+The I<Plugins List> shows the name, description, version and state
+(enabled or not) of each plugin found on your system. The plugins are
+searched in the following directories : B</usr/share/ethereal/plugins>,
+B</usr/local/share/ethereal/plugins> and B<~/.ethereal/plugins>
+
+A plugin must be activated using the I<Enable> button in order to use it
+to dissect packets. It can also be deactivated with the I<Disable> button.
+
+The I<Filter> button shows the filter used to select packets which should
+be dissected by a plugin (see L<"DISPLAY FILTER SYNTAX"> below). This
+filter can be modified.
=head1 CAPTURE FILTER SYNTAX
=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
-IPX networks are represented by unsigned 32-bit integers. Most likely you will be using
-hexadecimal when testing for IPX network values:
+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:
+
+ 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':
+
+ 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)
+
+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:
+
+ 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</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
+ 00:00:BE:EF IT_Server1
+ 110f FileServer3
+
=head1 SEE ALSO
L<tcpdump(8)>, L<pcap(3)>
=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
Bobo Rajec <bobo@bsp-consulting.sk>
Laurent Deniel <deniel@worldnet.fr>
Don Lafontaine <lafont02@cn.ca>
- Guy Harris <guy@netapp.com>
+ Guy Harris <guy@alum.mit.edu>
Simon Wilkinson <sxw@dcs.ed.ac.uk>
Joerg Mayer <jmayer@telemation.de>
Martin Maciaszek <fastjack@i-s-o.net>
Aaron Hillegass <aaron@classmax.com>
Jason Lango <jal@netapp.com>
Johan Feyaerts <Johan.Feyaerts@siemens.atea.be>
- Olivier Abad <abad@daba.dhis.org>
+ Olivier Abad <abad@daba.dhis.net>
Thierry Andry <Thierry.Andry@advalvas.be>
Jeff Foster <jjfoste@woodward.com>
Peter Torvals <petertv@xoommail.com>
Tomislav Vujec <tvujec@carnet.hr>
Kojak <kojak@bigwig.net>
Uwe Girlich <Uwe.Girlich@philosys.de>
+ Warren Young <tangent@mail.com>
+ Heikki Vatiainen <hessu@cs.tut.fi>
+ Greg Hankins <gregh@twoguys.org>
+ Jerry Talkington <jerryt@netapp.com>
+ Dave Chapeskie <dchapes@ddm.on.ca>
+ James Coe <jammer@cin.net>
+ Bert Driehuis <driehuis@playbeing.org>
+ Stuart Stanley <stuarts@mxmail.net>
+ John Thomes <john@ensemblecom.com>
+ Laurent Cazalet <laurent.cazalet@mailclub.net>
+ Thomas Parvais <thomas.parvais@advalvas.be>
Alain Magloire <alainm@rcsm.ece.mcgill.ca> was kind enough to give his
permission to use his version of snprintf.c.
Dan Lasley <dlasley@promus.com> gave permission for his dumpit() hex-dump
routine to be used.
-
git.samba.org / obnox / wireshark / wip.git / blobdiff