Better update for the FAQ. We can now use the URL

http://www.wireshark.org/faq_plain.html, which doesn't have any images
or menus.

svn path=/trunk/; revision=18382

1 files changed, 1156 insertions, 1899 deletions

diff --git a/FAQ b/FAQ
index a8db25ba04..a76ee0a1de 100644
--- a/FAQ
+++ b/FAQ
@@ -11,202 +11,192 @@
 
 1. General Questions:
 
-   1.1 Where can I get help?
+   1.1 What is Wireshark?
 
-   1.2 How much does Ethereal cost?
+   1.2 What's up with the name change? Is Wireshark a fork?
 
-   1.3 Can I use Ethereal commercially?
+   1.3 Where can I get help?
 
-   1.4 Can I use Ethereal as part of my commercial product?
+   1.4 How much does Wireshark cost?
 
-   1.5 What protocols are currently supported?
+   1.5 Can I use Wireshark commercially?
 
-   1.6 Are there any plans to support {your favorite protocol}?
+   1.6 Can I use Wireshark as part of my commercial product?
 
-   1.7 Can Ethereal read capture files from {your favorite network analyzer}?
+   1.7 What protocols are currently supported?
 
-   1.8 What devices can Ethereal use to capture packets?
+   1.8 Are there any plans to support {your favorite protocol}?
 
-   1.9 How do you pronounce Ethereal? Where did the name come from?
+   1.9 Can Wireshark read capture files from {your favorite network
+   analyzer}?
 
-   1.10 Does Ethereal work on Windows Me? 
+   1.10 What devices can Wireshark use to capture packets?
 
-   1.11 Does Ethereal work on Windows XP? 
+   1.11 Does Wireshark work on Windows Me? 
 
-2. Downloading Ethereal:
+   1.12 Does Wireshark work on Windows XP? 
 
-   2.1 Why do I get an error when I try to run the Win32 installer?
+2. Downloading Wireshark:
 
-   2.2 Why can't I get to the WinPcap Web site in order to download WinPcap?
+   2.1 Why do I get an error when I try to run the Win32 installer?
 
-3. Installing Ethereal:
+3. Installing Wireshark:
 
-   3.1 I installed an Ethereal RPM; why did it install TShark but not
-   Ethereal?
+   3.1 I installed the Wireshark RPM (or other package); why did it
+   install TShark but not Wireshark?
 
-4. Building Ethereal:
+4. Building Wireshark:
 
-   4.1 I have libpcap installed; why did the configure script not find pcap.h
-   or bpf.h?
+   4.1 I have libpcap installed; why did the configure script not find
+   pcap.h or bpf.h?
 
    4.2 Why do I get the error 
 
-     dftest_DEPENDENCIES was already defined in condition TRUE, which implies
-     condition HAVE_PLUGINS_TRUE
+     dftest_DEPENDENCIES was already defined in condition TRUE, which
+     implies condition HAVE_PLUGINS_TRUE
 
-   when I try to build Ethereal from SVN or a SVN snapshot?
+   when I try to build Wireshark from SVN or a SVN snapshot?
 
    4.3 Why does the linker fail with a number of "Output line too long."
-   messages followed by linker errors when I try to buil Ethereal? 
+   messages followed by linker errors when I try to buil Wireshark? 
 
-   4.4 When I try to build Ethereal on Solaris, why does the link fail
+   4.4 When I try to build Wireshark on Solaris, why does the link fail
    complaining that plugin_list is undefined? 
 
-   4.5 When I try to build Ethereal on Windows, why does the build fail because
-   of conflicts between winsock.h and winsock2.h? 
-
-5. Starting Ethereal:
-
-   5.1 Why does Ethereal crash with a Bus Error when I try to run it on Solaris
-   8?
+   4.5 When I try to build Wireshark on Windows, why does the build fail
+   because of conflicts between winsock.h and winsock2.h? 
 
-   5.2 When I run TShark with the "-x" option, why does it crash with an
-   error 
+5. Starting Wireshark:
 
-     "** ERROR **: file print.c: line 691 (print_line): should not be reached.
+   5.1 Why does Wireshark crash with a Bus Error when I try to run it on
+   Solaris 8?
 
-   5.3 When I run Ethereal on Windows NT, why does it die with a Dr. Watson
-   error, reporting an "Integer division by zero" exception, when I start it?
+   5.2 When I run Wireshark on Windows NT, why does it die with a Dr.
+   Watson error, reporting an "Integer division by zero" exception, when
+   I start it?
 
-   5.4 When I try to run Ethereal, why does it complain about
+   5.3 When I try to run Wireshark, why does it complain about
    sprint_realloc_objid being undefined?
 
-   5.5 When I try to run Ethereal on Windows, why does it fail to run with a
-   complaint that it can't find packet.dll?
-
-   5.6 Why do I get the error 
-
-     Gdk-ERROR **: Palettized display (256-colour) mode not supported on
-     Windows.
-     aborting....
+   5.4 When I try to run Wireshark on Windows, why does it fail to run
+   with a complaint that it can't find packet.dll?
 
-   when I try to run Ethereal on Windows?
-
-   5.7 I've installed Ethereal from Fink on Mac OS X; why is it very slow to
-   start up? 
+   5.5 I've installed Wireshark from Fink on Mac OS X; why is it very
+   slow to start up? 
 
 6. Crashes and other fatal errors:
 
-   6.1 When I run Ethereal, why do I get an error 
-
-     Gtk-CRITICAL **: file gtkwindow.c: line 3107 (gtk_window_resize):
-     assertion `height > 0' failed.
-
-   6.2 I have an XXX network card on my machine; if I try to capture on it, why
-   does my machine crash or reset itself? 
+   6.1 I have an XXX network card on my machine; if I try to capture on
+   it, why does my machine crash or reset itself? 
 
-   6.3 Why does my machine crash or reset itself when I select "Start" from the
-   "Capture" menu or select "Preferences" from the "Edit" menu? 
+   6.2 Why does my machine crash or reset itself when I select "Start"
+   from the "Capture" menu or select "Preferences" from the "Edit" menu? 
 
 7. Capturing packets:
 
-   7.1 When I use Ethereal to capture packets, why do I see only packets to and
-   from my machine, or not see all the traffic I'm expecting to see from or to
-   the machine I'm trying to monitor?
+   7.1 When I use Wireshark to capture packets, why do I see only packets
+   to and from my machine, or not see all the traffic I'm expecting to
+   see from or to the machine I'm trying to monitor?
 
-   7.2 When I capture with Ethereal, why can't I see any TCP packets other than
-   packets to and from my machine, even though another analyzer on the network
-   sees those packets?
+   7.2 When I capture with Wireshark, why can't I see any TCP packets
+   other than packets to and from my machine, even though another
+   analyzer on the network sees those packets?
 
    7.3 Why am I only seeing ARP packets when I try to capture traffic?
 
    7.4 Why am I not seeing any traffic when I try to capture traffic?
 
-   7.5 Can Ethereal capture on (my T1/E1 line, SS7 links, etc.)? 
+   7.5 Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)? 
 
    7.6 How do I put an interface into promiscuous mode?
 
-   7.7 I can set a display filter just fine; why don't capture filters work? 
+   7.7 I can set a display filter just fine; why don't capture filters
+   work? 
 
-   7.8 I'm entering valid capture filters; why do I still get "parse error"
-   errors?
+   7.8 I'm entering valid capture filters; why do I still get "parse
+   error" errors?
 
    7.9 How can I capture packets with CRC errors? 
 
    7.10 How can I capture entire frames, including the FCS? 
 
-   7.11 I'm capturing packets on a machine on a VLAN; why don't the packets I'm
-   capturing have VLAN tags? 
+   7.11 I'm capturing packets on a machine on a VLAN; why don't the
+   packets I'm capturing have VLAN tags? 
 
-   7.12 Why does Ethereal hang after I stop a capture? 
+   7.12 Why does Wireshark hang after I stop a capture? 
 
 8. Capturing packets on Windows:
 
-   8.1 I'm running Ethereal on Windows; why does some network interface on my
-   machine not show up in the list of interfaces in the "Interface:" field in
-   the dialog box popped up by "Capture->Start", and/or why does Ethereal give
-   me an error if I try to capture on that interface? 
+   8.1 I'm running Wireshark on Windows; why does some network interface
+   on my machine not show up in the list of interfaces in the
+   "Interface:" field in the dialog box popped up by "Capture->Start",
+   and/or why does Wireshark give me an error if I try to capture on that
+   interface? 
 
-   8.2 I'm running Ethereal on Windows; why do no network interfaces show up in
-   the list of interfaces in the "Interface:" field in the dialog box popped up
-   by "Capture->Start"? 
+   8.2 I'm running Wireshark on Windows; why do no network interfaces
+   show up in the list of interfaces in the "Interface:" field in the
+   dialog box popped up by "Capture->Start"? 
 
-   8.3 I'm running Ethereal on Windows; why doesn't my serial port/ADSL
-   modem/ISDN modem show up in the list of interfaces in the "Interface:" field
-   in the dialog box popped up by "Capture->Start"? 
+   8.3 I'm running Wireshark on Windows; why doesn't my serial port/ADSL
+   modem/ISDN modem show up in the list of interfaces in the "Interface:"
+   field in the dialog box popped up by "Capture->Start"? 
 
-   8.4 I'm running Ethereal on Windows NT 4.0/Windows 2000/Windows XP/Windows
-   Server 2003; my machine has a PPP (dial-up POTS, ISDN, etc.) interface, and
-   it shows up in the "Interface" item in the "Capture Options" dialog box. Why
-   can no packets be sent on or received from that network while I'm trying to
-   capture traffic on that interface?
+   8.4 I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows
+   XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN,
+   etc.) interface, and it shows up in the "Interface" item in the
+   "Capture Options" dialog box. Why can no packets be sent on or
+   received from that network while I'm trying to capture traffic on that
+   interface?
 
-   8.5 I'm running Ethereal on Windows 95/98/Me, on a machine with more than
-   one network adapter of the same type; why does Ethereal show all of those
-   adapters with the same name, not letting me use any of those adapters other
-   than the first one?
+   8.5 I'm running Wireshark on Windows 95/98/Me, on a machine with more
+   than one network adapter of the same type; why does Wireshark show all
+   of those adapters with the same name, not letting me use any of those
+   adapters other than the first one?
 
-   8.6 I'm running Ethereal on Windows; why am I not seeing any traffic being
-   sent by the machine running Ethereal?
+   8.6 I'm running Wireshark on Windows; why am I not seeing any traffic
+   being sent by the machine running Wireshark?
 
-   8.7 When I capture on Windows in promiscuous mode, I can see packets other
-   than those sent to or from my machine; however, those packets show up with a
-   "Short Frame" indication, unlike packets to or from my machine. What should
-   I do to arrange that I see those packets in their entirety? 
+   8.7 When I capture on Windows in promiscuous mode, I can see packets
+   other than those sent to or from my machine; however, those packets
+   show up with a "Short Frame" indication, unlike packets to or from my
+   machine. What should I do to arrange that I see those packets in their
+   entirety? 
 
-   8.8 I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why are
-   the time stamps on packets wrong? 
+   8.8 I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why
+   are the time stamps on packets wrong? 
 
-   8.9 I'm trying to capture 802.11 traffic on Windows; why am I not seeing any
-   packets? 
+   8.9 I'm trying to capture 802.11 traffic on Windows; why am I not
+   seeing any packets? 
 
    8.10 I'm trying to capture 802.11 traffic on Windows; why am I seeing
-   packets received by the machine on which I'm capturing traffic, but not
-   packets sent by that machine? 
+   packets received by the machine on which I'm capturing traffic, but
+   not packets sent by that machine? 
 
    8.11 I'm trying to capture Ethernet VLAN traffic on Windows, and I'm
-   capturing on a "raw" Ethernet device rather than a "VLAN interface", so that
-   I can see the VLAN headers; why am I seeing packets received by the machine
-   on which I'm capturing traffic, but not packets sent by that machine? 
+   capturing on a "raw" Ethernet device rather than a "VLAN interface",
+   so that I can see the VLAN headers; why am I seeing packets received
+   by the machine on which I'm capturing traffic, but not packets sent by
+   that machine? 
 
 9. Capturing packets on UN*Xes:
 
-   9.1 I'm running Ethereal on a UNIX-flavored OS; why does some network
+   9.1 I'm running Wireshark on a UNIX-flavored OS; why does some network
    interface on my machine not show up in the list of interfaces in the
-   "Interface:" field in the dialog box popped up by "Capture->Start", and/or
-   why does Ethereal give me an error if I try to capture on that interface? 
+   "Interface:" field in the dialog box popped up by "Capture->Start",
+   and/or why does Wireshark give me an error if I try to capture on that
+   interface? 
 
-   9.2 I'm running Ethereal on a UNIX-flavored OS; why do no network interfaces
-   show up in the list of interfaces in the "Interface:" field in the dialog
-   box popped up by "Capture->Start"? 
+   9.2 I'm running Wireshark on a UNIX-flavored OS; why do no network
+   interfaces show up in the list of interfaces in the "Interface:" field
+   in the dialog box popped up by "Capture->Start"? 
 
-   9.3 I'm capturing packets on Linux; why do the time stamps have only 100ms
-   resolution, rather than 1us resolution?
+   9.3 I'm capturing packets on Linux; why do the time stamps have only
+   100ms resolution, rather than 1us resolution?
 
 10. Capturing packets on wireless LANs:
 
-   10.1 How can I capture raw 802.11 frames, including non-data (management,
-   beacon) frames? 
+   10.1 How can I capture raw 802.11 frames, including non-data
+   (management, beacon) frames? 
 
    10.2 How do I capture on an 802.11 device in monitor mode?
 
@@ -214,873 +204,151 @@
 
    11.1 Why am I seeing lots of packets with incorrect TCP checksums?
 
-   11.2 I've just installed Ethereal, and the traffic on my local LAN is
+   11.2 I've just installed Wireshark, and the traffic on my local LAN is
    boring. Where can I find more interesting captures? 
 
-   11.3 Why doesn't Ethereal correctly identify RTP packets? It shows them only
-   as UDP.
+   11.3 Why doesn't Wireshark correctly identify RTP packets? It shows
+   them only as UDP.
 
-   11.4 Why doesn't Ethereal show Yahoo Messenger packets in captures that
-   contain Yahoo Messenger traffic?
+   11.4 Why doesn't Wireshark show Yahoo Messenger packets in captures
+   that contain Yahoo Messenger traffic?
 
 12. Filtering traffic:
 
-   12.1 I saved a filter and tried to use its name to filter the display; why
-   do I get an "Unexpected end of filter string" error?
+   12.1 I saved a filter and tried to use its name to filter the display;
+   why do I get an "Unexpected end of filter string" error?
 
-   12.2 How can I search for, or filter, packets that have a particular string
-   anywhere in them? 
+   12.2 How can I search for, or filter, packets that have a particular
+   string anywhere in them? 
 
    12.3 How do I filter a capture to see traffic for virus XXX? 
 
 1. General Questions
 
-   Q 1.1: Where can I get help?
+   Q 1.1: What is Wireshark?
+
+   A: Gerald Combs, the creator of Ethereal®, has initiated the Wireshark
+   network protocol analyzer project, a successor to Ethereal®. The
+   Ethereal® core developer team has moved with Gerald to the Wireshark
+   project. Consequently, Wireshark is positioned to be the world's most
+   popular network protocol analyzer. It has a rich and powerful feature
+   set, and runs on most computing platforms including Windows, OS X, and
+   Linux. It is freely available as open source, and is released under
+   the GNU General Public License.
+
+   For more information, please see the About Wireshark page.
+
+   Q 1.2: What's up with the name change? Is Wireshark a fork?
+
+   A: In May of 2006, the original author of Ethereal® went to work for
+   CACE Technologies (best known for WinPcap). At that time he started
+   the Wireshark open-source project.
+
+   Wireshark is almost (but not quite) a fork. Normally a "fork" of an
+   open source project results in two names, web sites, development
+   teams, support infrastructures, etc. This is the case with Wireshark
+   except for one notable exception -- every member of the core
+   development team is now working on Wireshark.
+
+   Q 1.3: Where can I get help?
 
    A: Community support is available on the wireshark-users mailing list.
-   Subscription information and archives for all of Ethereal's mailing lists
-   can be found at http://www.wireshark.org/lists. An IRC channel dedicated to
-   Ethereal can be found at irc://irc.freenode.net/ethereal.
+   Subscription information and archives for all of Wireshark's mailing
+   lists can be found at http://www.wireshark.org/lists. An IRC channel
+   dedicated to Wireshark can be found at
+   irc://irc.freenode.net/ethereal.
 
-   Commercial support, training, and development services are available from
-   Ethereal Software.
+   Commercial support, training, and development services are available
+   from CACE Technologies.
 
-   Q 1.2: How much does Ethereal cost?
+   Q 1.4: How much does Wireshark cost?
 
-   A: Wireshark is "free software"; you can download it without paying any
-   license fee. The version of Ethereal you download isn't a "demo" version,
-   with limitations not present in a "full" version; it is the full version.
+   A: Wireshark is "free software"; you can download it without paying
+   any license fee. The version of Wireshark you download isn't a "demo"
+   version, with limitations not present in a "full" version; it is the
+   full version.
 
    The license under which Wireshark is issued is the GNU General Public
    License. See the GNU GPL FAQ for some more information.
 
-   Q 1.3: Can I use Ethereal commercially?
-
-   A: Yes, if, for example, you mean "I work for a commercial organization; can
-   I use Ethereal to capture and analyze network traffic in our company's
-   networks or in our customer's networks?"
-
-   If you mean "Can I use Ethereal as part of my commercial product?", see the
-   next entry in the FAQ.
-
-   Q 1.4: Can I use Ethereal as part of my commercial product?
-
-   A: As noted, Wireshark is licensed under the GNU General Public License. The
-   GPL imposes conditions on your use of GPL'ed code in your own products; you
-   cannot, for example, make a "derived work" from Ethereal, by making
-   modifications to it, and then sell the resulting derived work and not allow
-   recipients to give away the resulting work. You must also make the changes
-   you've made to the Wireshark source available to all recipients of your
-   modified version; those changes must also be licensed under the terms of the
-   GPL. See the GPL FAQ for more details; in particular, note the answer to the
-   question about modifying a GPLed program and selling it commercially, and
-   the question about linking GPLed code with other code to make a proprietary
-   program.
-
-   You can combine a GPLed program such as Ethereal and a commercial program as
-   long as they communicate "at arm's length", as per this item in the GPL FAQ.
-
-   Q 1.5: What protocols are currently supported?
-
-   A: There are currently 750 supported protocols and media, listed below.
-   Descriptions can be found in the ethereal(1) man page.
-
-            3Com XNS Encapsulation
-            3GPP2 A11
-            3com Network Jack
-            802.1Q Virtual LAN
-            802.1X Authentication
-            AAL type 2 signalling protocol (Q.2630)
-            ACN
-            AFS (4.0) Replication Server call declarations
-            AIM Administrative
-            AIM Advertisements
-            AIM Buddylist Service
-            AIM Chat Navigation
-            AIM Chat Service
-            AIM Directory Search
-            AIM E-mail
-            AIM Generic Service
-            AIM ICQ
-            AIM Invitation Service
-            AIM Location
-            AIM Messaging
-            AIM OFT
-            AIM Popup
-            AIM Privacy Management Service
-            AIM Server Side Info
-            AIM Server Side Themes
-            AIM Signon
-            AIM Statistics
-            AIM Translate
-            AIM User Lookup
-            ANSI A-I/F BSMAP
-            ANSI A-I/F DTAP
-            ANSI IS-637-A (SMS) Teleservice Layer
-            ANSI IS-637-A (SMS) Transport Layer
-            ANSI IS-683-A (OTA (Mobile))
-            ANSI IS-801 (Location Services (PLD))
-            ANSI Mobile Application Part
-            AOL Instant Messenger
-            ARCNET
-            ASN.1 decoding
-            ATAoverEthernet
-            ATM
-            ATM AAL1
-            ATM AAL3/4
-            ATM LAN Emulation
-            ATM OAM AAL
-            AVS WLAN Capture header
-            AX/4000 Test Block
-            Active Directory Setup
-            Ad hoc On-demand Distance Vector Routing Protocol
-            Adaptive Multi-Rate
-            Address Resolution Protocol
-            AgentX
-            Aggregate Server Access Protocol
-            Alert Standard Forum
-            Alteon - Transparent Proxy Cache Protocol
-            Andrew File System (AFS)
-            Apache JServ Protocol v1.3
-            Apple Filing Protocol
-            Apple IP-over-IEEE 1394
-            AppleTalk Session Protocol
-            AppleTalk Transaction Protocol packet
-            Appletalk Address Resolution Protocol
-            Application Configuration Access Protocol
-            Art-Net
-            Aruba - Aruba Discovery Protocol
-            Async data over ISDN (V.120)
-            Asynchronous Layered Coding
-            AudioCodes Trunk Trace
-            Authentication Header
-            BACnet Virtual Link Control
-            BEA Tuxedo
-            BSSAP/BSAP
-            Banyan Vines ARP
-            Banyan Vines Echo
-            Banyan Vines Fragmentation Protocol
-            Banyan Vines ICP
-            Banyan Vines IP
-            Banyan Vines IPC
-            Banyan Vines LLC
-            Banyan Vines RTP
-            Banyan Vines SPP
-            Base Station Subsystem GPRS Protocol
-            Basic Encoding Rules (ASN.1 X.690)
-            Bearer Independent Call Control
-            Bi-directional Fault Detection Control Message
-            BitTorrent
-            Blocks Extensible Exchange Protocol
-            Blubster/Piolet MANOLITO Protocol
-            Boardwalk
-            Boot Parameters
-            Bootstrap Protocol
-            Border Gateway Protocol
-            Building Automation and Control Network APDU
-            Building Automation and Control Network NPDU
-            CBAPhysicalDevice
-            CCSDS
-            CDS Clerk Server Calls
-            CSM_ENCAPS
-            Camel
-            Cast Client Control Protocol
-            Certificate Management Protocol
-            Certificate Request Message Format
-            Check Point High Availability Protocol
-            Checkpoint FW-1
-            Cisco Auto-RP
-            Cisco Discovery Protocol
-            Cisco Group Management Protocol
-            Cisco HDLC
-            Cisco Hot Standby Router Protocol
-            Cisco ISL
-            Cisco Interior Gateway Routing Protocol
-            Cisco NetFlow
-            Cisco SLARP
-            Cisco Session Management
-            Cisco Wireless Layer 2
-            Clearcase NFS
-            CoSine IPNOS L2 debug output
-            Common Image Generator Interface
-            Common Industrial Protocol
-            Common Open Policy Service
-            Common Unix Printing System (CUPS) Browsing Protocol
-            Compressed Data Type
-            Compuserve GIF
-            Computer Interface to Message Distribution
-            Configuration Test Protocol (loopback)
-            Connectionless Lightweight Directory Access Protocol
-            Coseventcomm Dissector Using GIOP API
-            Cosnaming Dissector Using GIOP API
-            Cross Point Frame Injector
-            Cryptographic Message Syntax
-            DCE Distributed Time Service Local Server
-            DCE Distributed Time Service Provider
-            DCE Name Service
-            DCE RPC
-            DCE Security ID Mapper
-            DCE/DFS BUDB
-            DCE/RPC BOS Server
-            DCE/RPC BUTC
-            DCE/RPC CDS Solicitation
-            DCE/RPC Conversation Manager
-            DCE/RPC Directory Acl Interface
-            DCE/RPC Endpoint Mapper
-            DCE/RPC Endpoint Mapper v4
-            DCE/RPC FLDB
-            DCE/RPC FLDB UBIK TRANSFER
-            DCE/RPC FLDB UBIKVOTE
-            DCE/RPC ICL RPC
-            DCE/RPC Kerberos V
-            DCE/RPC NCS 1.5.1 Local Location Broker
-            DCE/RPC Operations between registry server replicas
-            DCE/RPC Prop Attr
-            DCE/RPC RS_ACCT
-            DCE/RPC RS_BIND
-            DCE/RPC RS_MISC
-            DCE/RPC RS_PROP_ACCT
-            DCE/RPC RS_UNIX
-            DCE/RPC Registry Password Management
-            DCE/RPC Registry Server Attributes Schema
-            DCE/RPC Registry server propagation interface - ACLs.
-            DCE/RPC Registry server propagation interface - PGO items
-            DCE/RPC Registry server propagation interface - properties and poli
-cies
-            DCE/RPC Remote Management
-            DCE/RPC Repserver Calls
-            DCE/RPC TokenServer Calls
-            DCE/RPC UpServer
-            DCOM
-            DCOM IDispatch
-            DCOM IRemoteActivation
-            DCOM OXID Resolver
-            DEC DNA Routing Protocol
-            DEC Spanning Tree Protocol
-            DFS Calls
-            DG Gryphon Protocol
-            DHCP Failover
-            DHCPv6
-            DICOM
-            DLT_USER_A
-            DLT_USER_B
-            DLT_USER_C
-            DLT_USER_D
-            DNS Control Program Server
-            DOCSIS 1.1
-            DOCSIS Appendix C TLV's
-            DOCSIS Baseline Privacy Key Management Attributes
-            DOCSIS Baseline Privacy Key Management Request
-            DOCSIS Baseline Privacy Key Management Response
-            DOCSIS Dynamic Service Addition Acknowledge
-            DOCSIS Dynamic Service Addition Request
-            DOCSIS Dynamic Service Addition Response
-            DOCSIS Dynamic Service Change Acknowledgement
-            DOCSIS Dynamic Service Change Request
-            DOCSIS Dynamic Service Change Response
-            DOCSIS Dynamic Service Delete Request
-            DOCSIS Dynamic Service Delete Response
-            DOCSIS Initial Ranging Message
-            DOCSIS Mac Management
-            DOCSIS Range Request Message
-            DOCSIS Ranging Response
-            DOCSIS Registration Acknowledge
-            DOCSIS Registration Requests
-            DOCSIS Registration Responses
-            DOCSIS Upstream Bandwidth Allocation
-            DOCSIS Upstream Channel Change Request
-            DOCSIS Upstream Channel Change Response
-            DOCSIS Upstream Channel Descriptor
-            DOCSIS Upstream Channel Descriptor Type 29
-            DOCSIS Vendor Specific Endodings
-            DPNSS/DASS2-User Adaptation Layer
-            DRSUAPI
-            Data
-            Data Link SWitching
-            Data Stream Interface
-            Datagram Congestion Control Protocol
-            Datagram Delivery Protocol
-            Decompressed SigComp message as raw text
-            Diameter Protocol
-            Digital Audio Access Protocol
-            Distance Vector Multicast Routing Protocol
-            Distcc Distributed Compiler
-            Distributed Checksum Clearinghouse Protocol
-            Distributed Interactive Simulation
-            Distributed Network Protocol 3.0
-            Domain Name Service
-            Dublin Core Metadata (DC)
-            Dynamic DNS Tools Protocol
-            Dynamic Trunking Protocol
-            ENTTEC
-            Echo
-            Encapsulating Security Payload
-            Endpoint Name Resolution Protocol
-            Enhanced Interior Gateway Routing Protocol
-            EtherNet/IP (Industrial Protocol)
-            Etheric
-            Ethernet
-            Ethernet over IP
-            Extended Security Services
-            Extensible Authentication Protocol
-            Extreme Discovery Protocol
-            FC Extended Link Svc
-            FC Fabric Configuration Server
-            FCIP
-            FTP Data
-            FTServer Operations
-            Fiber Distributed Data Interface
-            Fibre Channel
-            Fibre Channel Common Transport
-            Fibre Channel Fabric Zone Server
-            Fibre Channel Name Server
-            Fibre Channel Protocol for SCSI
-            Fibre Channel SW_ILS
-            Fibre Channel Security Protocol
-            Fibre Channel Single Byte Command
-            File Transfer Protocol (FTP)
-            Financial Information eXchange Protocol
-            Frame
-            Frame Relay
-            G.723
-            GARP Multicast Registration Protocol
-            GARP VLAN Registration Protocol
-            GPRS Network service
-            GPRS Tunneling Protocol
-            GSM A-I/F BSSMAP
-            GSM A-I/F DTAP
-            GSM A-I/F RP
-            GSM Mobile Application
-            GSM SMS TPDU (GSM 03.40)
-            GSM Short Message Service User Data
-            GSM_SS
-            GSS-API Generic Security Service Application Program Interface
-            General Inter-ORB Protocol
-            Generic Routing Encapsulation
-            Gnutella Protocol
-            H.248 MEGACO
-            H.324/CCSRL
-            H.324/SRP
-            H221NonStandard
-            H235-SECURITY-MESSAGES
-            H323-MESSAGES
-            HP Extended Local-Link Control
-            HP Remote Maintenance Protocol
-            HP Switch Protocol
-            HP-UX Network Tracing and Logging
-            Hummingbird NFS Daemon
-            HyperSCSI
-            Hypertext Transfer Protocol
-            ICBAAccoCallback
-            ICBAAccoCallback2
-            ICBAAccoMgt
-            ICBAAccoMgt2
-            ICBAAccoServer
-            ICBAAccoServer2
-            ICBAAccoServerSRT
-            ICBAAccoSync
-            ICBABrowse
-            ICBABrowse2
-            ICBAGroupError
-            ICBAGroupErrorEvent
-            ICBALogicalDevice
-            ICBALogicalDevice2
-            ICBAPersist
-            ICBAPersist2
-            ICBAPhysicalDevice
-            ICBAPhysicalDevice2
-            ICBAPhysicalDevicePC
-            ICBAPhysicalDevicePCEvent
-            ICBARTAuto
-            ICBARTAuto2
-            ICBAState
-            ICBAStateEvent
-            ICBASystemProperties
-            ICBATime
-            ICQ Protocol
-            IEEE 802.11 Radiotap Capture header
-            IEEE 802.11 wireless LAN
-            IEEE 802.11 wireless LAN management frame
-            IEEE802a OUI Extended Ethertype
-            ILMI
-            IP Device Control (SS7 over IP)
-            IP Over FC
-            IP Payload Compression
-            IP Virtual Services Sync Daemon
-            IPX Message
-            IPX Routing Information Protocol
-            IPX WAN
-            IRemUnknown
-            IRemUnknown2
-            ISDN
-            ISDN Q.921-User Adaptation Layer
-            ISDN User Part
-            ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
-            ISO 8073 COTP Connection-Oriented Transport Protocol
-            ISO 8327-1 OSI Session Protocol
-            ISO 8473 CLNP ConnectionLess Network Protocol
-            ISO 8571 FTAM
-            ISO 8602 CLTP ConnectionLess Transport Protocol
-            ISO 8650-1 OSI Association Control Service
-            ISO 8823 OSI Presentation Protocol
-            ISO 9542 ESIS Routeing Information Exchange Protocol
-            ISUP Thin Protocol
-            ISystemActivator ISystemActivator Resolver
-            ITU M.3100 Generic Network Information Model
-            ITU-T E.164 number
-            ITU-T Recommendation H.223
-            ITU-T Recommendation H.261
-            ITU-T Recommendation H.263
-            ITU-T Recommendation H.263 RTP Payload header (RFC2190)
-            InMon sFlow
-            Information Access Protocol
-            Init shutdown service
-            Intel ANS probe
-            Intelligent Network Application Protocol
-            Intelligent Platform Management Interface
-            Inter-Access-Point Protocol
-            Inter-Asterisk eXchange v2
-            InterSwitch Message Protocol
-            Interbase
-            Internet Cache Protocol
-            Internet Communications Engine Protocol
-            Internet Content Adaptation Protocol
-            Internet Control Message Protocol
-            Internet Control Message Protocol v6
-            Internet Group Management Protocol
-            Internet Group membership Authentication Protocol
-            Internet Message Access Protocol
-            Internet Printing Protocol
-            Internet Protocol
-            Internet Protocol Version 6
-            Internet Relay Chat
-            Internet Security Association and Key Management Protocol
-            Internetwork Datagram Protocol
-            Internetwork Packet eXchange
-            IrCOMM Protocol
-            IrDA Link Access Protocol
-            IrDA Link Management Protocol
-            IuUP
-            JPEG File Interchange Format
-            JXTA Connection Welcome Message
-            JXTA Message
-            JXTA Message Framing
-            JXTA P2P
-            JXTA UDP
-            Jabber XML Messaging
-            Java RMI
-            Java Serialization
-            Juniper
-            K12xx
-            Kerberized Internet Negotiation of Key
-            Kerberos
-            Kerberos Administration
-            Kerberos v4
-            Kernel Lock Manager
-            LWAP Control Message
-            LWAPP Encapsulated Packet
-            LWAPP Layer 3 Packet
-            Label Distribution Protocol
-            Laplink
-            Layer 2 Tunneling Protocol
-            Light Weight DNS RESolver (BIND9)
-            Lightweight Directory Access Protocol
-            Lightweight User Datagram Protocol
-            Line Printer Daemon Protocol
-            Line-based text data
-            Link Access Procedure Balanced (LAPB)
-            Link Access Procedure Balanced Ethernet (LAPBETHER)
-            Link Access Procedure, Channel D (LAPD)
-            Link Layer Discovery Protocol
-            Link Management Protocol (LMP)
-            Linux cooked-mode capture
-            Local Management Interface
-            LocalTalk Link Access Protocol
-            Log Message
-            Logical Link Control GPRS
-            Logical-Link Control
-            Logical-Link Control Basic Format XID
-            Logotype Certificate Extensions
-            Lucent/Ascend debug output
-            MAC Control
-            MAP_DialoguePDU
-            MDS Header
-            MEGACO
-            MIME Multipart Media Encapsulation
-            MMS
-            MMS Message Encapsulation
-            MS Kpasswd
-            MS Network Load Balancing
-            MS Proxy Protocol
-            MSN Messenger Service
-            MSNIP: Multicast Source Notification of Interest Protocol
-            MTP 2 Transparent Proxy
-            MTP 2 User Adaptation Layer
-            MTP 3 User Adaptation Layer
-            MTP2 Peer Adaptation Layer
-            MULTIMEDIA-SYSTEM-CONTROL
-            Media Gateway Control Protocol
-            Media Type
-            Media Type: message/http
-            Message Session Relay Protocol
-            Message Transfer Part Level 2
-            Message Transfer Part Level 3
-            Message Transfer Part Level 3 Management
-            Meta Analysis Tracing Engine
-            Microsoft AT-Scheduler Service
-            Microsoft Distributed File System
-            Microsoft Distributed Link Tracking Server Service
-            Microsoft Encrypted File System Service
-            Microsoft Eventlog Service
-            Microsoft Exchange MAPI
-            Microsoft File Replication Service
-            Microsoft File Replication Service API
-            Microsoft Local Security Architecture
-            Microsoft Media Server
-            Microsoft Messenger Service
-            Microsoft Network Logon
-            Microsoft Plug and Play service
-            Microsoft Routing and Remote Access Service
-            Microsoft Security Account Manager
-            Microsoft Server Service
-            Microsoft Service Control
-            Microsoft Spool Subsystem
-            Microsoft Telephony API Service
-            Microsoft Windows Browser Protocol
-            Microsoft Windows Lanman Remote API Protocol
-            Microsoft Windows Logon Protocol (Old)
-            Microsoft Workstation Service
-            Mobile IP
-            Mobile IPv6 / Network Mobility
-            Modbus/TCP
-            Monotone Netsync
-            Mount Service
-            MultiProtocol Label Switching Header
-            Multicast Router DISCovery protocol
-            Multicast Source Discovery Protocol
-            Multiprotocol Label Switching Echo
-            MySQL Protocol
-            NBMA Next Hop Resolution Protocol
-            NFSACL
-            NFSAUTH
-            NIS+
-            NIS+ Callback
-            NSPI
-            NTLM Secure Service Provider
-            Name Binding Protocol
-            Name Management Protocol over IPX
-            Negative-acknowledgment Oriented Reliable Multicast
-            NetBIOS
-            NetBIOS Datagram Service
-            NetBIOS Name Service
-            NetBIOS Session Service
-            NetBIOS over IPX
-            NetScape Certificate Extensions
-            NetWare Core Protocol
-            NetWare Link Services Protocol
-            NetWare Serialization Protocol
-            Network Data Management Protocol
-            Network File System
-            Network Lock Manager Protocol
-            Network News Transfer Protocol
-            Network Service Over IP
-            Network Status Monitor CallBack Protocol
-            Network Status Monitor Protocol
-            Network Time Protocol
-            Nortel SONMP
-            Novell Cluster Services
-            Novell Distributed Print System
-            Novell Modular Authentication Service
-            Novell SecretStore Services
-            Null/Loopback
-            Online Certificate Status Protocol
-            Open Policy Service Interface
-            Open Shortest Path First
-            OpenBSD Encapsulating device
-            OpenBSD Packet Filter log file
-            OpenBSD Packet Filter log file, pre 3.4
-            Optimized Link State Routing Protocol
-            PC NFS
-            PKCS#1
-            PKINIT
-            PKIX CERT File Format
-            PKIX Qualified
-            PKIX Time Stamp Protocol
-            PKIX1Explitit
-            PKIX1Implitit
-            PKIXProxy (RFC3820)
-            PPP Bandwidth Allocation Control Protocol
-            PPP Bandwidth Allocation Protocol
-            PPP CDP Control Protocol
-            PPP Callback Control Protocol
-            PPP Challenge Handshake Authentication Protocol
-            PPP Compressed Datagram
-            PPP Compression Control Protocol
-            PPP IP Control Protocol
-            PPP IPv6 Control Protocol
-            PPP In HDLC-Like Framing
-            PPP Link Control Protocol
-            PPP MPLS Control Protocol
-            PPP Multilink Protocol
-            PPP Multiplexing
-            PPP OSI Control Protocol
-            PPP Password Authentication Protocol
-            PPP VJ Compression
-            PPP-over-Ethernet Discovery
-            PPP-over-Ethernet Session
-            PPPMux Control Protocol
-            PROFINET DCP
-            PROFINET IO
-            PROFINET Real-Time Protocol
-            P_Mul (ACP142)
-            Packed Encoding Rules (ASN.1 X.691)
-            Packet Cable Lawful Intercept
-            PacketCable
-            Parallel Virtual File System
-            Parlay Dissector Using GIOP API
-            Plan 9 9P
-            Point-to-Point Protocol
-            Point-to-Point Tunnelling Protocol
-            Port Aggregation Protocol
-            Portmap
-            Post Office Protocol
-            PostgreSQL
-            Pragmatic General Multicast
-            Precision Time Protocol (IEEE1588)
-            Printer Access Protocol
-            Prism
-            Privilege Server operations
-            Protocol Independent Multicast
-            Q.2931
-            Q.931
-            Q.933
-            Quake II Network Protocol
-            Quake III Arena Network Protocol
-            Quake Network Protocol
-            QuakeWorld Network Protocol
-            Qualified Logical Link Control
-            RDM
-            RFC 2250 MPEG1
-            RFC 2833 RTP Event
-            RIPng
-            RPC Browser
-            RS Interface properties
-            RSTAT
-            RSYNC File Synchroniser
-            RTcfg
-            RX Protocol
-            Radio Access Network Application Part
-            Radius Protocol
-            Raw packet data
-            Real Data Transport
-            Real Time Streaming Protocol
-            Real-Time Media Access Control
-            Real-Time Publish-Subscribe Wire Protocol
-            Real-Time Transport Protocol
-            Real-time Transport Control Protocol
-            Redback
-            Redundant Link Management Protocol
-            Registry Server Attributes Manipulation Interface
-            Registry server administration operations.
-            Reliable UDP
-            Remote Management Control Protocol
-            Remote Override interface
-            Remote Procedure Call
-            Remote Program Load
-            Remote Quota
-            Remote Registry Service
-            Remote Shell
-            Remote Wall protocol
-            Remote sec_login preauth interface.
-            Resource ReserVation Protocol (RSVP)
-            Retix Spanning Tree Protocol
-            Rlogin Protocol
-            Routing Information Protocol
-            Routing Table Maintenance Protocol
-            SADMIND
-            SCSI
-            SEBEK - Kernel Data Capture
-            SGI Mount Service
-            SMB (Server Message Block Protocol)
-            SMB MailSlot Protocol
-            SMB Pipe Protocol
-            SMB2 (Server Message Block Protocol version 2)
-            SNA-over-Ethernet
-            SNMP Multiplex Protocol
-            SPNEGO-KRB5
-            SPRAY
-            SS7 SCCP-User Adaptation Layer
-            SSCF-NNI
-            SSCOP
-            SSH Protocol
-            STANAG 4406 Military Message
-            STANAG 5066 (SIS layer)
-            Secure Socket Layer
-            Sequenced Packet Protocol
-            Sequenced Packet eXchange
-            Serial Infrared
-            Service Advertisement Protocol
-            Service Location Protocol
-            Session Announcement Protocol
-            Session Description Protocol
-            Session Initiation Protocol
-            Session Initiation Protocol (SIP as raw text)
-            Short Message Peer to Peer
-            Short Message Relaying Service
-            Signaling Compression
-            Signalling Connection Control Part
-            Signalling Connection Control Part Management
-            Simple Mail Transfer Protocol
-            Simple Network Management Protocol
-            Simple Protected Negotiation
-            Simple Traversal of UDP Through NAT
-            Sinec H1 Protocol
-            Sipfrag
-            Skinny Client Control Protocol
-            SliMP3 Communication Protocol
-            Slow Protocols
-            Socks Protocol
-            SoulSeek Protocol
-            Spanning Tree Protocol
-            Stream Control Transmission Protocol
-            Subnetwork Dependent Convergence Protocol
-            Symantec Enterprise Firewall
-            Synchronized Multimedia Integration Language
-            Synchronous Data Link Control (SDLC)
-            Synergy
-            Syslog message
-            Systems Network Architecture
-            Systems Network Architecture XID
-            T.38
-            TACACS
-            TACACS+
-            TDMA RTmac Discipline
-            TEI Management Procedure, Channel D (LAPD)
-            TPKT - ISO on TCP - RFC1006
-            Tabular Data Stream
-            Tango Dissector Using GIOP API
-            Tazmen Sniffer Protocol
-            Telnet
-            Teredo IPv6 over UDP tunneling
-            The Armagetron Advanced OpenGL Tron clone
-            Time Protocol
-            Time Synchronization Protocol
-            Tiny Transport Protocol
-            Token-Ring
-            Token-Ring Media Access Control
-            Transaction Capabilities Application Part
-            Transmission Control Protocol
-            Transparent Inter Process Communication(TIPC)
-            Transparent Network Substrate Protocol
-            Transport Adapter Layer Interface v1.0, RFC 3094
-            Trivial File Transfer Protocol
-            UDP Encapsulation of IPsec Packets
-            UTRAN Iub interface NBAP signalling
-            UTRAN Iur interface Radio Network Subsystem Application Part
-            Universal Computer Protocol
-            Unlicensed Mobile Access
-            User Datagram Protocol
-            V5.2-User Adaptation Layer
-            Virtual Network Computing
-            Virtual Router Redundancy Protocol
-            Virtual Trunking Protocol
-            WAP Binary XML
-            WAP Session Initiation Request
-            WINS (Windows Internet Name Service) Replication
-            Web Cache Coordination Protocol
-            WebSphere MQ
-            WebSphere MQ Programmable Command Formats
-            Wellfleet Breath of Life
-            Wellfleet Compression
-            Wellfleet HDLC
-            Who
-            Windows 2000 DNS
-            Wireless Session Protocol
-            Wireless Transaction Protocol
-            Wireless Transport Layer Security
-            Wlan Certificate Extension
-            X Display Manager Control Protocol
-            X.228 OSI Reliable Transfer Service
-            X.25
-            X.25 over TCP
-            X.29
-            X.411 Message Transfer Service
-            X.420 File Transfer Body Part
-            X.420 Information Object
-            X.501 Directory Operational Binding Management Protocol
-            X.509 Authentication Framework
-            X.509 Certificate Extensions
-            X.509 Information Framework
-            X.509 Selected Attribute Types
-            X.519 Directory Access Protocol
-            X.519 Directory Information Shadowing Protocol
-            X.519 Directory System Protocol
-            X.880 OSI Remote Operations Service
-            X11
-            X711 CMIP
-            Xyplex
-            Yahoo Messenger Protocol
-            Yahoo YMSG Messenger Protocol
-            Yellow Pages Bind
-            Yellow Pages Passwd
-            Yellow Pages Service
-            Yellow Pages Transfer
-            Zebra Protocol
-            Zone Information Protocol
-            eDonkey Protocol
-            eXtensible Markup Language
-            giFT Internet File Transfer
-            h450
-            iFCP
-            iSCSI
-            iSNS
-            iTunes podCast rss elements
-            rss
-
-   Q 1.6: Are there any plans to support {your favorite protocol}?
-
-   A: Support for particular protocols is added to Ethereal as a result of
-   people contributing that support; no formal plans for adding support for
-   particular protocols in particular future releases exist.
-
-   Q 1.7: Can Ethereal read capture files from {your favorite network
+   Q 1.5: Can I use Wireshark commercially?
+
+   A: Yes, if, for example, you mean "I work for a commercial
+   organization; can I use Wireshark to capture and analyze network
+   traffic in our company's networks or in our customer's networks?"
+
+   If you mean "Can I use Wireshark as part of my commercial product?",
+   see the next entry in the FAQ.
+
+   Q 1.6: Can I use Wireshark as part of my commercial product?
+
+   A: As noted, Wireshark is licensed under the GNU General Public
+   License. The GPL imposes conditions on your use of GPL'ed code in your
+   own products; you cannot, for example, make a "derived work" from
+   Wireshark, by making modifications to it, and then sell the resulting
+   derived work and not allow recipients to give away the resulting work.
+   You must also make the changes you've made to the Wireshark source
+   available to all recipients of your modified version; those changes
+   must also be licensed under the terms of the GPL. See the GPL FAQ for
+   more details; in particular, note the answer to the question about
+   modifying a GPLed program and selling it commercially, and the
+   question about linking GPLed code with other code to make a
+   proprietary program.
+
+   You can combine a GPLed program such as Wireshark and a commercial
+   program as long as they communicate "at arm's length", as per this
+   item in the GPL FAQ.
+
+   Q 1.7: What protocols are currently supported?
+
+   A: There are currently hundreds of supported protocols and media.
+   Details can be found in the wireshark(1) man page.
+
+   Q 1.8: Are there any plans to support {your favorite protocol}?
+
+   A: Support for particular protocols is added to Wireshark as a result
+   of people contributing that support; no formal plans for adding
+   support for particular protocols in particular future releases exist.
+
+   Q 1.9: Can Wireshark read capture files from {your favorite network
    analyzer}?
 
-   A: Support for particular protocols is added to Ethereal as a result of
-   people contributing that support; no formal plans for adding support for
-   particular protocols in particular future releases exist.
+   A: Support for particular protocols is added to Wireshark as a result
+   of people contributing that support; no formal plans for adding
+   support for particular protocols in particular future releases exist.
 
-   If a network analyzer writes out files in a format already supported by
-   Ethereal (e.g., in libpcap format), Ethereal may already be able to read
-   them, unless the analyzer has added its own proprietary extensions to that
-   format.
+   If a network analyzer writes out files in a format already supported
+   by Wireshark (e.g., in libpcap format), Wireshark may already be able
+   to read them, unless the analyzer has added its own proprietary
+   extensions to that format.
 
    If a network analyzer writes out files in its own format, or has added
-   proprietary extensions to another format, in order to make Ethereal read
-   captures from that network analyzer, we would either have to have a
-   specification for the file format, or the extensions, sufficient to give us
-   enough information to read the parts of the file relevant to Ethereal, or
-   would need at least one capture file in that format AND a detailed textual
-   analysis of the packets in that capture file (showing packet time stamps,
-   packet lengths, and the top-level packet header) in order to
-   reverse-engineer the file format.
-
-   Note that there is no guarantee that we will be able to reverse-engineer a
-   capture file format.
-
-   Q 1.8: What devices can Ethereal use to capture packets?
-
-   A: Ethereal can read live data from Ethernet, Token-Ring, FDDI, serial (PPP
-   and SLIP) (if the OS on which it's running allows Ethereal to do so), 802.11
-   wireless LAN (if the OS on which it's running allows Ethereal to do so), ATM
-   connections (if the OS on which it's running allows Ethereal to do so), and
-   the "any" device supported on Linux by recent versions of libpcap. See the
-   list of supported capture media on various OSes for details (several items
-   in there say "Unknown", which doesn't mean "Ethereal can't capture on them",
-   it means "we don't know whether it can capture on them"; we expect that it
-   will be able to capture on many of them, but we haven't tried it ourselves -
-   if you try one of those types and it works, please send an update to
-   wireshark-web[AT]wireshark.org).
+   proprietary extensions to another format, in order to make Wireshark
+   read captures from that network analyzer, we would either have to have
+   a specification for the file format, or the extensions, sufficient to
+   give us enough information to read the parts of the file relevant to
+   Wireshark, or would need at least one capture file in that format AND
+   a detailed textual analysis of the packets in that capture file
+   (showing packet time stamps, packet lengths, and the top-level packet
+   header) in order to reverse-engineer the file format.
+
+   Note that there is no guarantee that we will be able to
+   reverse-engineer a capture file format.
+
+   Q 1.10: What devices can Wireshark use to capture packets?
+
+   A: Wireshark can read live data from Ethernet, Token-Ring, FDDI,
+   serial (PPP and SLIP) (if the OS on which it's running allows
+   Wireshark to do so), 802.11 wireless LAN (if the OS on which it's
+   running allows Wireshark to do so), ATM connections (if the OS on
+   which it's running allows Wireshark to do so), and the "any" device
+   supported on Linux by recent versions of libpcap. See the list of
+   supported capture media on various OSes for details (several items in
+   there say "Unknown", which doesn't mean "Wireshark can't capture on
+   them", it means "we don't know whether it can capture on them"; we
+   expect that it will be able to capture on many of them, but we haven't
+   tried it ourselves - if you try one of those types and it works,
+   please send an update to ).
 
    It can also read a variety of capture file formats, including:
      * AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet
@@ -1099,8 +367,8 @@ cies
      * Lucent/Ascend router debug output
      * Microsoft Network Monitor captures
      * Network Associates Windows-based Sniffer captures
-     * Network General/Network Associates DOS-based Sniffer (compressed or
-       uncompressed) captures
+     * Network General/Network Associates DOS-based Sniffer (compressed
+       or uncompressed) captures
      * Network Instruments Observer version 9 captures
      * Novell LANalyzer captures
      * RADCOM's WAN/LAN analyzer captures
@@ -1108,765 +376,736 @@ cies
      * Toshiba's ISDN routers dump output
      * VMS TCPIPtrace/TCPtrace/UCX$TRACE output
      * Visual Networks' Visual UpTime traffic capture
-     * libpcap, tcpdump and various other tools using tcpdump's capture format
+     * libpcap, tcpdump and various other tools using tcpdump's capture
+       format
      * snoop and atmsnoop output
 
-   so that it can read traces from various network types, as captured by other
-   applications or equipment, even if it cannot itself capture on those network
-   types.
-
-   Q 1.9: How do you pronounce Ethereal? Where did the name come from?
-
-   A: The English pronunciation can be found in Merriam-Webster's online
-   dictionary at
-   http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=ethereal.
-
-   According to the book "Computer Networks" by Andrew Tannenbaum, Ethernet was
-   named after the "luminiferous ether" which was once thought to carry
-   electromagnetic radiation. Taking that into consideration, Ethereal seemed
-   like an appropriate name for something that started out as an Ethernet
-   analyzer.
+   so that it can read traces from various network types, as captured by
+   other applications or equipment, even if it cannot itself capture on
+   those network types.
 
-   Q 1.10: Does Ethereal work on Windows Me?
+   Q 1.11: Does Wireshark work on Windows Me?
 
-   A: Yes, but if you want to capture packets, you will need to install the
-   latest version of WinPcap, as 2.02 and earlier versions of WinPcap didn't
-   support Windows Me. You should also install the latest version of Ethereal
-   as well.
+   A: Yes, but if you want to capture packets, you will need to install
+   the latest version of WinPcap, as 2.02 and earlier versions of WinPcap
+   didn't support Windows Me. You should also install the latest version
+   of Wireshark as well.
 
-   Q 1.11: Does Ethereal work on Windows XP?
+   Q 1.12: Does Wireshark work on Windows XP?
 
-   A: Yes, but if you want to capture packets, you will need to install the
-   latest version of WinPcap, as 2.2 and earlier versions of WinPcap didn't
-   support Windows XP.
+   A: Yes, but if you want to capture packets, you will need to install
+   the latest version of WinPcap, as 2.2 and earlier versions of WinPcap
+   didn't support Windows XP.
 
-2. Downloading Ethereal
+2. Downloading Wireshark
 
    Q 2.1: Why do I get an error when I try to run the Win32 installer?
 
-   A: The program you used to download it may have downloaded it incorrectly.
-   Web browsers sometimes may do this.
+   A: The program you used to download it may have downloaded it
+   incorrectly. Web browsers sometimes may do this.
 
    Try downloading it with, for example:
-     * Wget, for which Windows binaries are available on the SunSITE FTP server
-       at sunsite.tk or Heiko Herold's windows wget spot - wGetGUI offers a GUI
-       interface that uses wget;
+     * Wget, for which Windows binaries are available on the SunSITE FTP
+       server at sunsite.tk or Heiko Herold's windows wget spot - wGetGUI
+       offers a GUI interface that uses wget;
      * WS_FTP from Ipswitch,
      * the ftp command that comes with Windows.
 
-   If you use the ftp command, make sure you do the transfer in binary mode
-   rather than ASCII mode, by using the binary command before transferring the
-   file.
+   If you use the ftp command, make sure you do the transfer in binary
+   mode rather than ASCII mode, by using the binary command before
+   transferring the file.
 
-   Q 2.2: Why can't I get to the WinPcap Web site in order to download WinPcap?
+3. Installing Wireshark
 
-   A: As is the case with all Web sites, that site won't necessarily always be
-   accessible; the server may be down due to a problem or down for maintenance,
-   or there may be a networking problem between you and the server. You should
-   try again later, or try the local mirror or the Wiretapped.net mirror.
+   Q 3.1: I installed the Wireshark RPM (or other package); why did it
+   install TShark but not Wireshark?
 
-   Note that current Ethereal releases include an installer for WinPcap.
+   A: Many distributions have separate Wireshark packages, one for
+   non-GUI components such as TShark, editcap, dumpcap, etc. and one for
+   the GUI. If this is the case on your system, there's probably a
+   separate package named wireshark-gnome or wireshark-gtk+. Find it and
+   install it.
 
-3. Installing Ethereal
-
-   Q 3.1: I installed an Ethereal RPM; why did it install TShark but not
-   Ethereal?
-
-   A: Older versions of the Red Hat RPMs for Wireshark put only the non-GUI
-   components into the ethereal RPM, the fact that Wireshark is a GUI program
-   nonwithstanding; newer versions make it a bit clearer by giving that RPM a
-   name starting with wireshark-base.
-
-   In those older versions, there's a separate wireshark-gnome RPM that includes
-   GUI components such as Ethereal itself, the fact that Ethereal doesn't use
-   GNOME nonwithstanding; newer versions make it a bit clearer by giving that
-   RPM a name starting with wireshark-gtk+.
-
-   Find the wireshark-gnome or wireshark-gtk+ RPM, and install that also.
-
-4. Building Ethereal
+4. Building Wireshark
 
    Q 4.1: I have libpcap installed; why did the configure script not find
    pcap.h or bpf.h?
 
-   A: Are you sure pcap.h and bpf.h are installed? The official distribution of
-   libpcap only installs the libpcap.a library file when "make install" is run.
-   To install pcap.h and bpf.h, you must run "make install-incl". If you're
-   running Debian or Redhat, make sure you have the "libpcap-dev" or
-   "libpcap-devel" packages installed.
+   A: Are you sure pcap.h and bpf.h are installed? The official
+   distribution of libpcap only installs the libpcap.a library file when
+   "make install" is run. To install pcap.h and bpf.h, you must run "make
+   install-incl". If you're running Debian or Redhat, make sure you have
+   the "libpcap-dev" or "libpcap-devel" packages installed.
 
-   It's also possible that pcap.h and bpf.h have been installed in a strange
-   location. If this is the case, you may have to tweak aclocal.m4.
+   It's also possible that pcap.h and bpf.h have been installed in a
+   strange location. If this is the case, you may have to tweak
+   aclocal.m4.
 
    Q 4.2: Why do I get the error
 
-     dftest_DEPENDENCIES was already defined in condition TRUE, which implies
-     condition HAVE_PLUGINS_TRUE
-
-   when I try to build Ethereal from SVN or a SVN snapshot?
-
-   A: You probably have automake 1.5 installed on your machine (the command
-   automake --version will report the version of automake on your machine).
-   There is a bug in that version of automake that causes this problem; upgrade
-   to a later version of automake (1.6 or later).
-
-   Q 4.3: Why does the linker fail with a number of "Output line too long."
-   messages followed by linker errors when I try to buil Ethereal?
-
-   A: The version of the sed command on your system is incapable of handling
-   very long lines. On Solaris, for example, /usr/bin/sed has a line length
-   limit too low to allow libtool to work; /usr/xpg4/bin/sed can handle it, as
-   can GNU sed if you have it installed.
-
-   On Solaris, changing your command search path to search /usr/xpg4/bin before
-   /usr/bin should make the problem go away; on any platform on which you have
-   this problem, installing GNU sed and changing your command path to search
-   the directory in which it is installed before searching the directory with
-   the version of sed that came with the OS should make the problem go away.
-
-   Q 4.4: When I try to build Ethereal on Solaris, why does the link fail
-   complaining that plugin_list is undefined?
-
-   A: This appears to be due to a problem with some versions of the GTK+ and
-   GLib packages from www.sunfreeware.org; un-install those packages, and try
-   getting the 1.2.10 versions from that site, or the versions from The Written
-   Word, or the versions from Sun's GNOME distribution, or the versions from
-   the supplemental software CD that comes with the Solaris media kit, or build
-   them from source from the GTK Web site. Then re-run the configuration
-   script, and try rebuilding Ethereal. (If you get the 1.2.10 versions from
-   www.sunfreeware.org, and the problem persists, un-install them and try
-   installing one of the other versions mentioned.)
-
-   Q 4.5: When I try to build Ethereal on Windows, why does the build fail
-   because of conflicts between winsock.h and winsock2.h?
-
-   A: As of Ethereal 0.9.5, you must install WinPcap 2.3 or later, and the
-   corresponding version of the developer's pack, in order to be able to
-   compile Ethereal; it will not compile with older versions of the developer's
-   pack. The symptoms of this failure are conflicts between definitions in
-   winsock.h and in winsock2.h; Ethereal uses winsock2.h, but pre-2.3 versions
-   of the WinPcap developer's packet use winsock.h. (2.3 uses winsock2.h, so if
-   Ethereal were to use winsock.h, it would not be able to build with current
-   versions of the WinPcap developer's pack.)
-
-   Note that the installed version of the developer's pack should be the same
-   version as the version of WinPcap you have installed.
-
-5. Starting Ethereal
-
-   Q 5.1: Why does Ethereal crash with a Bus Error when I try to run it on
-   Solaris 8?
-
-   A: Some versions of the GTK+ library from www.sunfreeware.org appear to be
-   buggy, causing Ethereal to drop core with a Bus Error. Un-install those
-   packages, and try getting the 1.2.10 version from that site, or the version
-   from The Written Word, or the version from Sun's GNOME distribution, or the
-   version from the supplemental software CD that comes with the Solaris media
-   kit, or build it from source from the GTK Web site. Update the GLib library
-   to the 1.2.10 version, from the same source, as well. (If you get the 1.2.10
-   versions from www.sunfreeware.org, and the problem persists, un-install them
-   and try installing one of the other versions mentioned.)
-
-   Similar problems may exist with older versions of GTK+ for earlier versions
-   of Solaris.
-
-   Q 5.2: When I run TShark with the "-x" option, why does it crash with an
-   error
-
-     "** ERROR **: file print.c: line 691 (print_line): should not be reached.
-
-   A: This is a bug in Wireshark 0.10.0a, which is fixed in 0.10.1 and later
-   releases. To work around the bug, don't use "-x" unless you're also using
-   "-V"; note that "-V" produces a full dissection of each packet, so you might
-   not want to use it.
-
-   Q 5.3: When I run Ethereal on Windows NT, why does it die with a Dr. Watson
-   error, reporting an "Integer division by zero" exception, when I start it?
-
-   A: In at least some case, this appears to be due to using the default VGA
-   driver; if that's not the correct driver for your video card, try running
-   the correct driver for your video card.
-
-   Q 5.4: When I try to run Ethereal, why does it complain about
+     dftest_DEPENDENCIES was already defined in condition TRUE, which
+     implies condition HAVE_PLUGINS_TRUE
+
+   when I try to build Wireshark from SVN or a SVN snapshot?
+
+   A: You probably have automake 1.5 installed on your machine (the
+   command automake --version will report the version of automake on your
+   machine). There is a bug in that version of automake that causes this
+   problem; upgrade to a later version of automake (1.6 or later).
+
+   Q 4.3: Why does the linker fail with a number of "Output line too
+   long." messages followed by linker errors when I try to buil
+   Wireshark?
+
+   A: The version of the sed command on your system is incapable of
+   handling very long lines. On Solaris, for example, /usr/bin/sed has a
+   line length limit too low to allow libtool to work; /usr/xpg4/bin/sed
+   can handle it, as can GNU sed if you have it installed.
+
+   On Solaris, changing your command search path to search /usr/xpg4/bin
+   before /usr/bin should make the problem go away; on any platform on
+   which you have this problem, installing GNU sed and changing your
+   command path to search the directory in which it is installed before
+   searching the directory with the version of sed that came with the OS
+   should make the problem go away.
+
+   Q 4.4: When I try to build Wireshark on Solaris, why does the link
+   fail complaining that plugin_list is undefined?
+
+   A: This appears to be due to a problem with some versions of the GTK+
+   and GLib packages from www.sunfreeware.org; un-install those packages,
+   and try getting the 1.2.10 versions from that site, or the versions
+   from The Written Word, or the versions from Sun's GNOME distribution,
+   or the versions from the supplemental software CD that comes with the
+   Solaris media kit, or build them from source from the GTK Web site.
+   Then re-run the configuration script, and try rebuilding Wireshark.
+   (If you get the 1.2.10 versions from www.sunfreeware.org, and the
+   problem persists, un-install them and try installing one of the other
+   versions mentioned.)
+
+   Q 4.5: When I try to build Wireshark on Windows, why does the build
+   fail because of conflicts between winsock.h and winsock2.h?
+
+   A: As of Wireshark 0.9.5, you must install WinPcap 2.3 or later, and
+   the corresponding version of the developer's pack, in order to be able
+   to compile Wireshark; it will not compile with older versions of the
+   developer's pack. The symptoms of this failure are conflicts between
+   definitions in winsock.h and in winsock2.h; Wireshark uses winsock2.h,
+   but pre-2.3 versions of the WinPcap developer's packet use winsock.h.
+   (2.3 uses winsock2.h, so if Wireshark were to use winsock.h, it would
+   not be able to build with current versions of the WinPcap developer's
+   pack.)
+
+   Note that the installed version of the developer's pack should be the
+   same version as the version of WinPcap you have installed.
+
+5. Starting Wireshark
+
+   Q 5.1: Why does Wireshark crash with a Bus Error when I try to run it
+   on Solaris 8?
+
+   A: Some versions of the GTK+ library from www.sunfreeware.org appear
+   to be buggy, causing Wireshark to drop core with a Bus Error.
+   Un-install those packages, and try getting the 1.2.10 version from
+   that site, or the version from The Written Word, or the version from
+   Sun's GNOME distribution, or the version from the supplemental
+   software CD that comes with the Solaris media kit, or build it from
+   source from the GTK Web site. Update the GLib library to the 1.2.10
+   version, from the same source, as well. (If you get the 1.2.10
+   versions from www.sunfreeware.org, and the problem persists,
+   un-install them and try installing one of the other versions
+   mentioned.)
+
+   Similar problems may exist with older versions of GTK+ for earlier
+   versions of Solaris.
+
+   Q 5.2: When I run Wireshark on Windows NT, why does it die with a Dr.
+   Watson error, reporting an "Integer division by zero" exception, when
+   I start it?
+
+   A: In at least some case, this appears to be due to using the default
+   VGA driver; if that's not the correct driver for your video card, try
+   running the correct driver for your video card.
+
+   Q 5.3: When I try to run Wireshark, why does it complain about
    sprint_realloc_objid being undefined?
 
-   A: Ethereal can only be linked with version 4.2.2 or later of UCD SNMP. Your
-   version of Ethereal was dynamically linked with such a version of UCD SNMP;
-   however, you have an older version of UCD SNMP installed, which means that
-   when Wireshark is run, it tries to link to the older version, and fails. You
-   will have to replace that version of UCD SNMP with version 4.2.2 or a later
-   version.
-
-   Q 5.5: When I try to run Ethereal on Windows, why does it fail to run with a
-   complaint that it can't find packet.dll?
-
-   A: In older versions of Ethereal, there were two binary distributions
-   available for Windows, one that supported capturing packets, and one that
-   didn't. The version that supported capturing packets required that you
-   install the WinPcap driver; if you didn't install it, it would fail to run
-   because it couldn't find packet.dll.
-
-   The current version of Ethereal has only one binary distribution for
-   Windows; that version will check whether WinPcap is installed and, if it's
-   not, will disable support for packet capture.
-
-   The WinPcap driver and libraries can be downloaded from the WinPcap Web
-   site, the local mirror of the WinPcap Web site, or the Wiretapped.net mirror
-   of the WinPcap site.
-
-   Q 5.6: Why do I get the error
-
-     Gdk-ERROR **: Palettized display (256-colour) mode not supported on
-     Windows.
-     aborting....
-
-   when I try to run Ethereal on Windows?
-
-   A: Wireshark is built using the GTK+ toolkit, which supports most
-   UNIX-flavored OSes, and also supports Windows.
-
-   Windows versions of Ethereal before 0.9.14 were built with an older version
-   of that toolkit, which didn't support 256-color mode on Windows - it
-   required HiColor (16-bit colors) or more.
-
-   Windows versions of Ethereal 0.9.14 and later are built with a version of
-   that toolkit that supports 256-color mode; upgrade to the current version of
-   Ethereal if you want to run on a display in 256-color mode.
-
-   Q 5.7: I've installed Ethereal from Fink on Mac OS X; why is it very slow to
-   start up?
-
-   A: When an application is installed on OS X, prior to 10.4, it is usually
-   "prebound" to speed up launching the application. (That's what the
-   "Optimizing" phase of installation is.) Fink normally performs prebinding
-   automatically when you install a package. However, in some rare cases, for
-   whatever reason the prebinding caches get corrupt, and then not only does
-   prebinding fail, but startup actually becomes much slower, because the
-   system tries in vain to perform prebinding "on the fly" as you launch the
-   application. This fails, causing sometimes huge delays. To fix the
-   prebinding caches, run the command
+   A: Wireshark can only be linked with version 4.2.2 or later of UCD
+   SNMP. Your version of Wireshark was dynamically linked with such a
+   version of UCD SNMP; however, you have an older version of UCD SNMP
+   installed, which means that when Wireshark is run, it tries to link to
+   the older version, and fails. You will have to replace that version of
+   UCD SNMP with version 4.2.2 or a later version.
+
+   Q 5.4: When I try to run Wireshark on Windows, why does it fail to run
+   with a complaint that it can't find packet.dll?
+
+   A: In older versions of Wireshark, there were two binary distributions
+   available for Windows, one that supported capturing packets, and one
+   that didn't. The version that supported capturing packets required
+   that you install the WinPcap driver; if you didn't install it, it
+   would fail to run because it couldn't find packet.dll.
+
+   The current version of Wireshark has only one binary distribution for
+   Windows; that version will check whether WinPcap is installed and, if
+   it's not, will disable support for packet capture.
+
+   The WinPcap driver and libraries can be downloaded from the WinPcap
+   Web site or the Wiretapped.net mirror of the WinPcap site.
+
+   Q 5.5: I've installed Wireshark from Fink on Mac OS X; why is it very
+   slow to start up?
+
+   A: When an application is installed on OS X, prior to 10.4, it is
+   usually "prebound" to speed up launching the application. (That's what
+   the "Optimizing" phase of installation is.) Fink normally performs
+   prebinding automatically when you install a package. However, in some
+   rare cases, for whatever reason the prebinding caches get corrupt, and
+   then not only does prebinding fail, but startup actually becomes much
+   slower, because the system tries in vain to perform prebinding "on the
+   fly" as you launch the application. This fails, causing sometimes huge
+   delays. To fix the prebinding caches, run the command
         sudo /sw/var/lib/fink/prebound/update-package-prebinding.pl -f
 
 6. Crashes and other fatal errors
 
-   Q 6.1: When I run Ethereal, why do I get an error
-
-     Gtk-CRITICAL **: file gtkwindow.c: line 3107 (gtk_window_resize):
-     assertion `height > 0' failed.
-
-   A: This is a bug in Wireshark 0.10.5 and 0.10.5a, which is fixed in Wireshark
-   0.10.6 and later releases.
-
-   Q 6.2: I have an XXX network card on my machine; if I try to capture on it,
-   why does my machine crash or reset itself?
+   Q 6.1: I have an XXX network card on my machine; if I try to capture
+   on it, why does my machine crash or reset itself?
 
    A: This is almost certainly a problem with one or more of:
      * the operating system you're using;
      * the device driver for the interface you're using;
-     * the libpcap/WinPcap library and, if this is Windows, the WinPcap device
-       driver;
+     * the libpcap/WinPcap library and, if this is Windows, the WinPcap
+       device driver;
 
    so:
-     * if you are using Windows, see the WinPcap support page (or the local
-       mirror of that page) - check the "Submitting bugs" section;
-     * if you are using some Linux distribution, some version of BSD, or some
-       other UNIX-flavored OS, you should report the problem to the company or
-       organization that produces the OS (in the case of a Linux distribution,
-       report the problem to whoever produces the distribution).
-
-   Q 6.3: Why does my machine crash or reset itself when I select "Start" from
-   the "Capture" menu or select "Preferences" from the "Edit" menu?
-
-   A: Both of those operations cause Ethereal to try to build a list of the
-   interfaces that it can open; it does so by getting a list of interfaces and
-   trying to open them. There is probably an OS, driver, or, for Windows,
-   WinPcap bug that causes the system to crash when this happens; see the
-   previous question.
+     * if you are using Windows, see the WinPcap support page - check the
+       "Submitting bugs" section;
+     * if you are using some Linux distribution, some version of BSD, or
+       some other UNIX-flavored OS, you should report the problem to the
+       company or organization that produces the OS (in the case of a
+       Linux distribution, report the problem to whoever produces the
+       distribution).
+
+   Q 6.2: Why does my machine crash or reset itself when I select "Start"
+   from the "Capture" menu or select "Preferences" from the "Edit" menu?
+
+   A: Both of those operations cause Wireshark to try to build a list of
+   the interfaces that it can open; it does so by getting a list of
+   interfaces and trying to open them. There is probably an OS, driver,
+   or, for Windows, WinPcap bug that causes the system to crash when this
+   happens; see the previous question.
 
 7. Capturing packets
 
-   Q 7.1: When I use Ethereal to capture packets, why do I see only packets to
-   and from my machine, or not see all the traffic I'm expecting to see from or
-   to the machine I'm trying to monitor?
-
-   A: This might be because the interface on which you're capturing is plugged
-   into an Ethernet or Token Ring switch; on a switched network, unicast
-   traffic between two ports will not necessarily appear on other ports - only
-   broadcast and multicast traffic will be sent to all ports.
-
-   Note that even if your machine is plugged into a hub, the "hub" may be a
-   switched hub, in which case you're still on a switched network.
-
-   Note also that on the Linksys Web site, they say that their auto-sensing
-   hubs "broadcast the 10Mb packets to the port that operate at 10Mb only and
-   broadcast the 100Mb packets to the ports that operate at 100Mb only", which
-   would indicate that if you sniff on a 10Mb port, you will not see traffic
-   coming sent to a 100Mb port, and vice versa. This problem has also been
-   reported for Netgear dual-speed hubs, and may exist for other "auto-sensing"
-   or "dual-speed" hubs.
-
-   Some switches have the ability to replicate all traffic on all ports to a
-   single port so that you can plug your analyzer into that single port to
-   sniff all traffic. You would have to check the documentation for the switch
-   to see if this is possible and, if so, to see how to do this. See the switch
-   reference page on the Wireshark Wiki for information on some switches. (Note
-   that it's a Wiki, so you can update or fix that information, or add
-   additional information on those switches or information on new switches,
-   yourself.)
-
-   Note also that many firewall/NAT boxes have a switch built into them; this
-   includes many of the "cable/DSL router" boxes. If you have a box of that
-   sort, that has a switch with some number of Ethernet ports into which you
-   plug machines on your network, and another Ethernet port used to connect to
-   a cable or DSL modem, you can, at least, sniff traffic between the machines
-   on your network and the Internet by plugging the Ethernet port on the router
-   going to the modem, the Ethernet port on the modem, and the machine on which
-   you're running Ethereal into a hub (make sure it's not a switching hub, and
-   that, if it's a dual-speed hub, all three of those ports are running at the
+   Q 7.1: When I use Wireshark to capture packets, why do I see only
+   packets to and from my machine, or not see all the traffic I'm
+   expecting to see from or to the machine I'm trying to monitor?
+
+   A: This might be because the interface on which you're capturing is
+   plugged into an Ethernet or Token Ring switch; on a switched network,
+   unicast traffic between two ports will not necessarily appear on other
+   ports - only broadcast and multicast traffic will be sent to all
+   ports.
+
+   Note that even if your machine is plugged into a hub, the "hub" may be
+   a switched hub, in which case you're still on a switched network.
+
+   Note also that on the Linksys Web site, they say that their
+   auto-sensing hubs "broadcast the 10Mb packets to the port that operate
+   at 10Mb only and broadcast the 100Mb packets to the ports that operate
+   at 100Mb only", which would indicate that if you sniff on a 10Mb port,
+   you will not see traffic coming sent to a 100Mb port, and vice versa.
+   This problem has also been reported for Netgear dual-speed hubs, and
+   may exist for other "auto-sensing" or "dual-speed" hubs.
+
+   Some switches have the ability to replicate all traffic on all ports
+   to a single port so that you can plug your analyzer into that single
+   port to sniff all traffic. You would have to check the documentation
+   for the switch to see if this is possible and, if so, to see how to do
+   this. See the switch reference page on the Wireshark Wiki for
+   information on some switches. (Note that it's a Wiki, so you can
+   update or fix that information, or add additional information on those
+   switches or information on new switches, yourself.)
+
+   Note also that many firewall/NAT boxes have a switch built into them;
+   this includes many of the "cable/DSL router" boxes. If you have a box
+   of that sort, that has a switch with some number of Ethernet ports
+   into which you plug machines on your network, and another Ethernet
+   port used to connect to a cable or DSL modem, you can, at least, sniff
+   traffic between the machines on your network and the Internet by
+   plugging the Ethernet port on the router going to the modem, the
+   Ethernet port on the modem, and the machine on which you're running
+   Wireshark into a hub (make sure it's not a switching hub, and that, if
+   it's a dual-speed hub, all three of those ports are running at the
    same speed.
 
-   If your machine is not plugged into a switched network or a dual-speed hub,
-   or it is plugged into a switched network but the port is set up to have all
-   traffic replicated to it, the problem might be that the network interface on
-   which you're capturing doesn't support "promiscuous" mode, or because your
-   OS can't put the interface into promiscuous mode. Normally, network
-   interfaces supply to the host only:
+   If your machine is not plugged into a switched network or a dual-speed
+   hub, or it is plugged into a switched network but the port is set up
+   to have all traffic replicated to it, the problem might be that the
+   network interface on which you're capturing doesn't support
+   "promiscuous" mode, or because your OS can't put the interface into
+   promiscuous mode. Normally, network interfaces supply to the host
+   only:
      * packets sent to one of that host's link-layer addresses;
      * broadcast packets;
      * multicast packets sent to a multicast address that the host has
        configured the interface to accept.
 
-   Most network interfaces can also be put in "promiscuous" mode, in which they
-   supply to the host all network packets they see. Ethereal will try to put
+   Most network interfaces can also be put in "promiscuous" mode, in
+   which they supply to the host all network packets they see. Wireshark
+   will try to put the interface on which it's capturing into promiscuous
+   mode unless the "Capture packets in promiscuous mode" option is turned
+   off in the "Capture Options" dialog box, and TShark will try to put
    the interface on which it's capturing into promiscuous mode unless the
-   "Capture packets in promiscuous mode" option is turned off in the "Capture
-   Options" dialog box, and TShark will try to put the interface on which
-   it's capturing into promiscuous mode unless the -p option was specified.
-   However, some network interfaces don't support promiscuous mode, and some
-   OSes might not allow interfaces to be put into promiscuous mode.
+   -p option was specified. However, some network interfaces don't
+   support promiscuous mode, and some OSes might not allow interfaces to
+   be put into promiscuous mode.
 
    If the interface is not running in promiscuous mode, it won't see any
    traffic that isn't intended to be seen by your machine. It will see
-   broadcast packets, and multicast packets sent to a multicast MAC address the
-   interface is set up to receive.
+   broadcast packets, and multicast packets sent to a multicast MAC
+   address the interface is set up to receive.
 
-   You should ask the vendor of your network interface whether it supports
-   promiscuous mode. If it does, you should ask whoever supplied the driver for
-   the interface (the vendor, or the supplier of the OS you're running on your
-   machine) whether it supports promiscuous mode with that network interface.
+   You should ask the vendor of your network interface whether it
+   supports promiscuous mode. If it does, you should ask whoever supplied
+   the driver for the interface (the vendor, or the supplier of the OS
+   you're running on your machine) whether it supports promiscuous mode
+   with that network interface.
 
    In the case of token ring interfaces, the drivers for some of them, on
-   Windows, may require you to enable promiscuous mode in order to capture in
-   promiscuous mode. See the Wireshark Wiki item on Token Ring capturing for
-   details.
+   Windows, may require you to enable promiscuous mode in order to
+   capture in promiscuous mode. See the Wireshark Wiki item on Token Ring
+   capturing for details.
 
    In the case of wireless LAN interfaces, it appears that, when those
-   interfaces are promiscuously sniffing, they're running in a significantly
-   different mode from the mode that they run in when they're just acting as
-   network interfaces (to the extent that it would be a significant effor for
-   those drivers to support for promiscuously sniffing and acting as regular
-   network interfaces at the same time), so it may be that Windows drivers for
-   those interfaces don't support promiscuous mode.
-
-   Q 7.2: When I capture with Ethereal, why can't I see any TCP packets other
-   than packets to and from my machine, even though another analyzer on the
-   network sees those packets?
-
-   A: You're probably not seeing any packets other than unicast packets to or
-   from your machine, and broadcast and multicast packets; a switch will
-   normally send to a port only unicast traffic sent to the MAC address for the
-   interface on that port, and broadcast and multicast traffic - it won't send
-   to that port unicast traffic sent to a MAC address for some other interface
-   - and a network interface not in promiscuous mode will receive only unicast
-   traffic sent to the MAC address for that interface, broadcast traffic, and
-   multicast traffic sent to a multicast MAC address the interface is set up to
-   receive.
-
-   TCP doesn't use broadcast or multicast, so you will only see your own TCP
-   traffic, but UDP services may use broadcast or multicast so you'll see some
-   UDP traffic - however, this is not a problem with TCP traffic, it's a
-   problem with unicast traffic, as you also won't see all UDP traffic between
-   other machines.
+   interfaces are promiscuously sniffing, they're running in a
+   significantly different mode from the mode that they run in when
+   they're just acting as network interfaces (to the extent that it would
+   be a significant effor for those drivers to support for promiscuously
+   sniffing and acting as regular network interfaces at the same time),
+   so it may be that Windows drivers for those interfaces don't support
+   promiscuous mode.
+
+   Q 7.2: When I capture with Wireshark, why can't I see any TCP packets
+   other than packets to and from my machine, even though another
+   analyzer on the network sees those packets?
+
+   A: You're probably not seeing any packets other than unicast packets
+   to or from your machine, and broadcast and multicast packets; a switch
+   will normally send to a port only unicast traffic sent to the MAC
+   address for the interface on that port, and broadcast and multicast
+   traffic - it won't send to that port unicast traffic sent to a MAC
+   address for some other interface - and a network interface not in
+   promiscuous mode will receive only unicast traffic sent to the MAC
+   address for that interface, broadcast traffic, and multicast traffic
+   sent to a multicast MAC address the interface is set up to receive.
+
+   TCP doesn't use broadcast or multicast, so you will only see your own
+   TCP traffic, but UDP services may use broadcast or multicast so you'll
+   see some UDP traffic - however, this is not a problem with TCP
+   traffic, it's a problem with unicast traffic, as you also won't see
+   all UDP traffic between other machines.
 
    I.e., this is probably the same question as this earlier one; see the
    response to that question.
 
    Q 7.3: Why am I only seeing ARP packets when I try to capture traffic?
 
-   A: You're probably on a switched network, and running Ethereal on a machine
-   that's not sending traffic to the switch and not being sent any traffic from
-   other machines on the switch. ARP packets are often broadcast packets, which
-   are sent to all switch ports.
+   A: You're probably on a switched network, and running Wireshark on a
+   machine that's not sending traffic to the switch and not being sent
+   any traffic from other machines on the switch. ARP packets are often
+   broadcast packets, which are sent to all switch ports.
 
    I.e., this is probably the same question as this earlier one; see the
    response to that question.
 
    Q 7.4: Why am I not seeing any traffic when I try to capture traffic?
 
-   A: Is the machine running Ethereal sending out any traffic on the network
-   interface on which you're capturing, or receiving any traffic on that
-   network, or is there any broadcast traffic on the network or multicast
-   traffic to a multicast group to which the machine running Ethereal belongs?
+   A: Is the machine running Wireshark sending out any traffic on the
+   network interface on which you're capturing, or receiving any traffic
+   on that network, or is there any broadcast traffic on the network or
+   multicast traffic to a multicast group to which the machine running
+   Wireshark belongs?
 
-   If not, this may just be a problem with promiscuous sniffing, either due to
-   running on a switched network or a dual-speed hub, or due to problems with
-   the interface not supporting promiscuous mode; see the response to this
-   earlier question.
+   If not, this may just be a problem with promiscuous sniffing, either
+   due to running on a switched network or a dual-speed hub, or due to
+   problems with the interface not supporting promiscuous mode; see the
+   response to this earlier question.
 
    Otherwise, on Windows, see the response to this question and, on a
    UNIX-flavored OS, see the response to this question.
 
-   Q 7.5: Can Ethereal capture on (my T1/E1 line, SS7 links, etc.)?
+   Q 7.5: Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
 
-   A: Ethereal can only capture on devices supported by libpcap/WinPcap. On
-   most OSes, only devices that can act as network interfaces of the type that
-   support IP are supported as capture devices for libpcap/WinPcap, although
-   the device doesn't necessarily have to be running as an IP interface in
-   order to support traffic capture.
+   A: Wireshark can only capture on devices supported by libpcap/WinPcap.
+   On most OSes, only devices that can act as network interfaces of the
+   type that support IP are supported as capture devices for
+   libpcap/WinPcap, although the device doesn't necessarily have to be
+   running as an IP interface in order to support traffic capture.
 
    On Linux and FreeBSD, libpcap 0.8 and later support the API for Endace
-   Measurement Systems' DAG cards, so that a system with one of those cards,
-   and its driver and libraries, installed can capture traffic with those cards
-   with libpcap-based applications. You would either have to have a version of
-   Ethereal built with that version of libpcap, or a dynamically-linked version
-   of Ethereal and a shared libpcap library with DAG support, in order to do so
-   with Ethereal. You should ask Endace whether that could be used to capture
-   traffic on, for example, your T1/E1 link.
-   See the SS7 capture setup page on the Wireshark Wiki for current information
-   on capturing SS7 traffic on TDM links.
+   Measurement Systems' DAG cards, so that a system with one of those
+   cards, and its driver and libraries, installed can capture traffic
+   with those cards with libpcap-based applications. You would either
+   have to have a version of Wireshark built with that version of
+   libpcap, or a dynamically-linked version of Wireshark and a shared
+   libpcap library with DAG support, in order to do so with Wireshark.
+   You should ask Endace whether that could be used to capture traffic
+   on, for example, your T1/E1 link. See the SS7 capture setup page on
+   the Wireshark Wiki for current information on capturing SS7 traffic on
+   TDM links.
 
    Q 7.6: How do I put an interface into promiscuous mode?
 
-   A: By not disabling promiscuous mode when running Ethereal or TShark.
+   A: By not disabling promiscuous mode when running Wireshark or TShark.
 
    Note, however, that:
-     * the form of promiscuous mode that libpcap (the library that programs
-       such as tcpdump, Ethereal, etc. use to do packet capture) turns on will
-       not necessarily be shown if you run ifconfig on the interface on a UNIX
-       system;
-     * some network interfaces might not support promiscuous mode, and some
-       drivers might not allow promiscuous mode to be turned on - see this
-       earlier question for more information on that;
+     * the form of promiscuous mode that libpcap (the library that
+       programs such as tcpdump, Wireshark, etc. use to do packet
+       capture) turns on will not necessarily be shown if you run
+       ifconfig on the interface on a UNIX system;
+     * some network interfaces might not support promiscuous mode, and
+       some drivers might not allow promiscuous mode to be turned on -
+       see this earlier question for more information on that;
      * the fact that you're not seeing any traffic, or are only seeing
-       broadcast traffic, or aren't seeing any non-broadcast traffic other than
-       traffic to or from the machine running Ethereal, does not mean that
-       promiscuous mode isn't on - see this earlier question for more
-       information on that.
+       broadcast traffic, or aren't seeing any non-broadcast traffic
+       other than traffic to or from the machine running Wireshark, does
+       not mean that promiscuous mode isn't on - see this earlier
+       question for more information on that.
 
    I.e., this is probably the same question as this earlier one; see the
    response to that question.
 
-   Q 7.7: I can set a display filter just fine; why don't capture filters work?
+   Q 7.7: I can set a display filter just fine; why don't capture filters
+   work?
 
-   A: Capture filters currently use a different syntax than display filters.
-   Here's the corresponding section from the ethereal(1) man page:
+   A: Capture filters currently use a different syntax than display
+   filters. Here's the corresponding section from the wireshark(1) man
+   page:
 
-   "Display filters in Wireshark are very powerful; more fields are filterable
-   in Wireshark than in other protocol analyzers, and the syntax you can use to
-   create your filters is richer. As Ethereal progresses, expect more and more
-   protocol fields to be allowed in display filters.
+   "Display filters in Wireshark are very powerful; more fields are
+   filterable in Wireshark than in other protocol analyzers, and the
+   syntax you can use to create your filters is richer. As Wireshark
+   progresses, expect more and more protocol fields to be allowed in
+   display filters.
 
-   Packet capturing is performed with the pcap library. The capture filter
-   syntax follows the rules of the pcap library. This syntax is different from
-   the display filter syntax."
+   Packet capturing is performed with the pcap library. The capture
+   filter syntax follows the rules of the pcap library. This syntax is
+   different from the display filter syntax."
 
-   The capture filter syntax used by libpcap can be found in the tcpdump(8) man
-   page.
+   The capture filter syntax used by libpcap can be found in the
+   tcpdump(8) man page.
 
-   Q 7.8: I'm entering valid capture filters; why do I still get "parse error"
-   errors?
+   Q 7.8: I'm entering valid capture filters; why do I still get "parse
+   error" errors?
 
    A: There is a bug in some versions of libpcap/WinPcap that cause it to
    report parse errors even for valid expressions if a previous filter
    expression was invalid and got a parse error.
 
-   Try exiting and restarting Ethereal; if you are using a version of
-   libpcap/WinPcap with this bug, this will "erase" its memory of the previous
-   parse error. If the capture filter that got the "parse error" now works, the
-   earlier error with that filter was probably due to this bug.
+   Try exiting and restarting Wireshark; if you are using a version of
+   libpcap/WinPcap with this bug, this will "erase" its memory of the
+   previous parse error. If the capture filter that got the "parse error"
+   now works, the earlier error with that filter was probably due to this
+   bug.
 
-   The bug was fixed in libpcap 0.6; 0.4[.x] and 0.5[.x] versions of libpcap
-   have this bug, but 0.6[.x] and later versions don't.
+   The bug was fixed in libpcap 0.6; 0.4[.x] and 0.5[.x] versions of
+   libpcap have this bug, but 0.6[.x] and later versions don't.
 
-   Versions of WinPcap prior to 2.3 are based on pre-0.6 versions of libpcap,
-   and have this bug; WinPcap 2.3 is based on libpcap 0.6.2, and doesn't have
-   this bug.
+   Versions of WinPcap prior to 2.3 are based on pre-0.6 versions of
+   libpcap, and have this bug; WinPcap 2.3 is based on libpcap 0.6.2, and
+   doesn't have this bug.
 
-   If you are running Ethereal on a UNIX-flavored platform, run "ethereal -v",
-   or select "About Ethereal..." from the "Help" menu in Wireshark, to see what
-   version of libpcap it's using. If it's not 0.6 or later, you will need
-   either to upgrade your OS to get a later version of libpcap, or will need to
-   build and install a later version of libpcap from the tcpdump.org Web site
-   and then recompile Ethereal from source with that later version of libpcap.
+   If you are running Wireshark on a UNIX-flavored platform, run
+   "wireshark -v", or select "About Wireshark..." from the "Help" menu in
+   Wireshark, to see what version of libpcap it's using. If it's not 0.6
+   or later, you will need either to upgrade your OS to get a later
+   version of libpcap, or will need to build and install a later version
+   of libpcap from the tcpdump.org Web site and then recompile Wireshark
+   from source with that later version of libpcap.
 
-   If you are running Ethereal on Windows with a pre-2.3 version of WinPcap,
-   you will need to un-install WinPcap and then download and install WinPcap
-   2.3.
+   If you are running Wireshark on Windows with a pre-2.3 version of
+   WinPcap, you will need to un-install WinPcap and then download and
+   install WinPcap 2.3.
 
    Q 7.9: How can I capture packets with CRC errors?
 
-   A: Ethereal can capture only the packets that the packet capture library -
-   libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of libpcap on
-   Windows - can capture, and libpcap/WinPcap can capture only the packets that
-   the OS's raw packet capture mechanism (or the WinPcap driver, and the
-   underlying OS networking code and network interface drivers, on Windows)
-   will allow it to capture.
-
-   Unless the OS always supplies packets with errors such as invalid CRCs to
-   the raw packet capture mechanism, or can be configured to do so, invalid
-   CRCs to the raw packet capture mechanism, Ethereal - and other programs that
-   capture raw packets, such as tcpdump - cannot capture those packets. You
-   will have to determine whether your OS needs to be so configured and, if so,
-   can be so configured, configure it if necessary and possible, and make
-   whatever changes to libpcap and the packet capture program you're using are
-   necessary, if any, to support capturing those packets.
-
-   Most OSes probably do not support capturing packets with invalid CRCs on
-   Ethernet, and probably do not support it on most other link-layer types.
-   Some drivers on some OSes do support it, such as some Ethernet drivers on
-   FreeBSD; in those OSes, you might always get those packets, or you might
-   only get them if you capture in promiscuous mode (you'd have to determine
-   which is the case).
+   A: Wireshark can capture only the packets that the packet capture
+   library - libpcap on UNIX-flavored OSes, and the WinPcap port to
+   Windows of libpcap on Windows - can capture, and libpcap/WinPcap can
+   capture only the packets that the OS's raw packet capture mechanism
+   (or the WinPcap driver, and the underlying OS networking code and
+   network interface drivers, on Windows) will allow it to capture.
+
+   Unless the OS always supplies packets with errors such as invalid CRCs
+   to the raw packet capture mechanism, or can be configured to do so,
+   invalid CRCs to the raw packet capture mechanism, Wireshark - and
+   other programs that capture raw packets, such as tcpdump - cannot
+   capture those packets. You will have to determine whether your OS
+   needs to be so configured and, if so, can be so configured, configure
+   it if necessary and possible, and make whatever changes to libpcap and
+   the packet capture program you're using are necessary, if any, to
+   support capturing those packets.
+
+   Most OSes probably do not support capturing packets with invalid CRCs
+   on Ethernet, and probably do not support it on most other link-layer
+   types. Some drivers on some OSes do support it, such as some Ethernet
+   drivers on FreeBSD; in those OSes, you might always get those packets,
+   or you might only get them if you capture in promiscuous mode (you'd
+   have to determine which is the case).
 
    Note that libpcap does not currently supply to programs that use it an
-   indication of whether the packet's CRC was invalid (because the drivers
-   themselves do not supply that information to the raw packet capture
-   mechanism); therefore, Ethereal will not indicate which packets had CRC
-   errors unless the FCS was captured (see the next question) and you're using
-   Ethereal 0.9.15 and later, in which case Ethereal will check the CRC and
-   indicate whether it's correct or not.
+   indication of whether the packet's CRC was invalid (because the
+   drivers themselves do not supply that information to the raw packet
+   capture mechanism); therefore, Wireshark will not indicate which
+   packets had CRC errors unless the FCS was captured (see the next
+   question) and you're using Wireshark 0.9.15 and later, in which case
+   Wireshark will check the CRC and indicate whether it's correct or not.
 
    Q 7.10: How can I capture entire frames, including the FCS?
 
-   A: Ethereal can only capture data that the packet capture library - libpcap
-   on UNIX-flavored OSes, and the WinPcap port to Windows of libpcap on Windows
-   - can capture, and libpcap/WinPcap can capture only the data that the OS's
-   raw packet capture mechanism (or the WinPcap driver, and the underlying OS
-   networking code and network interface drivers, on Windows) will allow it to
-   capture.
-
-   For any particular link-layer network type, unless the OS supplies the FCS
-   of a frame as part of the frame, or can be configured to do so, Ethereal -
-   and other programs that capture raw packets, such as tcpdump - cannot
-   capture the FCS of a frame. You will have to determine whether your OS needs
-   to be so configured and, if so, can be so configured, configure it if
-   necessary and possible, and make whatever changes to libpcap and the packet
-   capture program you're using are necessary, if any, to support capturing the
-   FCS of a frame.
+   A: Wireshark can only capture data that the packet capture library -
+   libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of
+   libpcap on Windows - can capture, and libpcap/WinPcap can capture only
+   the data that the OS's raw packet capture mechanism (or the WinPcap
+   driver, and the underlying OS networking code and network interface
+   drivers, on Windows) will allow it to capture.
+
+   For any particular link-layer network type, unless the OS supplies the
+   FCS of a frame as part of the frame, or can be configured to do so,
+   Wireshark - and other programs that capture raw packets, such as
+   tcpdump - cannot capture the FCS of a frame. You will have to
+   determine whether your OS needs to be so configured and, if so, can be
+   so configured, configure it if necessary and possible, and make
+   whatever changes to libpcap and the packet capture program you're
+   using are necessary, if any, to support capturing the FCS of a frame.
 
    Most OSes do not support capturing the FCS of a frame on Ethernet, and
-   probably do not support it on most other link-layer types. Some drivres on
-   some OSes do support it, such as some (all?) Ethernet drivers on NetBSD and
-   possibly the driver for Apple's gigabit Ethernet interface in Mac OS X; in
-   those OSes, you might always get the FCS, or you might only get the FCS if
-   you capture in promiscuous mode (you'd have to determine which is the case).
-
-   Versions of Ethereal prior to 0.9.15 will not treat an Ethernet FCS in a
-   captured packet as an FCS. 0.9.15 and later will attempt to determine
-   whether there's an FCS at the end of the frame and, if it thinks there is,
-   will display it as such, and will check whether it's the correct CRC-32
-   value or not.
-
-   Q 7.11: I'm capturing packets on a machine on a VLAN; why don't the packets
-   I'm capturing have VLAN tags?
-
-   A: You might be capturing on what might be called a "VLAN interface" - the
-   way a particular OS makes VLANs plug into the networking stack might, for
-   example, be to have a network device object for the physical interface,
-   which takes VLAN packets, strips off the VLAN header and constructs an
-   Ethernet header, and passes that packet to an internal network device object
-   for the VLAN, which then passes the packets onto various higher-level
-   protocol implementations.
-
-   In order to see the raw Ethernet packets, rather than "de-VLANized" packets,
-   you would have to capture not on the virtual interface for the VLAN, but on
-   the interface corresponding to the physical network device, if possible. See
-   the Wireshark Wiki item on VLAN capturing for details.
-
-   Q 7.12: Why does Ethereal hang after I stop a capture?
-
-   A: The most likely reason for this is that Wireshark is trying to look up an
-   IP address in the capture to convert it to a name (so that, for example, it
-   can display the name in the source address or destination address columns),
-   and that lookup process is taking a very long time.
-
-   Ethereal calls a routine in the OS of the machine on which it's running to
-   convert of IP addresses to the corresponding names. That routine probably
-   does one or more of:
+   probably do not support it on most other link-layer types. Some
+   drivres on some OSes do support it, such as some (all?) Ethernet
+   drivers on NetBSD and possibly the driver for Apple's gigabit Ethernet
+   interface in Mac OS X; in those OSes, you might always get the FCS, or
+   you might only get the FCS if you capture in promiscuous mode (you'd
+   have to determine which is the case).
+
+   Versions of Wireshark prior to 0.9.15 will not treat an Ethernet FCS
+   in a captured packet as an FCS. 0.9.15 and later will attempt to
+   determine whether there's an FCS at the end of the frame and, if it
+   thinks there is, will display it as such, and will check whether it's
+   the correct CRC-32 value or not.
+
+   Q 7.11: I'm capturing packets on a machine on a VLAN; why don't the
+   packets I'm capturing have VLAN tags?
+
+   A: You might be capturing on what might be called a "VLAN interface" -
+   the way a particular OS makes VLANs plug into the networking stack
+   might, for example, be to have a network device object for the
+   physical interface, which takes VLAN packets, strips off the VLAN
+   header and constructs an Ethernet header, and passes that packet to an
+   internal network device object for the VLAN, which then passes the
+   packets onto various higher-level protocol implementations.
+
+   In order to see the raw Ethernet packets, rather than "de-VLANized"
+   packets, you would have to capture not on the virtual interface for
+   the VLAN, but on the interface corresponding to the physical network
+   device, if possible. See the Wireshark Wiki item on VLAN capturing for
+   details.
+
+   Q 7.12: Why does Wireshark hang after I stop a capture?
+
+   A: The most likely reason for this is that Wireshark is trying to look
+   up an IP address in the capture to convert it to a name (so that, for
+   example, it can display the name in the source address or destination
+   address columns), and that lookup process is taking a very long time.
+
+   Wireshark calls a routine in the OS of the machine on which it's
+   running to convert of IP addresses to the corresponding names. That
+   routine probably does one or more of:
      * a search of a system file listing IP addresses and names;
      * a lookup using DNS;
      * on UNIX systems, a lookup using NIS;
      * on Windows systems, a NetBIOS-over-TCP query.
 
-   If a DNS server that's used in an address lookup is not responding, the
-   lookup will fail, but will only fail after a timeout while the system
-   routine waits for a reply.
-
-   In addition, on Windows systems, if the DNS lookup of the address fails,
-   either because the server isn't responding or because there are no records
-   in the DNS that could be used to map the address to a name, a
-   NetBIOS-over-TCP query will be made. That query involves sending a message
-   to the NetBIOS-over-TCP name service on that machine, asking for the name
-   and other information about the machine. If the machine isn't running
-   software that responds to those queries - for example, many non-Windows
-   machines wouldn't be running that software - the lookup will only fail after
-   a timeout. Those timeouts can cause the lookup to take a long time.
-
-   If you disable network address-to-name translation - for example, by turning
-   off the "Enable network name resolution" option in the "Capture Options"
-   dialog box for starting a network capture - the lookups of the address won't
-   be done, which may speed up the process of reading the capture file after
-   the capture is stopped. You can make that setting the default by selecting
-   "Preferences" from the "Edit" menu, turning off the "Enable network name
-   resolution" option in the "Name resolution" options in the preferences
-   disalog box, and using the "Save" button in that dialog box; note that this
-   will save all your current preference settings.
-
-   If Ethereal hangs when reading a capture even with network name resolution
-   turned off, there might, for example, be a bug in one of Ethereal's
-   dissectors for a protocol causing it to loop infinitely. If you're not
-   running the most recent release of Ethereal, you should first upgrade to
-   that release, as, if there's a bug of that sort, it might've been fixed in a
-   release after the one you're running. If the hang occurs in the most recent
-   release of Ethereal, the bug should be reported to the Wireshark developers'
-   mailing list at wireshark-dev@wireshark.org.
-
-   On UNIX-flavored OSes, please try to force Ethereal to dump core, by sending
-   it a SIGABRT signal (usually signal 6) with the kill command, and then get a
-   stack trace if you have a debugger installed. A stack trace can be obtained
-   by using your debugger (gdb in this example), the Wireshark binary, and the
-   resulting core file. Here's an example of how to use the gdb command
-   backtrace to do so.
-        $ gdb ethereal core
+   If a DNS server that's used in an address lookup is not responding,
+   the lookup will fail, but will only fail after a timeout while the
+   system routine waits for a reply.
+
+   In addition, on Windows systems, if the DNS lookup of the address
+   fails, either because the server isn't responding or because there are
+   no records in the DNS that could be used to map the address to a name,
+   a NetBIOS-over-TCP query will be made. That query involves sending a
+   message to the NetBIOS-over-TCP name service on that machine, asking
+   for the name and other information about the machine. If the machine
+   isn't running software that responds to those queries - for example,
+   many non-Windows machines wouldn't be running that software - the
+   lookup will only fail after a timeout. Those timeouts can cause the
+   lookup to take a long time.
+
+   If you disable network address-to-name translation - for example, by
+   turning off the "Enable network name resolution" option in the
+   "Capture Options" dialog box for starting a network capture - the
+   lookups of the address won't be done, which may speed up the process
+   of reading the capture file after the capture is stopped. You can make
+   that setting the default by selecting "Preferences" from the "Edit"
+   menu, turning off the "Enable network name resolution" option in the
+   "Name resolution" options in the preferences disalog box, and using
+   the "Save" button in that dialog box; note that this will save all
+   your current preference settings.
+
+   If Wireshark hangs when reading a capture even with network name
+   resolution turned off, there might, for example, be a bug in one of
+   Wireshark's dissectors for a protocol causing it to loop infinitely.
+   If you're not running the most recent release of Wireshark, you should
+   first upgrade to that release, as, if there's a bug of that sort, it
+   might've been fixed in a release after the one you're running. If the
+   hang occurs in the most recent release of Wireshark, the bug should be
+   reported to the Wireshark developers' mailing list at
+   wireshark-dev@wireshark.org.
+
+   On UNIX-flavored OSes, please try to force Wireshark to dump core, by
+   sending it a SIGABRT signal (usually signal 6) with the kill command,
+   and then get a stack trace if you have a debugger installed. A stack
+   trace can be obtained by using your debugger (gdb in this example),
+   the Wireshark binary, and the resulting core file. Here's an example
+   of how to use the gdb command backtrace to do so.
+        $ gdb wireshark core
         (gdb) backtrace
         ..... prints the stack trace
         (gdb) quit
         $
 
-   The core dump file may be named "ethereal.core" rather than "core" on some
-   platforms (e.g., BSD systems).
-
-   Also, if at all possible, please send a copy of the capture file that caused
-   the problem; when capturing packets, Ethereal normally writes captured
-   packets to a temporary file, which will probably be in /tmp or /var/tmp on
-   UNIX-flavored OSes, \TEMP on the main system disk (normally C:) on Windows
-   9x/Me/NT 4.0, and \Documents and Settings\your login name\Local
-   Settings\Temp on the main system disk on Windows 2000/Windows XP/Windows
-   Server 2003, so the capture file will probably be there. It will have a name
-   beginning with ether, with some mixture of letters and numbers after that.
-   Please don't send a trace file greater than 1 MB when compressed; instead,
-   make it available via FTP or HTTP, or say it's available but leave it up to
-   a developer to ask for it. If the trace file contains sensitive information
-   (e.g., passwords), then please do not send it.
+   The core dump file may be named "wireshark.core" rather than "core" on
+   some platforms (e.g., BSD systems).
+
+   Also, if at all possible, please send a copy of the capture file that
+   caused the problem; when capturing packets, Wireshark normally writes
+   captured packets to a temporary file, which will probably be in /tmp
+   or /var/tmp on UNIX-flavored OSes, \TEMP on the main system disk
+   (normally C:) on Windows 9x/Me/NT 4.0, and \Documents and
+   Settings\your login name\Local Settings\Temp on the main system disk
+   on Windows 2000/Windows XP/Windows Server 2003, so the capture file
+   will probably be there. It will have a name beginning with ether, with
+   some mixture of letters and numbers after that. Please don't send a
+   trace file greater than 1 MB when compressed; instead, make it
+   available via FTP or HTTP, or say it's available but leave it up to a
+   developer to ask for it. If the trace file contains sensitive
+   information (e.g., passwords), then please do not send it.
 
 8. Capturing packets on Windows
 
-   Q 8.1: I'm running Ethereal on Windows; why does some network interface on
-   my machine not show up in the list of interfaces in the "Interface:" field
-   in the dialog box popped up by "Capture->Start", and/or why does Ethereal
-   give me an error if I try to capture on that interface?
-
-   A: If you are running Ethereal on Windows NT 4.0, Windows 2000, Windows XP,
-   or Windows Server 2003, and this is the first time you have run a
-   WinPcap-based program (such as Ethereal, or TShark, or WinDump, or
-   Analyzer, or...) since the machine was rebooted, you need to run that
-   program from an account with administrator privileges; once you have run
-   such a program, you will not need administrator privileges to run any such
-   programs until you reboot.
-
-   If you are running on Windows 95/98/Me, or if you are running on Windows NT
-   4.0/Windows 2000/Windows XP/Windows Server 2003 and have administrator
-   privileges or a WinPcap-based program has been run with those privileges
-   since the machine rebooted, this problem might clear up if you completely
-   un-install WinPcap and then re-install it.
-
-   If that doesn't work, then note that Ethereal relies on the WinPcap library,
-   on the WinPcap device driver, and on the facilities that come with the OS on
-   which it's running in order to do captures.
+   Q 8.1: I'm running Wireshark on Windows; why does some network
+   interface on my machine not show up in the list of interfaces in the
+   "Interface:" field in the dialog box popped up by "Capture->Start",
+   and/or why does Wireshark give me an error if I try to capture on that
+   interface?
+
+   A: If you are running Wireshark on Windows NT 4.0, Windows 2000,
+   Windows XP, or Windows Server 2003, and this is the first time you
+   have run a WinPcap-based program (such as Wireshark, or TShark, or
+   WinDump, or Analyzer, or...) since the machine was rebooted, you need
+   to run that program from an account with administrator privileges;
+   once you have run such a program, you will not need administrator
+   privileges to run any such programs until you reboot.
+
+   If you are running on Windows 95/98/Me, or if you are running on
+   Windows NT 4.0/Windows 2000/Windows XP/Windows Server 2003 and have
+   administrator privileges or a WinPcap-based program has been run with
+   those privileges since the machine rebooted, this problem might clear
+   up if you completely un-install WinPcap and then re-install it.
+
+   If that doesn't work, then note that Wireshark relies on the WinPcap
+   library, on the WinPcap device driver, and on the facilities that come
+   with the OS on which it's running in order to do captures.
 
    Therefore, if the OS, the WinPcap library, or the WinPcap driver don't
-   support capturing on a particular network interface device, Ethereal won't
-   be able to capture on that device.
+   support capturing on a particular network interface device, Wireshark
+   won't be able to capture on that device.
 
    Note that:
     1. 2.02 and earlier versions of the WinPcap driver and library that
-       Ethereal uses for packet capture didn't support Token Ring interfaces;
-       versions 2.1 and later support Token Ring, and the current version of
-       Ethereal works with (and, in fact, requires) WinPcap 2.1 or later.
-       If you are having problems capturing on Token Ring interfaces, and you
-       have WinPcap 2.02 or an earlier version of WinPcap installed, you should
-       uninstall WinPcap, download and install the current version of WinPcap,
-       and then install the latest version of Ethereal.
-    2. On Windows 95, 98, or Me, sometimes more than one interface will be
-       given the same name; if that is the case, you will only be able to
-       capture on one of those interfaces - it's not clear to which one the
-       name, when used in a WinPcap-based application, will refer. For example,
-       if you have a PPP serial interface and a VPN interface, they might show
-       up with the same name, for example "ppp-mac", and if you try to capture
-       on "ppp-mac", it might not capture on the interface you're currently
-       using. In that case, you might, for example, have to remove the VPN
-       interface from the system in order to capture on the PPP serial
-       interface.
-    3. WinPcap 2.3 has problems supporting PPP WAN interfaces on Windows NT
-       4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to avoid
-       those problems, support for PPP WAN interfaces on those versions of
-       Windows has been disabled in WinPcap 3.0. Regular dial-up lines, ISDN
-       lines, ADSL connections using PPPoE or PPPoA, and various other lines
-       such as T1/E1 lines are all PPP interfaces, so those interfaces might
-       not show up on the list of interfaces in the "Capture Options" dialog on
-       those OSes.
-       On Windows 2000, Windows XP, and Windows Server 2003, but not Windows NT
-       4.0 or Windows Vista Beta 1, you should be able to capture on the
-       "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
-       the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
-       un-install it and install the final 3.1 release.) See the Wireshark Wiki
-       item on PPP capturing for details.
-    4. WinPcap prior to 3.0 does not support multiprocessor machines (note that
-       machines with a single multi-threaded processor, such as Intel's new
-       multi-threaded x86 processors, are multiprocessor machines as far as the
-       OS and WinPcap are concerned), and recent 2.x versions of WinPcap refuse
-       to operate if they detect that they're running on a multiprocessor
-       machine, which means that they may not show any network interfaces. You
-       will need to use WinPcap 3.0 to capture on a multiprocessor machine.
+       Wireshark uses for packet capture didn't support Token Ring
+       interfaces; versions 2.1 and later support Token Ring, and the
+       current version of Wireshark works with (and, in fact, requires)
+       WinPcap 2.1 or later.
+       If you are having problems capturing on Token Ring interfaces, and
+       you have WinPcap 2.02 or an earlier version of WinPcap installed,
+       you should uninstall WinPcap, download and install the current
+       version of WinPcap, and then install the latest version of
+       Wireshark.
+    2. On Windows 95, 98, or Me, sometimes more than one interface will
+       be given the same name; if that is the case, you will only be able
+       to capture on one of those interfaces - it's not clear to which
+       one the name, when used in a WinPcap-based application, will
+       refer. For example, if you have a PPP serial interface and a VPN
+       interface, they might show up with the same name, for example
+       "ppp-mac", and if you try to capture on "ppp-mac", it might not
+       capture on the interface you're currently using. In that case, you
+       might, for example, have to remove the VPN interface from the
+       system in order to capture on the PPP serial interface.
+    3. WinPcap 2.3 has problems supporting PPP WAN interfaces on Windows
+       NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to
+       avoid those problems, support for PPP WAN interfaces on those
+       versions of Windows has been disabled in WinPcap 3.0. Regular
+       dial-up lines, ISDN lines, ADSL connections using PPPoE or PPPoA,
+       and various other lines such as T1/E1 lines are all PPP
+       interfaces, so those interfaces might not show up on the list of
+       interfaces in the "Capture Options" dialog on those OSes.
+       On Windows 2000, Windows XP, and Windows Server 2003, but not
+       Windows NT 4.0 or Windows Vista Beta 1, you should be able to
+       capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta
+       releases called it the "NdisWanAdapter"; if you're using a 3.1
+       beta release, you should un-install it and install the final 3.1
+       release.) See the Wireshark Wiki item on PPP capturing for
+       details.
+    4. WinPcap prior to 3.0 does not support multiprocessor machines
+       (note that machines with a single multi-threaded processor, such
+       as Intel's new multi-threaded x86 processors, are multiprocessor
+       machines as far as the OS and WinPcap are concerned), and recent
+       2.x versions of WinPcap refuse to operate if they detect that
+       they're running on a multiprocessor machine, which means that they
+       may not show any network interfaces. You will need to use WinPcap
+       3.0 to capture on a multiprocessor machine.
 
    If an interface doesn't show up in the list of interfaces in the
-   "Interface:" field, and you know the name of the interface, try entering
-   that name in the "Interface:" field and capturing on that device.
-
-   If the attempt to capture on it succeeds, the interface is somehow not being
-   reported by the mechanism Ethereal uses to get a list of interfaces. Try
-   listing the interfaces with WinDump; see the WinDump Web site or the local
-   mirror of the WinDump Web site for information on using WinDump.
-
-   You would run WinDump with the -D flag; if it lists the interface, please
-   report this to wireshark-dev@wireshark.org giving full details of the problem,
-   including
-     * the operating system you're using, and the version of that operating
-       system;
+   "Interface:" field, and you know the name of the interface, try
+   entering that name in the "Interface:" field and capturing on that
+   device.
+
+   If the attempt to capture on it succeeds, the interface is somehow not
+   being reported by the mechanism Wireshark uses to get a list of
+   interfaces. Try listing the interfaces with WinDump; see the WinDump
+   Web site for information on using WinDump.
+
+   You would run WinDump with the -D flag; if it lists the interface,
+   please report this to wireshark-dev@wireshark.org giving full details
+   of the problem, including
+     * the operating system you're using, and the version of that
+       operating system;
      * the type of network device you're using;
      * the output of WinDump.
 
-   If WinDump does not list the interface, this is almost certainly a problem
-   with one or more of:
+   If WinDump does not list the interface, this is almost certainly a
+   problem with one or more of:
      * the operating system you're using;
      * the device driver for the interface you're using;
      * the WinPcap library and/or the WinPcap device driver;
 
-   so first check the WinPcap FAQ, the local mirror of that FAQ, or the
-   Wiretapped.net mirror of that FAQ, to see if your problem is mentioned
-   there. If not, then see the WinPcap support page (or the local mirror of
-   that page) - check the "Submitting bugs" section.
+   so first check the WinPcap FAQ or the Wiretapped.net mirror of that
+   FAQ, to see if your problem is mentioned there. If not, then see the
+   WinPcap support page - check the "Submitting bugs" section.
 
-   If you are having trouble capturing on a particular network interface, first
-   try capturing on that device with WinDump; see the WinDump Web site or the
-   local mirror of the WinDump Web site for information on using WinDump.
+   If you are having trouble capturing on a particular network interface,
+   first try capturing on that device with WinDump; see the WinDump Web
+   site for information on using WinDump.
 
    If you can capture on the interface with WinDump, send mail to
-   wireshark-users@wireshark.org giving full details of the problem, including
-     * the operating system you're using, and the version of that operating
-       system;
+   wireshark-users@wireshark.org giving full details of the problem,
+   including
+     * the operating system you're using, and the version of that
+       operating system;
      * the type of network device you're using;
-     * the error message you get from Ethereal.
+     * the error message you get from Wireshark.
 
    If you cannot capture on the interface with WinDump, this is almost
    certainly a problem with one or more of:
@@ -1874,195 +1113,209 @@ cies
      * the device driver for the interface you're using;
      * the WinPcap library and/or the WinPcap device driver;
 
-   so first check the WinPcap FAQ, the local mirror of that FAQ, or the
-   Wiretapped.net mirror of that FAQ, to see if your problem is mentioned
-   there. If not, then see the WinPcap support page (or the local mirror of
-   that page) - check the "Submitting bugs" section.
+   so first check the WinPcap FAQ or the Wiretapped.net mirror of that
+   FAQ, to see if your problem is mentioned there. If not, then see the
+   WinPcap support page - check the "Submitting bugs" section.
 
    You may also want to ask the wireshark-users@wireshark.org and the
-   winpcap-users@winpcap.org mailing lists to see if anybody happens to know
-   about the problem and know a workaround or fix for the problem. (Note that
-   you will have to subscribe to that list in order to be allowed to mail to
-   it; see the WinPcap support page, or the local mirror of that page, for
-   information on the mailing list.) In your mail, please give full details of
-   the problem, as described above, and also indicate that the problem occurs
-   with WinDump, not just with Ethereal.
-
-   Q 8.2: I'm running Ethereal on Windows; why do no network interfaces show up
-   in the list of interfaces in the "Interface:" field in the dialog box popped
-   up by "Capture->Start"?
-
-   A: This is really the same question as the previous one; see the response to
-   that question.
-
-   Q 8.3: I'm running Ethereal on Windows; why doesn't my serial port/ADSL
-   modem/ISDN modem show up in the list of interfaces in the "Interface:" field
-   in the dialog box popped up by "Capture->Start"?
-
-   A: Internet access on those devices is often done with the Point-to-Point
-   (PPP) protocol; WinPcap 2.3 has problems supporting PPP WAN interfaces on
-   Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to
-   avoid those problems, support for PPP WAN interfaces on those versions of
-   Windows has been disabled in WinPcap 3.0.
-
-   On Windows 2000, Windows XP, and Windows Server 2003, but not Windows NT 4.0
-   or Windows Vista Beta 1, you should be able to capture on the
-   "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it the
-   "NdisWanAdapter"; if you're using a 3.1 beta release, you should un-install
-   it and install the final 3.1 release.) See the Wireshark Wiki item on PPP
-   capturing for details.
-
-   Q 8.4: I'm running Ethereal on Windows NT 4.0/Windows 2000/Windows
-   XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN, etc.)
-   interface, and it shows up in the "Interface" item in the "Capture Options"
-   dialog box. Why can no packets be sent on or received from that network
-   while I'm trying to capture traffic on that interface?
-
-   A: Some versions of WinPcap have problems with PPP WAN interfaces on Windows
-   NT 4.0, Windows 2000, Windows XP, and Windows Server 2003; one symptom that
-   may be seen is that attempts to capture in promiscuous mode on the interface
-   cause the interface to be incapable of sending or receiving packets. You can
-   disable promiscuous mode using the -p command-line flag or the item in the
-   "Capture Preferences" dialog box, but this may mean that outgoing packets,
-   or incoming packets, won't be seen in the capture.
-
-   On Windows 2000, Windows XP, and Windows Server 2003, but not Windows NT 4.0
-   or Windows Vista Beta 1, you should be able to capture on the
-   "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it the
-   "NdisWanAdapter"; if you're using a 3.1 beta release, you should un-install
-   it and install the final 3.1 release.) See the Wireshark Wiki item on PPP
-   capturing for details.
-
-   Q 8.5: I'm running Ethereal on Windows 95/98/Me, on a machine with more than
-   one network adapter of the same type; why does Ethereal show all of those
-   adapters with the same name, not letting me use any of those adapters other
-   than the first one?
-
-   A: Unfortunately, Windows 95/98/Me gives the same name to multiple instances
-   of the type of same network adapter. Therefore, WinPcap cannot distinguish
-   between them, so a WinPcap-based application can capture only on the first
-   such interface; Wireshark is a libpcap/WinPcap-based application.
-
-   Q 8.6: I'm running Ethereal on Windows; why am I not seeing any traffic
-   being sent by the machine running Ethereal?
-
-   A: If you are running some form of VPN client software, it might be causing
-   this problem; people have seen this problem when they have Check Point's VPN
-   software installed on their machine. If that's the cause of the problem, you
-   will have to remove the VPN software in order to have Ethereal (or any other
-   application using WinPcap) see outgoing packets; unfortunately, neither we
-   nor the WinPcap developers know any way to make WinPcap and the VPN software
-   work well together.
-
-   Also, some drivers for Windows (especially some wireless network interface
-   drivers) apparently do not, when running in promiscuous mode, arrange that
-   outgoing packets are delivered to the software that requested that the
-   interface run promiscuously; try turning promiscuous mode off.
-
-   Q 8.7: When I capture on Windows in promiscuous mode, I can see packets
-   other than those sent to or from my machine; however, those packets show up
-   with a "Short Frame" indication, unlike packets to or from my machine. What
-   should I do to arrange that I see those packets in their entirety?
-
-   A: In at least some cases, this appears to be the result of PGPnet running
-   on the network interface on which you're capturing; turn it off on that
-   interface.
-
-   Q 8.8: I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why
-   are the time stamps on packets wrong?
-
-   A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap 3.0
-   and later releases.
+   winpcap-users@winpcap.org mailing lists to see if anybody happens to
+   know about the problem and know a workaround or fix for the problem.
+   (Note that you will have to subscribe to that list in order to be
+   allowed to mail to it; see the WinPcap support page for information on
+   the mailing list.) In your mail, please give full details of the
+   problem, as described above, and also indicate that the problem occurs
+   with WinDump, not just with Wireshark.
+
+   Q 8.2: I'm running Wireshark on Windows; why do no network interfaces
+   show up in the list of interfaces in the "Interface:" field in the
+   dialog box popped up by "Capture->Start"?
+
+   A: This is really the same question as the previous one; see the
+   response to that question.
 
-   Q 8.9: I'm trying to capture 802.11 traffic on Windows; why am I not seeing
-   any packets?
+   Q 8.3: I'm running Wireshark on Windows; why doesn't my serial
+   port/ADSL modem/ISDN modem show up in the list of interfaces in the
+   "Interface:" field in the dialog box popped up by "Capture->Start"?
+
+   A: Internet access on those devices is often done with the
+   Point-to-Point (PPP) protocol; WinPcap 2.3 has problems supporting PPP
+   WAN interfaces on Windows NT 4.0, Windows 2000, Windows XP, and
+   Windows Server 2003, and, to avoid those problems, support for PPP WAN
+   interfaces on those versions of Windows has been disabled in WinPcap
+   3.0.
+
+   On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
+   NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
+   "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
+   the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
+   un-install it and install the final 3.1 release.) See the Wireshark
+   Wiki item on PPP capturing for details.
+
+   Q 8.4: I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows
+   XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN,
+   etc.) interface, and it shows up in the "Interface" item in the
+   "Capture Options" dialog box. Why can no packets be sent on or
+   received from that network while I'm trying to capture traffic on that
+   interface?
+
+   A: Some versions of WinPcap have problems with PPP WAN interfaces on
+   Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003; one
+   symptom that may be seen is that attempts to capture in promiscuous
+   mode on the interface cause the interface to be incapable of sending
+   or receiving packets. You can disable promiscuous mode using the -p
+   command-line flag or the item in the "Capture Preferences" dialog box,
+   but this may mean that outgoing packets, or incoming packets, won't be
+   seen in the capture.
+
+   On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
+   NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
+   "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
+   the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
+   un-install it and install the final 3.1 release.) See the Wireshark
+   Wiki item on PPP capturing for details.
+
+   Q 8.5: I'm running Wireshark on Windows 95/98/Me, on a machine with
+   more than one network adapter of the same type; why does Wireshark
+   show all of those adapters with the same name, not letting me use any
+   of those adapters other than the first one?
+
+   A: Unfortunately, Windows 95/98/Me gives the same name to multiple
+   instances of the type of same network adapter. Therefore, WinPcap
+   cannot distinguish between them, so a WinPcap-based application can
+   capture only on the first such interface; Wireshark is a
+   libpcap/WinPcap-based application.
+
+   Q 8.6: I'm running Wireshark on Windows; why am I not seeing any
+   traffic being sent by the machine running Wireshark?
+
+   A: If you are running some form of VPN client software, it might be
+   causing this problem; people have seen this problem when they have
+   Check Point's VPN software installed on their machine. If that's the
+   cause of the problem, you will have to remove the VPN software in
+   order to have Wireshark (or any other application using WinPcap) see
+   outgoing packets; unfortunately, neither we nor the WinPcap developers
+   know any way to make WinPcap and the VPN software work well together.
+
+   Also, some drivers for Windows (especially some wireless network
+   interface drivers) apparently do not, when running in promiscuous
+   mode, arrange that outgoing packets are delivered to the software that
+   requested that the interface run promiscuously; try turning
+   promiscuous mode off.
+
+   Q 8.7: When I capture on Windows in promiscuous mode, I can see
+   packets other than those sent to or from my machine; however, those
+   packets show up with a "Short Frame" indication, unlike packets to or
+   from my machine. What should I do to arrange that I see those packets
+   in their entirety?
+
+   A: In at least some cases, this appears to be the result of PGPnet
+   running on the network interface on which you're capturing; turn it
+   off on that interface.
+
+   Q 8.8: I'm capturing packets on {Windows 95, Windows 98, Windows Me};
+   why are the time stamps on packets wrong?
+
+   A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap
+   3.0 and later releases.
+
+   Q 8.9: I'm trying to capture 802.11 traffic on Windows; why am I not
+   seeing any packets?
 
    A: At least some 802.11 card drivers on Windows appear not to see any
-   packets if they're running in promiscuous mode. Try turning promiscuous mode
-   off; you'll only be able to see packets sent by and received by your
-   machine, not third-party traffic, and it'll look like Ethernet traffic and
-   won't include any management or control frames, but that's a limitation of
-   the card drivers.
-
-   See MicroLogix's list of cards supported with WinPcap for information on
-   support of various adapters and drivers with WinPcap.
-
-   Q 8.10: I'm trying to capture 802.11 traffic on Windows; why am I seeing
-   packets received by the machine on which I'm capturing traffic, but not
-   packets sent by that machine?
-
-   A: This appears to be another problem with promiscuous mode; try turning it
-   off.
-
-   Q 8.11: I'm trying to capture Ethernet VLAN traffic on Windows, and I'm
-   capturing on a "raw" Ethernet device rather than a "VLAN interface", so that
-   I can see the VLAN headers; why am I seeing packets received by the machine
-   on which I'm capturing traffic, but not packets sent by that machine?
-
-   A: The way the Windows networking code works probably means that packets are
-   sent on a "VLAN interface" rather than the "raw" device, so packets sent by
-   the machine will only be seen when you capture on the "VLAN interface". If
-   so, you will be unable to see outgoing packets when capturing on the "raw"
-   device, so you are stuck with a choice between seeing VLAN headers and
-   seeing outgoing packets.
+   packets if they're running in promiscuous mode. Try turning
+   promiscuous mode off; you'll only be able to see packets sent by and
+   received by your machine, not third-party traffic, and it'll look like
+   Ethernet traffic and won't include any management or control frames,
+   but that's a limitation of the card drivers.
+
+   See MicroLogix's list of cards supported with WinPcap for information
+   on support of various adapters and drivers with WinPcap.
+
+   Q 8.10: I'm trying to capture 802.11 traffic on Windows; why am I
+   seeing packets received by the machine on which I'm capturing traffic,
+   but not packets sent by that machine?
+
+   A: This appears to be another problem with promiscuous mode; try
+   turning it off.
+
+   Q 8.11: I'm trying to capture Ethernet VLAN traffic on Windows, and
+   I'm capturing on a "raw" Ethernet device rather than a "VLAN
+   interface", so that I can see the VLAN headers; why am I seeing
+   packets received by the machine on which I'm capturing traffic, but
+   not packets sent by that machine?
+
+   A: The way the Windows networking code works probably means that
+   packets are sent on a "VLAN interface" rather than the "raw" device,
+   so packets sent by the machine will only be seen when you capture on
+   the "VLAN interface". If so, you will be unable to see outgoing
+   packets when capturing on the "raw" device, so you are stuck with a
+   choice between seeing VLAN headers and seeing outgoing packets.
 
 9. Capturing packets on UN*Xes
 
-   Q 9.1: I'm running Ethereal on a UNIX-flavored OS; why does some network
-   interface on my machine not show up in the list of interfaces in the
-   "Interface:" field in the dialog box popped up by "Capture->Start", and/or
-   why does Ethereal give me an error if I try to capture on that interface?
-
-   A: You may need to run Ethereal from an account with sufficient privileges
-   to capture packets, such as the super-user account, or may need to give your
-   account sufficient privileges to capture packets. Only those interfaces that
-   Ethereal can open for capturing show up in that list; if you don't have
-   sufficient privileges to capture on any interfaces, no interfaces will show
-   up in the list. See the Wireshark Wiki item on capture privileges for details
-   on how to give a particular account or account group capture privileges on
-   platforms where that can be done.
-
-   If you are running Ethereal from an account with sufficient privileges, then
-   note that Ethereal relies on the libpcap library, and on the facilities that
-   come with the OS on which it's running in order to do captures. On some
-   OSes, those facilities aren't present by default; see the Wireshark Wiki item
-   on adding capture support for details.
-
-   And, even if you're running with an account that has sufficient privileges
-   to capture, and capture support is present in your OS, if the OS or the
-   libpcap library don't support capturing on a particular network interface
-   device or particular types of devices, Ethereal won't be able to capture on
-   that device.
-
-   On Solaris, note that libpcap 0.6.2 and earlier didn't support Token Ring
-   interfaces; the current version, 0.7.2, does support Token Ring, and the
-   current version of Ethereal works with libcap 0.7.2 and later.
+   Q 9.1: I'm running Wireshark on a UNIX-flavored OS; why does some
+   network interface on my machine not show up in the list of interfaces
+   in the "Interface:" field in the dialog box popped up by
+   "Capture->Start", and/or why does Wireshark give me an error if I try
+   to capture on that interface?
+
+   A: You may need to run Wireshark from an account with sufficient
+   privileges to capture packets, such as the super-user account, or may
+   need to give your account sufficient privileges to capture packets.
+   Only those interfaces that Wireshark can open for capturing show up in
+   that list; if you don't have sufficient privileges to capture on any
+   interfaces, no interfaces will show up in the list. See the Wireshark
+   Wiki item on capture privileges for details on how to give a
+   particular account or account group capture privileges on platforms
+   where that can be done.
+
+   If you are running Wireshark from an account with sufficient
+   privileges, then note that Wireshark relies on the libpcap library,
+   and on the facilities that come with the OS on which it's running in
+   order to do captures. On some OSes, those facilities aren't present by
+   default; see the Wireshark Wiki item on adding capture support for
+   details.
 
-   If an interface doesn't show up in the list of interfaces in the
-   "Interface:" field, and you know the name of the interface, try entering
-   that name in the "Interface:" field and capturing on that device.
+   And, even if you're running with an account that has sufficient
+   privileges to capture, and capture support is present in your OS, if
+   the OS or the libpcap library don't support capturing on a particular
+   network interface device or particular types of devices, Wireshark
+   won't be able to capture on that device.
 
-   If the attempt to capture on it succeeds, the interface is somehow not being
-   reported by the mechanism Ethereal uses to get a list of interfaces; please
-   report this to wireshark-dev@wireshark.org giving full details of the problem,
-   including
-     * the operating system you're using, and the version of that operating
-       system (for Linux, give both the version number of the kernel and the
-       name and version number of the distribution you're using);
+   On Solaris, note that libpcap 0.6.2 and earlier didn't support Token
+   Ring interfaces; the current version, 0.7.2, does support Token Ring,
+   and the current version of Wireshark works with libcap 0.7.2 and
+   later.
+
+   If an interface doesn't show up in the list of interfaces in the
+   "Interface:" field, and you know the name of the interface, try
+   entering that name in the "Interface:" field and capturing on that
+   device.
+
+   If the attempt to capture on it succeeds, the interface is somehow not
+   being reported by the mechanism Wireshark uses to get a list of
+   interfaces; please report this to wireshark-dev@wireshark.org giving
+   full details of the problem, including
+     * the operating system you're using, and the version of that
+       operating system (for Linux, give both the version number of the
+       kernel and the name and version number of the distribution you're
+       using);
      * the type of network device you're using.
 
-   If you are having trouble capturing on a particular network interface, and
-   you've made sure that (on platforms that require it) you've arranged that
-   packet capture support is present, as per the above, first try capturing on
-   that device with tcpdump.
+   If you are having trouble capturing on a particular network interface,
+   and you've made sure that (on platforms that require it) you've
+   arranged that packet capture support is present, as per the above,
+   first try capturing on that device with tcpdump.
 
    If you can capture on the interface with tcpdump, send mail to
-   wireshark-users@wireshark.org giving full details of the problem, including
-     * the operating system you're using, and the version of that operating
-       system (for Linux, give both the version number of the kernel and the
-       name and version number of the distribution you're using);
+   wireshark-users@wireshark.org giving full details of the problem,
+   including
+     * the operating system you're using, and the version of that
+       operating system (for Linux, give both the version number of the
+       kernel and the name and version number of the distribution you're
+       using);
      * the type of network device you're using;
-     * the error message you get from Ethereal.
+     * the error message you get from Wireshark.
 
    If you cannot capture on the interface with tcpdump, this is almost
    certainly a problem with one or more of:
@@ -2071,76 +1324,81 @@ cies
      * the libpcap library;
 
    so you should report the problem to the company or organization that
-   produces the OS (in the case of a Linux distribution, report the problem to
-   whoever produces the distribution).
+   produces the OS (in the case of a Linux distribution, report the
+   problem to whoever produces the distribution).
 
    You may also want to ask the wireshark-users@wireshark.org and the
-   tcpdump-workers@tcpdump.org mailing lists to see if anybody happens to know
-   about the problem and know a workaround or fix for the problem. In your
-   mail, please give full details of the problem, as described above, and also
-   indicate that the problem occurs with tcpdump not just with Ethereal.
-
-   Q 9.2: I'm running Ethereal on a UNIX-flavored OS; why do no network
-   interfaces show up in the list of interfaces in the "Interface:" field in
-   the dialog box popped up by "Capture->Start"?
+   tcpdump-workers@tcpdump.org mailing lists to see if anybody happens to
+   know about the problem and know a workaround or fix for the problem.
+   In your mail, please give full details of the problem, as described
+   above, and also indicate that the problem occurs with tcpdump not just
+   with Wireshark.
+
+   Q 9.2: I'm running Wireshark on a UNIX-flavored OS; why do no network
+   interfaces show up in the list of interfaces in the "Interface:" field
+   in the dialog box popped up by "Capture->Start"?
 
-   A: This is really the same question as the previous one; see the response to
-   that question.
+   A: This is really the same question as the previous one; see the
+   response to that question.
 
-   Q 9.3: I'm capturing packets on Linux; why do the time stamps have only
-   100ms resolution, rather than 1us resolution?
+   Q 9.3: I'm capturing packets on Linux; why do the time stamps have
+   only 100ms resolution, rather than 1us resolution?
 
-   A: Ethereal gets time stamps from libpcap/WinPcap, and libpcap/WinPcap get
-   them from the OS kernel, so Ethereal - and any other program using libpcap,
-   such as tcpdump - is at the mercy of the time stamping code in the OS for
-   time stamps.
+   A: Wireshark gets time stamps from libpcap/WinPcap, and
+   libpcap/WinPcap get them from the OS kernel, so Wireshark - and any
+   other program using libpcap, such as tcpdump - is at the mercy of the
+   time stamping code in the OS for time stamps.
 
-   At least on x86-based machines, Linux can get high-resolution time stamps on
-   newer processors with the Time Stamp Counter (TSC) register; for example,
-   Intel x86 processors, starting with the Pentium Pro, and including all x86
-   processors since then, have had a TSC, and other vendors probably added the
-   TSC at some point to their families of x86 processors.
+   At least on x86-based machines, Linux can get high-resolution time
+   stamps on newer processors with the Time Stamp Counter (TSC) register;
+   for example, Intel x86 processors, starting with the Pentium Pro, and
+   including all x86 processors since then, have had a TSC, and other
+   vendors probably added the TSC at some point to their families of x86
+   processors.
 
-   The Linux kernel must be configured with the CONFIG_X86_TSC option enabled
-   in order to use the TSC. Make sure this option is enabled in your kernel.
+   The Linux kernel must be configured with the CONFIG_X86_TSC option
+   enabled in order to use the TSC. Make sure this option is enabled in
+   your kernel.
 
-   In addition, some Linux distributions may have bugs in their versions of the
-   kernel that cause packets not to be given high-resolution time stamps even
-   if the TSC is enabled. See, for example, bug 61111 for Red Hat Linux 7.2. If
-   your distribution has a bug such as this, you may have to run a standard
-   kernel from kernel.org in order to get high-resolution time stamps.
+   In addition, some Linux distributions may have bugs in their versions
+   of the kernel that cause packets not to be given high-resolution time
+   stamps even if the TSC is enabled. See, for example, bug 61111 for Red
+   Hat Linux 7.2. If your distribution has a bug such as this, you may
+   have to run a standard kernel from kernel.org in order to get
+   high-resolution time stamps.
 
 10. Capturing packets on wireless LANs
 
-   Q 10.1: How can I capture raw 802.11 frames, including non-data (management,
-   beacon) frames?
+   Q 10.1: How can I capture raw 802.11 frames, including non-data
+   (management, beacon) frames?
 
-   A: That depends on the operating system on which you're running, and on the
-   802.11 interface on which you're capturing.
+   A: That depends on the operating system on which you're running, and
+   on the 802.11 interface on which you're capturing.
 
-   This would probably require that you capture in promiscuous mode or in the
-   mode called "monitor mode" or "RFMON mode". On some platforms, or with some
-   cards, this might require that you capture in monitor mode - promiscuous
-   mode might not be sufficient. If you want to capture traffic on networks
-   other than the one with which you're associated, you will have to capture in
-   monitor mode.
+   This would probably require that you capture in promiscuous mode or in
+   the mode called "monitor mode" or "RFMON mode". On some platforms, or
+   with some cards, this might require that you capture in monitor mode -
+   promiscuous mode might not be sufficient. If you want to capture
+   traffic on networks other than the one with which you're associated,
+   you will have to capture in monitor mode.
 
-   Not all operating systems support capturing non-data packets and, even on
-   operating systems that do support it, not all drivers, and thus not all
-   interfaces, support it. Even on those that do, monitor mode might not be
-   supported by the operating system or by the drivers for all interfaces.
+   Not all operating systems support capturing non-data packets and, even
+   on operating systems that do support it, not all drivers, and thus not
+   all interfaces, support it. Even on those that do, monitor mode might
+   not be supported by the operating system or by the drivers for all
+   interfaces.
 
    NOTE: an interface running in monitor mode will, on most if not all
-   platforms, not be able to act as a regular network interface; putting it
-   into monitor mode will, in effect, take your machine off of whatever network
-   it's on as long as the interface is in monitor mode, allowing it only to
-   passively capture packets.
+   platforms, not be able to act as a regular network interface; putting
+   it into monitor mode will, in effect, take your machine off of
+   whatever network it's on as long as the interface is in monitor mode,
+   allowing it only to passively capture packets.
 
-   This means that you should disable name resolution when capturing in monitor
-   mode; otherwise, when Ethereal (or TShark, or tcpdump) tries to display
-   IP addresses as host names, it will probably block for a long time trying to
-   resolve the name because it will not be able to communicate with any DNS or
-   NIS servers.
+   This means that you should disable name resolution when capturing in
+   monitor mode; otherwise, when Wireshark (or TShark, or tcpdump) tries
+   to display IP addresses as host names, it will probably block for a
+   long time trying to resolve the name because it will not be able to
+   communicate with any DNS or NIS servers.
 
    See the Wireshark Wiki item on 802.11 capturing for details.
 
@@ -2148,138 +1406,137 @@ cies
 
    A: Whether you will be able to capture in monitor mode depends on the
    operating system, adapter, and driver you're using. See the previous
-   question for information on monitor mode, including a link to the Ethereal
-   Wiki page that gives details on 802.11 capturing.
+   question for information on monitor mode, including a link to the
+   Wireshark Wiki page that gives details on 802.11 capturing.
 
 11. Viewing traffic
 
    Q 11.1: Why am I seeing lots of packets with incorrect TCP checksums?
 
-   A: If the packets that have incorrect TCP checksums are all being sent by
-   the machine on which Wireshark is running, this is probably because the
-   network interface on which you're capturing does TCP checksum offloading.
-   That means that the TCP checksum is added to the packet by the network
-   interface, not by the OS's TCP/IP stack; when capturing on an interface,
-   packets being sent by the host on which you're capturing are directly handed
-   to the capture interface by the OS, which means that they are handed to the
-   capture interface without a TCP checksum being added to them.
-
-   The only way to prevent this from happening would be to disable TCP checksum
-   offloading, but
+   A: If the packets that have incorrect TCP checksums are all being sent
+   by the machine on which Wireshark is running, this is probably because
+   the network interface on which you're capturing does TCP checksum
+   offloading. That means that the TCP checksum is added to the packet by
+   the network interface, not by the OS's TCP/IP stack; when capturing on
+   an interface, packets being sent by the host on which you're capturing
+   are directly handed to the capture interface by the OS, which means
+   that they are handed to the capture interface without a TCP checksum
+   being added to them.
+
+   The only way to prevent this from happening would be to disable TCP
+   checksum offloading, but
     1. that might not even be possible on some OSes;
     2. that could reduce networking performance significantly.
 
-   However, you can disable the check that Ethereal does of the TCP checksum,
-   so that it won't report any packets as having TCP checksum errors, and so
-   that it won't refuse to do TCP reassembly due to a packet having an
-   incorrect TCP checksum. That can be set as an Ethereal preference by
-   selecting "Preferences" from the "Edit" menu, opening up the "Protocols"
-   list in the left-hand pane of the "Preferences" dialog box, selecting "TCP",
-   from that list, turning off the "Check the validity of the TCP checksum when
-   possible" option, clicking "Save" if you want to save that setting in your
-   preference file, and clicking "OK".
+   However, you can disable the check that Wireshark does of the TCP
+   checksum, so that it won't report any packets as having TCP checksum
+   errors, and so that it won't refuse to do TCP reassembly due to a
+   packet having an incorrect TCP checksum. That can be set as an
+   Wireshark preference by selecting "Preferences" from the "Edit" menu,
+   opening up the "Protocols" list in the left-hand pane of the
+   "Preferences" dialog box, selecting "TCP", from that list, turning off
+   the "Check the validity of the TCP checksum when possible" option,
+   clicking "Save" if you want to save that setting in your preference
+   file, and clicking "OK".
 
    It can also be set on the Wireshark or TShark command line with a -o
    tcp.check_checksum:false command-line flag, or manually set in your
    preferences file by adding a tcp.check_checksum:false line.
 
-   Q 11.2: I've just installed Ethereal, and the traffic on my local LAN is
-   boring. Where can I find more interesting captures?
+   Q 11.2: I've just installed Wireshark, and the traffic on my local LAN
+   is boring. Where can I find more interesting captures?
 
    A: We have a collection of strange and exotic sample capture files at
    http://wiki.wireshark.org/SampleCaptures
 
-   Q 11.3: Why doesn't Ethereal correctly identify RTP packets? It shows them
-   only as UDP.
+   Q 11.3: Why doesn't Wireshark correctly identify RTP packets? It shows
+   them only as UDP.
 
-   A: Ethereal can identify a UDP datagram as containing a packet of a
+   A: Wireshark can identify a UDP datagram as containing a packet of a
    particular protocol running atop UDP only if
-    1. The protocol in question has a particular standard port number, and the
-       UDP source or destination port number is that port
-    2. Packets of that protocol can be identified by looking for a "signature"
-       of some type in the packet - i.e., some data that, if Ethereal finds it
-       in some particular part of a packet, means that the packet is almost
-       certainly a packet of that type.
-    3. Some other traffic earlier in the capture indicated that, for example,
-       UDP traffic between two particular addresses and ports will be RTP
-       traffic.
-
-   RTP doesn't have a standard port number, so 1) doesn't work; it doesn't, as
-   far as I know, have any "signature", so 2) doesn't work.
-
-   That leaves 3). If there's RTSP traffic that sets up an RTP session, then,
-   at least in some cases, the RTSP dissector will set things up so that
-   subsequent RTP traffic will be identified. Currently, that's the only place
-   we do that; there may be other places.
-
-   However, there will always be places where Wireshark is simply incapable of
-   deducing that a given UDP flow is RTP; a mechanism would be needed to allow
-   the user to specify that a given conversation should be treated as RTP. As
-   of Ethereal 0.8.16, such a mechanism exists; if you select a UDP or TCP
-   packet, the right mouse button menu will have a "Decode As..." menu item,
-   which will pop up a dialog box letting you specify that the source port, the
-   destination port, or both the source and destination ports of the packet
-   should be dissected as some particular protocol.
-
-   Q 11.4: Why doesn't Ethereal show Yahoo Messenger packets in captures that
-   contain Yahoo Messenger traffic?
-
-   A: Ethereal only recognizes as Yahoo Messenger traffic packets to or from
-   TCP port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP segments that
-   start with the middle of a Yahoo Messenger packet that takes more than one
-   TCP segment will not be recognized as Yahoo Messenger packets (even if the
-   TCP segment also contains the beginning of another Yahoo Messenger packet).
+    1. The protocol in question has a particular standard port number,
+       and the UDP source or destination port number is that port
+    2. Packets of that protocol can be identified by looking for a
+       "signature" of some type in the packet - i.e., some data that, if
+       Wireshark finds it in some particular part of a packet, means that
+       the packet is almost certainly a packet of that type.
+    3. Some other traffic earlier in the capture indicated that, for
+       example, UDP traffic between two particular addresses and ports
+       will be RTP traffic.
+
+   RTP doesn't have a standard port number, so 1) doesn't work; it
+   doesn't, as far as I know, have any "signature", so 2) doesn't work.
+
+   That leaves 3). If there's RTSP traffic that sets up an RTP session,
+   then, at least in some cases, the RTSP dissector will set things up so
+   that subsequent RTP traffic will be identified. Currently, that's the
+   only place we do that; there may be other places.
+
+   However, there will always be places where Wireshark is simply
+   incapable of deducing that a given UDP flow is RTP; a mechanism would
+   be needed to allow the user to specify that a given conversation
+   should be treated as RTP. As of Wireshark 0.8.16, such a mechanism
+   exists; if you select a UDP or TCP packet, the right mouse button menu
+   will have a "Decode As..." menu item, which will pop up a dialog box
+   letting you specify that the source port, the destination port, or
+   both the source and destination ports of the packet should be
+   dissected as some particular protocol.
+
+   Q 11.4: Why doesn't Wireshark show Yahoo Messenger packets in captures
+   that contain Yahoo Messenger traffic?
+
+   A: Wireshark only recognizes as Yahoo Messenger traffic packets to or
+   from TCP port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP
+   segments that start with the middle of a Yahoo Messenger packet that
+   takes more than one TCP segment will not be recognized as Yahoo
+   Messenger packets (even if the TCP segment also contains the beginning
+   of another Yahoo Messenger packet).
 
 12. Filtering traffic
 
-   Q 12.1: I saved a filter and tried to use its name to filter the display;
-   why do I get an "Unexpected end of filter string" error?
+   Q 12.1: I saved a filter and tried to use its name to filter the
+   display; why do I get an "Unexpected end of filter string" error?
 
-   A: You cannot use the name of a saved display filter as a filter. To filter
-   the display, you can enter a display filter expression - not the name of a
-   saved display filter - in the "Filter:" box at the bottom of the display,
-   and type the key or press the "Apply" button (that does not require you to
-   have a saved filter), or, if you want to use a saved filter, you can press
-   the "Filter:" button, select the filter in the dialog box that pops up, and
-   press the "OK" button.
+   A: You cannot use the name of a saved display filter as a filter. To
+   filter the display, you can enter a display filter expression - not
+   the name of a saved display filter - in the "Filter:" box at the
+   bottom of the display, and type the key or press the "Apply" button
+   (that does not require you to have a saved filter), or, if you want to
+   use a saved filter, you can press the "Filter:" button, select the
+   filter in the dialog box that pops up, and press the "OK" button.
 
-   Q 12.2: How can I search for, or filter, packets that have a particular
-   string anywhere in them?
+   Q 12.2: How can I search for, or filter, packets that have a
+   particular string anywhere in them?
 
-   A: If you want to do this when capturing, you can't. That's a feature that
-   would be hard to implement in capture filters without changes to the capture
-   filter code, which, on many platforms, is in the OS kernel and, on other
-   platforms, is in the libpcap library.
+   A: If you want to do this when capturing, you can't. That's a feature
+   that would be hard to implement in capture filters without changes to
+   the capture filter code, which, on many platforms, is in the OS kernel
+   and, on other platforms, is in the libpcap library.
 
-   In releases prior to 0.9.14, you also can't search for, or filter, packets
-   containing a particular string even after you've captured them.
+   In releases prior to 0.9.14, you also can't search for, or filter,
+   packets containing a particular string even after you've captured
+   them.
 
    In 0.9.14, you can search for, but not filter, packets that have a
-   particular string; this has been added to the "Find Frame" dialog ("Find
-   Frame" under the "Edit" menu, or control-F).
+   particular string; this has been added to the "Find Frame" dialog
+   ("Find Frame" under the "Edit" menu, or control-F).
 
    In 0.9.15 and later, you can search for those packets using either the
    mechanism introduced in 0.9.14 or using the new "contains" operator in
-   filter expressions, which lets you search the entire packet or text string
-   or byte string fields in the packet; the "contains" operator can also be
-   used in expressions used to filter the display.
+   filter expressions, which lets you search the entire packet or text
+   string or byte string fields in the packet; the "contains" operator
+   can also be used in expressions used to filter the display.
 
    Q 12.3: How do I filter a capture to see traffic for virus XXX?
 
-   A: For some viruses/worms there might be a capture filter to recognize the
-   virus traffic. Check the CaptureFilters page on the Wireshark Wiki to see if
-   anybody's added such a filter.
+   A: For some viruses/worms there might be a capture filter to recognize
+   the virus traffic. Check the CaptureFilters page on the Wireshark Wiki
+   to see if anybody's added such a filter.
 
-   Note that Ethereal was not designed to be an intrusion detection system; you
-   might be able to use it as an IDS, but in most cases software designed to be
-   an IDS, such as Snort or Prelude, will probably work better.
+   Note that Wireshark was not designed to be an intrusion detection
+   system; you might be able to use it as an IDS, but in most cases
+   software designed to be an IDS, such as Snort or Prelude, will
+   probably work better.
 
    The Bleeding Edge of Snort has a collection of signatures for Snort to
    detect various viruses, worms, and the like.
-
-   Please send support questions about Ethereal to the
-   wireshark-users[AT]wireshark.org mailing list.
-   For corrections/additions/suggestions for this web page (and not Ethereal
-   support questions), please send email to wireshark-web[AT]wireshark.org.
-   Last modified: Thu, February 23 2006.
-   "Ethereal" and the "e" logo are registered trademarks of Ethereal, Inc.