diff options
Diffstat (limited to 'docbook/faq.adoc')
| -rw-r--r-- | docbook/faq.adoc | 1087 |
1 files changed, 1087 insertions, 0 deletions
diff --git a/docbook/faq.adoc b/docbook/faq.adoc new file mode 100644 index 0000000..43cfa20 --- /dev/null +++ b/docbook/faq.adoc @@ -0,0 +1,1087 @@ +include::attributes.adoc[] +:stylesheet: ws.css +:linkcss: +:copycss: {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://www.wireshark.org/mailman/listinfo[https://www.wireshark.org/mailman/listinfo]. +// 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://sharkfestfoundation.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://sharkfestfoundation.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 https://gitlab.com/wireshark/wireshark/-/wikis/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:https://www.wireshark.org/docs/wsug_html_chunked/ChIntroPlatforms.html[Microsoft Windows section of the User’s Guide] +and the +link:https://gitlab.com/wireshark/wireshark/-/wikis/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 +https://gitlab.com/wireshark/wireshark/-/wikis/SwitchReference[the switch reference page] on +https://gitlab.com/wireshark/wireshark/-/wikis[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 https://gitlab.com/wireshark/wireshark/-/wikis/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.windump.org/[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.windump.org/[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 +https://gitlab.com/wireshark/wireshark/-/wikis/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 https://gitlab.com/wireshark/wireshark/-/wikis/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 https://gitlab.com/wireshark/wireshark/-/wikis/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 +https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures[https://gitlab.com/wireshark/wireshark/-/wikis/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 +https://gitlab.com/wireshark/wireshark/-/wikis/CaptureFilters[CaptureFilters] page on the +https://gitlab.com/wireshark/wireshark/-/wikis[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] |