1088 lines
53 KiB
Plaintext
1088 lines
53 KiB
Plaintext
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]
|