forked from osmocom/wireshark
make-faq: Format of the online file changed slightly.
Update FAQ and help/faq.txt to current version. svn path=/trunk/; revision=23515
This commit is contained in:
parent
59379adf4d
commit
06f0070947
290
FAQ
290
FAQ
|
@ -36,9 +36,7 @@
|
|||
|
||||
1.12 What devices can Wireshark use to capture packets?
|
||||
|
||||
1.13 Does Wireshark work on Windows Me?
|
||||
|
||||
1.14 Does Wireshark work on Windows XP?
|
||||
1.13 Does Wireshark work on Windows Vista?
|
||||
|
||||
2. Downloading Wireshark:
|
||||
|
||||
|
@ -82,10 +80,7 @@
|
|||
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
|
||||
5.4 I've installed Wireshark from Fink on Mac OS X; why is it very slow
|
||||
to start up?
|
||||
|
||||
6. Crashes and other fatal errors:
|
||||
|
@ -150,31 +145,23 @@
|
|||
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
|
||||
8.5 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
|
||||
8.6 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
|
||||
8.7 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
|
||||
8.8 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
|
||||
8.9 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
|
||||
|
@ -229,43 +216,39 @@
|
|||
|
||||
Q 1.1: What is Wireshark?
|
||||
|
||||
A: Wireshark is the world's most popular network protocol analyzer. It
|
||||
A: Wireshark® is 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. 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.
|
||||
|
||||
platforms including Windows, OS X, 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.
|
||||
It is developed and maintained by a global team of protocol experts,
|
||||
and it is an example of a 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.
|
||||
|
||||
and it is an example of a 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.
|
||||
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, Gerald Combs (the original author of Ethereal®) went
|
||||
A: 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.
|
||||
|
||||
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. As far as anyone knows, 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.
|
||||
|
||||
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:
|
||||
*
|
||||
*
|
||||
* Many other articles in
|
||||
|
||||
Q 1.3: Where can I get help?
|
||||
|
||||
|
@ -274,10 +257,8 @@
|
|||
lists can be found at http://www.wireshark.org/mailman/listinfo. An IRC
|
||||
channel dedicated to Wireshark can be found at
|
||||
irc://irc.freenode.net/wireshark.
|
||||
|
||||
Self-paced and instructor-led training is available at Wireshark
|
||||
University. A certification program will be announced in Q2 2007.
|
||||
|
||||
University. A certification program will be announced in Q3 2007.
|
||||
Commercial support and development services are available from CACE
|
||||
Technologies.
|
||||
|
||||
|
@ -290,7 +271,6 @@
|
|||
A: 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.
|
||||
|
||||
|
@ -300,7 +280,6 @@
|
|||
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.
|
||||
|
||||
|
@ -309,7 +288,6 @@
|
|||
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.
|
||||
|
||||
|
@ -326,7 +304,6 @@
|
|||
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.
|
||||
|
@ -348,12 +325,10 @@
|
|||
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
|
||||
|
@ -363,7 +338,6 @@
|
|||
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.
|
||||
|
||||
|
@ -375,7 +349,12 @@
|
|||
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 update the wiki page accordingly.
|
||||
It can also read a variety of capture file formats, including:
|
||||
* AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet
|
||||
Grabber captures
|
||||
|
@ -410,30 +389,25 @@
|
|||
other applications or equipment, even if it cannot itself capture on
|
||||
those network types.
|
||||
|
||||
Q 1.13: Does Wireshark work on Windows Me?
|
||||
Q 1.13: Does Wireshark work on Windows Vista?
|
||||
|
||||
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.14: Does Wireshark work on Windows XP?
|
||||
|
||||
A: Yes, but if you want to capture packets, you will need to install
|
||||
the latest version of WinPcap, as 2.2 and earlier versions of WinPcap
|
||||
didn't support Windows XP.
|
||||
A: Yes, but if you want to capture packets, you must make sure npf.sys
|
||||
is loaded. You can do this by selecting Start WinPcap service "NPF" at
|
||||
startup in the installer or by running sc config npf start= auto as
|
||||
Administrator from the command line. You can also run Wireshark as
|
||||
Administrator, but this is discouraged. See the CaputrePrivileges page
|
||||
on the wiki for more details.
|
||||
|
||||
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.
|
||||
|
||||
incorrectly. Web browsers and download accelerators 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;
|
||||
* Wget, for which Windows binaries are available from Christopher
|
||||
Lewis or wGetGUI, which offers a GUI interface that uses wget;
|
||||
* WS_FTP from Ipswitch,
|
||||
* the ftp command that comes with Windows.
|
||||
|
||||
|
@ -461,7 +435,6 @@
|
|||
"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.
|
||||
|
@ -485,7 +458,6 @@
|
|||
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
|
||||
|
@ -519,7 +491,6 @@
|
|||
(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.
|
||||
|
||||
|
@ -538,7 +509,6 @@
|
|||
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.
|
||||
|
||||
|
@ -560,34 +530,19 @@
|
|||
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
|
||||
Q 5.4: 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
|
||||
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
|
||||
|
@ -629,10 +584,8 @@
|
|||
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
|
||||
|
@ -640,7 +593,6 @@
|
|||
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
|
||||
|
@ -649,7 +601,6 @@
|
|||
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
|
||||
|
@ -660,7 +611,6 @@
|
|||
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
|
||||
|
@ -681,23 +631,19 @@
|
|||
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
|
||||
|
@ -720,13 +666,11 @@
|
|||
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.
|
||||
|
||||
|
@ -736,7 +680,6 @@
|
|||
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.
|
||||
|
||||
|
@ -747,12 +690,10 @@
|
|||
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.
|
||||
|
||||
|
@ -763,7 +704,6 @@
|
|||
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
|
||||
|
@ -772,13 +712,13 @@
|
|||
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.
|
||||
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)
|
||||
|
@ -802,17 +742,14 @@
|
|||
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.
|
||||
|
||||
|
@ -822,20 +759,16 @@
|
|||
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
|
||||
|
@ -843,7 +776,6 @@
|
|||
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.
|
||||
|
@ -856,7 +788,6 @@
|
|||
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
|
||||
|
@ -866,14 +797,12 @@
|
|||
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
|
||||
|
@ -890,7 +819,6 @@
|
|||
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
|
||||
|
@ -899,7 +827,6 @@
|
|||
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
|
||||
|
@ -907,7 +834,6 @@
|
|||
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
|
||||
|
@ -924,7 +850,6 @@
|
|||
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
|
||||
|
@ -937,7 +862,6 @@
|
|||
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:
|
||||
|
@ -949,7 +873,6 @@
|
|||
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,
|
||||
|
@ -960,7 +883,6 @@
|
|||
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
|
||||
|
@ -971,7 +893,6 @@
|
|||
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
|
||||
|
@ -981,7 +902,6 @@
|
|||
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
|
||||
|
@ -996,7 +916,6 @@
|
|||
|
||||
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
|
||||
|
@ -1026,21 +945,17 @@
|
|||
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 you are running on Windows 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
|
||||
|
@ -1052,17 +967,7 @@
|
|||
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
|
||||
2. 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
|
||||
|
@ -1076,7 +981,7 @@
|
|||
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
|
||||
3. 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
|
||||
|
@ -1089,12 +994,10 @@
|
|||
"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
|
||||
|
@ -1112,11 +1015,9 @@
|
|||
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
|
||||
|
@ -1134,7 +1035,6 @@
|
|||
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.
|
||||
|
@ -1148,8 +1048,8 @@
|
|||
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.
|
||||
A: This is really the same question as a 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
|
||||
|
@ -1161,7 +1061,6 @@
|
|||
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
|
||||
|
@ -1183,7 +1082,6 @@
|
|||
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
|
||||
|
@ -1191,18 +1089,7 @@
|
|||
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
|
||||
Q 8.5: 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
|
||||
|
@ -1212,14 +1099,13 @@
|
|||
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
|
||||
Q 8.6: 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
|
||||
|
@ -1229,13 +1115,7 @@
|
|||
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
|
||||
Q 8.7: 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
|
||||
|
@ -1244,18 +1124,17 @@
|
|||
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?
|
||||
Q 8.8: 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
|
||||
Q 8.9: 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
|
||||
|
@ -1285,29 +1164,24 @@
|
|||
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
|
||||
|
@ -1322,7 +1196,6 @@
|
|||
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
|
||||
|
@ -1342,7 +1215,6 @@
|
|||
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
|
||||
|
@ -1364,18 +1236,14 @@
|
|||
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.
|
||||
|
||||
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
|
||||
|
@ -1390,32 +1258,27 @@
|
|||
|
||||
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?
|
||||
|
@ -1438,7 +1301,6 @@
|
|||
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;
|
||||
|
@ -1454,7 +1316,6 @@
|
|||
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.
|
||||
|
@ -1482,12 +1343,10 @@
|
|||
|
||||
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
|
||||
|
@ -1528,14 +1387,11 @@
|
|||
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
|
||||
|
@ -1547,11 +1403,9 @@
|
|||
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.
|
||||
|
|
290
help/faq.txt
290
help/faq.txt
|
@ -36,9 +36,7 @@
|
|||
|
||||
1.12 What devices can Wireshark use to capture packets?
|
||||
|
||||
1.13 Does Wireshark work on Windows Me?
|
||||
|
||||
1.14 Does Wireshark work on Windows XP?
|
||||
1.13 Does Wireshark work on Windows Vista?
|
||||
|
||||
2. Downloading Wireshark:
|
||||
|
||||
|
@ -82,10 +80,7 @@
|
|||
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
|
||||
5.4 I've installed Wireshark from Fink on Mac OS X; why is it very slow
|
||||
to start up?
|
||||
|
||||
6. Crashes and other fatal errors:
|
||||
|
@ -150,31 +145,23 @@
|
|||
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
|
||||
8.5 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
|
||||
8.6 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
|
||||
8.7 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
|
||||
8.8 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
|
||||
8.9 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
|
||||
|
@ -229,43 +216,39 @@
|
|||
|
||||
Q 1.1: What is Wireshark?
|
||||
|
||||
A: Wireshark is the world's most popular network protocol analyzer. It
|
||||
A: Wireshark® is 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. 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.
|
||||
|
||||
platforms including Windows, OS X, 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.
|
||||
It is developed and maintained by a global team of protocol experts,
|
||||
and it is an example of a 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.
|
||||
|
||||
and it is an example of a 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.
|
||||
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, Gerald Combs (the original author of Ethereal®) went
|
||||
A: 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.
|
||||
|
||||
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. As far as anyone knows, 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.
|
||||
|
||||
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:
|
||||
*
|
||||
*
|
||||
* Many other articles in
|
||||
|
||||
Q 1.3: Where can I get help?
|
||||
|
||||
|
@ -274,10 +257,8 @@
|
|||
lists can be found at http://www.wireshark.org/mailman/listinfo. An IRC
|
||||
channel dedicated to Wireshark can be found at
|
||||
irc://irc.freenode.net/wireshark.
|
||||
|
||||
Self-paced and instructor-led training is available at Wireshark
|
||||
University. A certification program will be announced in Q2 2007.
|
||||
|
||||
University. A certification program will be announced in Q3 2007.
|
||||
Commercial support and development services are available from CACE
|
||||
Technologies.
|
||||
|
||||
|
@ -290,7 +271,6 @@
|
|||
A: 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.
|
||||
|
||||
|
@ -300,7 +280,6 @@
|
|||
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.
|
||||
|
||||
|
@ -309,7 +288,6 @@
|
|||
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.
|
||||
|
||||
|
@ -326,7 +304,6 @@
|
|||
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.
|
||||
|
@ -348,12 +325,10 @@
|
|||
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
|
||||
|
@ -363,7 +338,6 @@
|
|||
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.
|
||||
|
||||
|
@ -375,7 +349,12 @@
|
|||
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 update the wiki page accordingly.
|
||||
It can also read a variety of capture file formats, including:
|
||||
* AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet
|
||||
Grabber captures
|
||||
|
@ -410,30 +389,25 @@
|
|||
other applications or equipment, even if it cannot itself capture on
|
||||
those network types.
|
||||
|
||||
Q 1.13: Does Wireshark work on Windows Me?
|
||||
Q 1.13: Does Wireshark work on Windows Vista?
|
||||
|
||||
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.14: Does Wireshark work on Windows XP?
|
||||
|
||||
A: Yes, but if you want to capture packets, you will need to install
|
||||
the latest version of WinPcap, as 2.2 and earlier versions of WinPcap
|
||||
didn't support Windows XP.
|
||||
A: Yes, but if you want to capture packets, you must make sure npf.sys
|
||||
is loaded. You can do this by selecting Start WinPcap service "NPF" at
|
||||
startup in the installer or by running sc config npf start= auto as
|
||||
Administrator from the command line. You can also run Wireshark as
|
||||
Administrator, but this is discouraged. See the CaputrePrivileges page
|
||||
on the wiki for more details.
|
||||
|
||||
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.
|
||||
|
||||
incorrectly. Web browsers and download accelerators 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;
|
||||
* Wget, for which Windows binaries are available from Christopher
|
||||
Lewis or wGetGUI, which offers a GUI interface that uses wget;
|
||||
* WS_FTP from Ipswitch,
|
||||
* the ftp command that comes with Windows.
|
||||
|
||||
|
@ -461,7 +435,6 @@
|
|||
"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.
|
||||
|
@ -485,7 +458,6 @@
|
|||
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
|
||||
|
@ -519,7 +491,6 @@
|
|||
(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.
|
||||
|
||||
|
@ -538,7 +509,6 @@
|
|||
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.
|
||||
|
||||
|
@ -560,34 +530,19 @@
|
|||
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
|
||||
Q 5.4: 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
|
||||
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
|
||||
|
@ -629,10 +584,8 @@
|
|||
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
|
||||
|
@ -640,7 +593,6 @@
|
|||
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
|
||||
|
@ -649,7 +601,6 @@
|
|||
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
|
||||
|
@ -660,7 +611,6 @@
|
|||
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
|
||||
|
@ -681,23 +631,19 @@
|
|||
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
|
||||
|
@ -720,13 +666,11 @@
|
|||
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.
|
||||
|
||||
|
@ -736,7 +680,6 @@
|
|||
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.
|
||||
|
||||
|
@ -747,12 +690,10 @@
|
|||
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.
|
||||
|
||||
|
@ -763,7 +704,6 @@
|
|||
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
|
||||
|
@ -772,13 +712,13 @@
|
|||
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.
|
||||
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)
|
||||
|
@ -802,17 +742,14 @@
|
|||
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.
|
||||
|
||||
|
@ -822,20 +759,16 @@
|
|||
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
|
||||
|
@ -843,7 +776,6 @@
|
|||
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.
|
||||
|
@ -856,7 +788,6 @@
|
|||
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
|
||||
|
@ -866,14 +797,12 @@
|
|||
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
|
||||
|
@ -890,7 +819,6 @@
|
|||
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
|
||||
|
@ -899,7 +827,6 @@
|
|||
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
|
||||
|
@ -907,7 +834,6 @@
|
|||
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
|
||||
|
@ -924,7 +850,6 @@
|
|||
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
|
||||
|
@ -937,7 +862,6 @@
|
|||
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:
|
||||
|
@ -949,7 +873,6 @@
|
|||
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,
|
||||
|
@ -960,7 +883,6 @@
|
|||
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
|
||||
|
@ -971,7 +893,6 @@
|
|||
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
|
||||
|
@ -981,7 +902,6 @@
|
|||
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
|
||||
|
@ -996,7 +916,6 @@
|
|||
|
||||
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
|
||||
|
@ -1026,21 +945,17 @@
|
|||
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 you are running on Windows 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
|
||||
|
@ -1052,17 +967,7 @@
|
|||
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
|
||||
2. 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
|
||||
|
@ -1076,7 +981,7 @@
|
|||
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
|
||||
3. 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
|
||||
|
@ -1089,12 +994,10 @@
|
|||
"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
|
||||
|
@ -1112,11 +1015,9 @@
|
|||
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
|
||||
|
@ -1134,7 +1035,6 @@
|
|||
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.
|
||||
|
@ -1148,8 +1048,8 @@
|
|||
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.
|
||||
A: This is really the same question as a 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
|
||||
|
@ -1161,7 +1061,6 @@
|
|||
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
|
||||
|
@ -1183,7 +1082,6 @@
|
|||
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
|
||||
|
@ -1191,18 +1089,7 @@
|
|||
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
|
||||
Q 8.5: 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
|
||||
|
@ -1212,14 +1099,13 @@
|
|||
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
|
||||
Q 8.6: 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
|
||||
|
@ -1229,13 +1115,7 @@
|
|||
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
|
||||
Q 8.7: 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
|
||||
|
@ -1244,18 +1124,17 @@
|
|||
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?
|
||||
Q 8.8: 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
|
||||
Q 8.9: 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
|
||||
|
@ -1285,29 +1164,24 @@
|
|||
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
|
||||
|
@ -1322,7 +1196,6 @@
|
|||
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
|
||||
|
@ -1342,7 +1215,6 @@
|
|||
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
|
||||
|
@ -1364,18 +1236,14 @@
|
|||
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.
|
||||
|
||||
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
|
||||
|
@ -1390,32 +1258,27 @@
|
|||
|
||||
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?
|
||||
|
@ -1438,7 +1301,6 @@
|
|||
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;
|
||||
|
@ -1454,7 +1316,6 @@
|
|||
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.
|
||||
|
@ -1482,12 +1343,10 @@
|
|||
|
||||
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
|
||||
|
@ -1528,14 +1387,11 @@
|
|||
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
|
||||
|
@ -1547,11 +1403,9 @@
|
|||
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.
|
||||
|
|
Loading…
Reference in New Issue