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, 1387 insertions, 1409 deletions

diff --git a/help/faq.txt b/help/faq.txt
index ce7fe5bad6..a76ee0a1de 100644
--- a/help/faq.txt
+++ b/help/faq.txt
@@ -8,1557 +8,1535 @@
 
    INDEX
 
+
 1. General Questions:
 
-1.1 What is Wireshark?
+   1.1 What is Wireshark?
 
-1.2 What's up with the name change? Is Wireshark a fork?
+   1.2 What's up with the name change? Is Wireshark a fork?
 
-1.3 Where can I get help?
+   1.3 Where can I get help?
 
-1.4 How much does Wireshark cost?
+   1.4 How much does Wireshark cost?
 
-1.5 Can I use Wireshark commercially?
+   1.5 Can I use Wireshark commercially?
 
-1.6 Can I use Wireshark as part of my commercial product?
+   1.6 Can I use Wireshark as part of my commercial product?
 
-1.7 What protocols are currently supported?
+   1.7 What protocols are currently supported?
 
-1.8 Are there any plans to support {your favorite protocol}?
+   1.8 Are there any plans to support {your favorite protocol}?
 
-1.9 Can Wireshark read capture files from {your favorite network
-analyzer}?
+   1.9 Can Wireshark read capture files from {your favorite network
+   analyzer}?
 
-1.10 What devices can Wireshark use to capture packets?
+   1.10 What devices can Wireshark use to capture packets?
 
-1.11 Does Wireshark work on Windows Me?
+   1.11 Does Wireshark work on Windows Me? 
 
-1.12 Does Wireshark work on Windows XP?
+   1.12 Does Wireshark work on Windows XP? 
 
 2. Downloading Wireshark:
 
-2.1 Why do I get an error when I try to run the Win32 installer?
+   2.1 Why do I get an error when I try to run the Win32 installer?
 
 3. Installing Wireshark:
 
-3.1 I installed the Wireshark RPM (or other package); why did it
-install TShark but not Wireshark?
+   3.1 I installed the Wireshark RPM (or other package); why did it
+   install TShark but not Wireshark?
 
 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
+   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 Wireshark 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 Wireshark?
+   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? 
 
-4.4 When I try to build Wireshark on Solaris, why does the link fail
-complaining that plugin_list is undefined?
+   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 Wireshark on Windows, why does the build fail
-because of conflicts between winsock.h and winsock2.h?
+   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. Starting Wireshark:
 
-5.1 Why does Wireshark crash with a Bus Error when I try to run it on
-Solaris 8?
+   5.1 Why does Wireshark crash with a Bus Error when I try to run it on
+   Solaris 8?
 
-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.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.3 When I try to run Wireshark, why does it complain about
-sprint_realloc_objid being undefined?
+   5.3 When I try to run Wireshark, why does it complain about
+   sprint_realloc_objid being undefined?
 
-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?
+   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?
 
-5.5 I've installed Wireshark 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 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.2 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 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.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 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.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.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.4 Why am I not seeing any traffic when I try to capture traffic?
 
-7.5 Can Wireshark 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.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.9 How can I capture packets with CRC errors? 
 
-7.10 How can I capture entire frames, including the FCS?
+   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 Wireshark 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 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 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 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 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 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 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.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.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?
-
-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?
+   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 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 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 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 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 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.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.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? 
+
+   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? 
 
 9. Capturing packets on UN*Xes:
 
-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?
+   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? 
 
-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.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?
+   10.2 How do I capture on an 802.11 device in monitor mode?
 
 11. Viewing traffic:
 
-11.1 Why am I seeing lots of packets with incorrect TCP checksums?
+   11.1 Why am I seeing lots of packets with incorrect TCP checksums?
 
-11.2 I've just installed Wireshark, and the traffic on my local LAN is
-boring. Where can I find more interesting captures?
+   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 Wireshark 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 Wireshark 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?
+   12.3 How do I filter a capture to see traffic for virus XXX? 
 
 1. General Questions
 
-Q 1.1: What is Wireshark?
+   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.
+   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.
+   For more information, please see the About Wireshark page.
 
-Q 1.2: What's up with the name change? Is Wireshark a fork?
+   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 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 CACE Technologies.
-
-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 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.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 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 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 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
-    Grabber captures
-  • AIX's iptrace captures
-  • Accellent's 5Views LAN agent output
-  • Cinco Networks NetXRay captures
-  • Cisco Secure Intrusion Detection System IPLog output
-  • CoSine L2 debug output
-  • DBS Etherwatch VMS text output
-  • Endace Measurement Systems' ERF format captures
-  • EyeSDN USB S0 traces
-  • HP-UX nettl captures
-  • ISDN4BSD project i4btrace captures
-  • Linux Bluez Bluetooth stack hcidump -w traces
-  • 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 Instruments Observer version 9 captures
-  • Novell LANalyzer captures
-  • RADCOM's WAN/LAN analyzer captures
-  • Shomiti/Finisar Surveyor captures
-  • 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
-  • 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.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 Wireshark as well.
-
-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: 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 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 CACE Technologies.
+
+   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 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.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 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 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 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
+       Grabber captures
+     * AIX's iptrace captures
+     * Accellent's 5Views LAN agent output
+     * Cinco Networks NetXRay captures
+     * Cisco Secure Intrusion Detection System IPLog output
+     * CoSine L2 debug output
+     * DBS Etherwatch VMS text output
+     * Endace Measurement Systems' ERF format captures
+     * EyeSDN USB S0 traces
+     * HP-UX nettl captures
+     * ISDN4BSD project i4btrace captures
+     * Linux Bluez Bluetooth stack hcidump -w traces
+     * 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 Instruments Observer version 9 captures
+     * Novell LANalyzer captures
+     * RADCOM's WAN/LAN analyzer captures
+     * Shomiti/Finisar Surveyor captures
+     * 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
+     * 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.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 Wireshark as well.
+
+   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.
 
 2. Downloading Wireshark
 
-Q 2.1: Why do I get an error when I try to run the Win32 installer?
+   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:
+   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;
+     * WS_FTP from Ipswitch,
+     * the ftp command that comes with Windows.
 
-  • 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.
 
 3. Installing Wireshark
 
-Q 3.1: I installed the Wireshark RPM (or other package); why did it
-install TShark but not Wireshark?
+   Q 3.1: I installed the Wireshark RPM (or other package); why did it
+   install TShark but not Wireshark?
 
-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.
+   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.
 
 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.
-
-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 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.
+   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.
+
+   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 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: 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
-
+   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: 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: 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;
-
-so:
-
-  • 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.
+   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;
+
+   so:
+     * 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 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:
-
-  • 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. 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
--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.
-
-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.
-
-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 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 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 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.
-
-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 Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
-
-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 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 Wireshark or TShark.
-
-Note, however, 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 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?
-
-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 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."
-
-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?
-
-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 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.
-
-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 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 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: 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, 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: 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 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 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.
-
+   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:
+     * 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. 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
+   -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.
+
+   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.
+
+   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 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 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 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.
+
+   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 Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
+
+   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 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 Wireshark or TShark.
+
+   Note, however, 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 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?
+
+   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 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."
+
+   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?
+
+   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 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.
+
+   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 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 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: 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, 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: 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 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 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 "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.
+   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 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, 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
-    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 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:
-
-  • 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 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 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;
-  • the type of network device you're using;
-  • 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:
-
-  • 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 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 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.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.
+   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, 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
+       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 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:
+     * 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 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 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;
+     * the type of network device you're using;
+     * 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:
+     * 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 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 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.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.
 
 9. Capturing packets on UN*Xes
 
-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.
-
-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.
-
-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 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);
-  • the type of network device you're using;
-  • 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:
-
-  • the operating system you're using;
-  • the device driver for the interface you're using;
-  • 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).
-
-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 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.
-
-Q 9.3: I'm capturing packets on Linux; why do the time stamps have
-only 100ms resolution, rather than 1us resolution?
-
-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.
-
-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.
+   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.
+
+   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.
+
+   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 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);
+     * the type of network device you're using;
+     * 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:
+     * the operating system you're using;
+     * the device driver for the interface you're using;
+     * 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).
+
+   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 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.
+
+   Q 9.3: I'm capturing packets on Linux; why do the time stamps have
+   only 100ms resolution, rather than 1us resolution?
+
+   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.
+
+   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.
 
 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.
+   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.
 
-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.
+   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.
+   See the Wireshark Wiki item on 802.11 capturing for details.
 
-Q 10.2: How do I capture on an 802.11 device in monitor mode?
+   Q 10.2: How do I capture on an 802.11 device in monitor mode?
 
-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
-Wireshark Wiki page that gives details on 802.11 capturing.
+   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
+   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
-
- 1. that might not even be possible on some OSes;
- 2. that could reduce networking performance significantly.
-
-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 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 Wireshark correctly identify RTP packets? It shows
-them only as UDP.
-
-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
-    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).
+   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
+    1. that might not even be possible on some OSes;
+    2. that could reduce networking performance significantly.
+
+   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 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 Wireshark correctly identify RTP packets? It shows
+   them only as UDP.
+
+   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
+       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?
-
-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.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.2: How can I search for, or filter, packets that have a
-particular string anywhere in them?
+   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: 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.
+   Q 12.2: How can I search for, or filter, packets that have a
+   particular string anywhere in 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.
+   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 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).
+   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.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.
+   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).
 
-Q 12.3: How do I filter a capture to see traffic for virus XXX?
+   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.
 
-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.
+   Q 12.3: How do I filter a capture to see traffic for virus XXX?
 
-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.
+   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.
 
-The Bleeding Edge of Snort has a collection of signatures for Snort to
-detect various viruses, worms, and the like.
+   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.