=head1 NAME
-Ethereal - Interactively browse network traffic
+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<-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<-t> time stamp format ]>
S<[ B<-v> ]>
S<[ B<-w> savefile]>
+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> 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>, B<Sniffer> (compressed or uncompressed),
-Microsoft B<Network Monitor>, AIX's B<iptrace>, B<NetXray>, B<Sniffer
-Pro>, B<Etherpeek>, 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, and B<pppd logs> (pppdump format). There is no need to tell
+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> and B<TokenPeek>,
+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, and traffic capture
+files from Visual Networks' Visual UpTime. 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>
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
+=item -a
+
+Specify a criterion that specifies when B<Tethereal> 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, causes 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
Sets the initial height of the byte view (bottom) pane.
Disables network object name resolution (such as hostname, TCP and UDP port
names).
+=item -N
+
+Turns on name resolving for particular types of addresses and port
+numbers; 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
Sets a preference value, overriding the default value and any value read
=item -r
-Reads packet data from I<file>.
+Reads packet data from I<infile>.
=item -R
=item Capture:Start
-Initiates a live packet capture (see L<"Capture Preferences"> below). A
+Initiates 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
while a live capture is in progress or to enable or disable translation
of addresses to names in the display.
-=item Display:Match Selected
+=item Display:Match
+
+Creates a display filter, or adds to the display filter strip at the
+bottom, a display filter based on the data currently highlighted in the
+protocol tree, and applies 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
-Creates and applies a display filter based on the data that is currently
-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.
+Creates a display filter, or adds to the display filter strip at the
+bottom, a display filter based on the data currently highlighted in the
+protocol tree, but doesn't apply the filter.
=item Display:Colorize Display
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.
+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
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 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.
+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
=back
-=item TCP Stream Preferences
+=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 GUI Preferences
+=item User Interface Preferences
-The I<GUI> page is used to modify small aspects of the GUI to your own
-personal taste:
+The I<User Interface> page is used to modify small aspects of the GUI to
+your own personal taste:
=over 6
=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 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.
=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,
=item Save
-Saves the current filter list in F<$HOME/.ethereal/cfilters> if the list
-of filters being edited is the list of capture filters or in
-F<$HOME/.ethereal/dfilters> if the list of filters being edited is the
-list of display filters.
+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
=back
-=item Capture Preferences
+=item Capture Options
-The I<Capture Preferences> dialog lets you specify various parameters for
+The I<Capture Options> 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, or the name of a FIFO from which to get the 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 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, 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 packet data or a command from which to get the packet data via a
+pipe.
+
+The I<Count:> entry specifies the maximum number of packets to capture.
+0 means Ethereal will not stop capturing at some fixed number of
+captured packets.
+
+The I<File size:> entry specifies the maximum size of a capture file, in
+kilobytes (where a kilobyte is 1000 bytes, not 1024 bytes). 0 means
+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).
+
+The I<Duration:> entry specifies the maximum time over which to capture,
+in seconds. 0 means Ethereal will not stop capturing after some fixed
+time has elapsed.
+
+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 whether the interface is to be
+put in promiscuous mode or not with the I<Capture packets in promiscuous
+mode> check box, can specify whether Ethereal should run in "ring
+buffer" mode with the I<Use ring buffer> check box and can specify the
+number of files to use with the I<Number of files> spin 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, 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.
+translated to names in the display with the I<Enable MAC name
+resolution>, I<Enable network name resolution> and I<Enable transport
+name resolution> check boxes.
=item Display Options
"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 should be translated to names in
-the display.
+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 List> shows the name and version of each dissector plugin
module found on your system. The plugins are searched in the following
-directories: F</usr/share/ethereal/plugins>,
-F</usr/local/share/ethereal/plugins> and F<~/.ethereal/plugins>. 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
+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
ip.dst eq www.mit.edu
ip.src == 192.168.1.1
-IPv4 address can be compared with the same logical relations as numbers:
+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[0:2] == ff:ff
llc[3:1] eq 0xaa
-
The following syntax governs slices:
[i:j] i = start_offset, j = length
[: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
-*end* of the field. Here's how to check the last 4 bytes of a frame:
+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
+ 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:
=head1 FILES
-F</usr/local/etc/ethereal.conf> and F<$HOME/.ethereal/preferences>
-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 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
system-wide preference file.
Note that whenever the preferences are saved by using the I<Save> button
-in the I<Edit:Preferences> dialog box, F<$HOME/.ethereal/preferences>
+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.
-F</etc/ethers> is consulted to correlate 6-byte hardware addresses to
-names. If an address is not found in F</etc/ethers>, the
-F<$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:
+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
-F</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 F</etc/ethers> file, except that each address is
-three bytes instead of six.
-
-F</etc/ipxnets> and F<$HOME/.ethereal/ipxnets> correlate 4-byte IPX
-network numbers to names. The format is the same as the F</etc/ethers>
-file, except that each address if four bytes instead of six.
+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. The format of the file is the same as the
+F<ethers> file, except that each address is three bytes instead of six.
+
+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.
Original Author
-------- ------
- Gerald Combs <gerald@ethereal.com>
+ Gerald Combs <gerald[AT]ethereal.com>
Contributors
------------
- Gilbert Ramirez <gram@xiexie.org>
- Hannes R. Boehm <hannes@boehm.org>
- Mike Hall <mlh@io.com>
- Bobo Rajec <bobo@bsp-consulting.sk>
- Laurent Deniel <deniel@worldnet.fr>
- Don Lafontaine <lafont02@cn.ca>
- Guy Harris <guy@alum.mit.edu>
- Simon Wilkinson <sxw@dcs.ed.ac.uk>
- Joerg Mayer <jmayer@loplof.de>
- Martin Maciaszek <fastjack@i-s-o.net>
- Didier Jorand <Didier.Jorand@alcatel.fr>
- Jun-ichiro itojun Hagino <itojun@iijlab.net>
- Richard Sharpe <sharpe@ns.aus.com>
- John McDermott <jjm@jkintl.com>
- Jeff Jahr <jjahr@shastanets.com>
- Brad Robel-Forrest <bradr@watchguard.com>
- Ashok Narayanan <ashokn@cisco.com>
- Aaron Hillegass <aaron@classmax.com>
- Jason Lango <jal@netapp.com>
- Johan Feyaerts <Johan.Feyaerts@siemens.atea.be>
- Olivier Abad <oabad@cybercable.fr>
- Thierry Andry <Thierry.Andry@advalvas.be>
- Jeff Foster <jjfoste@woodward.com>
- Peter Torvals <petertv@xoommail.com>
- Christophe Tronche <ch.tronche@computer.org>
- Nathan Neulinger <nneul@umr.edu>
- 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>
- Gerrit Gehnen <G.Gehnen@atrie.de>
- Craig Newell <craign@cheque.uq.edu.au>
- Ed Meaney <emeaney@altiga.com>
- Dietmar Petras <DPetras@ELSA.de>
- Fred Reimer <fwr@ga.prestige.net>
- Florian Lohoff <flo@rfc822.org>
- Jochen Friedrich <jochen+ethereal@scram.de>
- Paul Welchinski <paul.welchinski@telusplanet.net>
- Doug Nazar <nazard@dragoninc.on.ca>
- Andreas Sikkema <andreas.sikkema@philips.com>
- Mark Muhlestein <mmm@netapp.com>
- Graham Bloice <graham.bloice@trihedral.com>
- Ralf Schneider <ralf.schneider@alcatel.se>
- Yaniv Kaul <ykaul@netvision.net.il>
- Paul Ionescu <ipaul@romsys.ro>
- Mark Burton <markb@ordern.com>
- Stefan Raab <sraab@cisco.com>
- Mark Clayton <clayton@shore.net>
- Michael Rozhavsky <mike@tochna.technion.ac.il>
- Dug Song <dugsong@monkey.org>
- Michael Tuexen <Michael.Tuexen@icn.siemens.de>
- Bruce Korb <bkorb@sco.com>
- Jose Pedro Oliveira <jpo@di.uminho.pt>
- David Frascone <dave@frascone.com>
- Peter Kjellerstedt <pkj@axis.com>
- Phil Techau <phil_t@altavista.net>
- Wes Hardaker <wjhardaker@ucdavis.edu>
- Robert Tsai <rtsai@netapp.com>
- Craig Metz <cmetz@inner.net>
- Per Flock <per.flock@axis.com>
- Jack Keane <jkeane@OpenReach.com>
- Brian Wellington <bwelling@xbill.org>
- Santeri Paavolainen <santtu@ssh.com>
- Ulrich Kiermayr <uk@ap.univie.ac.at>
- Neil Hunter <neil.hunter@energis-squared.com>
- Ralf Holzer <ralf@well.com>
- Craig Rodrigues <rodrigc@mediaone.net>
- Ed Warnicke <hagbard@physics.rutgers.edu>
- Johan Jorgensen <johan.jorgensen@axis.com>
- Frank Singleton <frank.singleton@ericsson.com>
- Kevin Shi <techishi@ms22.hinet.net>
- Mike Frisch <mfrisch@saturn.tlug.org>
- Burke Lau <burke_lau@agilent.com>
- Martti Kuparinen <martti.kuparinen@nomadiclab.com>
- David Hampton <dhampton@mac.com>
- Kent Engström <kent@unit.liu.se>
- Ronnie Sahlberg <rsahlber@bigpond.net.au>
- Alexandre P. Ferreira <alexandref@spliceip.com.br>
- Simharajan Srishylam <Simharajan.Srishylam@netapp.com>
- Greg Kilfoyle <gregk@redback.com>
- James E. Flemer <jflemer@acm.jhu.edu>
- Peter Lei <peterlei@cisco.com>
- Thomas Gimpel <thomas.gimpel@ferrari.de>
- Albert Chin <china@thewrittenword.com>
- Charles Levert <charles@comm.polymtl.ca>
- Todd Sabin <tas@webspan.net>
- Eduardo Pérez Ureta <eperez@dei.inf.uc3m.es>
- Martin Thomas <martin_a_thomas@yahoo.com>
- Hartmut Mueller <hartmut@wendolene.ping.de>
- Michal Melerowicz <Michal.Melerowicz@nokia.com>
- Hannes Gredler <hannes@juniper.net>
- Inoue <inoue@ainet.or.jp>
- Olivier Biot <Olivier.Biot@siemens.atea.be>
- Patrick Wolfe <pjw@zocalo.cellular.ameritech.com>
- Martin Held <Martin.Held@icn.siemens.de>
- Riaan Swart <rswart@cs.sun.ac.za>
- Christian Lacunza <celacunza@gmx.net>
- Michael Rozhavsky <mike@tochna.technion.ac.il>
- Scott Renfro <scott@renfro.org>
- Juan Toledo <toledo@users.sourceforge.net>
- Jean-Christian Pennetier <jeanchristian.pennetier@rd.francetelecom.fr>
- Jian Yu <bgp4news@yahoo.com>
- Eran Mann <emann@opticalaccess.com>
- Andy Hood <ahood@westpac.com.au>
- Randy McEoin <rmceoin@pe.net>
-
-Alain Magloire <alainm@rcsm.ece.mcgill.ca> was kind enough to give his
+ Gilbert Ramirez <gram[AT]alumni.rice.edu>
+ Hannes R. Boehm <hannes[AT]boehm.org>
+ Mike Hall <mlh[AT]io.com>
+ 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]iijlab.net>
+ 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]cybercable.fr>
+ Thierry Andry <Thierry.Andry[AT]advalvas.be>
+ Jeff Foster <jjfoste[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]altiga.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 <ipaul[AT]romsys.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]icn.siemens.de>
+ 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]saturn.tlug.org>
+ Burke Lau <burke_lau[AT]agilent.com>
+ Martti Kuparinen <martti.kuparinen[AT]iki.fi>
+ David Hampton <dhampton[AT]mac.com>
+ Kent Engström <kent[AT]unit.liu.se>
+ Ronnie Sahlberg <rsahlber[AT]bigpond.net.au>
+ Alexandre P. Ferreira <alexandref[AT]spliceip.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>
+ Michael Rozhavsky <mike[AT]tochna.technion.ac.il>
+ 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 <jfmule[AT]clarent.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 <mmilgram[AT]arrayinc.com>
+ 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]anfdata.cz>
+ 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ña <rbarroetavena[AT]veufort.com>
+ Alan Harrison <alanharrison[AT]mail.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@promus.com> gave permission for his dumpit() hex-dump
+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
git.samba.org / obnox / wireshark / wip.git / blobdiff