forked from osmocom/wireshark
1543 lines
73 KiB
Plaintext
1543 lines
73 KiB
Plaintext
|
||
The Wireshark FAQ
|
||
|
||
Note: This is just an ASCII snapshot of the faq and may not be up to
|
||
date. Please go to http://www.wireshark.org/faq.html for the up
|
||
to date version. The version of this snapshot can be found at
|
||
the end of this document.
|
||
|
||
INDEX
|
||
|
||
|
||
1. General Questions:
|
||
|
||
1.1 What is Wireshark?
|
||
|
||
1.2 What's up with the name change? Is Wireshark a fork?
|
||
|
||
1.3 Where can I get help?
|
||
|
||
1.4 How much does Wireshark cost?
|
||
|
||
1.5 Can I use Wireshark commercially?
|
||
|
||
1.6 Can I use Wireshark as part of my commercial product?
|
||
|
||
1.7 What protocols are currently supported?
|
||
|
||
1.8 Are there any plans to support {your favorite protocol}?
|
||
|
||
1.9 Can Wireshark read capture files from {your favorite network
|
||
analyzer}?
|
||
|
||
1.10 What devices can Wireshark use to capture packets?
|
||
|
||
1.11 Does Wireshark work on Windows Me?
|
||
|
||
1.12 Does Wireshark work on Windows XP?
|
||
|
||
2. Downloading Wireshark:
|
||
|
||
2.1 Why do I get an error when I try to run the Win32 installer?
|
||
|
||
3. Installing Wireshark:
|
||
|
||
3.1 I installed the Wireshark RPM (or other package); why did it
|
||
install TShark but not Wireshark?
|
||
|
||
4. Building Wireshark:
|
||
|
||
4.1 I have libpcap installed; why did the configure script not find
|
||
pcap.h or bpf.h?
|
||
|
||
4.2 Why do I get the error
|
||
|
||
dftest_DEPENDENCIES was already defined in condition TRUE, which
|
||
implies condition HAVE_PLUGINS_TRUE
|
||
|
||
when I try to build Wireshark from SVN or a SVN snapshot?
|
||
|
||
4.3 Why does the linker fail with a number of "Output line too long."
|
||
messages followed by linker errors when I try to buil Wireshark?
|
||
|
||
4.4 When I try to build Wireshark on Solaris, why does the link fail
|
||
complaining that plugin_list is undefined?
|
||
|
||
4.5 When I try to build Wireshark on Windows, why does the build fail
|
||
because of conflicts between winsock.h and winsock2.h?
|
||
|
||
5. Starting Wireshark:
|
||
|
||
5.1 Why does Wireshark crash with a Bus Error when I try to run it on
|
||
Solaris 8?
|
||
|
||
5.2 When I run Wireshark on Windows NT, why does it die with a Dr.
|
||
Watson error, reporting an "Integer division by zero" exception, when
|
||
I start it?
|
||
|
||
5.3 When I try to run Wireshark, why does it complain about
|
||
sprint_realloc_objid being undefined?
|
||
|
||
5.4 When I try to run Wireshark on Windows, why does it fail to run
|
||
with a complaint that it can't find packet.dll?
|
||
|
||
5.5 I've installed Wireshark from Fink on Mac OS X; why is it very
|
||
slow to start up?
|
||
|
||
6. Crashes and other fatal errors:
|
||
|
||
6.1 I have an XXX network card on my machine; if I try to capture on
|
||
it, why does my machine crash or reset itself?
|
||
|
||
6.2 Why does my machine crash or reset itself when I select "Start"
|
||
from the "Capture" menu or select "Preferences" from the "Edit" menu?
|
||
|
||
7. Capturing packets:
|
||
|
||
7.1 When I use Wireshark to capture packets, why do I see only packets
|
||
to and from my machine, or not see all the traffic I'm expecting to
|
||
see from or to the machine I'm trying to monitor?
|
||
|
||
7.2 When I capture with Wireshark, why can't I see any TCP packets
|
||
other than packets to and from my machine, even though another
|
||
analyzer on the network sees those packets?
|
||
|
||
7.3 Why am I only seeing ARP packets when I try to capture traffic?
|
||
|
||
7.4 Why am I not seeing any traffic when I try to capture traffic?
|
||
|
||
7.5 Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
|
||
|
||
7.6 How do I put an interface into promiscuous mode?
|
||
|
||
7.7 I can set a display filter just fine; why don't capture filters
|
||
work?
|
||
|
||
7.8 I'm entering valid capture filters; why do I still get "parse
|
||
error" errors?
|
||
|
||
7.9 How can I capture packets with CRC errors?
|
||
|
||
7.10 How can I capture entire frames, including the FCS?
|
||
|
||
7.11 I'm capturing packets on a machine on a VLAN; why don't the
|
||
packets I'm capturing have VLAN tags?
|
||
|
||
7.12 Why does Wireshark hang after I stop a capture?
|
||
|
||
8. Capturing packets on Windows:
|
||
|
||
8.1 I'm running Wireshark on Windows; why does some network interface
|
||
on my machine not show up in the list of interfaces in the
|
||
"Interface:" field in the dialog box popped up by "Capture->Start",
|
||
and/or why does Wireshark give me an error if I try to capture on that
|
||
interface?
|
||
|
||
8.2 I'm running Wireshark on Windows; why do no network interfaces
|
||
show up in the list of interfaces in the "Interface:" field in the
|
||
dialog box popped up by "Capture->Start"?
|
||
|
||
8.3 I'm running Wireshark on Windows; why doesn't my serial port/ADSL
|
||
modem/ISDN modem show up in the list of interfaces in the "Interface:"
|
||
field in the dialog box popped up by "Capture->Start"?
|
||
|
||
8.4 I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows
|
||
XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN,
|
||
etc.) interface, and it shows up in the "Interface" item in the
|
||
"Capture Options" dialog box. Why can no packets be sent on or
|
||
received from that network while I'm trying to capture traffic on that
|
||
interface?
|
||
|
||
8.5 I'm running Wireshark on Windows 95/98/Me, on a machine with more
|
||
than one network adapter of the same type; why does Wireshark show all
|
||
of those adapters with the same name, not letting me use any of those
|
||
adapters other than the first one?
|
||
|
||
8.6 I'm running Wireshark on Windows; why am I not seeing any traffic
|
||
being sent by the machine running Wireshark?
|
||
|
||
8.7 When I capture on Windows in promiscuous mode, I can see packets
|
||
other than those sent to or from my machine; however, those packets
|
||
show up with a "Short Frame" indication, unlike packets to or from my
|
||
machine. What should I do to arrange that I see those packets in their
|
||
entirety?
|
||
|
||
8.8 I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why
|
||
are the time stamps on packets wrong?
|
||
|
||
8.9 I'm trying to capture 802.11 traffic on Windows; why am I not
|
||
seeing any packets?
|
||
|
||
8.10 I'm trying to capture 802.11 traffic on Windows; why am I seeing
|
||
packets received by the machine on which I'm capturing traffic, but
|
||
not packets sent by that machine?
|
||
|
||
8.11 I'm trying to capture Ethernet VLAN traffic on Windows, and I'm
|
||
capturing on a "raw" Ethernet device rather than a "VLAN interface",
|
||
so that I can see the VLAN headers; why am I seeing packets received
|
||
by the machine on which I'm capturing traffic, but not packets sent by
|
||
that machine?
|
||
|
||
9. Capturing packets on UN*Xes:
|
||
|
||
9.1 I'm running Wireshark on a UNIX-flavored OS; why does some network
|
||
interface on my machine not show up in the list of interfaces in the
|
||
"Interface:" field in the dialog box popped up by "Capture->Start",
|
||
and/or why does Wireshark give me an error if I try to capture on that
|
||
interface?
|
||
|
||
9.2 I'm running Wireshark on a UNIX-flavored OS; why do no network
|
||
interfaces show up in the list of interfaces in the "Interface:" field
|
||
in the dialog box popped up by "Capture->Start"?
|
||
|
||
9.3 I'm capturing packets on Linux; why do the time stamps have only
|
||
100ms resolution, rather than 1us resolution?
|
||
|
||
10. Capturing packets on wireless LANs:
|
||
|
||
10.1 How can I capture raw 802.11 frames, including non-data
|
||
(management, beacon) frames?
|
||
|
||
10.2 How do I capture on an 802.11 device in monitor mode?
|
||
|
||
11. Viewing traffic:
|
||
|
||
11.1 Why am I seeing lots of packets with incorrect TCP checksums?
|
||
|
||
11.2 I've just installed Wireshark, and the traffic on my local LAN is
|
||
boring. Where can I find more interesting captures?
|
||
|
||
11.3 Why doesn't Wireshark correctly identify RTP packets? It shows
|
||
them only as UDP.
|
||
|
||
11.4 Why doesn't Wireshark show Yahoo Messenger packets in captures
|
||
that contain Yahoo Messenger traffic?
|
||
|
||
12. Filtering traffic:
|
||
|
||
12.1 I saved a filter and tried to use its name to filter the display;
|
||
why do I get an "Unexpected end of filter string" error?
|
||
|
||
12.2 How can I search for, or filter, packets that have a particular
|
||
string anywhere in them?
|
||
|
||
12.3 How do I filter a capture to see traffic for virus XXX?
|
||
|
||
1. General Questions
|
||
|
||
Q 1.1: What is Wireshark?
|
||
|
||
A: Gerald Combs, the creator of Ethereal<61>, has initiated the Wireshark
|
||
network protocol analyzer project, a successor to Ethereal<61>. The
|
||
Ethereal<61> core developer team has moved with Gerald to the Wireshark
|
||
project. Consequently, Wireshark is positioned to be the world's most
|
||
popular network protocol analyzer. It has a rich and powerful feature
|
||
set, and runs on most computing platforms including Windows, OS X, and
|
||
Linux. It is freely available as open source, and is released under
|
||
the GNU General Public License.
|
||
|
||
For more information, please see the About Wireshark page.
|
||
|
||
Q 1.2: What's up with the name change? Is Wireshark a fork?
|
||
|
||
A: In May of 2006, the original author of Ethereal<61> went to work for
|
||
CACE Technologies (best known for WinPcap). At that time he started
|
||
the Wireshark open-source project.
|
||
|
||
Wireshark is almost (but not quite) a fork. Normally a "fork" of an
|
||
open source project results in two names, web sites, development
|
||
teams, support infrastructures, etc. This is the case with Wireshark
|
||
except for one notable exception -- every member of the core
|
||
development team is now working on Wireshark.
|
||
|
||
Q 1.3: Where can I get help?
|
||
|
||
A: Community support is available on the wireshark-users mailing list.
|
||
Subscription information and archives for all of Wireshark's mailing
|
||
lists can be found at http://www.wireshark.org/lists. An IRC channel
|
||
dedicated to Wireshark can be found at
|
||
irc://irc.freenode.net/ethereal.
|
||
|
||
Commercial support, training, and development services are available
|
||
from CACE Technologies.
|
||
|
||
Q 1.4: How much does Wireshark cost?
|
||
|
||
A: Wireshark is "free software"; you can download it without paying
|
||
any license fee. The version of Wireshark you download isn't a "demo"
|
||
version, with limitations not present in a "full" version; it is the
|
||
full version.
|
||
|
||
The license under which Wireshark is issued is the GNU General Public
|
||
License. See the GNU GPL FAQ for some more information.
|
||
|
||
Q 1.5: Can I use Wireshark commercially?
|
||
|
||
A: Yes, if, for example, you mean "I work for a commercial
|
||
organization; can I use Wireshark to capture and analyze network
|
||
traffic in our company's networks or in our customer's networks?"
|
||
|
||
If you mean "Can I use Wireshark as part of my commercial product?",
|
||
see the next entry in the FAQ.
|
||
|
||
Q 1.6: Can I use Wireshark as part of my commercial product?
|
||
|
||
A: As noted, Wireshark is licensed under the GNU General Public
|
||
License. The GPL imposes conditions on your use of GPL'ed code in your
|
||
own products; you cannot, for example, make a "derived work" from
|
||
Wireshark, by making modifications to it, and then sell the resulting
|
||
derived work and not allow recipients to give away the resulting work.
|
||
You must also make the changes you've made to the Wireshark source
|
||
available to all recipients of your modified version; those changes
|
||
must also be licensed under the terms of the GPL. See the GPL FAQ for
|
||
more details; in particular, note the answer to the question about
|
||
modifying a GPLed program and selling it commercially, and the
|
||
question about linking GPLed code with other code to make a
|
||
proprietary program.
|
||
|
||
You can combine a GPLed program such as Wireshark and a commercial
|
||
program as long as they communicate "at arm's length", as per this
|
||
item in the GPL FAQ.
|
||
|
||
Q 1.7: What protocols are currently supported?
|
||
|
||
A: There are currently hundreds of supported protocols and media.
|
||
Details can be found in the wireshark(1) man page.
|
||
|
||
Q 1.8: Are there any plans to support {your favorite protocol}?
|
||
|
||
A: Support for particular protocols is added to Wireshark as a result
|
||
of people contributing that support; no formal plans for adding
|
||
support for particular protocols in particular future releases exist.
|
||
|
||
Q 1.9: Can Wireshark read capture files from {your favorite network
|
||
analyzer}?
|
||
|
||
A: Support for particular protocols is added to Wireshark as a result
|
||
of people contributing that support; no formal plans for adding
|
||
support for particular protocols in particular future releases exist.
|
||
|
||
If a network analyzer writes out files in a format already supported
|
||
by Wireshark (e.g., in libpcap format), Wireshark may already be able
|
||
to read them, unless the analyzer has added its own proprietary
|
||
extensions to that format.
|
||
|
||
If a network analyzer writes out files in its own format, or has added
|
||
proprietary extensions to another format, in order to make Wireshark
|
||
read captures from that network analyzer, we would either have to have
|
||
a specification for the file format, or the extensions, sufficient to
|
||
give us enough information to read the parts of the file relevant to
|
||
Wireshark, or would need at least one capture file in that format AND
|
||
a detailed textual analysis of the packets in that capture file
|
||
(showing packet time stamps, packet lengths, and the top-level packet
|
||
header) in order to reverse-engineer the file format.
|
||
|
||
Note that there is no guarantee that we will be able to
|
||
reverse-engineer a capture file format.
|
||
|
||
Q 1.10: What devices can Wireshark use to capture packets?
|
||
|
||
A: Wireshark can read live data from Ethernet, Token-Ring, FDDI,
|
||
serial (PPP and SLIP) (if the OS on which it's running allows
|
||
Wireshark to do so), 802.11 wireless LAN (if the OS on which it's
|
||
running allows Wireshark to do so), ATM connections (if the OS on
|
||
which it's running allows Wireshark to do so), and the "any" device
|
||
supported on Linux by recent versions of libpcap. See the list of
|
||
supported capture media on various OSes for details (several items in
|
||
there say "Unknown", which doesn't mean "Wireshark can't capture on
|
||
them", it means "we don't know whether it can capture on them"; we
|
||
expect that it will be able to capture on many of them, but we haven't
|
||
tried it ourselves - if you try one of those types and it works,
|
||
please send an update to ).
|
||
|
||
It can also read a variety of capture file formats, including:
|
||
* AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet
|
||
Grabber captures
|
||
* AIX's iptrace captures
|
||
* Accellent's 5Views LAN agent output
|
||
* Cinco Networks NetXRay captures
|
||
* Cisco Secure Intrusion Detection System IPLog output
|
||
* CoSine L2 debug output
|
||
* DBS Etherwatch VMS text output
|
||
* Endace Measurement Systems' ERF format captures
|
||
* EyeSDN USB S0 traces
|
||
* HP-UX nettl captures
|
||
* ISDN4BSD project i4btrace captures
|
||
* Linux Bluez Bluetooth stack hcidump -w traces
|
||
* Lucent/Ascend router debug output
|
||
* Microsoft Network Monitor captures
|
||
* Network Associates Windows-based Sniffer captures
|
||
* Network General/Network Associates DOS-based Sniffer (compressed
|
||
or uncompressed) captures
|
||
* Network Instruments Observer version 9 captures
|
||
* Novell LANalyzer captures
|
||
* RADCOM's WAN/LAN analyzer captures
|
||
* Shomiti/Finisar Surveyor captures
|
||
* Toshiba's ISDN routers dump output
|
||
* VMS TCPIPtrace/TCPtrace/UCX$TRACE output
|
||
* Visual Networks' Visual UpTime traffic capture
|
||
* libpcap, tcpdump and various other tools using tcpdump's capture
|
||
format
|
||
* snoop and atmsnoop output
|
||
|
||
so that it can read traces from various network types, as captured by
|
||
other applications or equipment, even if it cannot itself capture on
|
||
those network types.
|
||
|
||
Q 1.11: Does Wireshark work on Windows Me?
|
||
|
||
A: Yes, but if you want to capture packets, you will need to install
|
||
the latest version of WinPcap, as 2.02 and earlier versions of WinPcap
|
||
didn't support Windows Me. You should also install the latest version
|
||
of Wireshark as well.
|
||
|
||
Q 1.12: Does Wireshark work on Windows XP?
|
||
|
||
A: Yes, but if you want to capture packets, you will need to install
|
||
the latest version of WinPcap, as 2.2 and earlier versions of WinPcap
|
||
didn't support Windows XP.
|
||
|
||
2. Downloading Wireshark
|
||
|
||
Q 2.1: Why do I get an error when I try to run the Win32 installer?
|
||
|
||
A: The program you used to download it may have downloaded it
|
||
incorrectly. Web browsers sometimes may do this.
|
||
|
||
Try downloading it with, for example:
|
||
* Wget, for which Windows binaries are available on the SunSITE FTP
|
||
server at sunsite.tk or Heiko Herold's windows wget spot - wGetGUI
|
||
offers a GUI interface that uses wget;
|
||
* WS_FTP from Ipswitch,
|
||
* the ftp command that comes with Windows.
|
||
|
||
If you use the ftp command, make sure you do the transfer in binary
|
||
mode rather than ASCII mode, by using the binary command before
|
||
transferring the file.
|
||
|
||
3. Installing Wireshark
|
||
|
||
Q 3.1: I installed the Wireshark RPM (or other package); why did it
|
||
install TShark but not Wireshark?
|
||
|
||
A: Many distributions have separate Wireshark packages, one for
|
||
non-GUI components such as TShark, editcap, dumpcap, etc. and one for
|
||
the GUI. If this is the case on your system, there's probably a
|
||
separate package named wireshark-gnome or wireshark-gtk+. Find it and
|
||
install it.
|
||
|
||
4. Building Wireshark
|
||
|
||
Q 4.1: I have libpcap installed; why did the configure script not find
|
||
pcap.h or bpf.h?
|
||
|
||
A: Are you sure pcap.h and bpf.h are installed? The official
|
||
distribution of libpcap only installs the libpcap.a library file when
|
||
"make install" is run. To install pcap.h and bpf.h, you must run "make
|
||
install-incl". If you're running Debian or Redhat, make sure you have
|
||
the "libpcap-dev" or "libpcap-devel" packages installed.
|
||
|
||
It's also possible that pcap.h and bpf.h have been installed in a
|
||
strange location. If this is the case, you may have to tweak
|
||
aclocal.m4.
|
||
|
||
Q 4.2: Why do I get the error
|
||
|
||
dftest_DEPENDENCIES was already defined in condition TRUE, which
|
||
implies condition HAVE_PLUGINS_TRUE
|
||
|
||
when I try to build Wireshark from SVN or a SVN snapshot?
|
||
|
||
A: You probably have automake 1.5 installed on your machine (the
|
||
command automake --version will report the version of automake on your
|
||
machine). There is a bug in that version of automake that causes this
|
||
problem; upgrade to a later version of automake (1.6 or later).
|
||
|
||
Q 4.3: Why does the linker fail with a number of "Output line too
|
||
long." messages followed by linker errors when I try to buil
|
||
Wireshark?
|
||
|
||
A: The version of the sed command on your system is incapable of
|
||
handling very long lines. On Solaris, for example, /usr/bin/sed has a
|
||
line length limit too low to allow libtool to work; /usr/xpg4/bin/sed
|
||
can handle it, as can GNU sed if you have it installed.
|
||
|
||
On Solaris, changing your command search path to search /usr/xpg4/bin
|
||
before /usr/bin should make the problem go away; on any platform on
|
||
which you have this problem, installing GNU sed and changing your
|
||
command path to search the directory in which it is installed before
|
||
searching the directory with the version of sed that came with the OS
|
||
should make the problem go away.
|
||
|
||
Q 4.4: When I try to build Wireshark on Solaris, why does the link
|
||
fail complaining that plugin_list is undefined?
|
||
|
||
A: This appears to be due to a problem with some versions of the GTK+
|
||
and GLib packages from www.sunfreeware.org; un-install those packages,
|
||
and try getting the 1.2.10 versions from that site, or the versions
|
||
from The Written Word, or the versions from Sun's GNOME distribution,
|
||
or the versions from the supplemental software CD that comes with the
|
||
Solaris media kit, or build them from source from the GTK Web site.
|
||
Then re-run the configuration script, and try rebuilding Wireshark.
|
||
(If you get the 1.2.10 versions from www.sunfreeware.org, and the
|
||
problem persists, un-install them and try installing one of the other
|
||
versions mentioned.)
|
||
|
||
Q 4.5: When I try to build Wireshark on Windows, why does the build
|
||
fail because of conflicts between winsock.h and winsock2.h?
|
||
|
||
A: As of Wireshark 0.9.5, you must install WinPcap 2.3 or later, and
|
||
the corresponding version of the developer's pack, in order to be able
|
||
to compile Wireshark; it will not compile with older versions of the
|
||
developer's pack. The symptoms of this failure are conflicts between
|
||
definitions in winsock.h and in winsock2.h; Wireshark uses winsock2.h,
|
||
but pre-2.3 versions of the WinPcap developer's packet use winsock.h.
|
||
(2.3 uses winsock2.h, so if Wireshark were to use winsock.h, it would
|
||
not be able to build with current versions of the WinPcap developer's
|
||
pack.)
|
||
|
||
Note that the installed version of the developer's pack should be the
|
||
same version as the version of WinPcap you have installed.
|
||
|
||
5. Starting Wireshark
|
||
|
||
Q 5.1: Why does Wireshark crash with a Bus Error when I try to run it
|
||
on Solaris 8?
|
||
|
||
A: Some versions of the GTK+ library from www.sunfreeware.org appear
|
||
to be buggy, causing Wireshark to drop core with a Bus Error.
|
||
Un-install those packages, and try getting the 1.2.10 version from
|
||
that site, or the version from The Written Word, or the version from
|
||
Sun's GNOME distribution, or the version from the supplemental
|
||
software CD that comes with the Solaris media kit, or build it from
|
||
source from the GTK Web site. Update the GLib library to the 1.2.10
|
||
version, from the same source, as well. (If you get the 1.2.10
|
||
versions from www.sunfreeware.org, and the problem persists,
|
||
un-install them and try installing one of the other versions
|
||
mentioned.)
|
||
|
||
Similar problems may exist with older versions of GTK+ for earlier
|
||
versions of Solaris.
|
||
|
||
Q 5.2: When I run Wireshark on Windows NT, why does it die with a Dr.
|
||
Watson error, reporting an "Integer division by zero" exception, when
|
||
I start it?
|
||
|
||
A: In at least some case, this appears to be due to using the default
|
||
VGA driver; if that's not the correct driver for your video card, try
|
||
running the correct driver for your video card.
|
||
|
||
Q 5.3: When I try to run Wireshark, why does it complain about
|
||
sprint_realloc_objid being undefined?
|
||
|
||
A: Wireshark can only be linked with version 4.2.2 or later of UCD
|
||
SNMP. Your version of Wireshark was dynamically linked with such a
|
||
version of UCD SNMP; however, you have an older version of UCD SNMP
|
||
installed, which means that when Wireshark is run, it tries to link to
|
||
the older version, and fails. You will have to replace that version of
|
||
UCD SNMP with version 4.2.2 or a later version.
|
||
|
||
Q 5.4: When I try to run Wireshark on Windows, why does it fail to run
|
||
with a complaint that it can't find packet.dll?
|
||
|
||
A: In older versions of Wireshark, there were two binary distributions
|
||
available for Windows, one that supported capturing packets, and one
|
||
that didn't. The version that supported capturing packets required
|
||
that you install the WinPcap driver; if you didn't install it, it
|
||
would fail to run because it couldn't find packet.dll.
|
||
|
||
The current version of Wireshark has only one binary distribution for
|
||
Windows; that version will check whether WinPcap is installed and, if
|
||
it's not, will disable support for packet capture.
|
||
|
||
The WinPcap driver and libraries can be downloaded from the WinPcap
|
||
Web site or the Wiretapped.net mirror of the WinPcap site.
|
||
|
||
Q 5.5: I've installed Wireshark from Fink on Mac OS X; why is it very
|
||
slow to start up?
|
||
|
||
A: When an application is installed on OS X, prior to 10.4, it is
|
||
usually "prebound" to speed up launching the application. (That's what
|
||
the "Optimizing" phase of installation is.) Fink normally performs
|
||
prebinding automatically when you install a package. However, in some
|
||
rare cases, for whatever reason the prebinding caches get corrupt, and
|
||
then not only does prebinding fail, but startup actually becomes much
|
||
slower, because the system tries in vain to perform prebinding "on the
|
||
fly" as you launch the application. This fails, causing sometimes huge
|
||
delays. To fix the prebinding caches, run the command
|
||
sudo /sw/var/lib/fink/prebound/update-package-prebinding.pl -f
|
||
|
||
6. Crashes and other fatal errors
|
||
|
||
Q 6.1: I have an XXX network card on my machine; if I try to capture
|
||
on it, why does my machine crash or reset itself?
|
||
|
||
A: This is almost certainly a problem with one or more of:
|
||
* the operating system you're using;
|
||
* the device driver for the interface you're using;
|
||
* the libpcap/WinPcap library and, if this is Windows, the WinPcap
|
||
device driver;
|
||
|
||
so:
|
||
* if you are using Windows, see the WinPcap support page - check the
|
||
"Submitting bugs" section;
|
||
* if you are using some Linux distribution, some version of BSD, or
|
||
some other UNIX-flavored OS, you should report the problem to the
|
||
company or organization that produces the OS (in the case of a
|
||
Linux distribution, report the problem to whoever produces the
|
||
distribution).
|
||
|
||
Q 6.2: Why does my machine crash or reset itself when I select "Start"
|
||
from the "Capture" menu or select "Preferences" from the "Edit" menu?
|
||
|
||
A: Both of those operations cause Wireshark to try to build a list of
|
||
the interfaces that it can open; it does so by getting a list of
|
||
interfaces and trying to open them. There is probably an OS, driver,
|
||
or, for Windows, WinPcap bug that causes the system to crash when this
|
||
happens; see the previous question.
|
||
|
||
7. Capturing packets
|
||
|
||
Q 7.1: When I use Wireshark to capture packets, why do I see only
|
||
packets to and from my machine, or not see all the traffic I'm
|
||
expecting to see from or to the machine I'm trying to monitor?
|
||
|
||
A: This might be because the interface on which you're capturing is
|
||
plugged into an Ethernet or Token Ring switch; on a switched network,
|
||
unicast traffic between two ports will not necessarily appear on other
|
||
ports - only broadcast and multicast traffic will be sent to all
|
||
ports.
|
||
|
||
Note that even if your machine is plugged into a hub, the "hub" may be
|
||
a switched hub, in which case you're still on a switched network.
|
||
|
||
Note also that on the Linksys Web site, they say that their
|
||
auto-sensing hubs "broadcast the 10Mb packets to the port that operate
|
||
at 10Mb only and broadcast the 100Mb packets to the ports that operate
|
||
at 100Mb only", which would indicate that if you sniff on a 10Mb port,
|
||
you will not see traffic coming sent to a 100Mb port, and vice versa.
|
||
This problem has also been reported for Netgear dual-speed hubs, and
|
||
may exist for other "auto-sensing" or "dual-speed" hubs.
|
||
|
||
Some switches have the ability to replicate all traffic on all ports
|
||
to a single port so that you can plug your analyzer into that single
|
||
port to sniff all traffic. You would have to check the documentation
|
||
for the switch to see if this is possible and, if so, to see how to do
|
||
this. See the switch reference page on the Wireshark Wiki for
|
||
information on some switches. (Note that it's a Wiki, so you can
|
||
update or fix that information, or add additional information on those
|
||
switches or information on new switches, yourself.)
|
||
|
||
Note also that many firewall/NAT boxes have a switch built into them;
|
||
this includes many of the "cable/DSL router" boxes. If you have a box
|
||
of that sort, that has a switch with some number of Ethernet ports
|
||
into which you plug machines on your network, and another Ethernet
|
||
port used to connect to a cable or DSL modem, you can, at least, sniff
|
||
traffic between the machines on your network and the Internet by
|
||
plugging the Ethernet port on the router going to the modem, the
|
||
Ethernet port on the modem, and the machine on which you're running
|
||
Wireshark into a hub (make sure it's not a switching hub, and that, if
|
||
it's a dual-speed hub, all three of those ports are running at the
|
||
same speed.
|
||
|
||
If your machine is not plugged into a switched network or a dual-speed
|
||
hub, or it is plugged into a switched network but the port is set up
|
||
to have all traffic replicated to it, the problem might be that the
|
||
network interface on which you're capturing doesn't support
|
||
"promiscuous" mode, or because your OS can't put the interface into
|
||
promiscuous mode. Normally, network interfaces supply to the host
|
||
only:
|
||
* packets sent to one of that host's link-layer addresses;
|
||
* broadcast packets;
|
||
* multicast packets sent to a multicast address that the host has
|
||
configured the interface to accept.
|
||
|
||
Most network interfaces can also be put in "promiscuous" mode, in
|
||
which they supply to the host all network packets they see. Wireshark
|
||
will try to put the interface on which it's capturing into promiscuous
|
||
mode unless the "Capture packets in promiscuous mode" option is turned
|
||
off in the "Capture Options" dialog box, and TShark will try to put
|
||
the interface on which it's capturing into promiscuous mode unless the
|
||
-p option was specified. However, some network interfaces don't
|
||
support promiscuous mode, and some OSes might not allow interfaces to
|
||
be put into promiscuous mode.
|
||
|
||
If the interface is not running in promiscuous mode, it won't see any
|
||
traffic that isn't intended to be seen by your machine. It will see
|
||
broadcast packets, and multicast packets sent to a multicast MAC
|
||
address the interface is set up to receive.
|
||
|
||
You should ask the vendor of your network interface whether it
|
||
supports promiscuous mode. If it does, you should ask whoever supplied
|
||
the driver for the interface (the vendor, or the supplier of the OS
|
||
you're running on your machine) whether it supports promiscuous mode
|
||
with that network interface.
|
||
|
||
In the case of token ring interfaces, the drivers for some of them, on
|
||
Windows, may require you to enable promiscuous mode in order to
|
||
capture in promiscuous mode. See the Wireshark Wiki item on Token Ring
|
||
capturing for details.
|
||
|
||
In the case of wireless LAN interfaces, it appears that, when those
|
||
interfaces are promiscuously sniffing, they're running in a
|
||
significantly different mode from the mode that they run in when
|
||
they're just acting as network interfaces (to the extent that it would
|
||
be a significant effor for those drivers to support for promiscuously
|
||
sniffing and acting as regular network interfaces at the same time),
|
||
so it may be that Windows drivers for those interfaces don't support
|
||
promiscuous mode.
|
||
|
||
Q 7.2: When I capture with Wireshark, why can't I see any TCP packets
|
||
other than packets to and from my machine, even though another
|
||
analyzer on the network sees those packets?
|
||
|
||
A: You're probably not seeing any packets other than unicast packets
|
||
to or from your machine, and broadcast and multicast packets; a switch
|
||
will normally send to a port only unicast traffic sent to the MAC
|
||
address for the interface on that port, and broadcast and multicast
|
||
traffic - it won't send to that port unicast traffic sent to a MAC
|
||
address for some other interface - and a network interface not in
|
||
promiscuous mode will receive only unicast traffic sent to the MAC
|
||
address for that interface, broadcast traffic, and multicast traffic
|
||
sent to a multicast MAC address the interface is set up to receive.
|
||
|
||
TCP doesn't use broadcast or multicast, so you will only see your own
|
||
TCP traffic, but UDP services may use broadcast or multicast so you'll
|
||
see some UDP traffic - however, this is not a problem with TCP
|
||
traffic, it's a problem with unicast traffic, as you also won't see
|
||
all UDP traffic between other machines.
|
||
|
||
I.e., this is probably the same question as this earlier one; see the
|
||
response to that question.
|
||
|
||
Q 7.3: Why am I only seeing ARP packets when I try to capture traffic?
|
||
|
||
A: You're probably on a switched network, and running Wireshark on a
|
||
machine that's not sending traffic to the switch and not being sent
|
||
any traffic from other machines on the switch. ARP packets are often
|
||
broadcast packets, which are sent to all switch ports.
|
||
|
||
I.e., this is probably the same question as this earlier one; see the
|
||
response to that question.
|
||
|
||
Q 7.4: Why am I not seeing any traffic when I try to capture traffic?
|
||
|
||
A: Is the machine running Wireshark sending out any traffic on the
|
||
network interface on which you're capturing, or receiving any traffic
|
||
on that network, or is there any broadcast traffic on the network or
|
||
multicast traffic to a multicast group to which the machine running
|
||
Wireshark belongs?
|
||
|
||
If not, this may just be a problem with promiscuous sniffing, either
|
||
due to running on a switched network or a dual-speed hub, or due to
|
||
problems with the interface not supporting promiscuous mode; see the
|
||
response to this earlier question.
|
||
|
||
Otherwise, on Windows, see the response to this question and, on a
|
||
UNIX-flavored OS, see the response to this question.
|
||
|
||
Q 7.5: Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
|
||
|
||
A: Wireshark can only capture on devices supported by libpcap/WinPcap.
|
||
On most OSes, only devices that can act as network interfaces of the
|
||
type that support IP are supported as capture devices for
|
||
libpcap/WinPcap, although the device doesn't necessarily have to be
|
||
running as an IP interface in order to support traffic capture.
|
||
|
||
On Linux and FreeBSD, libpcap 0.8 and later support the API for Endace
|
||
Measurement Systems' DAG cards, so that a system with one of those
|
||
cards, and its driver and libraries, installed can capture traffic
|
||
with those cards with libpcap-based applications. You would either
|
||
have to have a version of Wireshark built with that version of
|
||
libpcap, or a dynamically-linked version of Wireshark and a shared
|
||
libpcap library with DAG support, in order to do so with Wireshark.
|
||
You should ask Endace whether that could be used to capture traffic
|
||
on, for example, your T1/E1 link. See the SS7 capture setup page on
|
||
the Wireshark Wiki for current information on capturing SS7 traffic on
|
||
TDM links.
|
||
|
||
Q 7.6: How do I put an interface into promiscuous mode?
|
||
|
||
A: By not disabling promiscuous mode when running Wireshark or TShark.
|
||
|
||
Note, however, that:
|
||
* the form of promiscuous mode that libpcap (the library that
|
||
programs such as tcpdump, Wireshark, etc. use to do packet
|
||
capture) turns on will not necessarily be shown if you run
|
||
ifconfig on the interface on a UNIX system;
|
||
* some network interfaces might not support promiscuous mode, and
|
||
some drivers might not allow promiscuous mode to be turned on -
|
||
see this earlier question for more information on that;
|
||
* the fact that you're not seeing any traffic, or are only seeing
|
||
broadcast traffic, or aren't seeing any non-broadcast traffic
|
||
other than traffic to or from the machine running Wireshark, does
|
||
not mean that promiscuous mode isn't on - see this earlier
|
||
question for more information on that.
|
||
|
||
I.e., this is probably the same question as this earlier one; see the
|
||
response to that question.
|
||
|
||
Q 7.7: I can set a display filter just fine; why don't capture filters
|
||
work?
|
||
|
||
A: Capture filters currently use a different syntax than display
|
||
filters. Here's the corresponding section from the wireshark(1) man
|
||
page:
|
||
|
||
"Display filters in Wireshark are very powerful; more fields are
|
||
filterable in Wireshark than in other protocol analyzers, and the
|
||
syntax you can use to create your filters is richer. As Wireshark
|
||
progresses, expect more and more protocol fields to be allowed in
|
||
display filters.
|
||
|
||
Packet capturing is performed with the pcap library. The capture
|
||
filter syntax follows the rules of the pcap library. This syntax is
|
||
different from the display filter syntax."
|
||
|
||
The capture filter syntax used by libpcap can be found in the
|
||
tcpdump(8) man page.
|
||
|
||
Q 7.8: I'm entering valid capture filters; why do I still get "parse
|
||
error" errors?
|
||
|
||
A: There is a bug in some versions of libpcap/WinPcap that cause it to
|
||
report parse errors even for valid expressions if a previous filter
|
||
expression was invalid and got a parse error.
|
||
|
||
Try exiting and restarting Wireshark; if you are using a version of
|
||
libpcap/WinPcap with this bug, this will "erase" its memory of the
|
||
previous parse error. If the capture filter that got the "parse error"
|
||
now works, the earlier error with that filter was probably due to this
|
||
bug.
|
||
|
||
The bug was fixed in libpcap 0.6; 0.4[.x] and 0.5[.x] versions of
|
||
libpcap have this bug, but 0.6[.x] and later versions don't.
|
||
|
||
Versions of WinPcap prior to 2.3 are based on pre-0.6 versions of
|
||
libpcap, and have this bug; WinPcap 2.3 is based on libpcap 0.6.2, and
|
||
doesn't have this bug.
|
||
|
||
If you are running Wireshark on a UNIX-flavored platform, run
|
||
"wireshark -v", or select "About Wireshark..." from the "Help" menu in
|
||
Wireshark, to see what version of libpcap it's using. If it's not 0.6
|
||
or later, you will need either to upgrade your OS to get a later
|
||
version of libpcap, or will need to build and install a later version
|
||
of libpcap from the tcpdump.org Web site and then recompile Wireshark
|
||
from source with that later version of libpcap.
|
||
|
||
If you are running Wireshark on Windows with a pre-2.3 version of
|
||
WinPcap, you will need to un-install WinPcap and then download and
|
||
install WinPcap 2.3.
|
||
|
||
Q 7.9: How can I capture packets with CRC errors?
|
||
|
||
A: Wireshark can capture only the packets that the packet capture
|
||
library - libpcap on UNIX-flavored OSes, and the WinPcap port to
|
||
Windows of libpcap on Windows - can capture, and libpcap/WinPcap can
|
||
capture only the packets that the OS's raw packet capture mechanism
|
||
(or the WinPcap driver, and the underlying OS networking code and
|
||
network interface drivers, on Windows) will allow it to capture.
|
||
|
||
Unless the OS always supplies packets with errors such as invalid CRCs
|
||
to the raw packet capture mechanism, or can be configured to do so,
|
||
invalid CRCs to the raw packet capture mechanism, Wireshark - and
|
||
other programs that capture raw packets, such as tcpdump - cannot
|
||
capture those packets. You will have to determine whether your OS
|
||
needs to be so configured and, if so, can be so configured, configure
|
||
it if necessary and possible, and make whatever changes to libpcap and
|
||
the packet capture program you're using are necessary, if any, to
|
||
support capturing those packets.
|
||
|
||
Most OSes probably do not support capturing packets with invalid CRCs
|
||
on Ethernet, and probably do not support it on most other link-layer
|
||
types. Some drivers on some OSes do support it, such as some Ethernet
|
||
drivers on FreeBSD; in those OSes, you might always get those packets,
|
||
or you might only get them if you capture in promiscuous mode (you'd
|
||
have to determine which is the case).
|
||
|
||
Note that libpcap does not currently supply to programs that use it an
|
||
indication of whether the packet's CRC was invalid (because the
|
||
drivers themselves do not supply that information to the raw packet
|
||
capture mechanism); therefore, Wireshark will not indicate which
|
||
packets had CRC errors unless the FCS was captured (see the next
|
||
question) and you're using Wireshark 0.9.15 and later, in which case
|
||
Wireshark will check the CRC and indicate whether it's correct or not.
|
||
|
||
Q 7.10: How can I capture entire frames, including the FCS?
|
||
|
||
A: Wireshark can only capture data that the packet capture library -
|
||
libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of
|
||
libpcap on Windows - can capture, and libpcap/WinPcap can capture only
|
||
the data that the OS's raw packet capture mechanism (or the WinPcap
|
||
driver, and the underlying OS networking code and network interface
|
||
drivers, on Windows) will allow it to capture.
|
||
|
||
For any particular link-layer network type, unless the OS supplies the
|
||
FCS of a frame as part of the frame, or can be configured to do so,
|
||
Wireshark - and other programs that capture raw packets, such as
|
||
tcpdump - cannot capture the FCS of a frame. You will have to
|
||
determine whether your OS needs to be so configured and, if so, can be
|
||
so configured, configure it if necessary and possible, and make
|
||
whatever changes to libpcap and the packet capture program you're
|
||
using are necessary, if any, to support capturing the FCS of a frame.
|
||
|
||
Most OSes do not support capturing the FCS of a frame on Ethernet, and
|
||
probably do not support it on most other link-layer types. Some
|
||
drivres on some OSes do support it, such as some (all?) Ethernet
|
||
drivers on NetBSD and possibly the driver for Apple's gigabit Ethernet
|
||
interface in Mac OS X; in those OSes, you might always get the FCS, or
|
||
you might only get the FCS if you capture in promiscuous mode (you'd
|
||
have to determine which is the case).
|
||
|
||
Versions of Wireshark prior to 0.9.15 will not treat an Ethernet FCS
|
||
in a captured packet as an FCS. 0.9.15 and later will attempt to
|
||
determine whether there's an FCS at the end of the frame and, if it
|
||
thinks there is, will display it as such, and will check whether it's
|
||
the correct CRC-32 value or not.
|
||
|
||
Q 7.11: I'm capturing packets on a machine on a VLAN; why don't the
|
||
packets I'm capturing have VLAN tags?
|
||
|
||
A: You might be capturing on what might be called a "VLAN interface" -
|
||
the way a particular OS makes VLANs plug into the networking stack
|
||
might, for example, be to have a network device object for the
|
||
physical interface, which takes VLAN packets, strips off the VLAN
|
||
header and constructs an Ethernet header, and passes that packet to an
|
||
internal network device object for the VLAN, which then passes the
|
||
packets onto various higher-level protocol implementations.
|
||
|
||
In order to see the raw Ethernet packets, rather than "de-VLANized"
|
||
packets, you would have to capture not on the virtual interface for
|
||
the VLAN, but on the interface corresponding to the physical network
|
||
device, if possible. See the Wireshark Wiki item on VLAN capturing for
|
||
details.
|
||
|
||
Q 7.12: Why does Wireshark hang after I stop a capture?
|
||
|
||
A: The most likely reason for this is that Wireshark is trying to look
|
||
up an IP address in the capture to convert it to a name (so that, for
|
||
example, it can display the name in the source address or destination
|
||
address columns), and that lookup process is taking a very long time.
|
||
|
||
Wireshark calls a routine in the OS of the machine on which it's
|
||
running to convert of IP addresses to the corresponding names. That
|
||
routine probably does one or more of:
|
||
* a search of a system file listing IP addresses and names;
|
||
* a lookup using DNS;
|
||
* on UNIX systems, a lookup using NIS;
|
||
* on Windows systems, a NetBIOS-over-TCP query.
|
||
|
||
If a DNS server that's used in an address lookup is not responding,
|
||
the lookup will fail, but will only fail after a timeout while the
|
||
system routine waits for a reply.
|
||
|
||
In addition, on Windows systems, if the DNS lookup of the address
|
||
fails, either because the server isn't responding or because there are
|
||
no records in the DNS that could be used to map the address to a name,
|
||
a NetBIOS-over-TCP query will be made. That query involves sending a
|
||
message to the NetBIOS-over-TCP name service on that machine, asking
|
||
for the name and other information about the machine. If the machine
|
||
isn't running software that responds to those queries - for example,
|
||
many non-Windows machines wouldn't be running that software - the
|
||
lookup will only fail after a timeout. Those timeouts can cause the
|
||
lookup to take a long time.
|
||
|
||
If you disable network address-to-name translation - for example, by
|
||
turning off the "Enable network name resolution" option in the
|
||
"Capture Options" dialog box for starting a network capture - the
|
||
lookups of the address won't be done, which may speed up the process
|
||
of reading the capture file after the capture is stopped. You can make
|
||
that setting the default by selecting "Preferences" from the "Edit"
|
||
menu, turning off the "Enable network name resolution" option in the
|
||
"Name resolution" options in the preferences disalog box, and using
|
||
the "Save" button in that dialog box; note that this will save all
|
||
your current preference settings.
|
||
|
||
If Wireshark hangs when reading a capture even with network name
|
||
resolution turned off, there might, for example, be a bug in one of
|
||
Wireshark's dissectors for a protocol causing it to loop infinitely.
|
||
If you're not running the most recent release of Wireshark, you should
|
||
first upgrade to that release, as, if there's a bug of that sort, it
|
||
might've been fixed in a release after the one you're running. If the
|
||
hang occurs in the most recent release of Wireshark, the bug should be
|
||
reported to the Wireshark developers' mailing list at
|
||
wireshark-dev@wireshark.org.
|
||
|
||
On UNIX-flavored OSes, please try to force Wireshark to dump core, by
|
||
sending it a SIGABRT signal (usually signal 6) with the kill command,
|
||
and then get a stack trace if you have a debugger installed. A stack
|
||
trace can be obtained by using your debugger (gdb in this example),
|
||
the Wireshark binary, and the resulting core file. Here's an example
|
||
of how to use the gdb command backtrace to do so.
|
||
$ gdb wireshark core
|
||
(gdb) backtrace
|
||
..... prints the stack trace
|
||
(gdb) quit
|
||
$
|
||
|
||
The core dump file may be named "wireshark.core" rather than "core" on
|
||
some platforms (e.g., BSD systems).
|
||
|
||
Also, if at all possible, please send a copy of the capture file that
|
||
caused the problem; when capturing packets, Wireshark normally writes
|
||
captured packets to a temporary file, which will probably be in /tmp
|
||
or /var/tmp on UNIX-flavored OSes, \TEMP on the main system disk
|
||
(normally C:) on Windows 9x/Me/NT 4.0, and \Documents and
|
||
Settings\your login name\Local Settings\Temp on the main system disk
|
||
on Windows 2000/Windows XP/Windows Server 2003, so the capture file
|
||
will probably be there. It will have a name beginning with ether, with
|
||
some mixture of letters and numbers after that. Please don't send a
|
||
trace file greater than 1 MB when compressed; instead, make it
|
||
available via FTP or HTTP, or say it's available but leave it up to a
|
||
developer to ask for it. If the trace file contains sensitive
|
||
information (e.g., passwords), then please do not send it.
|
||
|
||
8. Capturing packets on Windows
|
||
|
||
Q 8.1: I'm running Wireshark on Windows; why does some network
|
||
interface on my machine not show up in the list of interfaces in the
|
||
"Interface:" field in the dialog box popped up by "Capture->Start",
|
||
and/or why does Wireshark give me an error if I try to capture on that
|
||
interface?
|
||
|
||
A: If you are running Wireshark on Windows NT 4.0, Windows 2000,
|
||
Windows XP, or Windows Server 2003, and this is the first time you
|
||
have run a WinPcap-based program (such as Wireshark, or TShark, or
|
||
WinDump, or Analyzer, or...) since the machine was rebooted, you need
|
||
to run that program from an account with administrator privileges;
|
||
once you have run such a program, you will not need administrator
|
||
privileges to run any such programs until you reboot.
|
||
|
||
If you are running on Windows 95/98/Me, or if you are running on
|
||
Windows NT 4.0/Windows 2000/Windows XP/Windows Server 2003 and have
|
||
administrator privileges or a WinPcap-based program has been run with
|
||
those privileges since the machine rebooted, this problem might clear
|
||
up if you completely un-install WinPcap and then re-install it.
|
||
|
||
If that doesn't work, then note that Wireshark relies on the WinPcap
|
||
library, on the WinPcap device driver, and on the facilities that come
|
||
with the OS on which it's running in order to do captures.
|
||
|
||
Therefore, if the OS, the WinPcap library, or the WinPcap driver don't
|
||
support capturing on a particular network interface device, Wireshark
|
||
won't be able to capture on that device.
|
||
|
||
Note that:
|
||
1. 2.02 and earlier versions of the WinPcap driver and library that
|
||
Wireshark uses for packet capture didn't support Token Ring
|
||
interfaces; versions 2.1 and later support Token Ring, and the
|
||
current version of Wireshark works with (and, in fact, requires)
|
||
WinPcap 2.1 or later.
|
||
If you are having problems capturing on Token Ring interfaces, and
|
||
you have WinPcap 2.02 or an earlier version of WinPcap installed,
|
||
you should uninstall WinPcap, download and install the current
|
||
version of WinPcap, and then install the latest version of
|
||
Wireshark.
|
||
2. On Windows 95, 98, or Me, sometimes more than one interface will
|
||
be given the same name; if that is the case, you will only be able
|
||
to capture on one of those interfaces - it's not clear to which
|
||
one the name, when used in a WinPcap-based application, will
|
||
refer. For example, if you have a PPP serial interface and a VPN
|
||
interface, they might show up with the same name, for example
|
||
"ppp-mac", and if you try to capture on "ppp-mac", it might not
|
||
capture on the interface you're currently using. In that case, you
|
||
might, for example, have to remove the VPN interface from the
|
||
system in order to capture on the PPP serial interface.
|
||
3. WinPcap 2.3 has problems supporting PPP WAN interfaces on Windows
|
||
NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to
|
||
avoid those problems, support for PPP WAN interfaces on those
|
||
versions of Windows has been disabled in WinPcap 3.0. Regular
|
||
dial-up lines, ISDN lines, ADSL connections using PPPoE or PPPoA,
|
||
and various other lines such as T1/E1 lines are all PPP
|
||
interfaces, so those interfaces might not show up on the list of
|
||
interfaces in the "Capture Options" dialog on those OSes.
|
||
On Windows 2000, Windows XP, and Windows Server 2003, but not
|
||
Windows NT 4.0 or Windows Vista Beta 1, you should be able to
|
||
capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta
|
||
releases called it the "NdisWanAdapter"; if you're using a 3.1
|
||
beta release, you should un-install it and install the final 3.1
|
||
release.) See the Wireshark Wiki item on PPP capturing for
|
||
details.
|
||
4. WinPcap prior to 3.0 does not support multiprocessor machines
|
||
(note that machines with a single multi-threaded processor, such
|
||
as Intel's new multi-threaded x86 processors, are multiprocessor
|
||
machines as far as the OS and WinPcap are concerned), and recent
|
||
2.x versions of WinPcap refuse to operate if they detect that
|
||
they're running on a multiprocessor machine, which means that they
|
||
may not show any network interfaces. You will need to use WinPcap
|
||
3.0 to capture on a multiprocessor machine.
|
||
|
||
If an interface doesn't show up in the list of interfaces in the
|
||
"Interface:" field, and you know the name of the interface, try
|
||
entering that name in the "Interface:" field and capturing on that
|
||
device.
|
||
|
||
If the attempt to capture on it succeeds, the interface is somehow not
|
||
being reported by the mechanism Wireshark uses to get a list of
|
||
interfaces. Try listing the interfaces with WinDump; see the WinDump
|
||
Web site for information on using WinDump.
|
||
|
||
You would run WinDump with the -D flag; if it lists the interface,
|
||
please report this to wireshark-dev@wireshark.org giving full details
|
||
of the problem, including
|
||
* the operating system you're using, and the version of that
|
||
operating system;
|
||
* the type of network device you're using;
|
||
* the output of WinDump.
|
||
|
||
If WinDump does not list the interface, this is almost certainly a
|
||
problem with one or more of:
|
||
* the operating system you're using;
|
||
* the device driver for the interface you're using;
|
||
* the WinPcap library and/or the WinPcap device driver;
|
||
|
||
so first check the WinPcap FAQ or the Wiretapped.net mirror of that
|
||
FAQ, to see if your problem is mentioned there. If not, then see the
|
||
WinPcap support page - check the "Submitting bugs" section.
|
||
|
||
If you are having trouble capturing on a particular network interface,
|
||
first try capturing on that device with WinDump; see the WinDump Web
|
||
site for information on using WinDump.
|
||
|
||
If you can capture on the interface with WinDump, send mail to
|
||
wireshark-users@wireshark.org giving full details of the problem,
|
||
including
|
||
* the operating system you're using, and the version of that
|
||
operating system;
|
||
* the type of network device you're using;
|
||
* the error message you get from Wireshark.
|
||
|
||
If you cannot capture on the interface with WinDump, this is almost
|
||
certainly a problem with one or more of:
|
||
* the operating system you're using;
|
||
* the device driver for the interface you're using;
|
||
* the WinPcap library and/or the WinPcap device driver;
|
||
|
||
so first check the WinPcap FAQ or the Wiretapped.net mirror of that
|
||
FAQ, to see if your problem is mentioned there. If not, then see the
|
||
WinPcap support page - check the "Submitting bugs" section.
|
||
|
||
You may also want to ask the wireshark-users@wireshark.org and the
|
||
winpcap-users@winpcap.org mailing lists to see if anybody happens to
|
||
know about the problem and know a workaround or fix for the problem.
|
||
(Note that you will have to subscribe to that list in order to be
|
||
allowed to mail to it; see the WinPcap support page for information on
|
||
the mailing list.) In your mail, please give full details of the
|
||
problem, as described above, and also indicate that the problem occurs
|
||
with WinDump, not just with Wireshark.
|
||
|
||
Q 8.2: I'm running Wireshark on Windows; why do no network interfaces
|
||
show up in the list of interfaces in the "Interface:" field in the
|
||
dialog box popped up by "Capture->Start"?
|
||
|
||
A: This is really the same question as the previous one; see the
|
||
response to that question.
|
||
|
||
Q 8.3: I'm running Wireshark on Windows; why doesn't my serial
|
||
port/ADSL modem/ISDN modem show up in the list of interfaces in the
|
||
"Interface:" field in the dialog box popped up by "Capture->Start"?
|
||
|
||
A: Internet access on those devices is often done with the
|
||
Point-to-Point (PPP) protocol; WinPcap 2.3 has problems supporting PPP
|
||
WAN interfaces on Windows NT 4.0, Windows 2000, Windows XP, and
|
||
Windows Server 2003, and, to avoid those problems, support for PPP WAN
|
||
interfaces on those versions of Windows has been disabled in WinPcap
|
||
3.0.
|
||
|
||
On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
|
||
NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
|
||
"GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
|
||
the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
|
||
un-install it and install the final 3.1 release.) See the Wireshark
|
||
Wiki item on PPP capturing for details.
|
||
|
||
Q 8.4: I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows
|
||
XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN,
|
||
etc.) interface, and it shows up in the "Interface" item in the
|
||
"Capture Options" dialog box. Why can no packets be sent on or
|
||
received from that network while I'm trying to capture traffic on that
|
||
interface?
|
||
|
||
A: Some versions of WinPcap have problems with PPP WAN interfaces on
|
||
Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003; one
|
||
symptom that may be seen is that attempts to capture in promiscuous
|
||
mode on the interface cause the interface to be incapable of sending
|
||
or receiving packets. You can disable promiscuous mode using the -p
|
||
command-line flag or the item in the "Capture Preferences" dialog box,
|
||
but this may mean that outgoing packets, or incoming packets, won't be
|
||
seen in the capture.
|
||
|
||
On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
|
||
NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
|
||
"GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
|
||
the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
|
||
un-install it and install the final 3.1 release.) See the Wireshark
|
||
Wiki item on PPP capturing for details.
|
||
|
||
Q 8.5: I'm running Wireshark on Windows 95/98/Me, on a machine with
|
||
more than one network adapter of the same type; why does Wireshark
|
||
show all of those adapters with the same name, not letting me use any
|
||
of those adapters other than the first one?
|
||
|
||
A: Unfortunately, Windows 95/98/Me gives the same name to multiple
|
||
instances of the type of same network adapter. Therefore, WinPcap
|
||
cannot distinguish between them, so a WinPcap-based application can
|
||
capture only on the first such interface; Wireshark is a
|
||
libpcap/WinPcap-based application.
|
||
|
||
Q 8.6: I'm running Wireshark on Windows; why am I not seeing any
|
||
traffic being sent by the machine running Wireshark?
|
||
|
||
A: If you are running some form of VPN client software, it might be
|
||
causing this problem; people have seen this problem when they have
|
||
Check Point's VPN software installed on their machine. If that's the
|
||
cause of the problem, you will have to remove the VPN software in
|
||
order to have Wireshark (or any other application using WinPcap) see
|
||
outgoing packets; unfortunately, neither we nor the WinPcap developers
|
||
know any way to make WinPcap and the VPN software work well together.
|
||
|
||
Also, some drivers for Windows (especially some wireless network
|
||
interface drivers) apparently do not, when running in promiscuous
|
||
mode, arrange that outgoing packets are delivered to the software that
|
||
requested that the interface run promiscuously; try turning
|
||
promiscuous mode off.
|
||
|
||
Q 8.7: When I capture on Windows in promiscuous mode, I can see
|
||
packets other than those sent to or from my machine; however, those
|
||
packets show up with a "Short Frame" indication, unlike packets to or
|
||
from my machine. What should I do to arrange that I see those packets
|
||
in their entirety?
|
||
|
||
A: In at least some cases, this appears to be the result of PGPnet
|
||
running on the network interface on which you're capturing; turn it
|
||
off on that interface.
|
||
|
||
Q 8.8: I'm capturing packets on {Windows 95, Windows 98, Windows Me};
|
||
why are the time stamps on packets wrong?
|
||
|
||
A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap
|
||
3.0 and later releases.
|
||
|
||
Q 8.9: I'm trying to capture 802.11 traffic on Windows; why am I not
|
||
seeing any packets?
|
||
|
||
A: At least some 802.11 card drivers on Windows appear not to see any
|
||
packets if they're running in promiscuous mode. Try turning
|
||
promiscuous mode off; you'll only be able to see packets sent by and
|
||
received by your machine, not third-party traffic, and it'll look like
|
||
Ethernet traffic and won't include any management or control frames,
|
||
but that's a limitation of the card drivers.
|
||
|
||
See MicroLogix's list of cards supported with WinPcap for information
|
||
on support of various adapters and drivers with WinPcap.
|
||
|
||
Q 8.10: I'm trying to capture 802.11 traffic on Windows; why am I
|
||
seeing packets received by the machine on which I'm capturing traffic,
|
||
but not packets sent by that machine?
|
||
|
||
A: This appears to be another problem with promiscuous mode; try
|
||
turning it off.
|
||
|
||
Q 8.11: I'm trying to capture Ethernet VLAN traffic on Windows, and
|
||
I'm capturing on a "raw" Ethernet device rather than a "VLAN
|
||
interface", so that I can see the VLAN headers; why am I seeing
|
||
packets received by the machine on which I'm capturing traffic, but
|
||
not packets sent by that machine?
|
||
|
||
A: The way the Windows networking code works probably means that
|
||
packets are sent on a "VLAN interface" rather than the "raw" device,
|
||
so packets sent by the machine will only be seen when you capture on
|
||
the "VLAN interface". If so, you will be unable to see outgoing
|
||
packets when capturing on the "raw" device, so you are stuck with a
|
||
choice between seeing VLAN headers and seeing outgoing packets.
|
||
|
||
9. Capturing packets on UN*Xes
|
||
|
||
Q 9.1: I'm running Wireshark on a UNIX-flavored OS; why does some
|
||
network interface on my machine not show up in the list of interfaces
|
||
in the "Interface:" field in the dialog box popped up by
|
||
"Capture->Start", and/or why does Wireshark give me an error if I try
|
||
to capture on that interface?
|
||
|
||
A: You may need to run Wireshark from an account with sufficient
|
||
privileges to capture packets, such as the super-user account, or may
|
||
need to give your account sufficient privileges to capture packets.
|
||
Only those interfaces that Wireshark can open for capturing show up in
|
||
that list; if you don't have sufficient privileges to capture on any
|
||
interfaces, no interfaces will show up in the list. See the Wireshark
|
||
Wiki item on capture privileges for details on how to give a
|
||
particular account or account group capture privileges on platforms
|
||
where that can be done.
|
||
|
||
If you are running Wireshark from an account with sufficient
|
||
privileges, then note that Wireshark relies on the libpcap library,
|
||
and on the facilities that come with the OS on which it's running in
|
||
order to do captures. On some OSes, those facilities aren't present by
|
||
default; see the Wireshark Wiki item on adding capture support for
|
||
details.
|
||
|
||
And, even if you're running with an account that has sufficient
|
||
privileges to capture, and capture support is present in your OS, if
|
||
the OS or the libpcap library don't support capturing on a particular
|
||
network interface device or particular types of devices, Wireshark
|
||
won't be able to capture on that device.
|
||
|
||
On Solaris, note that libpcap 0.6.2 and earlier didn't support Token
|
||
Ring interfaces; the current version, 0.7.2, does support Token Ring,
|
||
and the current version of Wireshark works with libcap 0.7.2 and
|
||
later.
|
||
|
||
If an interface doesn't show up in the list of interfaces in the
|
||
"Interface:" field, and you know the name of the interface, try
|
||
entering that name in the "Interface:" field and capturing on that
|
||
device.
|
||
|
||
If the attempt to capture on it succeeds, the interface is somehow not
|
||
being reported by the mechanism Wireshark uses to get a list of
|
||
interfaces; please report this to wireshark-dev@wireshark.org giving
|
||
full details of the problem, including
|
||
* the operating system you're using, and the version of that
|
||
operating system (for Linux, give both the version number of the
|
||
kernel and the name and version number of the distribution you're
|
||
using);
|
||
* the type of network device you're using.
|
||
|
||
If you are having trouble capturing on a particular network interface,
|
||
and you've made sure that (on platforms that require it) you've
|
||
arranged that packet capture support is present, as per the above,
|
||
first try capturing on that device with tcpdump.
|
||
|
||
If you can capture on the interface with tcpdump, send mail to
|
||
wireshark-users@wireshark.org giving full details of the problem,
|
||
including
|
||
* the operating system you're using, and the version of that
|
||
operating system (for Linux, give both the version number of the
|
||
kernel and the name and version number of the distribution you're
|
||
using);
|
||
* the type of network device you're using;
|
||
* the error message you get from Wireshark.
|
||
|
||
If you cannot capture on the interface with tcpdump, this is almost
|
||
certainly a problem with one or more of:
|
||
* the operating system you're using;
|
||
* the device driver for the interface you're using;
|
||
* the libpcap library;
|
||
|
||
so you should report the problem to the company or organization that
|
||
produces the OS (in the case of a Linux distribution, report the
|
||
problem to whoever produces the distribution).
|
||
|
||
You may also want to ask the wireshark-users@wireshark.org and the
|
||
tcpdump-workers@tcpdump.org mailing lists to see if anybody happens to
|
||
know about the problem and know a workaround or fix for the problem.
|
||
In your mail, please give full details of the problem, as described
|
||
above, and also indicate that the problem occurs with tcpdump not just
|
||
with Wireshark.
|
||
|
||
Q 9.2: I'm running Wireshark on a UNIX-flavored OS; why do no network
|
||
interfaces show up in the list of interfaces in the "Interface:" field
|
||
in the dialog box popped up by "Capture->Start"?
|
||
|
||
A: This is really the same question as the previous one; see the
|
||
response to that question.
|
||
|
||
Q 9.3: I'm capturing packets on Linux; why do the time stamps have
|
||
only 100ms resolution, rather than 1us resolution?
|
||
|
||
A: Wireshark gets time stamps from libpcap/WinPcap, and
|
||
libpcap/WinPcap get them from the OS kernel, so Wireshark - and any
|
||
other program using libpcap, such as tcpdump - is at the mercy of the
|
||
time stamping code in the OS for time stamps.
|
||
|
||
At least on x86-based machines, Linux can get high-resolution time
|
||
stamps on newer processors with the Time Stamp Counter (TSC) register;
|
||
for example, Intel x86 processors, starting with the Pentium Pro, and
|
||
including all x86 processors since then, have had a TSC, and other
|
||
vendors probably added the TSC at some point to their families of x86
|
||
processors.
|
||
|
||
The Linux kernel must be configured with the CONFIG_X86_TSC option
|
||
enabled in order to use the TSC. Make sure this option is enabled in
|
||
your kernel.
|
||
|
||
In addition, some Linux distributions may have bugs in their versions
|
||
of the kernel that cause packets not to be given high-resolution time
|
||
stamps even if the TSC is enabled. See, for example, bug 61111 for Red
|
||
Hat Linux 7.2. If your distribution has a bug such as this, you may
|
||
have to run a standard kernel from kernel.org in order to get
|
||
high-resolution time stamps.
|
||
|
||
10. Capturing packets on wireless LANs
|
||
|
||
Q 10.1: How can I capture raw 802.11 frames, including non-data
|
||
(management, beacon) frames?
|
||
|
||
A: That depends on the operating system on which you're running, and
|
||
on the 802.11 interface on which you're capturing.
|
||
|
||
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 the Wireshark Wiki item on 802.11 capturing for details.
|
||
|
||
Q 10.2: How do I capture on an 802.11 device in monitor mode?
|
||
|
||
A: Whether you will be able to capture in monitor mode depends on the
|
||
operating system, adapter, and driver you're using. See the previous
|
||
question for information on monitor mode, including a link to the
|
||
Wireshark Wiki page that gives details on 802.11 capturing.
|
||
|
||
11. Viewing traffic
|
||
|
||
Q 11.1: Why am I seeing lots of packets with incorrect TCP checksums?
|
||
|
||
A: If the packets that have incorrect TCP checksums are all being sent
|
||
by the machine on which Wireshark is running, this is probably because
|
||
the network interface on which you're capturing does TCP checksum
|
||
offloading. That means that the TCP checksum is added to the packet by
|
||
the network interface, not by the OS's TCP/IP stack; when capturing on
|
||
an interface, packets being sent by the host on which you're capturing
|
||
are directly handed to the capture interface by the OS, which means
|
||
that they are handed to the capture interface without a TCP checksum
|
||
being added to them.
|
||
|
||
The only way to prevent this from happening would be to disable TCP
|
||
checksum offloading, but
|
||
1. that might not even be possible on some OSes;
|
||
2. that could reduce networking performance significantly.
|
||
|
||
However, you can disable the check that Wireshark does of the TCP
|
||
checksum, so that it won't report any packets as having TCP checksum
|
||
errors, and so that it won't refuse to do TCP reassembly due to a
|
||
packet having an incorrect TCP checksum. That can be set as an
|
||
Wireshark preference by selecting "Preferences" from the "Edit" menu,
|
||
opening up the "Protocols" list in the left-hand pane of the
|
||
"Preferences" dialog box, selecting "TCP", from that list, turning off
|
||
the "Check the validity of the TCP checksum when possible" option,
|
||
clicking "Save" if you want to save that setting in your preference
|
||
file, and clicking "OK".
|
||
|
||
It can also be set on the Wireshark or TShark command line with a -o
|
||
tcp.check_checksum:false command-line flag, or manually set in your
|
||
preferences file by adding a tcp.check_checksum:false line.
|
||
|
||
Q 11.2: I've just installed Wireshark, and the traffic on my local LAN
|
||
is boring. Where can I find more interesting captures?
|
||
|
||
A: We have a collection of strange and exotic sample capture files at
|
||
http://wiki.wireshark.org/SampleCaptures
|
||
|
||
Q 11.3: Why doesn't Wireshark correctly identify RTP packets? It shows
|
||
them only as UDP.
|
||
|
||
A: Wireshark can identify a UDP datagram as containing a packet of a
|
||
particular protocol running atop UDP only if
|
||
1. The protocol in question has a particular standard port number,
|
||
and the UDP source or destination port number is that port
|
||
2. Packets of that protocol can be identified by looking for a
|
||
"signature" of some type in the packet - i.e., some data that, if
|
||
Wireshark finds it in some particular part of a packet, means that
|
||
the packet is almost certainly a packet of that type.
|
||
3. Some other traffic earlier in the capture indicated that, for
|
||
example, UDP traffic between two particular addresses and ports
|
||
will be RTP traffic.
|
||
|
||
RTP doesn't have a standard port number, so 1) doesn't work; it
|
||
doesn't, as far as I know, have any "signature", so 2) doesn't work.
|
||
|
||
That leaves 3). If there's RTSP traffic that sets up an RTP session,
|
||
then, at least in some cases, the RTSP dissector will set things up so
|
||
that subsequent RTP traffic will be identified. Currently, that's the
|
||
only place we do that; there may be other places.
|
||
|
||
However, there will always be places where Wireshark is simply
|
||
incapable of deducing that a given UDP flow is RTP; a mechanism would
|
||
be needed to allow the user to specify that a given conversation
|
||
should be treated as RTP. As of Wireshark 0.8.16, such a mechanism
|
||
exists; if you select a UDP or TCP packet, the right mouse button menu
|
||
will have a "Decode As..." menu item, which will pop up a dialog box
|
||
letting you specify that the source port, the destination port, or
|
||
both the source and destination ports of the packet should be
|
||
dissected as some particular protocol.
|
||
|
||
Q 11.4: Why doesn't Wireshark show Yahoo Messenger packets in captures
|
||
that contain Yahoo Messenger traffic?
|
||
|
||
A: Wireshark only recognizes as Yahoo Messenger traffic packets to or
|
||
from TCP port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP
|
||
segments that start with the middle of a Yahoo Messenger packet that
|
||
takes more than one TCP segment will not be recognized as Yahoo
|
||
Messenger packets (even if the TCP segment also contains the beginning
|
||
of another Yahoo Messenger packet).
|
||
|
||
12. Filtering traffic
|
||
|
||
Q 12.1: I saved a filter and tried to use its name to filter the
|
||
display; why do I get an "Unexpected end of filter string" error?
|
||
|
||
A: You cannot use the name of a saved display filter as a filter. To
|
||
filter the display, you can enter a display filter expression - not
|
||
the name of a saved display filter - in the "Filter:" box at the
|
||
bottom of the display, and type the key or press the "Apply" button
|
||
(that does not require you to have a saved filter), or, if you want to
|
||
use a saved filter, you can press the "Filter:" button, select the
|
||
filter in the dialog box that pops up, and press the "OK" button.
|
||
|
||
Q 12.2: How can I search for, or filter, packets that have a
|
||
particular string anywhere in them?
|
||
|
||
A: If you want to do this when capturing, you can't. That's a feature
|
||
that would be hard to implement in capture filters without changes to
|
||
the capture filter code, which, on many platforms, is in the OS kernel
|
||
and, on other platforms, is in the libpcap library.
|
||
|
||
In releases prior to 0.9.14, you also can't search for, or filter,
|
||
packets containing a particular string even after you've captured
|
||
them.
|
||
|
||
In 0.9.14, you can search for, but not filter, packets that have a
|
||
particular string; this has been added to the "Find Frame" dialog
|
||
("Find Frame" under the "Edit" menu, or control-F).
|
||
|
||
In 0.9.15 and later, you can search for those packets using either the
|
||
mechanism introduced in 0.9.14 or using the new "contains" operator in
|
||
filter expressions, which lets you search the entire packet or text
|
||
string or byte string fields in the packet; the "contains" operator
|
||
can also be used in expressions used to filter the display.
|
||
|
||
Q 12.3: How do I filter a capture to see traffic for virus XXX?
|
||
|
||
A: For some viruses/worms there might be a capture filter to recognize
|
||
the virus traffic. Check the CaptureFilters page on the Wireshark Wiki
|
||
to see if anybody's added such a filter.
|
||
|
||
Note that Wireshark was not designed to be an intrusion detection
|
||
system; you might be able to use it as an IDS, but in most cases
|
||
software designed to be an IDS, such as Snort or Prelude, will
|
||
probably work better.
|
||
|
||
The Bleeding Edge of Snort has a collection of signatures for Snort to
|
||
detect various viruses, worms, and the like.
|