=head1 NAME
-Ethereal - Interactively browse network traffic
+ethereal - Interactively browse network traffic
=head1 SYNOPSYS
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 ]>
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<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 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.
+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, B<pppd logs> (pppdump format), the output from VMS's
+B<TCPIPtrace> utility, and the text output from the B<DBS Etherwatch>
+VMS utility. 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
interfaces; if there are no interfaces, B<Ethereal> reports an error and
doesn't start the capture.
+=item -l
+
+Turns 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
Sets the name of the font used by B<Ethereal> for most text.
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
display that packet's protocol tree and data even if another packet is
selected.
+=item Display:User Specified Decodes
+
+Creates 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
Allows you to see what dynamically loadable dissector plugin modules
=back
+=item Tools:Decode As
+
+If you have a packet selected, this menu item will 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:Protocol Hierarchy Statistics
+
+This shows 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".
+
=head2 WINDOWS
=over 4
=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
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
frame.pkt_len > 012
frame.pkt_len > 0xa
-Boolean values are either true or false. However, a boolean field is
-present in a protocol decode only if its value is true. If the value is
-false, the field is not presence. You can therefore check the truth
-value of a boolean field by simply checking for its existence, that is,
-by naming the field. For example, a token-ring packet's source route
-field is boolean. To find any source-routed packets, the display filter
-is simply:
+Boolean values are either true or false. 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
+ tr.sr == 1
-Non source-routed packets can be found with the negation of that filter:
+Non source-routed packets can be found with:
- ! tr.sr
+ 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:
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.
ipx.srcnet == 0xc0a82c00
-A substring operator also exists. You can check the substring
+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
-Or more simply, since the number of bytes is inherent in the byte-string
-you provide, you can provide just the offset. The previous example can
-be stated like this:
-
- eth.src[0] == 00:00:83
-
-In fact, the only time you need to explicitly provide a length is when
-you don't provide a byte-string, and are comparing fields against
-fields:
-
- fddi.src[0:3] == fddi.dst[0:3]
+If the length of your byte-slice is only one byte, then it is still
+represented in hex, but without the preceding "0x":
-If the length of your byte-string is only one byte, then it must be
-represented in the same way as an unsigned 8-bit integer:
+ llc[3] == aa
- llc[3] == 0xaa
-
-You can use the substring operator on a protocol name, too. And
+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.).
ipx[0:2] == ff:ff
llc[3:1] eq 0xaa
-Offsets for byte-strings can also be negative, in which case the
-negative number indicates the number of bytes from the end of the field
-or protocol that you are testing. Here's how to check the last 4 bytes
-of a frame:
+The following syntax governs slices:
- frame[-4] == 0.1.2.3
+ [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
-or
+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
- xor, ^^ Logical XOR
not, ! Logical NOT
Expressions can be grouped by parentheses as well. The following are
=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@telemation.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 <stefan.raab@nextel.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>
-
-Alain Magloire <alainm@rcsm.ece.mcgill.ca> was kind enough to give his
+ Gilbert Ramirez <gram[AT]xiexie.org>
+ 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>
+ Mark Burton <markb[AT]ordern.com>
+ 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>
+ 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>
+
+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