48d3d8eb26
SMB RTT statistics are similar to the RTT statistics already supported by ONC-RPC and DCE-RPC. It will present a table with all seen SMB commands and present the Min/Max and Avg response time in ms. Transaction2 and NT-Transaction commands are broken out and presented in its own subtables. tethereal feature is activated with -z smb,rtt switch and in ethereal it is activated either through -0z smb,rtt switch or through the Menu. svn path=/trunk/; revision=6966
1740 lines
69 KiB
Text
1740 lines
69 KiB
Text
|
||
=head1 NAME
|
||
|
||
ethereal - Interactively browse network traffic
|
||
|
||
=head1 SYNOPSYS
|
||
|
||
B<ethereal>
|
||
S<[ B<-a> capture autostop condition ] ...>
|
||
S<[ B<-b> number of ring buffer files ]>
|
||
S<[ B<-B> byte view height ]>
|
||
S<[ B<-c> count ]>
|
||
S<[ B<-f> capture filter expression ]>
|
||
S<[ B<-h> ]>
|
||
S<[ B<-i> interface ]>
|
||
S<[ B<-k> ]>
|
||
S<[ B<-l> ]>
|
||
S<[ B<-m> font ]>
|
||
S<[ B<-n> ]>
|
||
S<[ B<-N> resolving flags ] >
|
||
S<[ B<-o> preference setting ] ...>
|
||
S<[ B<-p> ]>
|
||
S<[ B<-P> packet list height ]>
|
||
S<[ B<-Q> ]>
|
||
S<[ B<-r> infile ]>
|
||
S<[ B<-R> display filter expression ]>
|
||
S<[ B<-S> ]>
|
||
S<[ B<-s> snaplen ]>
|
||
S<[ B<-T> tree view height ]>
|
||
S<[ B<-t> time stamp format ]>
|
||
S<[ B<-v> ]>
|
||
S<[ B<-w> savefile]>
|
||
S<[ B<-z> statistics-string ]>
|
||
S<[ infile ]>
|
||
|
||
=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. B<Ethereal>'s native capture file format
|
||
is B<libpcap> format, which is also the format used by B<tcpdump> and
|
||
various other tools. In addition, B<Ethereal> can read capture files
|
||
from B<snoop> and B<atmsnoop>, Shomiti/Finisar B<Surveyor>, Novell
|
||
B<LANalyzer>, Network General/Network Associates DOS-based B<Sniffer>
|
||
(compressed or uncompressed), Microsoft B<Network Monitor>, AIX's
|
||
B<iptrace>, Cinco Networks B<NetXRay>, Network Associates Windows-based
|
||
B<Sniffer>, AG Group/WildPackets B<EtherPeek>/B<TokenPeek>/B<AiroPeek>,
|
||
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, the
|
||
output from B<i4btrace> from the ISDN4BSD project, the output in
|
||
B<IPLog> format from the Cisco Secure Intrusion Detection System, B<pppd
|
||
logs> (pppdump format), the output from VMS's B<TCPIPtrace> utility, the
|
||
text output from the B<DBS Etherwatch> VMS utility, traffic capture
|
||
files from Visual Networks' Visual UpTime, and the output from B<CoSine>
|
||
L2 debug. 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
|
||
(or EBCDIC, or hex) 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.
|
||
|
||
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.
|
||
|
||
The pathname of a capture file to be read can be specified with the
|
||
B<-r> option or can be specified as a command-line argument.
|
||
|
||
=head1 OPTIONS
|
||
|
||
=over 4
|
||
|
||
Most users will want to start B<Ethereal> without options and configure
|
||
it from the menus instead. Those users may just skip this section.
|
||
|
||
=item -a
|
||
|
||
Specify a criterion that specifies when B<Ethereal> is to stop writing
|
||
to a capture file. The criterion is of the form I<test>B<:>I<value>,
|
||
where I<test> is one of:
|
||
|
||
=for man .RS
|
||
|
||
=for html <P><DL>
|
||
|
||
=item duration
|
||
|
||
Stop writing to a capture file after I<value> seconds have elapsed.
|
||
|
||
=item filesize
|
||
|
||
Stop writing to a capture file after it reaches a size of I<value>
|
||
kilobytes (where a kilobyte is 1000 bytes, not 1024 bytes).
|
||
|
||
=for man .RE
|
||
|
||
=for html </DL>
|
||
|
||
=item -b
|
||
|
||
If a maximum capture file size was specified, cause B<Ethereal> to run
|
||
in "ring buffer" mode, with the specified number of files. In "ring
|
||
buffer" mode, B<Ethereal> will write to several capture files; the name
|
||
of the first file, while the capture is in progress, will be the name
|
||
specified by the B<-w> flag, and subsequent files with have .I<n>
|
||
appended, with I<n> counting up.
|
||
|
||
When the first capture file fills up, B<Ethereal> will switch to writing
|
||
to the next file, until it fills up the last file, at which point it'll
|
||
discard the data in the first file and start writing to that file. When
|
||
that file fills up, B<Ethereal> will discard the data in the next file
|
||
and start writing to it, and so on.
|
||
|
||
When the capture completes, the files will be renamed to have names
|
||
based on the number of the file and on the date and time at which
|
||
packets most recently started being written to the file.
|
||
|
||
=item -B
|
||
|
||
Set the initial height of the byte view (bottom) pane.
|
||
|
||
=item -c
|
||
|
||
Set the default number of packets to read when capturing live
|
||
data.
|
||
|
||
=item -f
|
||
|
||
Set the capture filter expression.
|
||
|
||
=item -h
|
||
|
||
Print the version and options and exit.
|
||
|
||
=item -i
|
||
|
||
Set the name of the network interface or pipe to use for live packet
|
||
capture.
|
||
|
||
Network interface names should match one of the names listed in
|
||
"B<tethereal -D>". If you're using Unix, "B<netstat -i>" or "B<ifconfig
|
||
-a>" might also work to list interface names, although not all versions
|
||
of Unix support the B<-a> flag to B<ifconfig>.
|
||
|
||
Pipe names should be either the name of a FIFO (named pipe) or ``-'' to
|
||
read data from the standard input. Data read from pipes must be in
|
||
standard libpcap format.
|
||
|
||
=item -k
|
||
|
||
Start 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 -l
|
||
|
||
Turn on automatic scrolling if the packet display is being updated
|
||
automatically as packets arrive during a capture (as specified by the
|
||
B<-S> flag).
|
||
|
||
=item -m
|
||
|
||
Set the name of the font used by B<Ethereal> for most text.
|
||
B<Ethereal> will construct the name of the bold font used for the data
|
||
in the byte view pane that corresponds to the field selected in the
|
||
protocol tree pane from the name of the main text font.
|
||
|
||
=item -n
|
||
|
||
Disable network object name resolution (such as hostname, TCP and UDP port
|
||
names).
|
||
|
||
=item -N
|
||
|
||
Turn on name resolving for particular types of addresses and port
|
||
numbers, with name resolving for other types of addresses and port
|
||
numbers turned off; the argument is a string that may contain the
|
||
letters B<m> to enable MAC address resolution, B<n> to enable network
|
||
address resolution, and B<t> to enable transport-layer port number
|
||
resolution. This overrides B<-n> if both B<-N> and B<-n> are present.
|
||
|
||
=item -o
|
||
|
||
Set a preference value, overriding the default value and any value read
|
||
from a preference file. The argument to the flag is a string of the
|
||
form I<prefname>B<:>I<value>, where I<prefname> is the name of the
|
||
preference (which is the same name that would appear in the preference
|
||
file), and I<value> is the value to which it should be set.
|
||
|
||
=item -p
|
||
|
||
I<Don't> put the interface into promiscuous mode. Note that the
|
||
interface might be in promiscuous mode for some other reason; hence,
|
||
B<-p> cannot be used to ensure that the only traffic that is captured is
|
||
traffic sent to or from the machine on which B<Ethereal> is running,
|
||
broadcast traffic, and multicast traffic to addresses received by that
|
||
machine.
|
||
|
||
=item -P
|
||
|
||
Set the initial height of the packet list (top) pane.
|
||
|
||
=item -Q
|
||
|
||
Cause B<Ethereal> to exit after the end of capture session (useful in
|
||
batch mode with B<-c> option for instance); this option requires the
|
||
B<-i> and B<-w> parameters.
|
||
|
||
=item -r
|
||
|
||
Read packet data from I<infile>.
|
||
|
||
=item -R
|
||
|
||
When reading a capture file specified with the B<-r> flag, causes the
|
||
specified filter (which uses the syntax of display filters, rather than
|
||
that of capture filters) to be applied to all packets read from the
|
||
capture file; packets not matching the filter are discarded.
|
||
|
||
=item -S
|
||
|
||
Perform the live packet capture in a separate process, and automatically
|
||
update the packet display as packets are seen.
|
||
|
||
=item -s
|
||
|
||
Set the default snapshot length to use when capturing live data.
|
||
No more than I<snaplen> bytes of each network packet will be read into
|
||
memory, or saved to disk.
|
||
|
||
=item -T
|
||
|
||
Set the initial height of the tree view (middle) pane.
|
||
|
||
=item -t
|
||
|
||
Set the format of the packet timestamp displayed in the packet list
|
||
window. The format can be one of 'r' (relative), 'a' (absolute), 'ad'
|
||
(absolute with date), or 'd' (delta). The relative time is the time
|
||
elapsed between the first packet and the current packet. The absolute
|
||
time is the actual time the packet was captured, with no date displayed;
|
||
the absolute date and time is the actual time and date the packet was
|
||
captured. The delta time is the time since the previous packet was
|
||
captured. The default is relative.
|
||
|
||
=item -v
|
||
|
||
Print the version and exit.
|
||
|
||
=item -w
|
||
|
||
Set the default capture file name.
|
||
|
||
=item -z
|
||
|
||
Get B<Ethereal> to collect various types of statistics and display the result
|
||
in a window that updates in semi-real time.
|
||
Currently implemented statistics are:
|
||
|
||
B<-z> dcerpc,rtt,I<uuid>,I<major>.I<minor>[,I<filter>]
|
||
|
||
Collect call/reply RTT data for DCERPC interface I<uuid>,
|
||
version I<major>.I<minor>.
|
||
Data collected is number of calls for each procedure, MinRTT, MaxRTT
|
||
and AvgRTT.
|
||
Example: use B<-z dcerpc,rtt,12345778-1234-abcd-ef00-0123456789ac,1.0> to collect data for CIFS SAMR Interface.
|
||
This option can be used multiple times on the command line.
|
||
|
||
If the optional filterstring is provided, the stats will only be calculated
|
||
on those calls that match that filter.
|
||
Example: use B<-z dcerpc,rtt,12345778-1234-abcd-ef00-0123456789ac,1.0,ip.addr==1.2.3.4> to collect SAMR
|
||
RTT statistics for a specific host.
|
||
|
||
B<-z> io,stat
|
||
|
||
Collect frame/bytes statistics for the capture in intervals of 1 seconds.
|
||
This option will open a window with up to 5 color-coded graphs where
|
||
number-of-frames-per-second or number-of-bytes-per-second statistics
|
||
can be calculated and displayed.
|
||
|
||
This option can be used multiple times on the command line.
|
||
|
||
This graph window can also be opened from the Tools:Statistics:Traffic:IO-Stat
|
||
menu item.
|
||
|
||
|
||
B<-z> rpc,rtt,I<program>,I<version>[,<filter>]
|
||
|
||
Collect call/reply RTT data for I<program>/I<version>. Data collected
|
||
is number of calls for each procedure, MinRTT, MaxRTT and AvgRTT.
|
||
Example: use B<-z rpc,rtt,100003,3> to collect data for NFS v3. This
|
||
option can be used multiple times on the command line.
|
||
|
||
If the optional filter string is provided, the stats will only be calculated
|
||
on those calls that match that filter.
|
||
Example: use B<-z rpc,rtt,100003,3,nfs.fh.hash==0x12345678> to collect NFS v3
|
||
RTT statistics for a specific file.
|
||
|
||
B<-z> rpc,programs
|
||
|
||
Collect call/reply RTT data for all known ONC-RPC programs/versions.
|
||
Data collected is number of calls for each protocol/version, MinRTT,
|
||
MaxRTT and AvgRTT.
|
||
|
||
B<-z> smb,rtt[,I<filter>]
|
||
|
||
Collect call/reply RTT data for SMB. Data collected
|
||
is number of calls for each SMB command, MinRTT, MaxRTT and AvgRTT.
|
||
Example: use B<-z smb,rtt>.
|
||
|
||
The data will be presented as separate tables for all normal SMB commands,
|
||
all Transaction2 commands and all NT Transaction commands.
|
||
Only those commands that are seen in the capture will have its stats
|
||
displayed.
|
||
Only the first command in a xAndX command chain will be used in the
|
||
calculation. So for common SessionSetupAndX + TreeConnectAndX chains,
|
||
only the SessionSetupAndX call will be used in the statistics.
|
||
This is a flaw that might be fixed in the future.
|
||
|
||
This option can be used multiple times on the command line.
|
||
|
||
If the optional filterstring is provided, the stats will only be calculated
|
||
on those calls that match that filter.
|
||
Example: use B<-z "smb,rtt,ip.addr==1.2.3.4"> to only collect stats for
|
||
SMB packets echanged by the host at IP address 1.2.3.4 .
|
||
|
||
=back
|
||
|
||
=head1 INTERFACE
|
||
|
||
=head2 MENU ITEMS
|
||
|
||
=over 4
|
||
|
||
=item File:Open, File:Close, File:Reload
|
||
|
||
Open, close, or reload a capture file. The I<File:Open> dialog box
|
||
allows a filter to be specified; when the capture file is read, the
|
||
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. Check boxes let you select whether to save all
|
||
packets, or just those that have passed the current display filter and/or
|
||
those that are currently marked, 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
|
||
|
||
Print, 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 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
|
||
|
||
Exit the application.
|
||
|
||
=item Edit:Find Frame
|
||
|
||
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 expression.
|
||
|
||
=item Edit:Find Next
|
||
|
||
Search forward, starting with the currently selected packet
|
||
(or the most recently selected packet, if no packet is selected), for a
|
||
packet matching the filter from the previous search.
|
||
|
||
=item Edit:Find Previous
|
||
|
||
Search backward, starting with the currently selected packet (or the
|
||
most recently selected packet, if no packet is selected), for a packet
|
||
matching the filter from the previous search.
|
||
|
||
=item Edit:Go To Frame
|
||
|
||
Go to a particular numbered packet.
|
||
|
||
=item Edit:Mark Frame
|
||
|
||
Mark (or unmark if currently marked) the selected packet. The field
|
||
"frame.marked" is set for frames that are marked, so that, for example,
|
||
a display filters can be used to display only marked frames, and so that
|
||
the L<Find Frame> menu item can be used to find the next or previous
|
||
marked frame.
|
||
|
||
=item Edit:Mark All Frames
|
||
|
||
Mark all packets that are currently displayed.
|
||
|
||
=item Edit:Unmark All Frames
|
||
|
||
Unmark all packets that are currently displayed.
|
||
|
||
=item Edit:Preferences
|
||
|
||
Set the packet printing, column display, TCP stream coloring, and GUI
|
||
options (see L<"Preferences"> below).
|
||
|
||
=item Edit:Capture Filters
|
||
|
||
Edit the saved list of capture filters, allowing filters to be added,
|
||
changed, or deleted.
|
||
|
||
=item Edit:Display Filters
|
||
|
||
Edit the saved list of display filters, allowing filters to be added,
|
||
changed, or deleted.
|
||
|
||
=item Edit:Protocols
|
||
|
||
Allow protocol dissection to be enabled or disabled for a specific
|
||
protocol. Individual protocols can be enabled or disabled by clicking
|
||
on them in the list or by highlighting them and pressing the space bar.
|
||
The entire list can be enabled, disabled, or inverted using the buttons
|
||
below the list.
|
||
|
||
When a protocol is disabled, dissection in a particular packet stops
|
||
when that protocol is reached, and Ethereal moves on to the next packet.
|
||
Any higher-layer protocols that would otherwise have been processed will
|
||
not be displayed. For example, disabling TCP will prevent the dissection
|
||
and display of TCP, HTTP, SMTP, Telnet, and any other protocol exclusively
|
||
dependent on TCP.
|
||
|
||
=item Capture:Start
|
||
|
||
Initiate a live packet capture (see L<"Capture Options"> 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 B<Ethereal>. Otherwise, the default TMPDIR location is
|
||
system-dependent, but is likely either F</var/tmp> or F</tmp>.
|
||
|
||
=item Capture:Stop
|
||
|
||
In a capture that updates the packet display as packets arrive (so that
|
||
Ethereal responds to user input other than pressing the "Stop" button in
|
||
the capture packet statistics dialog box), stop the capture.
|
||
|
||
=item Display:Options
|
||
|
||
Pop up a dialog allowing you to set the format of the packet timestamp
|
||
displayed in the packet list window to relative, absolute, absolute date
|
||
and time, or delta, to enable or disable the automatic scrolling of the
|
||
packet list while a live capture is in progress or to enable or disable
|
||
translation of addresses to names in the display.
|
||
|
||
=item Display:Match
|
||
|
||
Create a display filter, or add to the display filter strip at the
|
||
bottom, a display filter based on the data currently highlighted in the
|
||
protocol tree, and apply the filter.
|
||
|
||
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.
|
||
|
||
The B<Selected> option creates a display filter that tests for a match
|
||
of the data; the B<Not Selected> option creates a display filter that
|
||
tests for a non-match of the data. The B<And Selected>, B<Or Selected>,
|
||
B<And Not Selected>, and B<Or Not Selected> options add to the end of
|
||
the display filter in the strip at the bottom an AND or OR operator
|
||
followed by the new display filter expression.
|
||
|
||
=item Display:Prepare
|
||
|
||
Create a display filter, or add to the display filter strip at the
|
||
bottom, a display filter based on the data currently highlighted in the
|
||
protocol tree, but don't apply the filter.
|
||
|
||
=item Display:Colorize Display
|
||
|
||
Change the foreground and background colors of the packet information in
|
||
the list of packets, based upon display filters. The list of display
|
||
filters is applied to each packet sequentially. After the first display
|
||
filter matches a packet, any additional display filters in the list are
|
||
ignored. Therefore, if you are filtering on the existence of protocols,
|
||
you should list the higher-level protocols first, and the lower-level
|
||
protocols last.
|
||
|
||
=item Display:Collapse All
|
||
|
||
Collapse the protocol tree branches.
|
||
|
||
=item Display:Expand All
|
||
|
||
Expand all branches of the protocol tree.
|
||
|
||
=item Display:Expand All
|
||
|
||
Expands all branches of the protocol tree.
|
||
|
||
=item Display:Show Packet In New Window
|
||
|
||
Create a new window containing a protocol tree view and a hex dump
|
||
window of the currently selected packet; this window will continue to
|
||
display that packet's protocol tree and data even if another packet is
|
||
selected.
|
||
|
||
=item Display:User Specified Decodes
|
||
|
||
Create a new window showing whether any protocol ID to dissector
|
||
mappings have been changed by the user. This window also allows the
|
||
user to reset all decodes to their default values.
|
||
|
||
=item Tools:Plugins
|
||
|
||
See what dynamically loadable dissector plugin modules have been loaded
|
||
(see I<"Plugins"> below).
|
||
|
||
=item Tools:Follow TCP Stream
|
||
|
||
If you have a TCP packet selected, display the contents of the data
|
||
stream for the TCP connection to which that packet belongs, as text, in
|
||
a separate window, and 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
|
||
to display:
|
||
|
||
=over 4
|
||
|
||
=item
|
||
|
||
whether to display the entire conversation, or one or the other side of
|
||
it;
|
||
|
||
=item
|
||
|
||
whether the data being displayed is to be treated as ASCII or EBCDIC
|
||
text or as raw hex data;
|
||
|
||
=back
|
||
|
||
=back
|
||
|
||
=over 4
|
||
|
||
=item
|
||
|
||
and lets you print what's currently being displayed, using the same
|
||
print options that are used for the I<File:Print Packet> menu item, or
|
||
save it as text to a file.
|
||
|
||
=back
|
||
|
||
=item Tools:Decode As
|
||
|
||
If you have a packet selected, present a dialog allowing you to change
|
||
which dissectors are used to decode this packet. The dialog has one
|
||
panel each for the link layer, network layer and transport layer
|
||
protocol/port numbers, and will allow each of these to be changed
|
||
independently. For example, if the selected packet is a TCP packet to
|
||
port 12345, using this dialog you can instruct Ethereal to decode all
|
||
packets to or from that TCP port as HTTP packets.
|
||
|
||
=item Tools:Go To Corresponding Frame
|
||
|
||
If a field in the protocol tree pane containing a frame number is
|
||
selected, go to the frame number specified by that field. (This works
|
||
only if the dissector that put that entry into the protocol tree put it
|
||
into the tree as a filterable field rather than just as text.) This can
|
||
be used, for example, to go to the frame for the request corresponding
|
||
to a reply, or the reply corresponding to a request, if that frame
|
||
number has been put into the protocol tree.
|
||
|
||
=item Tools:Protocol Hierarchy Statistics
|
||
|
||
Show the number of packets, and the number of bytes in those packets,
|
||
for each protocol in the trace. It organizes the protocols in the same
|
||
hierarchy in which they were found in the trace. Besides counting the
|
||
packets in which the protocol exists, a count is also made for packets
|
||
in which the protocol is the last protocol in the stack. These
|
||
last-protocol counts show you how many packets (and the byte count
|
||
associated with those packets) B<ended> in a particular protocol. In
|
||
the table, they are listed under "End Packets" and "End Bytes".
|
||
|
||
=item Tools:Statistics:ONC-RPC:RTT
|
||
|
||
Open a window to display statistics for an arbitrary ONC-RPC program interface
|
||
and display B<Procedure>, B<Number of Calls>, B<Minimum RTT>, B<Maximum RTT> and B<Average RTT> for all procedures for that program/version.
|
||
These windows opened will update in semi-real time to reflect changes when
|
||
doing live captures or when reading new capture files into B<Ethereal>.
|
||
|
||
This dialog will also allow an optional filter string to be used.
|
||
If an optional filter string is used only such ONC-RPC request/response pairs
|
||
that match that filter will be used to calculate the statistics. If no filter
|
||
string is specified all request/response pairs will be used.
|
||
|
||
=item Tools:Statistics:ONC-RPC:Programs
|
||
|
||
This dialog will open a window showing aggregated RTT statistics for all
|
||
ONC-RPC Programs/versions that exist in the capture file.
|
||
|
||
=item Tools:Statistics:DCE-RPC:RTT
|
||
|
||
Open a window to display statistics for an arbitrary DCE-RPC program interface
|
||
and display B<Procedure>, B<Number of Calls>, B<Minimum RTT>, B<Maximum RTT> and B<Average RTT> for all procedures for that program/version.
|
||
These windows opened will update in semi-real time to reflect changes when
|
||
doing live captures or when reading new capture files into B<Ethereal>.
|
||
|
||
This dialog will also allow an optional filter string to be used.
|
||
If an optional filter string is used only such DCE-RPC request/response pairs
|
||
that match that filter will be used to calculate the statistics. If no filter
|
||
string is specified all request/response pairs will be used.
|
||
|
||
=item Tools:Statistics:Traffic:IO-Stat
|
||
|
||
Open a window where up to 5 graphs in different colors can be displayed
|
||
to indicate number of frames or number of bytes per second for all packets
|
||
matching the specified filter.
|
||
By default only one graph will be displayed showing number of frames per second.
|
||
|
||
The top part of the window contains the graphs and scales for the X and Y axis.
|
||
If the graph is too long to fit inside the window there is a horizontal scrollbar below the drawing area that can scroll the graphs to the left or the right.
|
||
The horizontal axis displays the time into the capture and the vertical axis will display the measured quantity at that time.
|
||
|
||
Below the drawing area and the scrollbar are the controls.
|
||
On the bottom left there will be five similar sets of controls to control each
|
||
induvidual graph such as "Display:<button>" which button will toggle that individual graph on/off. If <button> is ticked, the graph will be displayed.
|
||
"Color:<color>" which is just a button to show which color will be used to draw that graph (color is only available in Gtk2 version) and finally
|
||
"Filter:<filter-text>" which can be used to specify a display filter for that particular graph.
|
||
|
||
If filter-text is empty then all packets will be used to calculate the quantity for that graph. If filter-text is specified only those packets that match that display filter will be considered in the calculation of quantity.
|
||
|
||
|
||
To the right of the 5 graph controls there are four menus to control global aspects of the draw area and graphs.
|
||
The "Unit:" menu is used to control what to measure; "frames/tick", "bytes/tick" or "advanced..."
|
||
|
||
frames/tick will measure the number of frames matching the (if specified) display filter for the graph in each measurement interval.
|
||
|
||
bytes/tick will measure the total number of bytes in all frames matching the (if specified) display filter for the graph in each measurement interval.
|
||
|
||
advanced... see below
|
||
|
||
|
||
"Tick interval:" specifies what measurement intervals to use. The default is 1 second and means that the data will be counted over 1 second intervals.
|
||
|
||
"Pixels per tick:" specifies how many pixels wide each measurement interval will be in the drawing area. The default is 5 pixels per tick.
|
||
|
||
"Y-scale:" controls the max value for the y-axis. Default value is "auto" which means that ethereal will try to adjust the maxvalue automatically.
|
||
|
||
|
||
|
||
"advanced..." If Unit:advanced... is selected the window will display two more controls for each of the five graphs.
|
||
One control will be a menu where the type of calculation can be selected from SUM,COUNT,MAX,MIN and AVG, and one control, textbox, where the name of a single display filter field can be specified.
|
||
|
||
The following restrictions apply to type and field combinations:
|
||
SUM: availabel for all types of integers.
|
||
COUNT: available for all field types.
|
||
MAX: available for all integer and relative time fields.
|
||
MIN: available for all integer and relative time fields.
|
||
AVG: available for all integer and relative time fields.
|
||
|
||
NOTE: due to the way this is implemented in ethereal there is a requirement that whatever field is specified in the textbox, that field MUST also be part of the filter for the graph or else the calculations will fail.
|
||
|
||
Example of advanced:
|
||
Display how NFS response time MAX/MIN/AVG changes over time:
|
||
|
||
Set first graph to filter:nfs&&rpc.time Calc:MAX rpc.time
|
||
Set second graph to filter:nfs&&rpc.time Calc:AVG rpc.time
|
||
Set third graph to filter:nfs&&rpc.time Calc:MIN rpc.time
|
||
|
||
|
||
Example of advanced:
|
||
Display how the average packetsize from host a.b.c.d changes over time.
|
||
|
||
Set first graph to filter:ip.addr==a.b.c.d&&frame.pkt_len Calc:AVG frame.pkt_len
|
||
|
||
|
||
=item Tools:Statistics:SMB:RTT
|
||
|
||
Collect call/reply RTT data for SMB. Data collected
|
||
is number of calls for each SMB command, MinRTT, MaxRTT and AvgRTT.
|
||
|
||
The data will be presented as separate tables for all normal SMB commands,
|
||
all Transaction2 commands and all NT Transaction commands.
|
||
Only those commands that are seen in the capture will have its stats
|
||
displayed.
|
||
Only the first command in a xAndX command chain will be used in the
|
||
calculation. So for common SessionSetupAndX + TreeConnectAndX chains,
|
||
only the SessionSetupAndX call will be used in the statistics.
|
||
This is a flaw that might be fixed in the future.
|
||
|
||
|
||
|
||
=head2 WINDOWS
|
||
|
||
=over 4
|
||
|
||
=item Main Window
|
||
|
||
The main window is split into three panes. You can resize each pane using
|
||
a "thumb" at the right end of each divider line. Below the panes is a
|
||
strip that shows the current filter and informational text.
|
||
|
||
=over 6
|
||
|
||
=item Top Pane
|
||
|
||
The top pane contains the list of network packets that you can scroll
|
||
through and select. By default, the packet number, packet timestamp,
|
||
source and destination addresses, protocol, and description are
|
||
displayed for each packet; the I<Columns> page in the dialog box popped
|
||
up by I<Edit:Preferences> lets you change this (although, unfortunately,
|
||
you currently have to save the preferences, and exit and restart
|
||
Ethereal, for those changes to take effect).
|
||
|
||
If you click on the heading for a column, the display will be sorted by
|
||
that column; clicking on the heading again will reverse the sort order
|
||
for that column.
|
||
|
||
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.
|
||
|
||
The right mouse button can be used to pop up a menu of operations.
|
||
|
||
The middle mouse button can be used to mark a packet.
|
||
|
||
=item Middle Pane
|
||
|
||
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. The right mouse button can be used to pop up a
|
||
menu of operations.
|
||
|
||
=item Bottom Pane
|
||
|
||
The lowest pane contains a hex dump of the actual packet data.
|
||
Selecting a field in the I<protocol tree> highlights the corresponding
|
||
bytes in this section.
|
||
|
||
The right mouse button can be used to pop up a menu of operations.
|
||
|
||
=item Current Filter
|
||
|
||
A display filter can be entered into the strip at the bottom.
|
||
A filter for HTTP, HTTPS, and DNS traffic might look like this:
|
||
|
||
tcp.port == 80 || tcp.port == 443 || tcp.port == 53
|
||
|
||
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, or selecting the I<Apply> button, 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.
|
||
|
||
=back
|
||
|
||
=item Preferences
|
||
|
||
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 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, on UNIX-compatible systems,
|
||
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
|
||
|
||
The I<Columns> page lets you specify the number, title, and format
|
||
of each column in the packet list.
|
||
|
||
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 Add New
|
||
|
||
Adds a new column to the list.
|
||
|
||
=item Delete
|
||
|
||
Deletes the currently selected list item.
|
||
|
||
=item Up / Down
|
||
|
||
Moves the selected list item up or down one position.
|
||
|
||
=item OK
|
||
|
||
Currently has no effect.
|
||
|
||
=item Save
|
||
|
||
Saves the current column format as the default.
|
||
|
||
=item Cancel
|
||
|
||
Closes the dialog without making any changes.
|
||
|
||
=back
|
||
|
||
=item TCP Streams Preferences
|
||
|
||
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.
|
||
|
||
=item User Interface Preferences
|
||
|
||
The I<User Interface> page is used to modify small aspects of the GUI to
|
||
your own personal taste:
|
||
|
||
=over 6
|
||
|
||
=item Scrollbars
|
||
|
||
The vertical scrollbars in the three panes can be set to be either on
|
||
the left or the right.
|
||
|
||
=item Selection Bars
|
||
|
||
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.
|
||
|
||
=item Tree Line Style
|
||
|
||
Trees can be drawn with no lines, solid lines, or dotted lines between
|
||
items, or can be drawn with "tab" headings.
|
||
|
||
=item Tree Expander Style
|
||
|
||
The expander item that can be clicked to show or hide items under a tree
|
||
item can be omitted (note that this will prevent you from changing
|
||
whether those items are shown or hidden!), or can be drawn as squares,
|
||
triangles, or circles.
|
||
|
||
=item Hex Display
|
||
|
||
The highlight method in the hex dump display for the selected protocol
|
||
item can be set to use either inverse video, or bold characters.
|
||
|
||
=item Save Window Position
|
||
|
||
If this item is selected, the position of the main Ethereal window will
|
||
be saved when Ethereal exits, and used when Ethereal is started again.
|
||
|
||
=item Save Window Size
|
||
|
||
If this item is selected, the size of the main Ethereal window will
|
||
be saved when Ethereal exits, and used when Ethereal is started again.
|
||
|
||
=item Fonts
|
||
|
||
The "Font..." button lets you select the font to be used for most text.
|
||
|
||
=item Colors
|
||
|
||
The "Colors..." button lets you select the colors to be used for instance
|
||
for the marked frames.
|
||
|
||
=back
|
||
|
||
=item Capture Preferences
|
||
|
||
The I<Capture> page lets you specify various parameters for capturing
|
||
live packet data; these are used the first time a capture is started.
|
||
|
||
The I<Interface:> combo box lets you specify the interface from which to
|
||
capture packet data, or the name of a FIFO from which to get the packet
|
||
data. You can specify whether the interface is to be put in promiscuous
|
||
mode or not with the I<Capture packets in promiscuous mode> check box,
|
||
can specify that the display should be updated as packets are captured
|
||
with the I<Update list of packets in real time> check box, and 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.
|
||
|
||
=item Protocol Preferences
|
||
|
||
There are also pages for various protocols that Ethereal dissects,
|
||
controlling the way Ethereal handles those protocols.
|
||
|
||
=back
|
||
|
||
=item Edit Capture Filter List
|
||
|
||
=item Edit Display Filter List
|
||
|
||
=item Capture Filter
|
||
|
||
=item Display Filter
|
||
|
||
=item Read Filter
|
||
|
||
=item Search Filter
|
||
|
||
The I<Edit Capture Filter List> dialog lets you create, modify, and
|
||
delete capture filters, and the I<Edit Display Filter List> dialog lets
|
||
you create, modify, and delete display filters.
|
||
|
||
The I<Capture Filter> dialog lets you do all of the editing operations
|
||
listed, and also lets you choose or construct a filter to be used when
|
||
capturing packets.
|
||
|
||
The I<Display Filter> dialog lets you do all of the editing operations
|
||
listed, and also lets you choose or construct a filter to be used to
|
||
filter the current capture being viewed.
|
||
|
||
The I<Read Filter> dialog lets you do all of the editing operations
|
||
listed, and also lets you choose or construct a filter to be used to
|
||
as a read filter for a capture file you open.
|
||
|
||
The I<Search Filter> dialog lets you do all of the editing operations
|
||
listed, and also lets you choose or construct a filter expression to be
|
||
used in a find operation.
|
||
|
||
In all of those dialogs, 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
|
||
|
||
If there is text in the two entry boxes, creates a new associated list
|
||
item.
|
||
|
||
=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.
|
||
|
||
=item Delete
|
||
|
||
Deletes the currently selected list item.
|
||
|
||
=item Add Expression...
|
||
|
||
For display filter expressions, pops up a dialog box to allow you to
|
||
construct a filter expression to test a particular field; it offers
|
||
lists of field names, and, when appropriate, lists from which to select
|
||
tests to perform on the field and values with which to compare it. In
|
||
that dialog box, the OK button will cause the filter expression you
|
||
constructed to be entered into the I<Filter string> entry at the current
|
||
cursor position.
|
||
|
||
=item OK
|
||
|
||
In the I<Capture Filter> dialog, closes the dialog box and makes the
|
||
filter in the I<Filter string> entry the filter in the I<Capture
|
||
Preferences> dialog. In the I<Display Filter> dialog, closes the dialog
|
||
box and makes the filter in the I<Filter string> entry the current
|
||
display filter, and applies it to the current capture. In the I<Read
|
||
Filter> dialog, closes the dialog box and makes the filter in the
|
||
I<Filter string> entry the filter in the I<Open Capture File> dialog.
|
||
In the I<Search Filter> dialog, closes the dialog box and makes the
|
||
filter in the I<Filter string> entry the filter in the I<Find Frame>
|
||
dialog.
|
||
|
||
=item Apply
|
||
|
||
Makes the filter in the I<Filter string> entry the current display
|
||
filter, and applies it to the current capture.
|
||
|
||
=item Save
|
||
|
||
Saves the current filter list in F<$HOME/.ethereal/cfilters> on
|
||
UNIX-compatible systems, and F<%APPDATA%\Ethereal\cfilters> (or, if
|
||
%APPDATA% isn't defined,
|
||
F<%USERPROFILE%\Application Data\Ethereal\cfilters>)
|
||
on Windows systems, if the list of filters being edited is the list of
|
||
capture filters, or in F<$HOME/.ethereal/dfilters> on UNIX-compatible
|
||
systems, and F<%APPDATA%\Ethereal\dfilters> (or, if %APPDATA% isn't
|
||
defined, F<%USERPROFILE%\Application Data\Ethereal\dfilters>) on Windows
|
||
systems, if the list of filters being edited is the list of display
|
||
filters.
|
||
|
||
=item Close
|
||
|
||
Closes the dialog without doing anything with the filter in the I<Filter
|
||
string> entry.
|
||
|
||
=back
|
||
|
||
=item Capture Options
|
||
|
||
The I<Capture Options> dialog lets you specify various parameters for
|
||
capturing live packet data.
|
||
|
||
The I<Interface:> field lets you specify the interface from which to
|
||
capture packet data or a command from which to get the packet data via a
|
||
pipe.
|
||
|
||
The I<Limit each packet to ... bytes> check box and field lets you
|
||
specify a maximum number of bytes per packet to capture and save; if the
|
||
check box is not checked, the limit will be 65535 bytes.
|
||
|
||
The I<Capture packets in promiscuous mode> check box lets you specify
|
||
whether the interface should be put into promiscuous mode when
|
||
capturing.
|
||
|
||
The I<Filter:> entry lets you specify the capture filter using a
|
||
tcpdump-style filter string as described above.
|
||
|
||
The I<File:> entry lets you specify the file into which captured packets
|
||
should be saved, as in the I<Printer Options> dialog above. If not
|
||
specified, the captured packets will be saved in a temporary file; you
|
||
can save those packets to a file with the I<File:Save As> menu item.
|
||
|
||
The I<Use ring buffer> check box lets you specify that the capture
|
||
should be done in "ring buffer" mode; the I<Number of files> field
|
||
lets you specify the number of files in the ring buffer.
|
||
|
||
The I<Update list of packets in real time> check box lets you specify
|
||
whether the display should be updated as packets are captured and, if
|
||
you specify that, the I<Automatic scrolling in live capture> check box
|
||
lets you specify the packet list pane should automatically scroll to
|
||
show the most recently captured packets as new packets arrive.
|
||
|
||
The I<Stop capture after ... packet(s) captured> check box and field let
|
||
you specify that Ethereal should stop capturing after having captured
|
||
some number of packets; if the check box is not checked, Ethereal will
|
||
not stop capturing at some fixed number of captured packets.
|
||
|
||
If "ring buffer" mode is not specified, the I<Stop capture after ...
|
||
kilobyte(s) captured> check box and field let you specify that Ethereal
|
||
should stop capturing after the the file to which captured packets are
|
||
being saved grows as large as or larger than some specified number of
|
||
kilobytes (where a kilobyte is 1000 bytes, not 1024 bytes). If the
|
||
check box is not checked, Ethereal will not stop capturing at some
|
||
capture file size (although the operating system on which Ethereal is
|
||
running, or the available disk space, may still limit the maximum size
|
||
of a capture file).
|
||
|
||
If "ring buffer" mode is specified, that field becomes the I<Rotate
|
||
capture file very ... kilobyte(s)> field, and specifies the number
|
||
of kilobytes at which to start writing to a new ring buffer file; the
|
||
check box is forced to be checked, as "ring buffer" mode requires a file
|
||
size to be specified.
|
||
|
||
The I<Stop capture after ... second(s)> check box and field let you
|
||
specify that Ethereal should stop capturing after it has been capturing
|
||
for some number of seconds; if the check box is not checked, Ethereal
|
||
will not stop capturing after some fixed time has elapsed.
|
||
|
||
The I<Enable MAC name resolution>, I<Enable network name resolution> and
|
||
I<Enable transport name resolution> check boxes let you specify whether
|
||
MAC addresses, network addresses, and transport-layer port numbers
|
||
should be translated to names.
|
||
|
||
=item Display Options
|
||
|
||
The I<Display Options> dialog lets you specify the format of the time
|
||
stamp in the packet list. You can select "Time of day" for absolute
|
||
time stamps, "Date and time of day" for absolute time stamps with the
|
||
date, "Seconds since beginning of capture" for relative time stamps, or
|
||
"Seconds since previous frame" for delta time stamps. You can also
|
||
specify whether, when the display is updated as packets are captured,
|
||
the list should automatically scroll to show the most recently captured
|
||
packets or not and whether addresses or port numbers should be
|
||
translated to names in the display on a MAC, network and transport layer
|
||
basis.
|
||
|
||
=item Plugins
|
||
|
||
The I<Plugins> dialog lets you view the dissector plugin modules
|
||
available on your system.
|
||
|
||
The I<Plugins List> shows the name and version of each dissector plugin
|
||
module found on your system. The plugins are searched in the following
|
||
directories: the F<lib/ethereal/plugins/$VERSION> directory under the
|
||
main installation directory (for example,
|
||
F</usr/local/lib/ethereal/plugins/$VERSION>),
|
||
F</usr/lib/ethereal/plugins/$VERSION>,
|
||
F</usr/local/lib/ethereal/plugins/$VERSION>, and
|
||
F<$HOME/.ethereal/plugins> on UNIX-compatible systems, and in the
|
||
F<plugins\$VERSION> directory under the main installation directory (for
|
||
example, F<C:\Program Files\Ethereal\plugins\$VERSION>) and
|
||
F<%APPDATA%\Ethereal\plugins\$VERSION> (or, if %APPDATA% isn't defined,
|
||
F<%USERPROFILE%\Application Data\Ethereal\plugins\$VERSION>) on Windows
|
||
systems; $VERSION is the version number of the plugin interface, which
|
||
is typically the version number of Ethereal. Note that a dissector
|
||
plugin module may support more than one protocol; there is not
|
||
necessarily a one-to-one correspondence between dissector plugin modules
|
||
and protocols. Protocols supported by a dissector plugin module are
|
||
enabled and disabled using the I<Edit:Protocols> dialog box, just as
|
||
protocols built into Ethereal are.
|
||
|
||
=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.
|
||
|
||
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:
|
||
|
||
eq, == Equal
|
||
ne, != Not equal
|
||
gt, > Greater than
|
||
lt, < Less Than
|
||
ge, >= Greater than or Equal to
|
||
le, <= Less than or Equal to
|
||
|
||
Furthermore, each protocol field is typed. The types are:
|
||
|
||
Unsigned integer (either 8-bit, 16-bit, 24-bit, or 32-bit)
|
||
Signed integer (either 8-bit, 16-bit, 24-bit, or 32-bit)
|
||
Boolean
|
||
Ethernet address (6 bytes)
|
||
Byte string (n-number of bytes)
|
||
IPv4 address
|
||
IPv6 address
|
||
IPX network number
|
||
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:
|
||
|
||
frame.pkt_len > 10
|
||
frame.pkt_len > 012
|
||
frame.pkt_len > 0xa
|
||
|
||
Boolean values are either true or false. In a display filter expression
|
||
testing the value of a Boolean field, "true" is expressed as 1 or any
|
||
other non-zero value, and "false" is expressed as zero. For example, a
|
||
token-ring packet's source route field is boolean. To find any
|
||
source-routed packets, a display filter would be:
|
||
|
||
tr.sr == 1
|
||
|
||
Non source-routed packets can be found with:
|
||
|
||
tr.sr == 0
|
||
|
||
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'.
|
||
|
||
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 addresses 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 slice 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
|
||
|
||
If the length of your byte-slice is only one byte, then it is still
|
||
represented in hex, but without the preceding "0x":
|
||
|
||
llc[3] == aa
|
||
|
||
You can use the slice 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
|
||
|
||
The following syntax governs slices:
|
||
|
||
[i:j] i = start_offset, j = length
|
||
[i-j] i = start_offet, j = end_offset, inclusive.
|
||
[i] i = start_offset, length = 1
|
||
[:j] start_offset = 0, length = j
|
||
[i:] start_offset = i, end_offset = end_of_field
|
||
|
||
Offsets and lengths can be negative, in which case they indicate the
|
||
offset from the B<end> of the field. Here's how to check the last 4
|
||
bytes of a frame:
|
||
|
||
frame[-4:4] == 0.1.2.3
|
||
|
||
or
|
||
|
||
frame[-4:] == 0.1.2.3
|
||
|
||
You can create complex concatenations of slices using the comma operator:
|
||
|
||
field[1,3-5,9:] == 01:03:04:05:09:0a:0b
|
||
|
||
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
|
||
not, ! Logical NOT
|
||
|
||
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:
|
||
|
||
ip.addr ne 192.168.4.1
|
||
not ip.addr eq 192.168.4.1
|
||
|
||
The first filter says "show me IP 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".
|
||
|
||
Be careful with multiply-recurring fields; they can be confusing.
|
||
|
||
Care must also be taken when using the display filter to remove noise
|
||
from the packet trace. If you want to e.g. filter out all IP multicast
|
||
packets to address 224.1.2.3, then using:
|
||
|
||
ip.dst ne 224.1.2.3
|
||
|
||
may be too restrictive. Filtering with "ip.dst" selects only those
|
||
B<IP> packets that satisfy the rule. Any other packets, including all
|
||
non-IP packets, will not displayed. For displaying also the non-IP
|
||
packets, you can use one of the following two expressions:
|
||
|
||
not ip or ip.dst ne 224.1.2.3
|
||
not ip.addr eq 224.1.2.3
|
||
|
||
The first filter uses "not ip" to include all non-IP packets and then
|
||
lets "ip.dst ne 224.1.2.3" to filter out the unwanted IP packets. The
|
||
second filter has already been explained above where filtering with
|
||
multiply occuring fields was discussed.
|
||
|
||
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
|
||
|
||
The F<ethereal.conf> file, which is installed in the F<etc> directory
|
||
under the main installation directory (for example, F</usr/local/etc>)
|
||
on UNIX-compatible systems, and in the main installation directory (for
|
||
example, F<C:\Program Files\Ethereal>) on Windows systems, and the
|
||
personal preferences file, which is F<$HOME/.ethereal/preferences> on
|
||
UNIX-compatible systems and F<%APPDATA%\Ethereal\preferences> (or, if
|
||
%APPDATA% isn't defined,
|
||
F<%USERPROFILE%\Application Data\Ethereal\preferences>) on
|
||
Windows systems, contain system-wide and personal preference settings,
|
||
respectively. The file contains preference settings of the form
|
||
I<prefname>B<:>I<value>, one per line, where I<prefname> is the name of
|
||
the preference (which is the same name that would appear in the
|
||
preference file), and I<value> is the value to which it should be set;
|
||
white space is allowed between B<:> and I<value>. A preference setting
|
||
can be continued on subsequent lines by indenting the continuation lines
|
||
with white space. A B<#> character starts a comment that runs to the
|
||
end of the line.
|
||
|
||
The system-wide preference file is read first, if it exists, overriding
|
||
B<Ethereal>'s default values; the personal preferences file is then
|
||
read, if it exists, overriding default values and values read from the
|
||
system-wide preference file.
|
||
|
||
Note that whenever the preferences are saved by using the I<Save> button
|
||
in the I<Edit:Preferences> dialog box, your personal preferences file
|
||
will be overwritten with the new settings, destroying any comments that
|
||
were in the file.
|
||
|
||
The F<ethers> file, which is found in the F</etc> directory on
|
||
UNIX-compatible systems, and in the main installation directory (for
|
||
example, F<C:\Program Files\Ethereal>) on Windows systems, is consulted
|
||
to correlate 6-byte hardware addresses to names. If an address is not
|
||
found in the F<ethers> file, the F<$HOME/.ethereal/ethers> file on
|
||
UNIX-compatible systems, and the F<%APPDATA%\Ethereal\ethers> file (or, if
|
||
%APPDATA% isn't defined, the
|
||
F<%USERPROFILE%\Application Data\Ethereal\ethers> file) on Windows
|
||
systems 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
|
||
|
||
The F<manuf> file, which is installed in the F<etc> directory under the
|
||
main installation directory (for example, F</usr/local/etc>) on
|
||
UNIX-compatible systems, and in the main installation directory (for
|
||
example, F<C:\Program Files\Ethereal>) on Windows systems, matches the
|
||
3-byte vendor portion of a 6-byte hardware address with the
|
||
manufacturer's name; it can also contain well-known MAC addresses and
|
||
address ranges specified with a netmask. The format of the file is the
|
||
same as the F<ethers> file, except that entries of the form
|
||
|
||
00:00:0C Cisco
|
||
|
||
can be provided, with the 3-byte OUI and the name for a vendor, and
|
||
entries of the form
|
||
|
||
00-00-0C-07-AC/40 All-HSRP-routers
|
||
|
||
can be specified, with a MAC address and a mask indicating how many bits
|
||
of the address must match. Trailing zero bytes can be omitted from
|
||
address ranges. That entry, for example, will match addresses from
|
||
00-00-0C-07-AC-00 through 00-00-0C-07-AC-FF. The mask need not be a
|
||
multiple of 8.
|
||
|
||
The F<ipxnets> file, which is found in the F</etc> directory on
|
||
UNIX-compatible systems, and in the main installation directory (for
|
||
example, F<C:\Program Files\Ethereal>) on Windows systems, correlates
|
||
4-byte IPX network numbers to names. If a network number is not found
|
||
in the F<ipxnets> file, the F<$HOME/.ethereal/ipxnets> file on
|
||
UNIX-compatible systems, and the F<%APPDATA%\Ethereal\ipxnets> file (or,
|
||
if %APPDATA% isn't defined, the
|
||
F<%USERPROFILE%\Application Data\Ethereal\ipxnets> file)
|
||
on Windows systems, is consulted next. The format is the same as the
|
||
F<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
|
||
|
||
I<tethereal(1)>, I<editcap(1)>, I<tcpdump(8)>, I<pcap(3)>
|
||
|
||
=head1 NOTES
|
||
|
||
The latest version of B<Ethereal> can be found at
|
||
B<http://www.ethereal.com>.
|
||
|
||
=head1 AUTHORS
|
||
|
||
Original Author
|
||
-------- ------
|
||
Gerald Combs <gerald[AT]ethereal.com>
|
||
|
||
|
||
Contributors
|
||
------------
|
||
Gilbert Ramirez <gram[AT]alumni.rice.edu>
|
||
Hannes R. Boehm <hannes[AT]boehm.org>
|
||
Mike Hall <mike [AT] hallzone.net>
|
||
Bobo Rajec <bobo[AT]bsp-consulting.sk>
|
||
Laurent Deniel <deniel[AT]worldnet.fr>
|
||
Don Lafontaine <lafont02[AT]cn.ca>
|
||
Guy Harris <guy[AT]alum.mit.edu>
|
||
Simon Wilkinson <sxw[AT]dcs.ed.ac.uk>
|
||
Joerg Mayer <jmayer[AT]loplof.de>
|
||
Martin Maciaszek <fastjack[AT]i-s-o.net>
|
||
Didier Jorand <Didier.Jorand[AT]alcatel.fr>
|
||
Jun-ichiro itojun Hagino <itojun[AT]itojun.org>
|
||
Richard Sharpe <sharpe[AT]ns.aus.com>
|
||
John McDermott <jjm[AT]jkintl.com>
|
||
Jeff Jahr <jjahr[AT]shastanets.com>
|
||
Brad Robel-Forrest <bradr[AT]watchguard.com>
|
||
Ashok Narayanan <ashokn[AT]cisco.com>
|
||
Aaron Hillegass <aaron[AT]classmax.com>
|
||
Jason Lango <jal[AT]netapp.com>
|
||
Johan Feyaerts <Johan.Feyaerts[AT]siemens.atea.be>
|
||
Olivier Abad <oabad[AT]noos.fr>
|
||
Thierry Andry <Thierry.Andry[AT]advalvas.be>
|
||
Jeff Foster <jfoste[AT]woodward.com>
|
||
Peter Torvals <petertv[AT]xoommail.com>
|
||
Christophe Tronche <ch.tronche[AT]computer.org>
|
||
Nathan Neulinger <nneul[AT]umr.edu>
|
||
Tomislav Vujec <tvujec[AT]carnet.hr>
|
||
Kojak <kojak[AT]bigwig.net>
|
||
Uwe Girlich <Uwe.Girlich[AT]philosys.de>
|
||
Warren Young <tangent[AT]mail.com>
|
||
Heikki Vatiainen <hessu[AT]cs.tut.fi>
|
||
Greg Hankins <gregh[AT]twoguys.org>
|
||
Jerry Talkington <jerryt[AT]netapp.com>
|
||
Dave Chapeskie <dchapes[AT]ddm.on.ca>
|
||
James Coe <jammer[AT]cin.net>
|
||
Bert Driehuis <driehuis[AT]playbeing.org>
|
||
Stuart Stanley <stuarts[AT]mxmail.net>
|
||
John Thomes <john[AT]ensemblecom.com>
|
||
Laurent Cazalet <laurent.cazalet[AT]mailclub.net>
|
||
Thomas Parvais <thomas.parvais[AT]advalvas.be>
|
||
Gerrit Gehnen <G.Gehnen[AT]atrie.de>
|
||
Craig Newell <craign[AT]cheque.uq.edu.au>
|
||
Ed Meaney <emeaney[AT]cisco.com>
|
||
Dietmar Petras <DPetras[AT]ELSA.de>
|
||
Fred Reimer <fwr[AT]ga.prestige.net>
|
||
Florian Lohoff <flo[AT]rfc822.org>
|
||
Jochen Friedrich <jochen+ethereal[AT]scram.de>
|
||
Paul Welchinski <paul.welchinski[AT]telusplanet.net>
|
||
Doug Nazar <nazard[AT]dragoninc.on.ca>
|
||
Andreas Sikkema <andreas.sikkema[AT]philips.com>
|
||
Mark Muhlestein <mmm[AT]netapp.com>
|
||
Graham Bloice <graham.bloice[AT]trihedral.com>
|
||
Ralf Schneider <ralf.schneider[AT]alcatel.se>
|
||
Yaniv Kaul <ykaul[AT]netvision.net.il>
|
||
Paul Ionescu <paul[AT]acorp.ro>
|
||
Mark Burton <markb[AT]ordern.com>
|
||
Stefan Raab <sraab[AT]cisco.com>
|
||
Mark Clayton <clayton[AT]shore.net>
|
||
Michael Rozhavsky <mike[AT]tochna.technion.ac.il>
|
||
Dug Song <dugsong[AT]monkey.org>
|
||
Michael Tuexen <Michael.Tuexen [AT] siemens.com>
|
||
Bruce Korb <bkorb[AT]sco.com>
|
||
Jose Pedro Oliveira <jpo[AT]di.uminho.pt>
|
||
David Frascone <dave[AT]frascone.com>
|
||
Peter Kjellerstedt <pkj[AT]axis.com>
|
||
Phil Techau <phil_t[AT]altavista.net>
|
||
Wes Hardaker <wjhardaker[AT]ucdavis.edu>
|
||
Robert Tsai <rtsai[AT]netapp.com>
|
||
Craig Metz <cmetz[AT]inner.net>
|
||
Per Flock <per.flock[AT]axis.com>
|
||
Jack Keane <jkeane[AT]OpenReach.com>
|
||
Brian Wellington <bwelling[AT]xbill.org>
|
||
Santeri Paavolainen <santtu[AT]ssh.com>
|
||
Ulrich Kiermayr <uk[AT]ap.univie.ac.at>
|
||
Neil Hunter <neil.hunter[AT]energis-squared.com>
|
||
Ralf Holzer <ralf[AT]well.com>
|
||
Craig Rodrigues <rodrigc[AT]mediaone.net>
|
||
Ed Warnicke <hagbard[AT]physics.rutgers.edu>
|
||
Johan Jorgensen <johan.jorgensen[AT]axis.com>
|
||
Frank Singleton <frank.singleton[AT]ericsson.com>
|
||
Kevin Shi <techishi[AT]ms22.hinet.net>
|
||
Mike Frisch <mfrisch[AT]isurfer.ca>
|
||
Burke Lau <burke_lau[AT]agilent.com>
|
||
Martti Kuparinen <martti.kuparinen[AT]iki.fi>
|
||
David Hampton <dhampton[AT]mac.com>
|
||
Kent Engstr<74>m <kent[AT]unit.liu.se>
|
||
Ronnie Sahlberg <sahlberg[AT]optushome.com.au>
|
||
Borosa Tomislav <tomislav.borosa[AT]SIEMENS.HR>
|
||
Alexandre P. Ferreira <alexandref[AT]tcoip.com.br>
|
||
Simharajan Srishylam <Simharajan.Srishylam[AT]netapp.com>
|
||
Greg Kilfoyle <gregk[AT]redback.com>
|
||
James E. Flemer <jflemer[AT]acm.jhu.edu>
|
||
Peter Lei <peterlei[AT]cisco.com>
|
||
Thomas Gimpel <thomas.gimpel[AT]ferrari.de>
|
||
Albert Chin <china[AT]thewrittenword.com>
|
||
Charles Levert <charles[AT]comm.polymtl.ca>
|
||
Todd Sabin <tas[AT]webspan.net>
|
||
Eduardo P<>rez Ureta <eperez[AT]dei.inf.uc3m.es>
|
||
Martin Thomas <martin_a_thomas[AT]yahoo.com>
|
||
Hartmut Mueller <hartmut[AT]wendolene.ping.de>
|
||
Michal Melerowicz <Michal.Melerowicz[AT]nokia.com>
|
||
Hannes Gredler <hannes[AT]juniper.net>
|
||
Inoue <inoue[AT]ainet.or.jp>
|
||
Olivier Biot <Olivier.Biot[AT]siemens.atea.be>
|
||
Patrick Wolfe <pjw[AT]zocalo.cellular.ameritech.com>
|
||
Martin Held <Martin.Held[AT]icn.siemens.de>
|
||
Riaan Swart <rswart[AT]cs.sun.ac.za>
|
||
Christian Lacunza <celacunza[AT]gmx.net>
|
||
Scott Renfro <scott[AT]renfro.org>
|
||
Juan Toledo <toledo[AT]users.sourceforge.net>
|
||
Jean-Christian Pennetier <jeanchristian.pennetier[AT]rd.francetelecom.fr>
|
||
Jian Yu <bgp4news[AT]yahoo.com>
|
||
Eran Mann <emann[AT]opticalaccess.com>
|
||
Andy Hood <ahood[AT]westpac.com.au>
|
||
Randy McEoin <rmceoin[AT]pe.net>
|
||
Edgar Iglesias <edgar.iglesias[AT]axis.com>
|
||
Martina Obermeier <Martina.Obermeier[AT]icn.siemens.de>
|
||
Javier Achirica <achirica[AT]ttd.net>
|
||
B. Johannessen <bob[AT]havoq.com>
|
||
Thierry Pelle <thierry.pelle[AT]rd.francetelecom.fr>
|
||
Francisco Javier Cabello <fjcabello[AT]vtools.es>
|
||
Laurent Rabret <laurent.rabret[AT]rd.francetelecom.fr>
|
||
nuf si <gnippiks[AT]yahoo.com>
|
||
Jeff Morriss <jeff.morriss[AT]ulticom.com>
|
||
Aamer Akhter <aakhter[AT]cisco.com>
|
||
Pekka Savola <pekkas[AT]netcore.fi>
|
||
David Eisner <cradle[AT]Glue.umd.edu>
|
||
Steve Dickson <steved[AT]talarian.com>
|
||
Markus Seehofer <mseehofe[AT]nt.hirschmann.de>
|
||
Lee Berger <lberger[AT]roy.org>
|
||
Motonori Shindo <mshindo[AT]mshindo.net>
|
||
Terje Krogdahl <tekr[AT]nextra.com>
|
||
Jean-Francois Mule <jfm[AT]cablelabs.com>
|
||
Thomas Wittwer <thomas.wittwer[AT]iclip.ch>
|
||
Matthias Nyffenegger <matthias.nyffenegger[AT]iclip.ch>
|
||
Palle Lyckegaard <Palle[AT]lyckegaard.dk>
|
||
Nicolas Balkota <balkota[AT]mac.com>
|
||
Tom Uijldert <Tom.Uijldert[AT]cmg.nl>
|
||
Endoh Akira <endoh[AT]netmarks.co.jp>
|
||
Graeme Hewson <graeme.hewson[AT]oracle.com>
|
||
Pasi Eronen <pasi.eronen[at]nixu.com>
|
||
Georg von Zezschwitz <gvz[AT]2scale.net>
|
||
Steffen Weinreich <steve[AT]weinreich.org>
|
||
Marc Milgram <ethereal[AT]mmilgram.NOSPAMmail.net>
|
||
Gordon McKinney <gordon[AT]night-ray.com>
|
||
Tim Farley <tfarley[AT]iss.net>
|
||
Daniel Thompson <daniel.thompson[AT]st.com>
|
||
Chris Jepeway <thai-dragon[AT]eleven29.com>
|
||
Pavel Novotny <Pavel.Novotny[AT]icn.siemens.de>
|
||
Shinsuke Suzuki <suz[AT]kame.net>
|
||
Andrew C. Feren <aferen[AT]cetacean.com>
|
||
Tomas Kukosa <tomas.kukosa [AT] siemens.com>
|
||
Andreas Stockmeier <a.stockmeier[AT]avm.de>
|
||
Pekka Nikander <pekka.nikander[AT]nomadiclab.com>
|
||
Hamish Moffatt <hamish[AT]cloud.net.au>
|
||
Kazushi Sugyo <k-sugyou[AT]nwsl.mesh.ad.jp>
|
||
Tim Potter <tpot[AT]samba.org>
|
||
Raghu Angadi <rangadi[AT]inktomi.com>
|
||
Taisuke Sasaki <sasaki[AT]soft.net.fujitsu.co.jp>
|
||
Tim Newsham <newsham[AT]lava.net>
|
||
Tom Nisbet <Tnisbet[AT]VisualNetworks.com>
|
||
Darren New <dnew[AT]san.rr.com>
|
||
Pavel Mores <pvl[AT]uh.cz>
|
||
Bernd Becker <bb[AT]bernd-becker.de>
|
||
Heinz Prantner <Heinz.Prantner[AT]radisys.com>
|
||
Irfan Khan <ikhan[AT]qualcomm.com>
|
||
Jayaram V.R <vjayar[AT]cisco.com>
|
||
Dinesh Dutt <ddutt[AT]cisco.com>
|
||
Nagarjuna Venna <nvenna[AT]Brixnet.com>
|
||
Jirka Novak <j.novak[AT]netsystem.cz>
|
||
Ricardo Barroetave<76>a <rbarroetavena[AT]veufort.com>
|
||
Alan Harrison <alanharrison[AT]mail.com>
|
||
Mike Frantzen <frantzen[AT]w4g.org>
|
||
Charlie Duke <cduke[AT]fvc.com>
|
||
Alfred Arnold <Alfred.Arnold[AT]elsa.de>
|
||
Dermot Bradley <dermot.bradley[AT]openwave.com>
|
||
Adam Sulmicki <adam[AT]cfar.umd.edu>
|
||
Kari Tiirikainen <kari.tiirikainen[AT]nokia.com>
|
||
John Mackenzie <John.A.Mackenzie[AT]t-online.de>
|
||
Peter Valchev <pvalchev[AT]openbsd.org>
|
||
Alex Ruzin <alexr[AT]nbase.co.il>
|
||
Jouni Malinen <jkmaline[AT]cc.hut.fi>
|
||
Paul E. Erkkila <pee[AT]erkkila.org>
|
||
Jakob Schlyter <jakob[AT]crt.se>
|
||
Jim Sienicki <sienicki[AT]issanni.com>
|
||
Steven French <sfrench[AT]us.ibm.com>
|
||
Diana Eichert <deicher[AT]sandia.gov>
|
||
Blair Cooper <blair[AT]teamon.com>
|
||
Kikuchi Ayamura <ayamura[AT]ayamura.org>
|
||
Didier Gautheron <dgautheron[AT]magic.fr>
|
||
Phil Williams <csypbw[AT]comp.leeds.ac.uk>
|
||
Kevin Humphries <khumphries[AT]networld.com>
|
||
Erik Nordstr<74>m <erik.nordstrom[AT]it.uu.se>
|
||
Devin Heitmueller <dheitmueller[AT]netilla.com>
|
||
Chenjiang Hu <chu[AT]chiaro.com>
|
||
Kan Sasaki <sasaki[AT]fcc.ad.jp>
|
||
Stefan Wenk <stefan.wenk[AT]gmx.at>
|
||
Ruud Linders <ruud[AT]lucent.com>
|
||
Andrew Esh <Andrew.Esh[AT]tricord.com>
|
||
Greg Morris <GMORRIS[AT]novell.com>
|
||
Dirk Steinberg <dws[AT]dirksteinberg.de>
|
||
Kari Heikkila <kari.o.heikkila[AT]nokia.com>
|
||
Olivier Dreux <Olivier.Dreux[AT]alcatel.fr>
|
||
Michael Stiller <ms[AT]2scale.net>
|
||
Antti Tuominen <ajtuomin[AT]tml.hut.fi>
|
||
Martin Gignac <lmcgign[AT]mobilitylab.net>
|
||
John Wells <wells[AT]ieee.org>
|
||
Loic Tortay <tortay[AT]cc.in2p3.fr>
|
||
Steve Housley <Steve_Housley[AT]eur.3com.com>
|
||
Peter Hawkins <peter[AT]hawkins.emu.id.au>
|
||
Bill Fumerola <billf[AT]FreeBSD.org>
|
||
Chris Waters <chris[AT]waters.co.nz>
|
||
Solomon Peachy <pizza[AT]shaftnet.org>
|
||
Jaime Fournier <jafour1[AT]yahoo.com>
|
||
Markus Steinmann <ms[AT]seh.de>
|
||
Tsutomu Mieno <iitom[AT]utouto.com>
|
||
Yasuhiro Shirasaki <yasuhiro[AT]gnome.gr.jp>
|
||
Anand V. Narwani <anarwani[AT]cisco.com>
|
||
Christopher K. St. John <cks[AT]distributopia.com>
|
||
Nix <nix[AT]esperi.demon.co.uk>
|
||
Liviu Daia <Liviu.Daia[AT]imar.ro>
|
||
Richard Urwin <rurwin[AT]schenck.co.uk>
|
||
Prabhakar Krishnan <Prabhakar.Krishnan[AT]netapp.com>
|
||
Jim McDonough <jmcd[AT]us.ibm.com>
|
||
Sergei Shokhor <sshokhor[AT]uroam.com>
|
||
Hidetaka Ogawa <ogawa[AT]bs2.qnes.nec.co.jp>
|
||
Jan Kratochvil <short[AT]ucw.cz>
|
||
Alfred Koebler <ak[AT]icon-sult.de>
|
||
Vassilii Khachaturov <Vassilii.Khachaturov[AT]comverse.com>
|
||
Bill Studenmund <wrstuden[AT]wasabisystems.com>
|
||
Brian Bruns <camber[AT]ais.org>
|
||
Flavio Poletti <flavio[AT]polettix.it>
|
||
Marcus Haebler <haeblerm[AT]yahoo.com>
|
||
Ulf Lamping <ulf.lamping[AT]web.de>
|
||
Matthew Smart <smart[AT]monkey.org>
|
||
Luke Howard <lukeh[AT]au.padl.com>
|
||
PC Drew <drewpc[AT]ibsncentral.com>
|
||
Renzo Tomas <renzo.toma [AT] xs4all.nl>
|
||
Clive A. Stubbings <eth[AT]vjet.demon.co.uk>
|
||
Steve Langasek <vorlon [AT] netexpress.net>
|
||
Brad Hards <bhards[AT]bigpond.net.au>
|
||
cjs 2895 <cjs2895[AT]hotmail.com>
|
||
Lutz Jaenicke <Lutz.Jaenicke [AT] aet.TU-Cottbus.DE>
|
||
Senthil Kumar Nagappan <sknagappan [AT] yahoo.com>
|
||
Jason House <jhouse [AT] mitre.org>
|
||
Peter Fales <psfales [AT] lucent.com>
|
||
Fritz Budiyanto <fritzb88 [AT] yahoo.com>
|
||
Jean-Baptiste Marchand <Jean-Baptiste.Marchand [AT] hsc.fr>
|
||
Andreas Trauer <andreas.trauer [AT] siemens.com>
|
||
Ronald Henderson <Ronald.Henderson [AT] CognicaseUSA.com>
|
||
Brian Ginsbach <ginsbach [AT] cray.com>
|
||
Dave Richards <d_m_richards [AT] attbi.com>
|
||
Martin Regner <martin.regner [AT] chello.se>
|
||
Jason Greene <jason [AT] inetgurus.net>
|
||
Marco Molteni <mmolteni [AT] cisco.com>
|
||
James Harris <jharris [AT] fourhorsemen.org>
|
||
rmkml <rmkml [AT] wanadoo.fr>
|
||
Anders Broman <a.broman [AT] telia.com>
|
||
Christian Falckenberg <christian.falckenberg [AT] nortelnetworks.com>
|
||
Huagang Xie <xie [AT] lids.org>
|
||
cjs 2895 <cjs2895 [AT] hotmail.com>
|
||
|
||
Alain Magloire <alainm[AT]rcsm.ece.mcgill.ca> was kind enough to give his
|
||
permission to use his version of snprintf.c.
|
||
|
||
Dan Lasley <dlasley[AT]promus.com> gave permission for his dumpit() hex-dump
|
||
routine to be used.
|
||
|
||
Mattia Cazzola <mattiac[AT]alinet.it> provided a patch to the hex dump
|
||
display routine.
|
||
|
||
We use the exception module from Kazlib, a C library written by
|
||
Kaz Kylheku <kaz[AT]ashi.footprints.net>. Thanks goes to him for his
|
||
well-written library. The Kazlib home page can be found at
|
||
http://users.footprints.net/~kaz/kazlib.html
|