Merging upstream version 4.4.0.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 1084 insertions, 0 deletions

diff --git a/doc/faq.adoc b/doc/faq.adoc
new file mode 100644
index 00000000..9173e615
--- /dev/null
+++ b/doc/faq.adoc
@@ -0,0 +1,1084 @@
+include::attributes.adoc[]
+:stylesheet: ws.css
+:linkcss:
+:copycss: {css_dir}/{stylesheet}
+:toc:
+
+= Wireshark Frequently Asked Questions
+
+== General Questions
+
+=== What is Wireshark?
+
+Wireshark® is a network protocol analyzer. It lets you capture and
+interactively browse the traffic running on a computer network. It has a
+rich and powerful feature set and is world's most popular tool of its
+kind. It runs on most computing platforms including Windows, macOS,
+Linux, and UNIX. Network professionals, security experts, developers,
+and educators around the world use it regularly. It is freely available
+as open source, and is released under the GNU General Public License
+version 2.
+
+It is developed and maintained by a global team of protocol experts,
+and it is an example of a
+https://en.wikipedia.org/wiki/Disruptive_technology[disruptive
+technology].
+
+Wireshark used to be known as Ethereal®. See the next question for
+details about the name change. If you're still using Ethereal, it is
+strongly recommended that you upgrade to Wireshark as Ethereal is
+unsupported and has known security vulnerabilities.
+
+For more information, please see the
+https://www.wireshark.org/about.html[About Wireshark] page.
+
+[#wheretogethelp]
+=== Where can I get help?
+
+Community support is available on the https://ask.wireshark.org/[Q&A site] and on the wireshark-users mailing list.
+Subscription information and archives for all of Wireshark's mailing lists can be found at https://lists.wireshark.org/.
+// An IRC channel dedicated to Wireshark can be found at
+// irc://irc.freenode.net/wireshark[irc://irc.freenode.net/wireshark].
+
+=== What kind of shark is Wireshark?
+
+_carcharodon photoshopia_.
+
+=== How is Wireshark pronounced, spelled and capitalized?
+
+Wireshark is pronounced as the word _wire_ followed immediately by
+the word _shark_. Exact pronunciation and emphasis may vary depending on
+your locale (e.g. Arkansas).
+
+It's spelled with a capital _W_, followed by a lower-case _ireshark_.
+It is not a CamelCase word, i.e., _WireShark_ is incorrect.
+
+=== How much does Wireshark cost?
+
+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
+https://www.gnu.org/licenses/gpl-2.0.html[the GNU General Public License
+version 2]. See
+https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html[the GNU GPL
+FAQ] for some more information.
+
+=== But I just paid someone on eBay for a copy of Wireshark! Did I get ripped off?
+
+That depends. Did they provide any sort of value-added product or
+service, such as installation support, installation media, training,
+trace file analysis, or funky-colored shark-themed socks? Probably not.
+
+Wireshark is https://www.wireshark.org/download.html[available for
+anyone to download, absolutely free, at any time]. Paying for a copy
+implies that you should get something for your money.
+
+=== Can I use Wireshark commercially?
+
+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 link:#derived_work_gpl[the next entry in the FAQ].
+
+=== Can I use Wireshark as part of my commercial product?
+
+As noted, Wireshark is licensed under
+https://www.gnu.org/licenses/gpl-2.0.html[the GNU General Public
+License, version 2]. 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
+https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html[GPL FAQ] for
+more details; in particular, note the answer to
+https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLCommercially[the
+question about modifying a GPLed program and selling it commercially],
+and
+https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL[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
+https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLInProprietarySystem[this
+item in the GPL FAQ].
+
+We recommend keeping Wireshark and your product completely separate,
+communicating over sockets or pipes. If you're loading any part of
+Wireshark as a DLL, you're probably doing it wrong.
+
+=== Can you help me fill out this compliance form so that I can use Wireshark?
+
+// While we try to make sure that Wireshark is as easy as possible to obtain and use, please keep in mind that it’s developed by a team of volunteers and that filling out compliance forms is pretty far beyond the scope of what those volunteers do.
+
+Please contact the https://wiresharkfoundation.org[Wireshark Foundation] and they will be able to help you for a nominal fee.
+
+=== Can you sign this legal agreement so that I can use Wireshark?
+
+// As with the previous question, Wireshark is developed by a team of volunteers.
+// Even if they were inclined to do so, they aren’t authorized to sign agreements on behalf of the project.
+
+Please contact the https://wiresharkfoundation.org[Wireshark Foundation] and they will be able to help you for a somewhat less nominal fee.
+
+=== What protocols are currently supported?
+
+There are currently hundreds of supported protocols and media.
+Details can be found in the
+https://www.wireshark.org/docs/man-pages/wireshark.html[wireshark(1)]
+man page.
+
+=== Are there any plans to support {your favorite protocol}?
+
+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.
+
+=== Can Wireshark read capture files from {your favorite network analyzer}?
+
+Support for particular capture file formats is added to Wireshark as
+a result of people contributing that support; no formal plans for adding
+support for particular capture file formats 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.
+
+=== What devices can Wireshark use to capture packets?
+
+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 {wireshark-wiki-url}CaptureSetup/NetworkMedia[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
+update the wiki page accordingly.
+
+It can also read a variety of capture file formats, including:
+
+* pcap, used by libpcap, tcpdump and various other tools
+* Oracle (previously Sun) snoop and atmsnoop captures
+* Finisar (previously Shomiti) Surveyor captures
+* Microsoft Network Monitor captures
+* Novell LANalyzer captures
+* AIX's iptrace captures
+* Cinco Networks NetXRay captures
+* NETSCOUT (previously Network Associates/Network General) Windows-based
+Sniffer captures
+* Network General/Network Associates DOS-based Sniffer captures
+(compressed or uncompressed)
+* LiveAction (previously WildPackets/Savvius) *Peek/EtherHelp/Packet Grabber
+captures
+* RADCOM's WAN/LAN analyzer captures
+* Viavi (previously Network Instruments) Observer captures
+* Lucent/Ascend router debug output
+* Toshiba's ISDN routers dump output
+* captures from HP-UX nettl
+* the output from i4btrace from the ISDN4BSD project
+* traces from the EyeSDN USB S0
+* the IPLog format output from the Cisco Secure Intrusion Detection System
+* pppd logs (pppdump format)
+* the text output from VMS's TCPIPtrace/TCPtrace/UCX$TRACE utilities
+* the text output from the DBS Etherwatch VMS utility
+* Visual Networks' Visual UpTime traffic capture
+* the output from CoSine L2 debug
+* the output from InfoVista (formerly Accellent) 5Views LAN agents
+* Endace Measurement Systems' ERF format captures
+* Linux Bluez Bluetooth stack hcidump -w traces
+* Catapult DCT2000 .out files
+* Gammu generated text output from Nokia DCT3 phones in Netmonitor mode
+* IBM Series (OS/400) Comm traces (ASCII & UNICODE)
+* Juniper Netscreen snoop files
+* Symbian OS btsnoop files
+* TamoSoft CommView files
+* Tektronix K12xx 32bit .rf5 format files
+* Tektronix K12 text file format captures
+* Apple PacketLogger files
+* Files from Aethra Telecommunications' PC108 software for their test
+instruments
+* Citrix NetScaler Trace files
+* Android Logcat binary and text format logs
+* Colasoft Capsa and Packet Builder captures
+* Micropross mplog files
+* Unigraf DPA-400 DisplayPort AUX channel monitor traces
+* 802.15.4 traces from Daintree's Sensor Network Analyzer
+* MPEG-2 Transport Streams as defined in ISO/IEC 13818-1
+* Log files from the _candump_ utility
+* Logs from the BUSMASTER tool
+* Ixia IxVeriWave raw captures
+* Rabbit Labs CAM Inspector files
+* systemd journal files
+* 3GPP TS 32.423 trace files
+
+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.
+
+=== Does Wireshark work on older versions of Windows such as Windows 7?
+
+Each major release branch of Wireshark supports the versions of Windows that are within their product lifecycle at the time of the “.0” release for that branch.
+For example, Wireshark 3.2.0 was released in December 2019, shortly before Windows 7 reached the end of its extended support in January 2020. As a result, each of the Wireshark 3.2._x_ releases supports Windows 7, even after January 2020.
+See the
+link:{wireshark-users-guide-url}ChIntroPlatforms.html[Microsoft Windows section of the User’s Guide]
+and the
+link:{wireshark-wiki-url}Development/LifeCycle[End Of Life Planning section of the Release Life Cycle wiki page]
+for more details.
+
+Npcap might not work well on Windows 8 and earlier, so you might want to install WinPcap instead.
+
+== Installing Wireshark
+
+=== I installed the Wireshark RPM (or other package); why did it install TShark but not Wireshark?
+
+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-qt”. Find it and install it.
+
+== Building Wireshark
+
+=== Why does building Wireshark fail due to missing headers (.h files)?
+
+If this is happening on Linux, it's likely due to missing development library packages.
+For example, Debian and Ubuntu ship the GLib library in the libglib2.0-0 package, but ship its header files and other development assets in the libglib2.0-dev package.
+
+We maintain setup scripts (_*-setup.sh_) for many major distributions in the _tools_ directory of the Wireshark sources that can install the required development packages for you.
+
+== Crashes and other fatal errors
+
+=== I have an _XXX_ network card on my machine; if I try to capture on it, why does my machine crash or reset itself?
+
+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/Npcap library and, if this is Windows, the Npcap device
+driver;
+
+so:
+
+* if you are using Windows, see {npcap-main-url}[the Npcap support page] - check the "Patches, Bug Reports, Questions, Suggestions,
+etc" 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).
+
+=== Why does my machine crash or reset itself when I select "Start" from the "Capture" menu or select "Preferences" from the "Edit" menu?
+
+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, Npcap bug that causes the system to crash when this
+happens; see the previous question.
+
+== Capturing packets
+
+[#promiscsniff]
+=== 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?
+
+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
+{wireshark-wiki-url}SwitchReference[the switch reference page] on
+{wireshark-wiki-url}[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 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 effort 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.
+
+=== 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?
+
+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 link:#promiscsniff[the same question as this
+earlier one]; see the response to that question.
+
+=== Why am I only seeing ARP packets when I try to capture traffic?
+
+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 link:#promiscsniff[the same question as this
+earlier one]; see the response to that question.
+
+=== Why am I not seeing any traffic when I try to capture traffic?
+
+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 link:#promiscsniff[this earlier question].
+
+Otherwise, on Windows, see the response to link:#capprobwin[this
+question] and, on a UNIX-flavored OS, see the response to
+link:#capprobunix[this question].
+
+=== How do I put an interface into promiscuous mode?
+
+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
+link:#promiscsniff[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 link:#promiscsniff[this earlier
+question] for more information on that.
+
+I.e., this is probably link:#promiscsniff[the same question as this
+earlier one]; see the response to that question.
+
+=== I can set a display filter just fine; why don't capture filters work?
+
+Capture filters currently use a different syntax than display
+filters. Here's the corresponding section from the
+https://www.wireshark.org/docs/man-pages/wireshark.html[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
+http://www.tcpdump.org/tcpdump_man.html[tcpdump(8)] man page.
+
+=== How can I capture packets with CRC errors?
+
+Wireshark can capture only the packets that the packet capture
+library - libpcap on UNIX-flavored OSes, and the Npcap port to Windows
+of libpcap on Windows - can capture, and libpcap/Npcap can capture only
+the packets that the OS's raw packet capture mechanism (or the Npcap
+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.
+
+=== How can I capture entire frames, including the FCS?
+
+Wireshark can only capture data that the packet capture library -
+libpcap on UNIX-flavored OSes, and the Npcap port to Windows of libpcap
+on Windows - can capture, and libpcap/Npcap can capture only the data
+that the OS's raw packet capture mechanism (or the Npcap 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
+drivers 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 macOS; 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.
+
+=== I'm capturing packets on a machine on a VLAN; why don't the packets I'm capturing have VLAN tags?
+
+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 {wireshark-wiki-url}CaptureSetup/VLAN[the
+Wireshark Wiki item on VLAN capturing] for details.
+
+=== Why does Wireshark hang after I stop a capture?
+
+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 dialog 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 mailto:wireshark-dev@wireshark.org[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 `\Documents and Settings\<your login name>\Local Settings\Temp` on the main system disk on Windows XP and
+Server 2003, and `\Users\<your login name>\AppData\Local\Temp` on the main
+system disk on Windows Vista and later, so the capture file will
+probably be there. If you are capturing on a single interface, it will
+have a name of the form,
+`wireshark_<iface>_YYYYmmddHHMMSS_XXXXXX.<fmt>`, where <fmt> is the
+capture file format (pcap or pcapng), and <iface> is the actual name of
+the interface you are capturing on; otherwise, if you are capturing on
+multiple interfaces, it will have a name of the form,
+`wireshark_<N>_interfaces_YYYYmmddHHMMSS_XXXXXX.<fmt>`, where <N> is the
+number of simultaneous interfaces you are capturing on. 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.
+
+== Capturing packets on Windows
+
+[#capprobwin]
+=== 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?
+
+Wireshark relies on the Npcap library, the Npcap device driver,
+and the facilities that come with the OS on which it's running in
+order to do captures.
+
+Therefore, if the OS, the Npcap library, or the Npcap driver don't
+support capturing on a particular network interface device, Wireshark
+won't be able to capture on that device.
+
+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
+https://www.winpcap.org/windump/[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
+mailto:wireshark-dev@wireshark.org[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 Npcap library and/or the Npcap device driver;
+
+so first check {npcap-main-url}guide/npcap-users-guide.html[the Npcap User's Guide] to see if your problem is mentioned there.
+If not, then see {npcap-main-url}[the main Npcap page] - check the "Patches, Bug Reports, Questions, Suggestions, etc" section.
+
+If you are having trouble capturing on a particular network interface,
+first try capturing on that device with WinDump; see
+https://www.winpcap.org/windump/[the WinDump Web site] for information on using
+WinDump.
+
+If you can capture on the interface with WinDump, send mail to
+mailto:wireshark-users@wireshark.org[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 Npcap library and/or the Npcap device driver;
+
+so first check {npcap-main-url}guide/npcap-users-guide.html[the Npcap User's Guide] to see if your problem is mentioned there.
+If not, then see {npcap-main-url}[the main Npcap page] - check the "Patches, Bug Reports, Questions, Suggestions, etc" section.
+
+You may also want to ask the
+mailto:wireshark-users@wireshark.org[wireshark-users@wireshark.org] and
+the mailto:dev@nmap.org[dev@nmap.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
+{npcap-main-url}[the Npcap 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.
+
+=== 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"?
+
+This is really link:#capprobwin[the same question as a previous one];
+see the response to that question.
+
+=== I'm running Wireshark on Windows; why am I not seeing any traffic being sent by the machine running Wireshark?
+
+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 Npcap) see outgoing packets;
+unfortunately, neither we nor the Npcap developers know any way to make
+Npcap 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.
+
+=== 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?
+
+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.
+
+=== I'm trying to capture 802.11 traffic on Windows; why am I not seeing any packets?
+
+You should first ensure that Npcap was installed with {npcap-main-url}/guide/npcap-devguide.html#npcap-feature-dot11[raw 802.11 support] and that monitor mode is enabled.
+
+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.
+
+// XXX Is this still relevant?
+// See the archived
+// https://web.archive.org/web/20090226193157/http://www.micro-logix.com/winpcap/Supported.asp[MicroLogix's
+// list of cards supported with WinPcap] for information on support of
+// various adapters and drivers with WinPcap.
+
+=== 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?
+
+This appears to be another problem with promiscuous mode; try turning
+it off.
+
+=== 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?
+
+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.
+
+== Capturing packets on UN*Xes
+
+[#capprobunix]
+=== 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?
+
+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
+{wireshark-wiki-url}CaptureSetup/CapturePrivileges[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 {wireshark-wiki-url}CaptureSetup/CaptureSupport[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 libpcap 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
+mailto:wireshark-dev@wireshark.org[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
+mailto:wireshark-users@wireshark.org[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
+mailto:wireshark-users@wireshark.org[wireshark-users@wireshark.org] and
+the
+mailto:tcpdump-workers@lists.tcpdump.org[tcpdump-workers@lists.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.
+
+=== 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"?
+
+This is really link:#capprobunix[the same question as the previous
+one]; see the response to that question.
+
+=== I'm capturing packets on Linux; why do the time stamps have only 100ms resolution, rather than 1us resolution?
+
+Wireshark gets time stamps from libpcap/Npcap, and libpcap/Npcap 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.
+
+== Capturing packets on wireless LANs
+
+=== How can I capture raw 802.11 frames, including non-data (management, beacon) frames?
+
+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.
+
+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.
+
+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 {wireshark-wiki-url}CaptureSetup/WLAN[the Wireshark Wiki
+item on 802.11 capturing] for details.
+
+=== How do I capture on an 802.11 device in monitor mode?
+
+Whether you will be able to capture in monitor mode depends on the
+operating system, adapter, and driver you're using. See
+link:#raw_80211_sniff[the previous question] for information on monitor
+mode, including a link to the Wireshark Wiki page that gives details on
+802.11 capturing.
+
+== Viewing traffic
+
+=== Why am I seeing lots of packets with incorrect TCP checksums?
+
+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.
+
+=== I've just installed Wireshark, and the traffic on my local LAN is boring. Where can I find more interesting captures?
+
+We have a collection of strange and exotic sample capture files at
+{wireshark-wiki-url}SampleCaptures[{wireshark-wiki-url}SampleCaptures]
+
+=== Why doesn't Wireshark correctly identify RTP packets? It shows them only as UDP.
+
+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.
+
+=== Why doesn't Wireshark show Yahoo Messenger packets in captures that contain Yahoo Messenger traffic?
+
+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).
+
+== Filtering traffic
+
+=== 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?
+
+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 <Enter> 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.
+
+=== How can I search for, or filter, packets that have a particular string anywhere in them?
+
+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.
+
+After capture, you can search for text by selecting _Edit→Find
+Packet..._ and making sure _String_ is selected. Alternately, you can
+use the "contains" display filter operator or "matches" operator if it's
+supported on your system.
+
+=== How do I filter a capture to see traffic for virus XXX?
+
+For some viruses/worms there might be a capture filter to recognize
+the virus traffic. Check the
+{wireshark-wiki-url}CaptureFilters[CaptureFilters] page on the
+{wireshark-wiki-url}[Wireshark Wiki] to see if anybody's added
+such a filter.
+
+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 https://www.snort.org/[Snort] or
+https://www.prelude-siem.org/[Prelude], will probably work better.
+
+== Questions Which Are Still Notable Even Though They Aren’t Asked Much Any More
+
+=== What's up with the name change? Is Wireshark a fork?
+
+In May of 2006, Gerald Combs (the original author of Ethereal) went
+to work for CACE Technologies (best known for WinPcap). Unfortunately,
+he had to leave the Ethereal trademarks behind.
+
+This left the project in an awkward position. The only reasonable way
+to ensure the continued success of the project was to change the name.
+This is how Wireshark was born.
+
+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. There has been no active development on
+Ethereal since the name change. Several parts of the Ethereal web site`
+(such as the mailing lists, source code repository, and build farm) have
+gone offline.
+
+More information on the name change can be found here:
+
+* https://www.prweb.com/releases/2006/6/prweb396098.htm[Original press
+release]
+* https://www.linux.com/news/ethereal-changes-name-wireshark[NewsForge article]
+* Many other articles in https://www.wireshark.org/bibliography.html[our
+bibliography]