1. General Questions:
- 1.1 Where can I get help?
+ 1.1 What is Wireshark?
- 1.2 How much does Ethereal cost?
+ 1.2 What's up with the name change? Is Wireshark a fork?
- 1.3 Can I use Ethereal commercially?
+ 1.3 Where can I get help?
- 1.4 Can I use Ethereal as part of my commercial product?
+ 1.4 How much does Wireshark cost?
- 1.5 What protocols are currently supported?
+ 1.5 Can I use Wireshark commercially?
- 1.6 Are there any plans to support {your favorite protocol}?
+ 1.6 Can I use Wireshark as part of my commercial product?
- 1.7 Can Ethereal read capture files from {your favorite network analyzer}?
+ 1.7 What protocols are currently supported?
- 1.8 What devices can Ethereal use to capture packets?
+ 1.8 Are there any plans to support {your favorite protocol}?
- 1.9 How do you pronounce Ethereal? Where did the name come from?
+ 1.9 Can Wireshark read capture files from {your favorite network
+ analyzer}?
- 1.10 Does Ethereal work on Windows Me?
+ 1.10 What devices can Wireshark use to capture packets?
- 1.11 Does Ethereal work on Windows XP?
+ 1.11 Does Wireshark work on Windows Me?
-2. Downloading Ethereal:
+ 1.12 Does Wireshark work on Windows XP?
- 2.1 Why do I get an error when I try to run the Win32 installer?
+2. Downloading Wireshark:
- 2.2 Why can't I get to the WinPcap Web site in order to download WinPcap?
+ 2.1 Why do I get an error when I try to run the Win32 installer?
-3. Installing Ethereal:
+3. Installing Wireshark:
- 3.1 I installed an Ethereal RPM; why did it install TShark but not
- Ethereal?
+ 3.1 I installed the Wireshark RPM (or other package); why did it
+ install TShark but not Wireshark?
-4. Building Ethereal:
+4. Building Wireshark:
- 4.1 I have libpcap installed; why did the configure script not find pcap.h
- or bpf.h?
+ 4.1 I have libpcap installed; why did the configure script not find
+ pcap.h or bpf.h?
4.2 Why do I get the error
- dftest_DEPENDENCIES was already defined in condition TRUE, which implies
- condition HAVE_PLUGINS_TRUE
+ dftest_DEPENDENCIES was already defined in condition TRUE, which
+ implies condition HAVE_PLUGINS_TRUE
- when I try to build Ethereal from SVN or a SVN snapshot?
+ when I try to build Wireshark from SVN or a SVN snapshot?
4.3 Why does the linker fail with a number of "Output line too long."
- messages followed by linker errors when I try to buil Ethereal?
+ messages followed by linker errors when I try to buil Wireshark?
- 4.4 When I try to build Ethereal on Solaris, why does the link fail
+ 4.4 When I try to build Wireshark on Solaris, why does the link fail
complaining that plugin_list is undefined?
- 4.5 When I try to build Ethereal on Windows, why does the build fail because
- of conflicts between winsock.h and winsock2.h?
-
-5. Starting Ethereal:
-
- 5.1 Why does Ethereal crash with a Bus Error when I try to run it on Solaris
- 8?
+ 4.5 When I try to build Wireshark on Windows, why does the build fail
+ because of conflicts between winsock.h and winsock2.h?
- 5.2 When I run TShark with the "-x" option, why does it crash with an
- error
+5. Starting Wireshark:
- "** ERROR **: file print.c: line 691 (print_line): should not be reached.
+ 5.1 Why does Wireshark crash with a Bus Error when I try to run it on
+ Solaris 8?
- 5.3 When I run Ethereal on Windows NT, why does it die with a Dr. Watson
- error, reporting an "Integer division by zero" exception, when I start it?
+ 5.2 When I run Wireshark on Windows NT, why does it die with a Dr.
+ Watson error, reporting an "Integer division by zero" exception, when
+ I start it?
- 5.4 When I try to run Ethereal, why does it complain about
+ 5.3 When I try to run Wireshark, why does it complain about
sprint_realloc_objid being undefined?
- 5.5 When I try to run Ethereal on Windows, why does it fail to run with a
- complaint that it can't find packet.dll?
-
- 5.6 Why do I get the error
-
- Gdk-ERROR **: Palettized display (256-colour) mode not supported on
- Windows.
- aborting....
+ 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?
- when I try to run Ethereal on Windows?
-
- 5.7 I've installed Ethereal from Fink on Mac OS X; why is it very slow to
- start up?
+ 5.5 I've installed Wireshark from Fink on Mac OS X; why is it very
+ slow to start up?
6. Crashes and other fatal errors:
- 6.1 When I run Ethereal, why do I get an error
-
- Gtk-CRITICAL **: file gtkwindow.c: line 3107 (gtk_window_resize):
- assertion `height > 0' failed.
-
- 6.2 I have an XXX network card on my machine; if I try to capture on it, why
- does my machine crash or reset itself?
+ 6.1 I have an XXX network card on my machine; if I try to capture on
+ it, why does my machine crash or reset itself?
- 6.3 Why does my machine crash or reset itself when I select "Start" from the
- "Capture" menu or select "Preferences" from the "Edit" menu?
+ 6.2 Why does my machine crash or reset itself when I select "Start"
+ from the "Capture" menu or select "Preferences" from the "Edit" menu?
7. Capturing packets:
- 7.1 When I use Ethereal to capture packets, why do I see only packets to and
- from my machine, or not see all the traffic I'm expecting to see from or to
- the machine I'm trying to monitor?
+ 7.1 When I use Wireshark to capture packets, why do I see only packets
+ to and from my machine, or not see all the traffic I'm expecting to
+ see from or to the machine I'm trying to monitor?
- 7.2 When I capture with Ethereal, why can't I see any TCP packets other than
- packets to and from my machine, even though another analyzer on the network
- sees those packets?
+ 7.2 When I capture with Wireshark, why can't I see any TCP packets
+ other than packets to and from my machine, even though another
+ analyzer on the network sees those packets?
7.3 Why am I only seeing ARP packets when I try to capture traffic?
7.4 Why am I not seeing any traffic when I try to capture traffic?
- 7.5 Can Ethereal capture on (my T1/E1 line, SS7 links, etc.)?
+ 7.5 Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
7.6 How do I put an interface into promiscuous mode?
- 7.7 I can set a display filter just fine; why don't capture filters work?
+ 7.7 I can set a display filter just fine; why don't capture filters
+ work?
- 7.8 I'm entering valid capture filters; why do I still get "parse error"
- errors?
+ 7.8 I'm entering valid capture filters; why do I still get "parse
+ error" errors?
7.9 How can I capture packets with CRC errors?
7.10 How can I capture entire frames, including the FCS?
- 7.11 I'm capturing packets on a machine on a VLAN; why don't the packets I'm
- capturing have VLAN tags?
+ 7.11 I'm capturing packets on a machine on a VLAN; why don't the
+ packets I'm capturing have VLAN tags?
- 7.12 Why does Ethereal hang after I stop a capture?
+ 7.12 Why does Wireshark hang after I stop a capture?
8. Capturing packets on Windows:
- 8.1 I'm running Ethereal on Windows; why does some network interface on my
- machine not show up in the list of interfaces in the "Interface:" field in
- the dialog box popped up by "Capture->Start", and/or why does Ethereal give
- me an error if I try to capture on that interface?
+ 8.1 I'm running Wireshark on Windows; why does some network interface
+ on my machine not show up in the list of interfaces in the
+ "Interface:" field in the dialog box popped up by "Capture->Start",
+ and/or why does Wireshark give me an error if I try to capture on that
+ interface?
- 8.2 I'm running Ethereal on Windows; why do no network interfaces show up in
- the list of interfaces in the "Interface:" field in the dialog box popped up
- by "Capture->Start"?
+ 8.2 I'm running Wireshark on Windows; why do no network interfaces
+ show up in the list of interfaces in the "Interface:" field in the
+ dialog box popped up by "Capture->Start"?
- 8.3 I'm running Ethereal on Windows; why doesn't my serial port/ADSL
- modem/ISDN modem show up in the list of interfaces in the "Interface:" field
- in the dialog box popped up by "Capture->Start"?
+ 8.3 I'm running Wireshark on Windows; why doesn't my serial port/ADSL
+ modem/ISDN modem show up in the list of interfaces in the "Interface:"
+ field in the dialog box popped up by "Capture->Start"?
- 8.4 I'm running Ethereal on Windows NT 4.0/Windows 2000/Windows XP/Windows
- Server 2003; my machine has a PPP (dial-up POTS, ISDN, etc.) interface, and
- it shows up in the "Interface" item in the "Capture Options" dialog box. Why
- can no packets be sent on or received from that network while I'm trying to
- capture traffic on that interface?
+ 8.4 I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows
+ XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN,
+ etc.) interface, and it shows up in the "Interface" item in the
+ "Capture Options" dialog box. Why can no packets be sent on or
+ received from that network while I'm trying to capture traffic on that
+ interface?
- 8.5 I'm running Ethereal on Windows 95/98/Me, on a machine with more than
- one network adapter of the same type; why does Ethereal show all of those
- adapters with the same name, not letting me use any of those adapters other
- than the first one?
+ 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 Ethereal on Windows; why am I not seeing any traffic being
- sent by the machine running Ethereal?
+ 8.6 I'm running Wireshark on Windows; why am I not seeing any traffic
+ being sent by the machine running Wireshark?
- 8.7 When I capture on Windows in promiscuous mode, I can see packets other
- than those sent to or from my machine; however, those packets show up with a
- "Short Frame" indication, unlike packets to or from my machine. What should
- I do to arrange that I see those packets in their entirety?
+ 8.7 When I capture on Windows in promiscuous mode, I can see packets
+ other than those sent to or from my machine; however, those packets
+ show up with a "Short Frame" indication, unlike packets to or from my
+ machine. What should I do to arrange that I see those packets in their
+ entirety?
- 8.8 I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why are
- the time stamps on packets wrong?
+ 8.8 I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why
+ are the time stamps on packets wrong?
- 8.9 I'm trying to capture 802.11 traffic on Windows; why am I not seeing any
- packets?
+ 8.9 I'm trying to capture 802.11 traffic on Windows; why am I not
+ seeing any packets?
8.10 I'm trying to capture 802.11 traffic on Windows; why am I seeing
- packets received by the machine on which I'm capturing traffic, but not
- packets sent by that machine?
+ packets received by the machine on which I'm capturing traffic, but
+ not packets sent by that machine?
8.11 I'm trying to capture Ethernet VLAN traffic on Windows, and I'm
- capturing on a "raw" Ethernet device rather than a "VLAN interface", so that
- I can see the VLAN headers; why am I seeing packets received by the machine
- on which I'm capturing traffic, but not packets sent by that machine?
+ capturing on a "raw" Ethernet device rather than a "VLAN interface",
+ so that I can see the VLAN headers; why am I seeing packets received
+ by the machine on which I'm capturing traffic, but not packets sent by
+ that machine?
9. Capturing packets on UN*Xes:
- 9.1 I'm running Ethereal on a UNIX-flavored OS; why does some network
+ 9.1 I'm running Wireshark on a UNIX-flavored OS; why does some network
interface on my machine not show up in the list of interfaces in the
- "Interface:" field in the dialog box popped up by "Capture->Start", and/or
- why does Ethereal give me an error if I try to capture on that interface?
+ "Interface:" field in the dialog box popped up by "Capture->Start",
+ and/or why does Wireshark give me an error if I try to capture on that
+ interface?
- 9.2 I'm running Ethereal on a UNIX-flavored OS; why do no network interfaces
- show up in the list of interfaces in the "Interface:" field in the dialog
- box popped up by "Capture->Start"?
+ 9.2 I'm running Wireshark on a UNIX-flavored OS; why do no network
+ interfaces show up in the list of interfaces in the "Interface:" field
+ in the dialog box popped up by "Capture->Start"?
- 9.3 I'm capturing packets on Linux; why do the time stamps have only 100ms
- resolution, rather than 1us resolution?
+ 9.3 I'm capturing packets on Linux; why do the time stamps have only
+ 100ms resolution, rather than 1us resolution?
10. Capturing packets on wireless LANs:
- 10.1 How can I capture raw 802.11 frames, including non-data (management,
- beacon) frames?
+ 10.1 How can I capture raw 802.11 frames, including non-data
+ (management, beacon) frames?
10.2 How do I capture on an 802.11 device in monitor mode?
11.1 Why am I seeing lots of packets with incorrect TCP checksums?
- 11.2 I've just installed Ethereal, and the traffic on my local LAN is
+ 11.2 I've just installed Wireshark, and the traffic on my local LAN is
boring. Where can I find more interesting captures?
- 11.3 Why doesn't Ethereal correctly identify RTP packets? It shows them only
- as UDP.
+ 11.3 Why doesn't Wireshark correctly identify RTP packets? It shows
+ them only as UDP.
- 11.4 Why doesn't Ethereal show Yahoo Messenger packets in captures that
- contain Yahoo Messenger traffic?
+ 11.4 Why doesn't Wireshark show Yahoo Messenger packets in captures
+ that contain Yahoo Messenger traffic?
12. Filtering traffic:
- 12.1 I saved a filter and tried to use its name to filter the display; why
- do I get an "Unexpected end of filter string" error?
+ 12.1 I saved a filter and tried to use its name to filter the display;
+ why do I get an "Unexpected end of filter string" error?
- 12.2 How can I search for, or filter, packets that have a particular string
- anywhere in them?
+ 12.2 How can I search for, or filter, packets that have a particular
+ string anywhere in them?
12.3 How do I filter a capture to see traffic for virus XXX?
1. General Questions
- Q 1.1: Where can I get help?
+ Q 1.1: What is Wireshark?
+
+ A: Gerald Combs, the creator of Ethereal®, has initiated the Wireshark
+ network protocol analyzer project, a successor to Ethereal®. The
+ Ethereal® core developer team has moved with Gerald to the Wireshark
+ project. Consequently, Wireshark is positioned to be the world's most
+ popular network protocol analyzer. It has a rich and powerful feature
+ set, and runs on most computing platforms including Windows, OS X, and
+ Linux. It is freely available as open source, and is released under
+ the GNU General Public License.
+
+ For more information, please see the About Wireshark page.
+
+ Q 1.2: What's up with the name change? Is Wireshark a fork?
+
+ A: In May of 2006, the original author of Ethereal® went to work for
+ CACE Technologies (best known for WinPcap). At that time he started
+ the Wireshark open-source project.
+
+ Wireshark is almost (but not quite) a fork. Normally a "fork" of an
+ open source project results in two names, web sites, development
+ teams, support infrastructures, etc. This is the case with Wireshark
+ except for one notable exception -- every member of the core
+ development team is now working on Wireshark.
+
+ Q 1.3: Where can I get help?
A: Community support is available on the wireshark-users mailing list.
- Subscription information and archives for all of Ethereal's mailing lists
- can be found at http://www.wireshark.org/lists. An IRC channel dedicated to
- Ethereal can be found at irc://irc.freenode.net/ethereal.
+ Subscription information and archives for all of Wireshark's mailing
+ lists can be found at http://www.wireshark.org/lists. An IRC channel
+ dedicated to Wireshark can be found at
+ irc://irc.freenode.net/ethereal.
- Commercial support, training, and development services are available from
- Ethereal Software.
+ Commercial support, training, and development services are available
+ from CACE Technologies.
- Q 1.2: How much does Ethereal cost?
+ Q 1.4: How much does Wireshark cost?
- A: Wireshark is "free software"; you can download it without paying any
- license fee. The version of Ethereal you download isn't a "demo" version,
- with limitations not present in a "full" version; it is the full version.
+ A: Wireshark is "free software"; you can download it without paying
+ any license fee. The version of Wireshark you download isn't a "demo"
+ version, with limitations not present in a "full" version; it is the
+ full version.
The license under which Wireshark is issued is the GNU General Public
License. See the GNU GPL FAQ for some more information.
- Q 1.3: Can I use Ethereal commercially?
-
- A: Yes, if, for example, you mean "I work for a commercial organization; can
- I use Ethereal to capture and analyze network traffic in our company's
- networks or in our customer's networks?"
-
- If you mean "Can I use Ethereal as part of my commercial product?", see the
- next entry in the FAQ.
-
- Q 1.4: Can I use Ethereal as part of my commercial product?
-
- A: As noted, Wireshark is licensed under the GNU General Public License. The
- GPL imposes conditions on your use of GPL'ed code in your own products; you
- cannot, for example, make a "derived work" from Ethereal, by making
- modifications to it, and then sell the resulting derived work and not allow
- recipients to give away the resulting work. You must also make the changes
- you've made to the Wireshark source available to all recipients of your
- modified version; those changes must also be licensed under the terms of the
- GPL. See the GPL FAQ for more details; in particular, note the answer to the
- question about modifying a GPLed program and selling it commercially, and
- the question about linking GPLed code with other code to make a proprietary
- program.
-
- You can combine a GPLed program such as Ethereal and a commercial program as
- long as they communicate "at arm's length", as per this item in the GPL FAQ.
-
- Q 1.5: What protocols are currently supported?
-
- A: There are currently 750 supported protocols and media, listed below.
- Descriptions can be found in the ethereal(1) man page.
-
- 3Com XNS Encapsulation
- 3GPP2 A11
- 3com Network Jack
- 802.1Q Virtual LAN
- 802.1X Authentication
- AAL type 2 signalling protocol (Q.2630)
- ACN
- AFS (4.0) Replication Server call declarations
- AIM Administrative
- AIM Advertisements
- AIM Buddylist Service
- AIM Chat Navigation
- AIM Chat Service
- AIM Directory Search
- AIM E-mail
- AIM Generic Service
- AIM ICQ
- AIM Invitation Service
- AIM Location
- AIM Messaging
- AIM OFT
- AIM Popup
- AIM Privacy Management Service
- AIM Server Side Info
- AIM Server Side Themes
- AIM Signon
- AIM Statistics
- AIM Translate
- AIM User Lookup
- ANSI A-I/F BSMAP
- ANSI A-I/F DTAP
- ANSI IS-637-A (SMS) Teleservice Layer
- ANSI IS-637-A (SMS) Transport Layer
- ANSI IS-683-A (OTA (Mobile))
- ANSI IS-801 (Location Services (PLD))
- ANSI Mobile Application Part
- AOL Instant Messenger
- ARCNET
- ASN.1 decoding
- ATAoverEthernet
- ATM
- ATM AAL1
- ATM AAL3/4
- ATM LAN Emulation
- ATM OAM AAL
- AVS WLAN Capture header
- AX/4000 Test Block
- Active Directory Setup
- Ad hoc On-demand Distance Vector Routing Protocol
- Adaptive Multi-Rate
- Address Resolution Protocol
- AgentX
- Aggregate Server Access Protocol
- Alert Standard Forum
- Alteon - Transparent Proxy Cache Protocol
- Andrew File System (AFS)
- Apache JServ Protocol v1.3
- Apple Filing Protocol
- Apple IP-over-IEEE 1394
- AppleTalk Session Protocol
- AppleTalk Transaction Protocol packet
- Appletalk Address Resolution Protocol
- Application Configuration Access Protocol
- Art-Net
- Aruba - Aruba Discovery Protocol
- Async data over ISDN (V.120)
- Asynchronous Layered Coding
- AudioCodes Trunk Trace
- Authentication Header
- BACnet Virtual Link Control
- BEA Tuxedo
- BSSAP/BSAP
- Banyan Vines ARP
- Banyan Vines Echo
- Banyan Vines Fragmentation Protocol
- Banyan Vines ICP
- Banyan Vines IP
- Banyan Vines IPC
- Banyan Vines LLC
- Banyan Vines RTP
- Banyan Vines SPP
- Base Station Subsystem GPRS Protocol
- Basic Encoding Rules (ASN.1 X.690)
- Bearer Independent Call Control
- Bi-directional Fault Detection Control Message
- BitTorrent
- Blocks Extensible Exchange Protocol
- Blubster/Piolet MANOLITO Protocol
- Boardwalk
- Boot Parameters
- Bootstrap Protocol
- Border Gateway Protocol
- Building Automation and Control Network APDU
- Building Automation and Control Network NPDU
- CBAPhysicalDevice
- CCSDS
- CDS Clerk Server Calls
- CSM_ENCAPS
- Camel
- Cast Client Control Protocol
- Certificate Management Protocol
- Certificate Request Message Format
- Check Point High Availability Protocol
- Checkpoint FW-1
- Cisco Auto-RP
- Cisco Discovery Protocol
- Cisco Group Management Protocol
- Cisco HDLC
- Cisco Hot Standby Router Protocol
- Cisco ISL
- Cisco Interior Gateway Routing Protocol
- Cisco NetFlow
- Cisco SLARP
- Cisco Session Management
- Cisco Wireless Layer 2
- Clearcase NFS
- CoSine IPNOS L2 debug output
- Common Image Generator Interface
- Common Industrial Protocol
- Common Open Policy Service
- Common Unix Printing System (CUPS) Browsing Protocol
- Compressed Data Type
- Compuserve GIF
- Computer Interface to Message Distribution
- Configuration Test Protocol (loopback)
- Connectionless Lightweight Directory Access Protocol
- Coseventcomm Dissector Using GIOP API
- Cosnaming Dissector Using GIOP API
- Cross Point Frame Injector
- Cryptographic Message Syntax
- DCE Distributed Time Service Local Server
- DCE Distributed Time Service Provider
- DCE Name Service
- DCE RPC
- DCE Security ID Mapper
- DCE/DFS BUDB
- DCE/RPC BOS Server
- DCE/RPC BUTC
- DCE/RPC CDS Solicitation
- DCE/RPC Conversation Manager
- DCE/RPC Directory Acl Interface
- DCE/RPC Endpoint Mapper
- DCE/RPC Endpoint Mapper v4
- DCE/RPC FLDB
- DCE/RPC FLDB UBIK TRANSFER
- DCE/RPC FLDB UBIKVOTE
- DCE/RPC ICL RPC
- DCE/RPC Kerberos V
- DCE/RPC NCS 1.5.1 Local Location Broker
- DCE/RPC Operations between registry server replicas
- DCE/RPC Prop Attr
- DCE/RPC RS_ACCT
- DCE/RPC RS_BIND
- DCE/RPC RS_MISC
- DCE/RPC RS_PROP_ACCT
- DCE/RPC RS_UNIX
- DCE/RPC Registry Password Management
- DCE/RPC Registry Server Attributes Schema
- DCE/RPC Registry server propagation interface - ACLs.
- DCE/RPC Registry server propagation interface - PGO items
- DCE/RPC Registry server propagation interface - properties and poli
-cies
- DCE/RPC Remote Management
- DCE/RPC Repserver Calls
- DCE/RPC TokenServer Calls
- DCE/RPC UpServer
- DCOM
- DCOM IDispatch
- DCOM IRemoteActivation
- DCOM OXID Resolver
- DEC DNA Routing Protocol
- DEC Spanning Tree Protocol
- DFS Calls
- DG Gryphon Protocol
- DHCP Failover
- DHCPv6
- DICOM
- DLT_USER_A
- DLT_USER_B
- DLT_USER_C
- DLT_USER_D
- DNS Control Program Server
- DOCSIS 1.1
- DOCSIS Appendix C TLV's
- DOCSIS Baseline Privacy Key Management Attributes
- DOCSIS Baseline Privacy Key Management Request
- DOCSIS Baseline Privacy Key Management Response
- DOCSIS Dynamic Service Addition Acknowledge
- DOCSIS Dynamic Service Addition Request
- DOCSIS Dynamic Service Addition Response
- DOCSIS Dynamic Service Change Acknowledgement
- DOCSIS Dynamic Service Change Request
- DOCSIS Dynamic Service Change Response
- DOCSIS Dynamic Service Delete Request
- DOCSIS Dynamic Service Delete Response
- DOCSIS Initial Ranging Message
- DOCSIS Mac Management
- DOCSIS Range Request Message
- DOCSIS Ranging Response
- DOCSIS Registration Acknowledge
- DOCSIS Registration Requests
- DOCSIS Registration Responses
- DOCSIS Upstream Bandwidth Allocation
- DOCSIS Upstream Channel Change Request
- DOCSIS Upstream Channel Change Response
- DOCSIS Upstream Channel Descriptor
- DOCSIS Upstream Channel Descriptor Type 29
- DOCSIS Vendor Specific Endodings
- DPNSS/DASS2-User Adaptation Layer
- DRSUAPI
- Data
- Data Link SWitching
- Data Stream Interface
- Datagram Congestion Control Protocol
- Datagram Delivery Protocol
- Decompressed SigComp message as raw text
- Diameter Protocol
- Digital Audio Access Protocol
- Distance Vector Multicast Routing Protocol
- Distcc Distributed Compiler
- Distributed Checksum Clearinghouse Protocol
- Distributed Interactive Simulation
- Distributed Network Protocol 3.0
- Domain Name Service
- Dublin Core Metadata (DC)
- Dynamic DNS Tools Protocol
- Dynamic Trunking Protocol
- ENTTEC
- Echo
- Encapsulating Security Payload
- Endpoint Name Resolution Protocol
- Enhanced Interior Gateway Routing Protocol
- EtherNet/IP (Industrial Protocol)
- Etheric
- Ethernet
- Ethernet over IP
- Extended Security Services
- Extensible Authentication Protocol
- Extreme Discovery Protocol
- FC Extended Link Svc
- FC Fabric Configuration Server
- FCIP
- FTP Data
- FTServer Operations
- Fiber Distributed Data Interface
- Fibre Channel
- Fibre Channel Common Transport
- Fibre Channel Fabric Zone Server
- Fibre Channel Name Server
- Fibre Channel Protocol for SCSI
- Fibre Channel SW_ILS
- Fibre Channel Security Protocol
- Fibre Channel Single Byte Command
- File Transfer Protocol (FTP)
- Financial Information eXchange Protocol
- Frame
- Frame Relay
- G.723
- GARP Multicast Registration Protocol
- GARP VLAN Registration Protocol
- GPRS Network service
- GPRS Tunneling Protocol
- GSM A-I/F BSSMAP
- GSM A-I/F DTAP
- GSM A-I/F RP
- GSM Mobile Application
- GSM SMS TPDU (GSM 03.40)
- GSM Short Message Service User Data
- GSM_SS
- GSS-API Generic Security Service Application Program Interface
- General Inter-ORB Protocol
- Generic Routing Encapsulation
- Gnutella Protocol
- H.248 MEGACO
- H.324/CCSRL
- H.324/SRP
- H221NonStandard
- H235-SECURITY-MESSAGES
- H323-MESSAGES
- HP Extended Local-Link Control
- HP Remote Maintenance Protocol
- HP Switch Protocol
- HP-UX Network Tracing and Logging
- Hummingbird NFS Daemon
- HyperSCSI
- Hypertext Transfer Protocol
- ICBAAccoCallback
- ICBAAccoCallback2
- ICBAAccoMgt
- ICBAAccoMgt2
- ICBAAccoServer
- ICBAAccoServer2
- ICBAAccoServerSRT
- ICBAAccoSync
- ICBABrowse
- ICBABrowse2
- ICBAGroupError
- ICBAGroupErrorEvent
- ICBALogicalDevice
- ICBALogicalDevice2
- ICBAPersist
- ICBAPersist2
- ICBAPhysicalDevice
- ICBAPhysicalDevice2
- ICBAPhysicalDevicePC
- ICBAPhysicalDevicePCEvent
- ICBARTAuto
- ICBARTAuto2
- ICBAState
- ICBAStateEvent
- ICBASystemProperties
- ICBATime
- ICQ Protocol
- IEEE 802.11 Radiotap Capture header
- IEEE 802.11 wireless LAN
- IEEE 802.11 wireless LAN management frame
- IEEE802a OUI Extended Ethertype
- ILMI
- IP Device Control (SS7 over IP)
- IP Over FC
- IP Payload Compression
- IP Virtual Services Sync Daemon
- IPX Message
- IPX Routing Information Protocol
- IPX WAN
- IRemUnknown
- IRemUnknown2
- ISDN
- ISDN Q.921-User Adaptation Layer
- ISDN User Part
- ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
- ISO 8073 COTP Connection-Oriented Transport Protocol
- ISO 8327-1 OSI Session Protocol
- ISO 8473 CLNP ConnectionLess Network Protocol
- ISO 8571 FTAM
- ISO 8602 CLTP ConnectionLess Transport Protocol
- ISO 8650-1 OSI Association Control Service
- ISO 8823 OSI Presentation Protocol
- ISO 9542 ESIS Routeing Information Exchange Protocol
- ISUP Thin Protocol
- ISystemActivator ISystemActivator Resolver
- ITU M.3100 Generic Network Information Model
- ITU-T E.164 number
- ITU-T Recommendation H.223
- ITU-T Recommendation H.261
- ITU-T Recommendation H.263
- ITU-T Recommendation H.263 RTP Payload header (RFC2190)
- InMon sFlow
- Information Access Protocol
- Init shutdown service
- Intel ANS probe
- Intelligent Network Application Protocol
- Intelligent Platform Management Interface
- Inter-Access-Point Protocol
- Inter-Asterisk eXchange v2
- InterSwitch Message Protocol
- Interbase
- Internet Cache Protocol
- Internet Communications Engine Protocol
- Internet Content Adaptation Protocol
- Internet Control Message Protocol
- Internet Control Message Protocol v6
- Internet Group Management Protocol
- Internet Group membership Authentication Protocol
- Internet Message Access Protocol
- Internet Printing Protocol
- Internet Protocol
- Internet Protocol Version 6
- Internet Relay Chat
- Internet Security Association and Key Management Protocol
- Internetwork Datagram Protocol
- Internetwork Packet eXchange
- IrCOMM Protocol
- IrDA Link Access Protocol
- IrDA Link Management Protocol
- IuUP
- JPEG File Interchange Format
- JXTA Connection Welcome Message
- JXTA Message
- JXTA Message Framing
- JXTA P2P
- JXTA UDP
- Jabber XML Messaging
- Java RMI
- Java Serialization
- Juniper
- K12xx
- Kerberized Internet Negotiation of Key
- Kerberos
- Kerberos Administration
- Kerberos v4
- Kernel Lock Manager
- LWAP Control Message
- LWAPP Encapsulated Packet
- LWAPP Layer 3 Packet
- Label Distribution Protocol
- Laplink
- Layer 2 Tunneling Protocol
- Light Weight DNS RESolver (BIND9)
- Lightweight Directory Access Protocol
- Lightweight User Datagram Protocol
- Line Printer Daemon Protocol
- Line-based text data
- Link Access Procedure Balanced (LAPB)
- Link Access Procedure Balanced Ethernet (LAPBETHER)
- Link Access Procedure, Channel D (LAPD)
- Link Layer Discovery Protocol
- Link Management Protocol (LMP)
- Linux cooked-mode capture
- Local Management Interface
- LocalTalk Link Access Protocol
- Log Message
- Logical Link Control GPRS
- Logical-Link Control
- Logical-Link Control Basic Format XID
- Logotype Certificate Extensions
- Lucent/Ascend debug output
- MAC Control
- MAP_DialoguePDU
- MDS Header
- MEGACO
- MIME Multipart Media Encapsulation
- MMS
- MMS Message Encapsulation
- MS Kpasswd
- MS Network Load Balancing
- MS Proxy Protocol
- MSN Messenger Service
- MSNIP: Multicast Source Notification of Interest Protocol
- MTP 2 Transparent Proxy
- MTP 2 User Adaptation Layer
- MTP 3 User Adaptation Layer
- MTP2 Peer Adaptation Layer
- MULTIMEDIA-SYSTEM-CONTROL
- Media Gateway Control Protocol
- Media Type
- Media Type: message/http
- Message Session Relay Protocol
- Message Transfer Part Level 2
- Message Transfer Part Level 3
- Message Transfer Part Level 3 Management
- Meta Analysis Tracing Engine
- Microsoft AT-Scheduler Service
- Microsoft Distributed File System
- Microsoft Distributed Link Tracking Server Service
- Microsoft Encrypted File System Service
- Microsoft Eventlog Service
- Microsoft Exchange MAPI
- Microsoft File Replication Service
- Microsoft File Replication Service API
- Microsoft Local Security Architecture
- Microsoft Media Server
- Microsoft Messenger Service
- Microsoft Network Logon
- Microsoft Plug and Play service
- Microsoft Routing and Remote Access Service
- Microsoft Security Account Manager
- Microsoft Server Service
- Microsoft Service Control
- Microsoft Spool Subsystem
- Microsoft Telephony API Service
- Microsoft Windows Browser Protocol
- Microsoft Windows Lanman Remote API Protocol
- Microsoft Windows Logon Protocol (Old)
- Microsoft Workstation Service
- Mobile IP
- Mobile IPv6 / Network Mobility
- Modbus/TCP
- Monotone Netsync
- Mount Service
- MultiProtocol Label Switching Header
- Multicast Router DISCovery protocol
- Multicast Source Discovery Protocol
- Multiprotocol Label Switching Echo
- MySQL Protocol
- NBMA Next Hop Resolution Protocol
- NFSACL
- NFSAUTH
- NIS+
- NIS+ Callback
- NSPI
- NTLM Secure Service Provider
- Name Binding Protocol
- Name Management Protocol over IPX
- Negative-acknowledgment Oriented Reliable Multicast
- NetBIOS
- NetBIOS Datagram Service
- NetBIOS Name Service
- NetBIOS Session Service
- NetBIOS over IPX
- NetScape Certificate Extensions
- NetWare Core Protocol
- NetWare Link Services Protocol
- NetWare Serialization Protocol
- Network Data Management Protocol
- Network File System
- Network Lock Manager Protocol
- Network News Transfer Protocol
- Network Service Over IP
- Network Status Monitor CallBack Protocol
- Network Status Monitor Protocol
- Network Time Protocol
- Nortel SONMP
- Novell Cluster Services
- Novell Distributed Print System
- Novell Modular Authentication Service
- Novell SecretStore Services
- Null/Loopback
- Online Certificate Status Protocol
- Open Policy Service Interface
- Open Shortest Path First
- OpenBSD Encapsulating device
- OpenBSD Packet Filter log file
- OpenBSD Packet Filter log file, pre 3.4
- Optimized Link State Routing Protocol
- PC NFS
- PKCS#1
- PKINIT
- PKIX CERT File Format
- PKIX Qualified
- PKIX Time Stamp Protocol
- PKIX1Explitit
- PKIX1Implitit
- PKIXProxy (RFC3820)
- PPP Bandwidth Allocation Control Protocol
- PPP Bandwidth Allocation Protocol
- PPP CDP Control Protocol
- PPP Callback Control Protocol
- PPP Challenge Handshake Authentication Protocol
- PPP Compressed Datagram
- PPP Compression Control Protocol
- PPP IP Control Protocol
- PPP IPv6 Control Protocol
- PPP In HDLC-Like Framing
- PPP Link Control Protocol
- PPP MPLS Control Protocol
- PPP Multilink Protocol
- PPP Multiplexing
- PPP OSI Control Protocol
- PPP Password Authentication Protocol
- PPP VJ Compression
- PPP-over-Ethernet Discovery
- PPP-over-Ethernet Session
- PPPMux Control Protocol
- PROFINET DCP
- PROFINET IO
- PROFINET Real-Time Protocol
- P_Mul (ACP142)
- Packed Encoding Rules (ASN.1 X.691)
- Packet Cable Lawful Intercept
- PacketCable
- Parallel Virtual File System
- Parlay Dissector Using GIOP API
- Plan 9 9P
- Point-to-Point Protocol
- Point-to-Point Tunnelling Protocol
- Port Aggregation Protocol
- Portmap
- Post Office Protocol
- PostgreSQL
- Pragmatic General Multicast
- Precision Time Protocol (IEEE1588)
- Printer Access Protocol
- Prism
- Privilege Server operations
- Protocol Independent Multicast
- Q.2931
- Q.931
- Q.933
- Quake II Network Protocol
- Quake III Arena Network Protocol
- Quake Network Protocol
- QuakeWorld Network Protocol
- Qualified Logical Link Control
- RDM
- RFC 2250 MPEG1
- RFC 2833 RTP Event
- RIPng
- RPC Browser
- RS Interface properties
- RSTAT
- RSYNC File Synchroniser
- RTcfg
- RX Protocol
- Radio Access Network Application Part
- Radius Protocol
- Raw packet data
- Real Data Transport
- Real Time Streaming Protocol
- Real-Time Media Access Control
- Real-Time Publish-Subscribe Wire Protocol
- Real-Time Transport Protocol
- Real-time Transport Control Protocol
- Redback
- Redundant Link Management Protocol
- Registry Server Attributes Manipulation Interface
- Registry server administration operations.
- Reliable UDP
- Remote Management Control Protocol
- Remote Override interface
- Remote Procedure Call
- Remote Program Load
- Remote Quota
- Remote Registry Service
- Remote Shell
- Remote Wall protocol
- Remote sec_login preauth interface.
- Resource ReserVation Protocol (RSVP)
- Retix Spanning Tree Protocol
- Rlogin Protocol
- Routing Information Protocol
- Routing Table Maintenance Protocol
- SADMIND
- SCSI
- SEBEK - Kernel Data Capture
- SGI Mount Service
- SMB (Server Message Block Protocol)
- SMB MailSlot Protocol
- SMB Pipe Protocol
- SMB2 (Server Message Block Protocol version 2)
- SNA-over-Ethernet
- SNMP Multiplex Protocol
- SPNEGO-KRB5
- SPRAY
- SS7 SCCP-User Adaptation Layer
- SSCF-NNI
- SSCOP
- SSH Protocol
- STANAG 4406 Military Message
- STANAG 5066 (SIS layer)
- Secure Socket Layer
- Sequenced Packet Protocol
- Sequenced Packet eXchange
- Serial Infrared
- Service Advertisement Protocol
- Service Location Protocol
- Session Announcement Protocol
- Session Description Protocol
- Session Initiation Protocol
- Session Initiation Protocol (SIP as raw text)
- Short Message Peer to Peer
- Short Message Relaying Service
- Signaling Compression
- Signalling Connection Control Part
- Signalling Connection Control Part Management
- Simple Mail Transfer Protocol
- Simple Network Management Protocol
- Simple Protected Negotiation
- Simple Traversal of UDP Through NAT
- Sinec H1 Protocol
- Sipfrag
- Skinny Client Control Protocol
- SliMP3 Communication Protocol
- Slow Protocols
- Socks Protocol
- SoulSeek Protocol
- Spanning Tree Protocol
- Stream Control Transmission Protocol
- Subnetwork Dependent Convergence Protocol
- Symantec Enterprise Firewall
- Synchronized Multimedia Integration Language
- Synchronous Data Link Control (SDLC)
- Synergy
- Syslog message
- Systems Network Architecture
- Systems Network Architecture XID
- T.38
- TACACS
- TACACS+
- TDMA RTmac Discipline
- TEI Management Procedure, Channel D (LAPD)
- TPKT - ISO on TCP - RFC1006
- Tabular Data Stream
- Tango Dissector Using GIOP API
- Tazmen Sniffer Protocol
- Telnet
- Teredo IPv6 over UDP tunneling
- The Armagetron Advanced OpenGL Tron clone
- Time Protocol
- Time Synchronization Protocol
- Tiny Transport Protocol
- Token-Ring
- Token-Ring Media Access Control
- Transaction Capabilities Application Part
- Transmission Control Protocol
- Transparent Inter Process Communication(TIPC)
- Transparent Network Substrate Protocol
- Transport Adapter Layer Interface v1.0, RFC 3094
- Trivial File Transfer Protocol
- UDP Encapsulation of IPsec Packets
- UTRAN Iub interface NBAP signalling
- UTRAN Iur interface Radio Network Subsystem Application Part
- Universal Computer Protocol
- Unlicensed Mobile Access
- User Datagram Protocol
- V5.2-User Adaptation Layer
- Virtual Network Computing
- Virtual Router Redundancy Protocol
- Virtual Trunking Protocol
- WAP Binary XML
- WAP Session Initiation Request
- WINS (Windows Internet Name Service) Replication
- Web Cache Coordination Protocol
- WebSphere MQ
- WebSphere MQ Programmable Command Formats
- Wellfleet Breath of Life
- Wellfleet Compression
- Wellfleet HDLC
- Who
- Windows 2000 DNS
- Wireless Session Protocol
- Wireless Transaction Protocol
- Wireless Transport Layer Security
- Wlan Certificate Extension
- X Display Manager Control Protocol
- X.228 OSI Reliable Transfer Service
- X.25
- X.25 over TCP
- X.29
- X.411 Message Transfer Service
- X.420 File Transfer Body Part
- X.420 Information Object
- X.501 Directory Operational Binding Management Protocol
- X.509 Authentication Framework
- X.509 Certificate Extensions
- X.509 Information Framework
- X.509 Selected Attribute Types
- X.519 Directory Access Protocol
- X.519 Directory Information Shadowing Protocol
- X.519 Directory System Protocol
- X.880 OSI Remote Operations Service
- X11
- X711 CMIP
- Xyplex
- Yahoo Messenger Protocol
- Yahoo YMSG Messenger Protocol
- Yellow Pages Bind
- Yellow Pages Passwd
- Yellow Pages Service
- Yellow Pages Transfer
- Zebra Protocol
- Zone Information Protocol
- eDonkey Protocol
- eXtensible Markup Language
- giFT Internet File Transfer
- h450
- iFCP
- iSCSI
- iSNS
- iTunes podCast rss elements
- rss
-
- Q 1.6: Are there any plans to support {your favorite protocol}?
-
- A: Support for particular protocols is added to Ethereal as a result of
- people contributing that support; no formal plans for adding support for
- particular protocols in particular future releases exist.
-
- Q 1.7: Can Ethereal read capture files from {your favorite network
+ Q 1.5: Can I use Wireshark commercially?
+
+ A: Yes, if, for example, you mean "I work for a commercial
+ organization; can I use Wireshark to capture and analyze network
+ traffic in our company's networks or in our customer's networks?"
+
+ If you mean "Can I use Wireshark as part of my commercial product?",
+ see the next entry in the FAQ.
+
+ Q 1.6: Can I use Wireshark as part of my commercial product?
+
+ A: As noted, Wireshark is licensed under the GNU General Public
+ License. The GPL imposes conditions on your use of GPL'ed code in your
+ own products; you cannot, for example, make a "derived work" from
+ Wireshark, by making modifications to it, and then sell the resulting
+ derived work and not allow recipients to give away the resulting work.
+ You must also make the changes you've made to the Wireshark source
+ available to all recipients of your modified version; those changes
+ must also be licensed under the terms of the GPL. See the GPL FAQ for
+ more details; in particular, note the answer to the question about
+ modifying a GPLed program and selling it commercially, and the
+ question about linking GPLed code with other code to make a
+ proprietary program.
+
+ You can combine a GPLed program such as Wireshark and a commercial
+ program as long as they communicate "at arm's length", as per this
+ item in the GPL FAQ.
+
+ Q 1.7: What protocols are currently supported?
+
+ A: There are currently hundreds of supported protocols and media.
+ Details can be found in the wireshark(1) man page.
+
+ Q 1.8: Are there any plans to support {your favorite protocol}?
+
+ A: Support for particular protocols is added to Wireshark as a result
+ of people contributing that support; no formal plans for adding
+ support for particular protocols in particular future releases exist.
+
+ Q 1.9: Can Wireshark read capture files from {your favorite network
analyzer}?
- A: Support for particular protocols is added to Ethereal as a result of
- people contributing that support; no formal plans for adding support for
- particular protocols in particular future releases exist.
+ 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
- Ethereal (e.g., in libpcap format), Ethereal 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 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 Ethereal read
- captures from that network analyzer, we would either have to have a
- specification for the file format, or the extensions, sufficient to give us
- enough information to read the parts of the file relevant to Ethereal, or
- would need at least one capture file in that format AND a detailed textual
- analysis of the packets in that capture file (showing packet time stamps,
- packet lengths, and the top-level packet header) in order to
- reverse-engineer the file format.
-
- Note that there is no guarantee that we will be able to reverse-engineer a
- capture file format.
-
- Q 1.8: What devices can Ethereal use to capture packets?
-
- A: Ethereal can read live data from Ethernet, Token-Ring, FDDI, serial (PPP
- and SLIP) (if the OS on which it's running allows Ethereal to do so), 802.11
- wireless LAN (if the OS on which it's running allows Ethereal to do so), ATM
- connections (if the OS on which it's running allows Ethereal 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 "Ethereal can't capture on them",
- it means "we don't know whether it can capture on them"; we expect that it
- will be able to capture on many of them, but we haven't tried it ourselves -
- if you try one of those types and it works, please send an update to
- wireshark-web[AT]wireshark.org).
+ proprietary extensions to another format, in order to make Wireshark
+ read captures from that network analyzer, we would either have to have
+ a specification for the file format, or the extensions, sufficient to
+ give us enough information to read the parts of the file relevant to
+ Wireshark, or would need at least one capture file in that format AND
+ a detailed textual analysis of the packets in that capture file
+ (showing packet time stamps, packet lengths, and the top-level packet
+ header) in order to reverse-engineer the file format.
+
+ Note that there is no guarantee that we will be able to
+ reverse-engineer a capture file format.
+
+ Q 1.10: What devices can Wireshark use to capture packets?
+
+ A: Wireshark can read live data from Ethernet, Token-Ring, FDDI,
+ serial (PPP and SLIP) (if the OS on which it's running allows
+ Wireshark to do so), 802.11 wireless LAN (if the OS on which it's
+ running allows Wireshark to do so), ATM connections (if the OS on
+ which it's running allows Wireshark to do so), and the "any" device
+ supported on Linux by recent versions of libpcap. See the list of
+ supported capture media on various OSes for details (several items in
+ there say "Unknown", which doesn't mean "Wireshark can't capture on
+ them", it means "we don't know whether it can capture on them"; we
+ expect that it will be able to capture on many of them, but we haven't
+ tried it ourselves - if you try one of those types and it works,
+ please send an update to ).
It can also read a variety of capture file formats, including:
* AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet
* Lucent/Ascend router debug output
* Microsoft Network Monitor captures
* Network Associates Windows-based Sniffer captures
- * Network General/Network Associates DOS-based Sniffer (compressed or
- uncompressed) captures
+ * Network General/Network Associates DOS-based Sniffer (compressed
+ or uncompressed) captures
* Network Instruments Observer version 9 captures
* Novell LANalyzer captures
* RADCOM's WAN/LAN analyzer captures
* Toshiba's ISDN routers dump output
* VMS TCPIPtrace/TCPtrace/UCX$TRACE output
* Visual Networks' Visual UpTime traffic capture
- * libpcap, tcpdump and various other tools using tcpdump's capture format
+ * libpcap, tcpdump and various other tools using tcpdump's capture
+ format
* snoop and atmsnoop output
- so that it can read traces from various network types, as captured by other
- applications or equipment, even if it cannot itself capture on those network
- types.
-
- Q 1.9: How do you pronounce Ethereal? Where did the name come from?
-
- A: The English pronunciation can be found in Merriam-Webster's online
- dictionary at
- http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=ethereal.
-
- According to the book "Computer Networks" by Andrew Tannenbaum, Ethernet was
- named after the "luminiferous ether" which was once thought to carry
- electromagnetic radiation. Taking that into consideration, Ethereal seemed
- like an appropriate name for something that started out as an Ethernet
- analyzer.
+ so that it can read traces from various network types, as captured by
+ other applications or equipment, even if it cannot itself capture on
+ those network types.
- Q 1.10: Does Ethereal work on Windows Me?
+ Q 1.11: Does Wireshark work on Windows Me?
- A: Yes, but if you want to capture packets, you will need to install the
- latest version of WinPcap, as 2.02 and earlier versions of WinPcap didn't
- support Windows Me. You should also install the latest version of Ethereal
- as well.
+ 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.11: Does Ethereal work on Windows XP?
+ Q 1.12: Does Wireshark work on Windows XP?
- A: Yes, but if you want to capture packets, you will need to install the
- latest version of WinPcap, as 2.2 and earlier versions of WinPcap didn't
- support Windows XP.
+ A: Yes, but if you want to capture packets, you will need to install
+ the latest version of WinPcap, as 2.2 and earlier versions of WinPcap
+ didn't support Windows XP.
-2. Downloading Ethereal
+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.
+ A: The program you used to download it may have downloaded it
+ incorrectly. Web browsers sometimes may do this.
Try downloading it with, for example:
- * Wget, for which Windows binaries are available on the SunSITE FTP server
- at sunsite.tk or Heiko Herold's windows wget spot - wGetGUI offers a GUI
- interface that uses wget;
+ * Wget, for which Windows binaries are available on the SunSITE FTP
+ server at sunsite.tk or Heiko Herold's windows wget spot - wGetGUI
+ offers a GUI interface that uses wget;
* WS_FTP from Ipswitch,
* the ftp command that comes with Windows.
- If you use the ftp command, make sure you do the transfer in binary mode
- rather than ASCII mode, by using the binary command before transferring the
- file.
+ If you use the ftp command, make sure you do the transfer in binary
+ mode rather than ASCII mode, by using the binary command before
+ transferring the file.
- Q 2.2: Why can't I get to the WinPcap Web site in order to download WinPcap?
+3. Installing Wireshark
- A: As is the case with all Web sites, that site won't necessarily always be
- accessible; the server may be down due to a problem or down for maintenance,
- or there may be a networking problem between you and the server. You should
- try again later, or try the local mirror or the Wiretapped.net mirror.
+ Q 3.1: I installed the Wireshark RPM (or other package); why did it
+ install TShark but not Wireshark?
- Note that current Ethereal releases include an installer for WinPcap.
+ A: Many distributions have separate Wireshark packages, one for
+ non-GUI components such as TShark, editcap, dumpcap, etc. and one for
+ the GUI. If this is the case on your system, there's probably a
+ separate package named wireshark-gnome or wireshark-gtk+. Find it and
+ install it.
-3. Installing Ethereal
-
- Q 3.1: I installed an Ethereal RPM; why did it install TShark but not
- Ethereal?
-
- A: Older versions of the Red Hat RPMs for Wireshark put only the non-GUI
- components into the ethereal RPM, the fact that Wireshark is a GUI program
- nonwithstanding; newer versions make it a bit clearer by giving that RPM a
- name starting with wireshark-base.
-
- In those older versions, there's a separate wireshark-gnome RPM that includes
- GUI components such as Ethereal itself, the fact that Ethereal doesn't use
- GNOME nonwithstanding; newer versions make it a bit clearer by giving that
- RPM a name starting with wireshark-gtk+.
-
- Find the wireshark-gnome or wireshark-gtk+ RPM, and install that also.
-
-4. Building Ethereal
+4. Building Wireshark
Q 4.1: I have libpcap installed; why did the configure script not find
pcap.h or bpf.h?
- A: Are you sure pcap.h and bpf.h are installed? The official distribution of
- libpcap only installs the libpcap.a library file when "make install" is run.
- To install pcap.h and bpf.h, you must run "make install-incl". If you're
- running Debian or Redhat, make sure you have the "libpcap-dev" or
- "libpcap-devel" packages installed.
+ A: Are you sure pcap.h and bpf.h are installed? The official
+ distribution of libpcap only installs the libpcap.a library file when
+ "make install" is run. To install pcap.h and bpf.h, you must run "make
+ install-incl". If you're running Debian or Redhat, make sure you have
+ the "libpcap-dev" or "libpcap-devel" packages installed.
- It's also possible that pcap.h and bpf.h have been installed in a strange
- location. If this is the case, you may have to tweak aclocal.m4.
+ It's also possible that pcap.h and bpf.h have been installed in a
+ strange location. If this is the case, you may have to tweak
+ aclocal.m4.
Q 4.2: Why do I get the error
- dftest_DEPENDENCIES was already defined in condition TRUE, which implies
- condition HAVE_PLUGINS_TRUE
-
- when I try to build Ethereal from SVN or a SVN snapshot?
-
- A: You probably have automake 1.5 installed on your machine (the command
- automake --version will report the version of automake on your machine).
- There is a bug in that version of automake that causes this problem; upgrade
- to a later version of automake (1.6 or later).
-
- Q 4.3: Why does the linker fail with a number of "Output line too long."
- messages followed by linker errors when I try to buil Ethereal?
-
- A: The version of the sed command on your system is incapable of handling
- very long lines. On Solaris, for example, /usr/bin/sed has a line length
- limit too low to allow libtool to work; /usr/xpg4/bin/sed can handle it, as
- can GNU sed if you have it installed.
-
- On Solaris, changing your command search path to search /usr/xpg4/bin before
- /usr/bin should make the problem go away; on any platform on which you have
- this problem, installing GNU sed and changing your command path to search
- the directory in which it is installed before searching the directory with
- the version of sed that came with the OS should make the problem go away.
-
- Q 4.4: When I try to build Ethereal on Solaris, why does the link fail
- complaining that plugin_list is undefined?
-
- A: This appears to be due to a problem with some versions of the GTK+ and
- GLib packages from www.sunfreeware.org; un-install those packages, and try
- getting the 1.2.10 versions from that site, or the versions from The Written
- Word, or the versions from Sun's GNOME distribution, or the versions from
- the supplemental software CD that comes with the Solaris media kit, or build
- them from source from the GTK Web site. Then re-run the configuration
- script, and try rebuilding Ethereal. (If you get the 1.2.10 versions from
- www.sunfreeware.org, and the problem persists, un-install them and try
- installing one of the other versions mentioned.)
-
- Q 4.5: When I try to build Ethereal on Windows, why does the build fail
- because of conflicts between winsock.h and winsock2.h?
-
- A: As of Ethereal 0.9.5, you must install WinPcap 2.3 or later, and the
- corresponding version of the developer's pack, in order to be able to
- compile Ethereal; it will not compile with older versions of the developer's
- pack. The symptoms of this failure are conflicts between definitions in
- winsock.h and in winsock2.h; Ethereal uses winsock2.h, but pre-2.3 versions
- of the WinPcap developer's packet use winsock.h. (2.3 uses winsock2.h, so if
- Ethereal were to use winsock.h, it would not be able to build with current
- versions of the WinPcap developer's pack.)
-
- Note that the installed version of the developer's pack should be the same
- version as the version of WinPcap you have installed.
-
-5. Starting Ethereal
-
- Q 5.1: Why does Ethereal crash with a Bus Error when I try to run it on
- Solaris 8?
-
- A: Some versions of the GTK+ library from www.sunfreeware.org appear to be
- buggy, causing Ethereal to drop core with a Bus Error. Un-install those
- packages, and try getting the 1.2.10 version from that site, or the version
- from The Written Word, or the version from Sun's GNOME distribution, or the
- version from the supplemental software CD that comes with the Solaris media
- kit, or build it from source from the GTK Web site. Update the GLib library
- to the 1.2.10 version, from the same source, as well. (If you get the 1.2.10
- versions from www.sunfreeware.org, and the problem persists, un-install them
- and try installing one of the other versions mentioned.)
-
- Similar problems may exist with older versions of GTK+ for earlier versions
- of Solaris.
-
- Q 5.2: When I run TShark with the "-x" option, why does it crash with an
- error
-
- "** ERROR **: file print.c: line 691 (print_line): should not be reached.
-
- A: This is a bug in Wireshark 0.10.0a, which is fixed in 0.10.1 and later
- releases. To work around the bug, don't use "-x" unless you're also using
- "-V"; note that "-V" produces a full dissection of each packet, so you might
- not want to use it.
-
- Q 5.3: When I run Ethereal on Windows NT, why does it die with a Dr. Watson
- error, reporting an "Integer division by zero" exception, when I start it?
-
- A: In at least some case, this appears to be due to using the default VGA
- driver; if that's not the correct driver for your video card, try running
- the correct driver for your video card.
-
- Q 5.4: When I try to run Ethereal, why does it complain about
+ dftest_DEPENDENCIES was already defined in condition TRUE, which
+ implies condition HAVE_PLUGINS_TRUE
+
+ when I try to build Wireshark from SVN or a SVN snapshot?
+
+ A: You probably have automake 1.5 installed on your machine (the
+ command automake --version will report the version of automake on your
+ machine). There is a bug in that version of automake that causes this
+ problem; upgrade to a later version of automake (1.6 or later).
+
+ Q 4.3: Why does the linker fail with a number of "Output line too
+ long." messages followed by linker errors when I try to buil
+ Wireshark?
+
+ A: The version of the sed command on your system is incapable of
+ handling very long lines. On Solaris, for example, /usr/bin/sed has a
+ line length limit too low to allow libtool to work; /usr/xpg4/bin/sed
+ can handle it, as can GNU sed if you have it installed.
+
+ On Solaris, changing your command search path to search /usr/xpg4/bin
+ before /usr/bin should make the problem go away; on any platform on
+ which you have this problem, installing GNU sed and changing your
+ command path to search the directory in which it is installed before
+ searching the directory with the version of sed that came with the OS
+ should make the problem go away.
+
+ Q 4.4: When I try to build Wireshark on Solaris, why does the link
+ fail complaining that plugin_list is undefined?
+
+ A: This appears to be due to a problem with some versions of the GTK+
+ and GLib packages from www.sunfreeware.org; un-install those packages,
+ and try getting the 1.2.10 versions from that site, or the versions
+ from The Written Word, or the versions from Sun's GNOME distribution,
+ or the versions from the supplemental software CD that comes with the
+ Solaris media kit, or build them from source from the GTK Web site.
+ Then re-run the configuration script, and try rebuilding Wireshark.
+ (If you get the 1.2.10 versions from www.sunfreeware.org, and the
+ problem persists, un-install them and try installing one of the other
+ versions mentioned.)
+
+ Q 4.5: When I try to build Wireshark on Windows, why does the build
+ fail because of conflicts between winsock.h and winsock2.h?
+
+ A: As of Wireshark 0.9.5, you must install WinPcap 2.3 or later, and
+ the corresponding version of the developer's pack, in order to be able
+ to compile Wireshark; it will not compile with older versions of the
+ developer's pack. The symptoms of this failure are conflicts between
+ definitions in winsock.h and in winsock2.h; Wireshark uses winsock2.h,
+ but pre-2.3 versions of the WinPcap developer's packet use winsock.h.
+ (2.3 uses winsock2.h, so if Wireshark were to use winsock.h, it would
+ not be able to build with current versions of the WinPcap developer's
+ pack.)
+
+ Note that the installed version of the developer's pack should be the
+ same version as the version of WinPcap you have installed.
+
+5. Starting Wireshark
+
+ Q 5.1: Why does Wireshark crash with a Bus Error when I try to run it
+ on Solaris 8?
+
+ A: Some versions of the GTK+ library from www.sunfreeware.org appear
+ to be buggy, causing Wireshark to drop core with a Bus Error.
+ Un-install those packages, and try getting the 1.2.10 version from
+ that site, or the version from The Written Word, or the version from
+ Sun's GNOME distribution, or the version from the supplemental
+ software CD that comes with the Solaris media kit, or build it from
+ source from the GTK Web site. Update the GLib library to the 1.2.10
+ version, from the same source, as well. (If you get the 1.2.10
+ versions from www.sunfreeware.org, and the problem persists,
+ un-install them and try installing one of the other versions
+ mentioned.)
+
+ Similar problems may exist with older versions of GTK+ for earlier
+ versions of Solaris.
+
+ Q 5.2: When I run Wireshark on Windows NT, why does it die with a Dr.
+ Watson error, reporting an "Integer division by zero" exception, when
+ I start it?
+
+ A: In at least some case, this appears to be due to using the default
+ VGA driver; if that's not the correct driver for your video card, try
+ running the correct driver for your video card.
+
+ Q 5.3: When I try to run Wireshark, why does it complain about
sprint_realloc_objid being undefined?
- A: Ethereal can only be linked with version 4.2.2 or later of UCD SNMP. Your
- version of Ethereal was dynamically linked with such a version of UCD SNMP;
- however, you have an older version of UCD SNMP installed, which means that
- when Wireshark is run, it tries to link to the older version, and fails. You
- will have to replace that version of UCD SNMP with version 4.2.2 or a later
- version.
-
- Q 5.5: When I try to run Ethereal on Windows, why does it fail to run with a
- complaint that it can't find packet.dll?
-
- A: In older versions of Ethereal, 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 Ethereal 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, the local mirror of the WinPcap Web site, or the Wiretapped.net mirror
- of the WinPcap site.
-
- Q 5.6: Why do I get the error
-
- Gdk-ERROR **: Palettized display (256-colour) mode not supported on
- Windows.
- aborting....
-
- when I try to run Ethereal on Windows?
-
- A: Wireshark is built using the GTK+ toolkit, which supports most
- UNIX-flavored OSes, and also supports Windows.
-
- Windows versions of Ethereal before 0.9.14 were built with an older version
- of that toolkit, which didn't support 256-color mode on Windows - it
- required HiColor (16-bit colors) or more.
-
- Windows versions of Ethereal 0.9.14 and later are built with a version of
- that toolkit that supports 256-color mode; upgrade to the current version of
- Ethereal if you want to run on a display in 256-color mode.
-
- Q 5.7: I've installed Ethereal 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
+ A: Wireshark can only be linked with version 4.2.2 or later of UCD
+ SNMP. Your version of Wireshark was dynamically linked with such a
+ version of UCD SNMP; however, you have an older version of UCD SNMP
+ installed, which means that when Wireshark is run, it tries to link to
+ the older version, and fails. You will have to replace that version of
+ UCD SNMP with version 4.2.2 or a later version.
+
+ Q 5.4: When I try to run Wireshark on Windows, why does it fail to run
+ with a complaint that it can't find packet.dll?
+
+ A: In older versions of Wireshark, there were two binary distributions
+ available for Windows, one that supported capturing packets, and one
+ that didn't. The version that supported capturing packets required
+ that you install the WinPcap driver; if you didn't install it, it
+ would fail to run because it couldn't find packet.dll.
+
+ The current version of Wireshark has only one binary distribution for
+ Windows; that version will check whether WinPcap is installed and, if
+ it's not, will disable support for packet capture.
+
+ The WinPcap driver and libraries can be downloaded from the WinPcap
+ Web site or the Wiretapped.net mirror of the WinPcap site.
+
+ Q 5.5: I've installed Wireshark from Fink on Mac OS X; why is it very
+ slow to start up?
+
+ A: When an application is installed on OS X, prior to 10.4, it is
+ usually "prebound" to speed up launching the application. (That's what
+ the "Optimizing" phase of installation is.) Fink normally performs
+ prebinding automatically when you install a package. However, in some
+ rare cases, for whatever reason the prebinding caches get corrupt, and
+ then not only does prebinding fail, but startup actually becomes much
+ slower, because the system tries in vain to perform prebinding "on the
+ fly" as you launch the application. This fails, causing sometimes huge
+ delays. To fix the prebinding caches, run the command
sudo /sw/var/lib/fink/prebound/update-package-prebinding.pl -f
6. Crashes and other fatal errors
- Q 6.1: When I run Ethereal, why do I get an error
-
- Gtk-CRITICAL **: file gtkwindow.c: line 3107 (gtk_window_resize):
- assertion `height > 0' failed.
-
- A: This is a bug in Wireshark 0.10.5 and 0.10.5a, which is fixed in Wireshark
- 0.10.6 and later releases.
-
- Q 6.2: I have an XXX network card on my machine; if I try to capture on it,
- why does my machine crash or reset itself?
+ Q 6.1: I have an XXX network card on my machine; if I try to capture
+ on it, why does my machine crash or reset itself?
A: This is almost certainly a problem with one or more of:
* the operating system you're using;
* the device driver for the interface you're using;
- * the libpcap/WinPcap library and, if this is Windows, the WinPcap device
- driver;
+ * the libpcap/WinPcap library and, if this is Windows, the WinPcap
+ device driver;
so:
- * if you are using Windows, see the WinPcap support page (or the local
- mirror of that page) - check the "Submitting bugs" section;
- * if you are using some Linux distribution, some version of BSD, or some
- other UNIX-flavored OS, you should report the problem to the company or
- organization that produces the OS (in the case of a Linux distribution,
- report the problem to whoever produces the distribution).
-
- Q 6.3: Why does my machine crash or reset itself when I select "Start" from
- the "Capture" menu or select "Preferences" from the "Edit" menu?
-
- A: Both of those operations cause Ethereal to try to build a list of the
- interfaces that it can open; it does so by getting a list of interfaces and
- trying to open them. There is probably an OS, driver, or, for Windows,
- WinPcap bug that causes the system to crash when this happens; see the
- previous question.
+ * if you are using Windows, see the WinPcap support page - check the
+ "Submitting bugs" section;
+ * if you are using some Linux distribution, some version of BSD, or
+ some other UNIX-flavored OS, you should report the problem to the
+ company or organization that produces the OS (in the case of a
+ Linux distribution, report the problem to whoever produces the
+ distribution).
+
+ Q 6.2: Why does my machine crash or reset itself when I select "Start"
+ from the "Capture" menu or select "Preferences" from the "Edit" menu?
+
+ A: Both of those operations cause Wireshark to try to build a list of
+ the interfaces that it can open; it does so by getting a list of
+ interfaces and trying to open them. There is probably an OS, driver,
+ or, for Windows, WinPcap bug that causes the system to crash when this
+ happens; see the previous question.
7. Capturing packets
- Q 7.1: When I use Ethereal to capture packets, why do I see only packets to
- and from my machine, or not see all the traffic I'm expecting to see from or
- to the machine I'm trying to monitor?
-
- A: This might be because the interface on which you're capturing is plugged
- into an Ethernet or Token Ring switch; on a switched network, unicast
- traffic between two ports will not necessarily appear on other ports - only
- broadcast and multicast traffic will be sent to all ports.
-
- Note that even if your machine is plugged into a hub, the "hub" may be a
- switched hub, in which case you're still on a switched network.
-
- Note also that on the Linksys Web site, they say that their auto-sensing
- hubs "broadcast the 10Mb packets to the port that operate at 10Mb only and
- broadcast the 100Mb packets to the ports that operate at 100Mb only", which
- would indicate that if you sniff on a 10Mb port, you will not see traffic
- coming sent to a 100Mb port, and vice versa. This problem has also been
- reported for Netgear dual-speed hubs, and may exist for other "auto-sensing"
- or "dual-speed" hubs.
-
- Some switches have the ability to replicate all traffic on all ports to a
- single port so that you can plug your analyzer into that single port to
- sniff all traffic. You would have to check the documentation for the switch
- to see if this is possible and, if so, to see how to do this. See the switch
- reference page on the Wireshark Wiki for information on some switches. (Note
- that it's a Wiki, so you can update or fix that information, or add
- additional information on those switches or information on new switches,
- yourself.)
-
- Note also that many firewall/NAT boxes have a switch built into them; this
- includes many of the "cable/DSL router" boxes. If you have a box of that
- sort, that has a switch with some number of Ethernet ports into which you
- plug machines on your network, and another Ethernet port used to connect to
- a cable or DSL modem, you can, at least, sniff traffic between the machines
- on your network and the Internet by plugging the Ethernet port on the router
- going to the modem, the Ethernet port on the modem, and the machine on which
- you're running Ethereal 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
+ Q 7.1: When I use Wireshark to capture packets, why do I see only
+ packets to and from my machine, or not see all the traffic I'm
+ expecting to see from or to the machine I'm trying to monitor?
+
+ A: This might be because the interface on which you're capturing is
+ plugged into an Ethernet or Token Ring switch; on a switched network,
+ unicast traffic between two ports will not necessarily appear on other
+ ports - only broadcast and multicast traffic will be sent to all
+ ports.
+
+ Note that even if your machine is plugged into a hub, the "hub" may be
+ a switched hub, in which case you're still on a switched network.
+
+ Note also that on the Linksys Web site, they say that their
+ auto-sensing hubs "broadcast the 10Mb packets to the port that operate
+ at 10Mb only and broadcast the 100Mb packets to the ports that operate
+ at 100Mb only", which would indicate that if you sniff on a 10Mb port,
+ you will not see traffic coming sent to a 100Mb port, and vice versa.
+ This problem has also been reported for Netgear dual-speed hubs, and
+ may exist for other "auto-sensing" or "dual-speed" hubs.
+
+ Some switches have the ability to replicate all traffic on all ports
+ to a single port so that you can plug your analyzer into that single
+ port to sniff all traffic. You would have to check the documentation
+ for the switch to see if this is possible and, if so, to see how to do
+ this. See the switch reference page on the Wireshark Wiki for
+ information on some switches. (Note that it's a Wiki, so you can
+ update or fix that information, or add additional information on those
+ switches or information on new switches, yourself.)
+
+ Note also that many firewall/NAT boxes have a switch built into them;
+ this includes many of the "cable/DSL router" boxes. If you have a box
+ of that sort, that has a switch with some number of Ethernet ports
+ into which you plug machines on your network, and another Ethernet
+ port used to connect to a cable or DSL modem, you can, at least, sniff
+ traffic between the machines on your network and the Internet by
+ plugging the Ethernet port on the router going to the modem, the
+ Ethernet port on the modem, and the machine on which you're running
+ Wireshark into a hub (make sure it's not a switching hub, and that, if
+ it's a dual-speed hub, all three of those ports are running at the
same speed.
- If your machine is not plugged into a switched network or a dual-speed hub,
- or it is plugged into a switched network but the port is set up to have all
- traffic replicated to it, the problem might be that the network interface on
- which you're capturing doesn't support "promiscuous" mode, or because your
- OS can't put the interface into promiscuous mode. Normally, network
- interfaces supply to the host only:
+ If your machine is not plugged into a switched network or a dual-speed
+ hub, or it is plugged into a switched network but the port is set up
+ to have all traffic replicated to it, the problem might be that the
+ network interface on which you're capturing doesn't support
+ "promiscuous" mode, or because your OS can't put the interface into
+ promiscuous mode. Normally, network interfaces supply to the host
+ only:
* packets sent to one of that host's link-layer addresses;
* broadcast packets;
* multicast packets sent to a multicast address that the host has
configured the interface to accept.
- Most network interfaces can also be put in "promiscuous" mode, in which they
- supply to the host all network packets they see. Ethereal will try to put
+ Most network interfaces can also be put in "promiscuous" mode, in
+ which they supply to the host all network packets they see. Wireshark
+ will try to put the interface on which it's capturing into promiscuous
+ mode unless the "Capture packets in promiscuous mode" option is turned
+ off in the "Capture Options" dialog box, and TShark will try to put
the interface on which it's capturing into promiscuous mode unless the
- "Capture packets in promiscuous mode" option is turned off in the "Capture
- Options" dialog box, and TShark will try to put the interface on which
- it's capturing into promiscuous mode unless the -p option was specified.
- However, some network interfaces don't support promiscuous mode, and some
- OSes might not allow interfaces to be put into promiscuous mode.
+ -p option was specified. However, some network interfaces don't
+ support promiscuous mode, and some OSes might not allow interfaces to
+ be put into promiscuous mode.
If the interface is not running in promiscuous mode, it won't see any
traffic that isn't intended to be seen by your machine. It will see
- broadcast packets, and multicast packets sent to a multicast MAC address the
- interface is set up to receive.
+ 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.
+ 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.
+ Windows, may require you to enable promiscuous mode in order to
+ capture in promiscuous mode. See the Wireshark Wiki item on Token Ring
+ capturing for details.
In the case of wireless LAN interfaces, it appears that, when those
- interfaces are promiscuously sniffing, they're running in a significantly
- different mode from the mode that they run in when they're just acting as
- network interfaces (to the extent that it would be a significant effor for
- those drivers to support for promiscuously sniffing and acting as regular
- network interfaces at the same time), so it may be that Windows drivers for
- those interfaces don't support promiscuous mode.
-
- Q 7.2: When I capture with Ethereal, why can't I see any TCP packets other
- than packets to and from my machine, even though another analyzer on the
- network sees those packets?
-
- A: You're probably not seeing any packets other than unicast packets to or
- from your machine, and broadcast and multicast packets; a switch will
- normally send to a port only unicast traffic sent to the MAC address for the
- interface on that port, and broadcast and multicast traffic - it won't send
- to that port unicast traffic sent to a MAC address for some other interface
- - and a network interface not in promiscuous mode will receive only unicast
- traffic sent to the MAC address for that interface, broadcast traffic, and
- multicast traffic sent to a multicast MAC address the interface is set up to
- receive.
-
- TCP doesn't use broadcast or multicast, so you will only see your own TCP
- traffic, but UDP services may use broadcast or multicast so you'll see some
- UDP traffic - however, this is not a problem with TCP traffic, it's a
- problem with unicast traffic, as you also won't see all UDP traffic between
- other machines.
+ interfaces are promiscuously sniffing, they're running in a
+ significantly different mode from the mode that they run in when
+ they're just acting as network interfaces (to the extent that it would
+ be a significant effor for those drivers to support for promiscuously
+ sniffing and acting as regular network interfaces at the same time),
+ so it may be that Windows drivers for those interfaces don't support
+ promiscuous mode.
+
+ Q 7.2: When I capture with Wireshark, why can't I see any TCP packets
+ other than packets to and from my machine, even though another
+ analyzer on the network sees those packets?
+
+ A: You're probably not seeing any packets other than unicast packets
+ to or from your machine, and broadcast and multicast packets; a switch
+ will normally send to a port only unicast traffic sent to the MAC
+ address for the interface on that port, and broadcast and multicast
+ traffic - it won't send to that port unicast traffic sent to a MAC
+ address for some other interface - and a network interface not in
+ promiscuous mode will receive only unicast traffic sent to the MAC
+ address for that interface, broadcast traffic, and multicast traffic
+ sent to a multicast MAC address the interface is set up to receive.
+
+ TCP doesn't use broadcast or multicast, so you will only see your own
+ TCP traffic, but UDP services may use broadcast or multicast so you'll
+ see some UDP traffic - however, this is not a problem with TCP
+ traffic, it's a problem with unicast traffic, as you also won't see
+ all UDP traffic between other machines.
I.e., this is probably the same question as this earlier one; see the
response to that question.
Q 7.3: Why am I only seeing ARP packets when I try to capture traffic?
- A: You're probably on a switched network, and running Ethereal on a machine
- that's not sending traffic to the switch and not being sent any traffic from
- other machines on the switch. ARP packets are often broadcast packets, which
- are sent to all switch ports.
+ A: You're probably on a switched network, and running Wireshark on a
+ machine that's not sending traffic to the switch and not being sent
+ any traffic from other machines on the switch. ARP packets are often
+ broadcast packets, which are sent to all switch ports.
I.e., this is probably the same question as this earlier one; see the
response to that question.
Q 7.4: Why am I not seeing any traffic when I try to capture traffic?
- A: Is the machine running Ethereal sending out any traffic on the network
- interface on which you're capturing, or receiving any traffic on that
- network, or is there any broadcast traffic on the network or multicast
- traffic to a multicast group to which the machine running Ethereal belongs?
+ A: Is the machine running Wireshark sending out any traffic on the
+ network interface on which you're capturing, or receiving any traffic
+ on that network, or is there any broadcast traffic on the network or
+ multicast traffic to a multicast group to which the machine running
+ Wireshark belongs?
- If not, this may just be a problem with promiscuous sniffing, either due to
- running on a switched network or a dual-speed hub, or due to problems with
- the interface not supporting promiscuous mode; see the response to this
- earlier question.
+ If not, this may just be a problem with promiscuous sniffing, either
+ due to running on a switched network or a dual-speed hub, or due to
+ problems with the interface not supporting promiscuous mode; see the
+ response to this earlier question.
Otherwise, on Windows, see the response to this question and, on a
UNIX-flavored OS, see the response to this question.
- Q 7.5: Can Ethereal capture on (my T1/E1 line, SS7 links, etc.)?
+ Q 7.5: Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
- A: Ethereal can only capture on devices supported by libpcap/WinPcap. On
- most OSes, only devices that can act as network interfaces of the type that
- support IP are supported as capture devices for libpcap/WinPcap, although
- the device doesn't necessarily have to be running as an IP interface in
- order to support traffic capture.
+ A: Wireshark can only capture on devices supported by libpcap/WinPcap.
+ On most OSes, only devices that can act as network interfaces of the
+ type that support IP are supported as capture devices for
+ libpcap/WinPcap, although the device doesn't necessarily have to be
+ running as an IP interface in order to support traffic capture.
On Linux and FreeBSD, libpcap 0.8 and later support the API for Endace
- Measurement Systems' DAG cards, so that a system with one of those cards,
- and its driver and libraries, installed can capture traffic with those cards
- with libpcap-based applications. You would either have to have a version of
- Ethereal built with that version of libpcap, or a dynamically-linked version
- of Ethereal and a shared libpcap library with DAG support, in order to do so
- with Ethereal. 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.
+ Measurement Systems' DAG cards, so that a system with one of those
+ cards, and its driver and libraries, installed can capture traffic
+ with those cards with libpcap-based applications. You would either
+ have to have a version of Wireshark built with that version of
+ libpcap, or a dynamically-linked version of Wireshark and a shared
+ libpcap library with DAG support, in order to do so with Wireshark.
+ You should ask Endace whether that could be used to capture traffic
+ on, for example, your T1/E1 link. See the SS7 capture setup page on
+ the Wireshark Wiki for current information on capturing SS7 traffic on
+ TDM links.
Q 7.6: How do I put an interface into promiscuous mode?
- A: By not disabling promiscuous mode when running Ethereal or TShark.
+ 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, Ethereal, etc. use to do packet capture) turns on will
- not necessarily be shown if you run ifconfig on the interface on a UNIX
- system;
- * some network interfaces might not support promiscuous mode, and some
- drivers might not allow promiscuous mode to be turned on - see this
- earlier question for more information on that;
+ * the form of promiscuous mode that libpcap (the library that
+ programs such as tcpdump, Wireshark, etc. use to do packet
+ capture) turns on will not necessarily be shown if you run
+ ifconfig on the interface on a UNIX system;
+ * some network interfaces might not support promiscuous mode, and
+ some drivers might not allow promiscuous mode to be turned on -
+ see this earlier question for more information on that;
* the fact that you're not seeing any traffic, or are only seeing
- broadcast traffic, or aren't seeing any non-broadcast traffic other than
- traffic to or from the machine running Ethereal, does not mean that
- promiscuous mode isn't on - see this earlier question for more
- information on that.
+ broadcast traffic, or aren't seeing any non-broadcast traffic
+ other than traffic to or from the machine running Wireshark, does
+ not mean that promiscuous mode isn't on - see this earlier
+ question for more information on that.
I.e., this is probably the same question as this earlier one; see the
response to that question.
- Q 7.7: I can set a display filter just fine; why don't capture filters work?
+ Q 7.7: I can set a display filter just fine; why don't capture filters
+ work?
- A: Capture filters currently use a different syntax than display filters.
- Here's the corresponding section from the ethereal(1) man page:
+ 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 Ethereal progresses, expect more and more
- protocol fields to be allowed in display filters.
+ "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."
+ 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.
+ The capture filter syntax used by libpcap can be found in the
+ tcpdump(8) man page.
- Q 7.8: I'm entering valid capture filters; why do I still get "parse error"
- errors?
+ Q 7.8: I'm entering valid capture filters; why do I still get "parse
+ error" errors?
A: There is a bug in some versions of libpcap/WinPcap that cause it to
report parse errors even for valid expressions if a previous filter
expression was invalid and got a parse error.
- Try exiting and restarting Ethereal; 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.
+ 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.
+ 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.
+ 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 Ethereal on a UNIX-flavored platform, run "ethereal -v",
- or select "About Ethereal..." from the "Help" menu in Wireshark, to see what
- version of libpcap it's using. If it's not 0.6 or later, you will need
- either to upgrade your OS to get a later version of libpcap, or will need to
- build and install a later version of libpcap from the tcpdump.org Web site
- and then recompile Ethereal from source with that later version of libpcap.
+ If you are running Wireshark on a UNIX-flavored platform, run
+ "wireshark -v", or select "About Wireshark..." from the "Help" menu in
+ Wireshark, to see what version of libpcap it's using. If it's not 0.6
+ or later, you will need either to upgrade your OS to get a later
+ version of libpcap, or will need to build and install a later version
+ of libpcap from the tcpdump.org Web site and then recompile Wireshark
+ from source with that later version of libpcap.
- If you are running Ethereal 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.
+ If you are running Wireshark on Windows with a pre-2.3 version of
+ WinPcap, you will need to un-install WinPcap and then download and
+ install WinPcap 2.3.
Q 7.9: How can I capture packets with CRC errors?
- A: Ethereal can capture only the packets that the packet capture library -
- libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of libpcap on
- Windows - can capture, and libpcap/WinPcap can capture only the packets that
- the OS's raw packet capture mechanism (or the WinPcap driver, and the
- underlying OS networking code and network interface drivers, on Windows)
- will allow it to capture.
-
- Unless the OS always supplies packets with errors such as invalid CRCs to
- the raw packet capture mechanism, or can be configured to do so, invalid
- CRCs to the raw packet capture mechanism, Ethereal - and other programs that
- capture raw packets, such as tcpdump - cannot capture those packets. You
- will have to determine whether your OS needs to be so configured and, if so,
- can be so configured, configure it if necessary and possible, and make
- whatever changes to libpcap and the packet capture program you're using are
- necessary, if any, to support capturing those packets.
-
- Most OSes probably do not support capturing packets with invalid CRCs on
- Ethernet, and probably do not support it on most other link-layer types.
- Some drivers on some OSes do support it, such as some Ethernet drivers on
- FreeBSD; in those OSes, you might always get those packets, or you might
- only get them if you capture in promiscuous mode (you'd have to determine
- which is the case).
+ A: Wireshark can capture only the packets that the packet capture
+ library - libpcap on UNIX-flavored OSes, and the WinPcap port to
+ Windows of libpcap on Windows - can capture, and libpcap/WinPcap can
+ capture only the packets that the OS's raw packet capture mechanism
+ (or the WinPcap driver, and the underlying OS networking code and
+ network interface drivers, on Windows) will allow it to capture.
+
+ Unless the OS always supplies packets with errors such as invalid CRCs
+ to the raw packet capture mechanism, or can be configured to do so,
+ invalid CRCs to the raw packet capture mechanism, Wireshark - and
+ other programs that capture raw packets, such as tcpdump - cannot
+ capture those packets. You will have to determine whether your OS
+ needs to be so configured and, if so, can be so configured, configure
+ it if necessary and possible, and make whatever changes to libpcap and
+ the packet capture program you're using are necessary, if any, to
+ support capturing those packets.
+
+ Most OSes probably do not support capturing packets with invalid CRCs
+ on Ethernet, and probably do not support it on most other link-layer
+ types. Some drivers on some OSes do support it, such as some Ethernet
+ drivers on FreeBSD; in those OSes, you might always get those packets,
+ or you might only get them if you capture in promiscuous mode (you'd
+ have to determine which is the case).
Note that libpcap does not currently supply to programs that use it an
- indication of whether the packet's CRC was invalid (because the drivers
- themselves do not supply that information to the raw packet capture
- mechanism); therefore, Ethereal will not indicate which packets had CRC
- errors unless the FCS was captured (see the next question) and you're using
- Ethereal 0.9.15 and later, in which case Ethereal will check the CRC and
- indicate whether it's correct or not.
+ indication of whether the packet's CRC was invalid (because the
+ drivers themselves do not supply that information to the raw packet
+ capture mechanism); therefore, Wireshark will not indicate which
+ packets had CRC errors unless the FCS was captured (see the next
+ question) and you're using Wireshark 0.9.15 and later, in which case
+ Wireshark will check the CRC and indicate whether it's correct or not.
Q 7.10: How can I capture entire frames, including the FCS?
- A: Ethereal can only capture data that the packet capture library - libpcap
- on UNIX-flavored OSes, and the WinPcap port to Windows of libpcap on Windows
- - can capture, and libpcap/WinPcap can capture only the data that the OS's
- raw packet capture mechanism (or the WinPcap driver, and the underlying OS
- networking code and network interface drivers, on Windows) will allow it to
- capture.
-
- For any particular link-layer network type, unless the OS supplies the FCS
- of a frame as part of the frame, or can be configured to do so, Ethereal -
- and other programs that capture raw packets, such as tcpdump - cannot
- capture the FCS of a frame. You will have to determine whether your OS needs
- to be so configured and, if so, can be so configured, configure it if
- necessary and possible, and make whatever changes to libpcap and the packet
- capture program you're using are necessary, if any, to support capturing the
- FCS of a frame.
+ A: Wireshark can only capture data that the packet capture library -
+ libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of
+ libpcap on Windows - can capture, and libpcap/WinPcap can capture only
+ the data that the OS's raw packet capture mechanism (or the WinPcap
+ driver, and the underlying OS networking code and network interface
+ drivers, on Windows) will allow it to capture.
+
+ For any particular link-layer network type, unless the OS supplies the
+ FCS of a frame as part of the frame, or can be configured to do so,
+ Wireshark - and other programs that capture raw packets, such as
+ tcpdump - cannot capture the FCS of a frame. You will have to
+ determine whether your OS needs to be so configured and, if so, can be
+ so configured, configure it if necessary and possible, and make
+ whatever changes to libpcap and the packet capture program you're
+ using are necessary, if any, to support capturing the FCS of a frame.
Most OSes do not support capturing the FCS of a frame on Ethernet, and
- probably do not support it on most other link-layer types. Some drivres on
- some OSes do support it, such as some (all?) Ethernet drivers on NetBSD and
- possibly the driver for Apple's gigabit Ethernet interface in Mac OS X; in
- those OSes, you might always get the FCS, or you might only get the FCS if
- you capture in promiscuous mode (you'd have to determine which is the case).
-
- Versions of Ethereal prior to 0.9.15 will not treat an Ethernet FCS in a
- captured packet as an FCS. 0.9.15 and later will attempt to determine
- whether there's an FCS at the end of the frame and, if it thinks there is,
- will display it as such, and will check whether it's the correct CRC-32
- value or not.
-
- Q 7.11: I'm capturing packets on a machine on a VLAN; why don't the packets
- I'm capturing have VLAN tags?
-
- A: You might be capturing on what might be called a "VLAN interface" - the
- way a particular OS makes VLANs plug into the networking stack might, for
- example, be to have a network device object for the physical interface,
- which takes VLAN packets, strips off the VLAN header and constructs an
- Ethernet header, and passes that packet to an internal network device object
- for the VLAN, which then passes the packets onto various higher-level
- protocol implementations.
-
- In order to see the raw Ethernet packets, rather than "de-VLANized" packets,
- you would have to capture not on the virtual interface for the VLAN, but on
- the interface corresponding to the physical network device, if possible. See
- the Wireshark Wiki item on VLAN capturing for details.
-
- Q 7.12: Why does Ethereal hang after I stop a capture?
-
- A: The most likely reason for this is that Wireshark is trying to look up an
- IP address in the capture to convert it to a name (so that, for example, it
- can display the name in the source address or destination address columns),
- and that lookup process is taking a very long time.
-
- Ethereal 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:
+ probably do not support it on most other link-layer types. Some
+ drivres on some OSes do support it, such as some (all?) Ethernet
+ drivers on NetBSD and possibly the driver for Apple's gigabit Ethernet
+ interface in Mac OS X; in those OSes, you might always get the FCS, or
+ you might only get the FCS if you capture in promiscuous mode (you'd
+ have to determine which is the case).
+
+ Versions of Wireshark prior to 0.9.15 will not treat an Ethernet FCS
+ in a captured packet as an FCS. 0.9.15 and later will attempt to
+ determine whether there's an FCS at the end of the frame and, if it
+ thinks there is, will display it as such, and will check whether it's
+ the correct CRC-32 value or not.
+
+ Q 7.11: I'm capturing packets on a machine on a VLAN; why don't the
+ packets I'm capturing have VLAN tags?
+
+ A: You might be capturing on what might be called a "VLAN interface" -
+ the way a particular OS makes VLANs plug into the networking stack
+ might, for example, be to have a network device object for the
+ physical interface, which takes VLAN packets, strips off the VLAN
+ header and constructs an Ethernet header, and passes that packet to an
+ internal network device object for the VLAN, which then passes the
+ packets onto various higher-level protocol implementations.
+
+ In order to see the raw Ethernet packets, rather than "de-VLANized"
+ packets, you would have to capture not on the virtual interface for
+ the VLAN, but on the interface corresponding to the physical network
+ device, if possible. See the Wireshark Wiki item on VLAN capturing for
+ details.
+
+ Q 7.12: Why does Wireshark hang after I stop a capture?
+
+ A: The most likely reason for this is that Wireshark is trying to look
+ up an IP address in the capture to convert it to a name (so that, for
+ example, it can display the name in the source address or destination
+ address columns), and that lookup process is taking a very long time.
+
+ Wireshark calls a routine in the OS of the machine on which it's
+ running to convert of IP addresses to the corresponding names. That
+ routine probably does one or more of:
* a search of a system file listing IP addresses and names;
* a lookup using DNS;
* on UNIX systems, a lookup using NIS;
* on Windows systems, a NetBIOS-over-TCP query.
- If a DNS server that's used in an address lookup is not responding, the
- lookup will fail, but will only fail after a timeout while the system
- routine waits for a reply.
-
- In addition, on Windows systems, if the DNS lookup of the address fails,
- either because the server isn't responding or because there are no records
- in the DNS that could be used to map the address to a name, a
- NetBIOS-over-TCP query will be made. That query involves sending a message
- to the NetBIOS-over-TCP name service on that machine, asking for the name
- and other information about the machine. If the machine isn't running
- software that responds to those queries - for example, many non-Windows
- machines wouldn't be running that software - the lookup will only fail after
- a timeout. Those timeouts can cause the lookup to take a long time.
-
- If you disable network address-to-name translation - for example, by turning
- off the "Enable network name resolution" option in the "Capture Options"
- dialog box for starting a network capture - the lookups of the address won't
- be done, which may speed up the process of reading the capture file after
- the capture is stopped. You can make that setting the default by selecting
- "Preferences" from the "Edit" menu, turning off the "Enable network name
- resolution" option in the "Name resolution" options in the preferences
- disalog box, and using the "Save" button in that dialog box; note that this
- will save all your current preference settings.
-
- If Ethereal hangs when reading a capture even with network name resolution
- turned off, there might, for example, be a bug in one of Ethereal's
- dissectors for a protocol causing it to loop infinitely. If you're not
- running the most recent release of Ethereal, you should first upgrade to
- that release, as, if there's a bug of that sort, it might've been fixed in a
- release after the one you're running. If the hang occurs in the most recent
- release of Ethereal, the bug should be reported to the Wireshark developers'
- mailing list at wireshark-dev@wireshark.org.
-
- On UNIX-flavored OSes, please try to force Ethereal to dump core, by sending
- it a SIGABRT signal (usually signal 6) with the kill command, and then get a
- stack trace if you have a debugger installed. A stack trace can be obtained
- by using your debugger (gdb in this example), the Wireshark binary, and the
- resulting core file. Here's an example of how to use the gdb command
- backtrace to do so.
- $ gdb ethereal core
+ If a DNS server that's used in an address lookup is not responding,
+ the lookup will fail, but will only fail after a timeout while the
+ system routine waits for a reply.
+
+ In addition, on Windows systems, if the DNS lookup of the address
+ fails, either because the server isn't responding or because there are
+ no records in the DNS that could be used to map the address to a name,
+ a NetBIOS-over-TCP query will be made. That query involves sending a
+ message to the NetBIOS-over-TCP name service on that machine, asking
+ for the name and other information about the machine. If the machine
+ isn't running software that responds to those queries - for example,
+ many non-Windows machines wouldn't be running that software - the
+ lookup will only fail after a timeout. Those timeouts can cause the
+ lookup to take a long time.
+
+ If you disable network address-to-name translation - for example, by
+ turning off the "Enable network name resolution" option in the
+ "Capture Options" dialog box for starting a network capture - the
+ lookups of the address won't be done, which may speed up the process
+ of reading the capture file after the capture is stopped. You can make
+ that setting the default by selecting "Preferences" from the "Edit"
+ menu, turning off the "Enable network name resolution" option in the
+ "Name resolution" options in the preferences disalog box, and using
+ the "Save" button in that dialog box; note that this will save all
+ your current preference settings.
+
+ If Wireshark hangs when reading a capture even with network name
+ resolution turned off, there might, for example, be a bug in one of
+ Wireshark's dissectors for a protocol causing it to loop infinitely.
+ If you're not running the most recent release of Wireshark, you should
+ first upgrade to that release, as, if there's a bug of that sort, it
+ might've been fixed in a release after the one you're running. If the
+ hang occurs in the most recent release of Wireshark, the bug should be
+ reported to the Wireshark developers' mailing list at
+ wireshark-dev@wireshark.org.
+
+ On UNIX-flavored OSes, please try to force Wireshark to dump core, by
+ sending it a SIGABRT signal (usually signal 6) with the kill command,
+ and then get a stack trace if you have a debugger installed. A stack
+ trace can be obtained by using your debugger (gdb in this example),
+ the Wireshark binary, and the resulting core file. Here's an example
+ of how to use the gdb command backtrace to do so.
+ $ gdb wireshark core
(gdb) backtrace
..... prints the stack trace
(gdb) quit
$
- The core dump file may be named "ethereal.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, Ethereal normally writes captured
- packets to a temporary file, which will probably be in /tmp or /var/tmp on
- UNIX-flavored OSes, \TEMP on the main system disk (normally C:) on Windows
- 9x/Me/NT 4.0, and \Documents and Settings\your login name\Local
- Settings\Temp on the main system disk on Windows 2000/Windows XP/Windows
- Server 2003, so the capture file will probably be there. It will have a name
- beginning with ether, with some mixture of letters and numbers after that.
- Please don't send a trace file greater than 1 MB when compressed; instead,
- make it available via FTP or HTTP, or say it's available but leave it up to
- a developer to ask for it. If the trace file contains sensitive information
- (e.g., passwords), then please do not send it.
+ The core dump file may be named "wireshark.core" rather than "core" on
+ some platforms (e.g., BSD systems).
+
+ Also, if at all possible, please send a copy of the capture file that
+ caused the problem; when capturing packets, Wireshark normally writes
+ captured packets to a temporary file, which will probably be in /tmp
+ or /var/tmp on UNIX-flavored OSes, \TEMP on the main system disk
+ (normally C:) on Windows 9x/Me/NT 4.0, and \Documents and
+ Settings\your login name\Local Settings\Temp on the main system disk
+ on Windows 2000/Windows XP/Windows Server 2003, so the capture file
+ will probably be there. It will have a name beginning with ether, with
+ some mixture of letters and numbers after that. Please don't send a
+ trace file greater than 1 MB when compressed; instead, make it
+ available via FTP or HTTP, or say it's available but leave it up to a
+ developer to ask for it. If the trace file contains sensitive
+ information (e.g., passwords), then please do not send it.
8. Capturing packets on Windows
- Q 8.1: I'm running Ethereal on Windows; why does some network interface on
- my machine not show up in the list of interfaces in the "Interface:" field
- in the dialog box popped up by "Capture->Start", and/or why does Ethereal
- give me an error if I try to capture on that interface?
-
- A: If you are running Ethereal on Windows NT 4.0, Windows 2000, Windows XP,
- or Windows Server 2003, and this is the first time you have run a
- WinPcap-based program (such as Ethereal, or TShark, or WinDump, or
- Analyzer, or...) since the machine was rebooted, you need to run that
- program from an account with administrator privileges; once you have run
- such a program, you will not need administrator privileges to run any such
- programs until you reboot.
-
- If you are running on Windows 95/98/Me, or if you are running on Windows NT
- 4.0/Windows 2000/Windows XP/Windows Server 2003 and have administrator
- privileges or a WinPcap-based program has been run with those privileges
- since the machine rebooted, this problem might clear up if you completely
- un-install WinPcap and then re-install it.
-
- If that doesn't work, then note that Ethereal 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.
+ Q 8.1: I'm running Wireshark on Windows; why does some network
+ interface on my machine not show up in the list of interfaces in the
+ "Interface:" field in the dialog box popped up by "Capture->Start",
+ and/or why does Wireshark give me an error if I try to capture on that
+ interface?
+
+ A: If you are running Wireshark on Windows NT 4.0, Windows 2000,
+ Windows XP, or Windows Server 2003, and this is the first time you
+ have run a WinPcap-based program (such as Wireshark, or TShark, or
+ WinDump, or Analyzer, or...) since the machine was rebooted, you need
+ to run that program from an account with administrator privileges;
+ once you have run such a program, you will not need administrator
+ privileges to run any such programs until you reboot.
+
+ If you are running on Windows 95/98/Me, or if you are running on
+ Windows NT 4.0/Windows 2000/Windows XP/Windows Server 2003 and have
+ administrator privileges or a WinPcap-based program has been run with
+ those privileges since the machine rebooted, this problem might clear
+ up if you completely un-install WinPcap and then re-install it.
+
+ If that doesn't work, then note that Wireshark relies on the WinPcap
+ library, on the WinPcap device driver, and on the facilities that come
+ with the OS on which it's running in order to do captures.
Therefore, if the OS, the WinPcap library, or the WinPcap driver don't
- support capturing on a particular network interface device, Ethereal won't
- be able to capture on that device.
+ 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
- Ethereal uses for packet capture didn't support Token Ring interfaces;
- versions 2.1 and later support Token Ring, and the current version of
- Ethereal works with (and, in fact, requires) WinPcap 2.1 or later.
- If you are having problems capturing on Token Ring interfaces, and you
- have WinPcap 2.02 or an earlier version of WinPcap installed, you should
- uninstall WinPcap, download and install the current version of WinPcap,
- and then install the latest version of Ethereal.
- 2. On Windows 95, 98, or Me, sometimes more than one interface will be
- given the same name; if that is the case, you will only be able to
- capture on one of those interfaces - it's not clear to which one the
- name, when used in a WinPcap-based application, will refer. For example,
- if you have a PPP serial interface and a VPN interface, they might show
- up with the same name, for example "ppp-mac", and if you try to capture
- on "ppp-mac", it might not capture on the interface you're currently
- using. In that case, you might, for example, have to remove the VPN
- interface from the system in order to capture on the PPP serial
- interface.
- 3. WinPcap 2.3 has problems supporting PPP WAN interfaces on Windows NT
- 4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to avoid
- those problems, support for PPP WAN interfaces on those versions of
- Windows has been disabled in WinPcap 3.0. Regular dial-up lines, ISDN
- lines, ADSL connections using PPPoE or PPPoA, and various other lines
- such as T1/E1 lines are all PPP interfaces, so those interfaces might
- not show up on the list of interfaces in the "Capture Options" dialog on
- those OSes.
- On Windows 2000, Windows XP, and Windows Server 2003, but not Windows NT
- 4.0 or Windows Vista Beta 1, you should be able to capture on the
- "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
- the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
- un-install it and install the final 3.1 release.) See the Wireshark Wiki
- item on PPP capturing for details.
- 4. WinPcap prior to 3.0 does not support multiprocessor machines (note that
- machines with a single multi-threaded processor, such as Intel's new
- multi-threaded x86 processors, are multiprocessor machines as far as the
- OS and WinPcap are concerned), and recent 2.x versions of WinPcap refuse
- to operate if they detect that they're running on a multiprocessor
- machine, which means that they may not show any network interfaces. You
- will need to use WinPcap 3.0 to capture on a multiprocessor machine.
+ Wireshark uses for packet capture didn't support Token Ring
+ interfaces; versions 2.1 and later support Token Ring, and the
+ current version of Wireshark works with (and, in fact, requires)
+ WinPcap 2.1 or later.
+ If you are having problems capturing on Token Ring interfaces, and
+ you have WinPcap 2.02 or an earlier version of WinPcap installed,
+ you should uninstall WinPcap, download and install the current
+ version of WinPcap, and then install the latest version of
+ Wireshark.
+ 2. On Windows 95, 98, or Me, sometimes more than one interface will
+ be given the same name; if that is the case, you will only be able
+ to capture on one of those interfaces - it's not clear to which
+ one the name, when used in a WinPcap-based application, will
+ refer. For example, if you have a PPP serial interface and a VPN
+ interface, they might show up with the same name, for example
+ "ppp-mac", and if you try to capture on "ppp-mac", it might not
+ capture on the interface you're currently using. In that case, you
+ might, for example, have to remove the VPN interface from the
+ system in order to capture on the PPP serial interface.
+ 3. WinPcap 2.3 has problems supporting PPP WAN interfaces on Windows
+ NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to
+ avoid those problems, support for PPP WAN interfaces on those
+ versions of Windows has been disabled in WinPcap 3.0. Regular
+ dial-up lines, ISDN lines, ADSL connections using PPPoE or PPPoA,
+ and various other lines such as T1/E1 lines are all PPP
+ interfaces, so those interfaces might not show up on the list of
+ interfaces in the "Capture Options" dialog on those OSes.
+ On Windows 2000, Windows XP, and Windows Server 2003, but not
+ Windows NT 4.0 or Windows Vista Beta 1, you should be able to
+ capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta
+ releases called it the "NdisWanAdapter"; if you're using a 3.1
+ beta release, you should un-install it and install the final 3.1
+ release.) See the Wireshark Wiki item on PPP capturing for
+ details.
+ 4. WinPcap prior to 3.0 does not support multiprocessor machines
+ (note that machines with a single multi-threaded processor, such
+ as Intel's new multi-threaded x86 processors, are multiprocessor
+ machines as far as the OS and WinPcap are concerned), and recent
+ 2.x versions of WinPcap refuse to operate if they detect that
+ they're running on a multiprocessor machine, which means that they
+ may not show any network interfaces. You will need to use WinPcap
+ 3.0 to capture on a multiprocessor machine.
If an interface doesn't show up in the list of interfaces in the
- "Interface:" field, and you know the name of the interface, try entering
- that name in the "Interface:" field and capturing on that device.
-
- If the attempt to capture on it succeeds, the interface is somehow not being
- reported by the mechanism Ethereal uses to get a list of interfaces. Try
- listing the interfaces with WinDump; see the WinDump Web site or the local
- mirror of the WinDump Web site for information on using WinDump.
-
- You would run WinDump with the -D flag; if it lists the interface, please
- report this to wireshark-dev@wireshark.org giving full details of the problem,
- including
- * the operating system you're using, and the version of that operating
- system;
+ "Interface:" field, and you know the name of the interface, try
+ entering that name in the "Interface:" field and capturing on that
+ device.
+
+ If the attempt to capture on it succeeds, the interface is somehow not
+ being reported by the mechanism Wireshark uses to get a list of
+ interfaces. Try listing the interfaces with WinDump; see the WinDump
+ Web site for information on using WinDump.
+
+ You would run WinDump with the -D flag; if it lists the interface,
+ please report this to wireshark-dev@wireshark.org giving full details
+ of the problem, including
+ * the operating system you're using, and the version of that
+ operating system;
* the type of network device you're using;
* the output of WinDump.
- If WinDump does not list the interface, this is almost certainly a problem
- with one or more of:
+ If WinDump does not list the interface, this is almost certainly a
+ problem with one or more of:
* the operating system you're using;
* the device driver for the interface you're using;
* the WinPcap library and/or the WinPcap device driver;
- so first check the WinPcap FAQ, the local mirror of that 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 (or the local mirror of
- that page) - check the "Submitting bugs" section.
+ 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 or the
- local mirror of the WinDump Web site for information on using WinDump.
+ If you are having trouble capturing on a particular network interface,
+ first try capturing on that device with WinDump; see the WinDump Web
+ site for information on using WinDump.
If you can capture on the interface with WinDump, send mail to
- wireshark-users@wireshark.org giving full details of the problem, including
- * the operating system you're using, and the version of that operating
- system;
+ wireshark-users@wireshark.org giving full details of the problem,
+ including
+ * the operating system you're using, and the version of that
+ operating system;
* the type of network device you're using;
- * the error message you get from Ethereal.
+ * the error message you get from Wireshark.
If you cannot capture on the interface with WinDump, this is almost
certainly a problem with one or more of:
* the device driver for the interface you're using;
* the WinPcap library and/or the WinPcap device driver;
- so first check the WinPcap FAQ, the local mirror of that 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 (or the local mirror of
- that page) - check the "Submitting bugs" section.
+ so first check the WinPcap FAQ or the Wiretapped.net mirror of that
+ FAQ, to see if your problem is mentioned there. If not, then see the
+ WinPcap support page - check the "Submitting bugs" section.
You may also want to ask the wireshark-users@wireshark.org and the
- winpcap-users@winpcap.org mailing lists to see if anybody happens to know
- about the problem and know a workaround or fix for the problem. (Note that
- you will have to subscribe to that list in order to be allowed to mail to
- it; see the WinPcap support page, or the local mirror of that page, for
- information on the mailing list.) In your mail, please give full details of
- the problem, as described above, and also indicate that the problem occurs
- with WinDump, not just with Ethereal.
-
- Q 8.2: I'm running Ethereal on Windows; why do no network interfaces show up
- in the list of interfaces in the "Interface:" field in the dialog box popped
- up by "Capture->Start"?
-
- A: This is really the same question as the previous one; see the response to
- that question.
-
- Q 8.3: I'm running Ethereal on Windows; why doesn't my serial port/ADSL
- modem/ISDN modem show up in the list of interfaces in the "Interface:" field
- in the dialog box popped up by "Capture->Start"?
-
- A: Internet access on those devices is often done with the Point-to-Point
- (PPP) protocol; WinPcap 2.3 has problems supporting PPP WAN interfaces on
- Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to
- avoid those problems, support for PPP WAN interfaces on those versions of
- Windows has been disabled in WinPcap 3.0.
-
- On Windows 2000, Windows XP, and Windows Server 2003, but not Windows NT 4.0
- or Windows Vista Beta 1, you should be able to capture on the
- "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it the
- "NdisWanAdapter"; if you're using a 3.1 beta release, you should un-install
- it and install the final 3.1 release.) See the Wireshark Wiki item on PPP
- capturing for details.
-
- Q 8.4: I'm running Ethereal on Windows NT 4.0/Windows 2000/Windows
- XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN, etc.)
- interface, and it shows up in the "Interface" item in the "Capture Options"
- dialog box. Why can no packets be sent on or received from that network
- while I'm trying to capture traffic on that interface?
-
- A: Some versions of WinPcap have problems with PPP WAN interfaces on Windows
- NT 4.0, Windows 2000, Windows XP, and Windows Server 2003; one symptom that
- may be seen is that attempts to capture in promiscuous mode on the interface
- cause the interface to be incapable of sending or receiving packets. You can
- disable promiscuous mode using the -p command-line flag or the item in the
- "Capture Preferences" dialog box, but this may mean that outgoing packets,
- or incoming packets, won't be seen in the capture.
-
- On Windows 2000, Windows XP, and Windows Server 2003, but not Windows NT 4.0
- or Windows Vista Beta 1, you should be able to capture on the
- "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it the
- "NdisWanAdapter"; if you're using a 3.1 beta release, you should un-install
- it and install the final 3.1 release.) See the Wireshark Wiki item on PPP
- capturing for details.
-
- Q 8.5: I'm running Ethereal on Windows 95/98/Me, on a machine with more than
- one network adapter of the same type; why does Ethereal 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 Ethereal on Windows; why am I not seeing any traffic
- being sent by the machine running Ethereal?
-
- A: If you are running some form of VPN client software, it might be causing
- this problem; people have seen this problem when they have Check Point's VPN
- software installed on their machine. If that's the cause of the problem, you
- will have to remove the VPN software in order to have Ethereal (or any other
- application using WinPcap) see outgoing packets; unfortunately, neither we
- nor the WinPcap developers know any way to make WinPcap and the VPN software
- work well together.
-
- Also, some drivers for Windows (especially some wireless network interface
- drivers) apparently do not, when running in promiscuous mode, arrange that
- outgoing packets are delivered to the software that requested that the
- interface run promiscuously; try turning promiscuous mode off.
-
- Q 8.7: When I capture on Windows in promiscuous mode, I can see packets
- other than those sent to or from my machine; however, those packets show up
- with a "Short Frame" indication, unlike packets to or from my machine. What
- should I do to arrange that I see those packets in their entirety?
-
- A: In at least some cases, this appears to be the result of PGPnet running
- on the network interface on which you're capturing; turn it off on that
- interface.
-
- Q 8.8: I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why
- are the time stamps on packets wrong?
-
- A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap 3.0
- and later releases.
+ winpcap-users@winpcap.org mailing lists to see if anybody happens to
+ know about the problem and know a workaround or fix for the problem.
+ (Note that you will have to subscribe to that list in order to be
+ allowed to mail to it; see the WinPcap support page for information on
+ the mailing list.) In your mail, please give full details of the
+ problem, as described above, and also indicate that the problem occurs
+ with WinDump, not just with Wireshark.
+
+ Q 8.2: I'm running Wireshark on Windows; why do no network interfaces
+ show up in the list of interfaces in the "Interface:" field in the
+ dialog box popped up by "Capture->Start"?
+
+ A: This is really the same question as the previous one; see the
+ response to that question.
- Q 8.9: I'm trying to capture 802.11 traffic on Windows; why am I not seeing
- any packets?
+ Q 8.3: I'm running Wireshark on Windows; why doesn't my serial
+ port/ADSL modem/ISDN modem show up in the list of interfaces in the
+ "Interface:" field in the dialog box popped up by "Capture->Start"?
+
+ A: Internet access on those devices is often done with the
+ Point-to-Point (PPP) protocol; WinPcap 2.3 has problems supporting PPP
+ WAN interfaces on Windows NT 4.0, Windows 2000, Windows XP, and
+ Windows Server 2003, and, to avoid those problems, support for PPP WAN
+ interfaces on those versions of Windows has been disabled in WinPcap
+ 3.0.
+
+ On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
+ NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
+ "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
+ the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
+ un-install it and install the final 3.1 release.) See the Wireshark
+ Wiki item on PPP capturing for details.
+
+ Q 8.4: I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows
+ XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN,
+ etc.) interface, and it shows up in the "Interface" item in the
+ "Capture Options" dialog box. Why can no packets be sent on or
+ received from that network while I'm trying to capture traffic on that
+ interface?
+
+ A: Some versions of WinPcap have problems with PPP WAN interfaces on
+ Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003; one
+ symptom that may be seen is that attempts to capture in promiscuous
+ mode on the interface cause the interface to be incapable of sending
+ or receiving packets. You can disable promiscuous mode using the -p
+ command-line flag or the item in the "Capture Preferences" dialog box,
+ but this may mean that outgoing packets, or incoming packets, won't be
+ seen in the capture.
+
+ On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
+ NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
+ "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
+ the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
+ un-install it and install the final 3.1 release.) See the Wireshark
+ Wiki item on PPP capturing for details.
+
+ Q 8.5: I'm running Wireshark on Windows 95/98/Me, on a machine with
+ more than one network adapter of the same type; why does Wireshark
+ show all of those adapters with the same name, not letting me use any
+ of those adapters other than the first one?
+
+ A: Unfortunately, Windows 95/98/Me gives the same name to multiple
+ instances of the type of same network adapter. Therefore, WinPcap
+ cannot distinguish between them, so a WinPcap-based application can
+ capture only on the first such interface; Wireshark is a
+ libpcap/WinPcap-based application.
+
+ Q 8.6: I'm running Wireshark on Windows; why am I not seeing any
+ traffic being sent by the machine running Wireshark?
+
+ A: If you are running some form of VPN client software, it might be
+ causing this problem; people have seen this problem when they have
+ Check Point's VPN software installed on their machine. If that's the
+ cause of the problem, you will have to remove the VPN software in
+ order to have Wireshark (or any other application using WinPcap) see
+ outgoing packets; unfortunately, neither we nor the WinPcap developers
+ know any way to make WinPcap and the VPN software work well together.
+
+ Also, some drivers for Windows (especially some wireless network
+ interface drivers) apparently do not, when running in promiscuous
+ mode, arrange that outgoing packets are delivered to the software that
+ requested that the interface run promiscuously; try turning
+ promiscuous mode off.
+
+ Q 8.7: When I capture on Windows in promiscuous mode, I can see
+ packets other than those sent to or from my machine; however, those
+ packets show up with a "Short Frame" indication, unlike packets to or
+ from my machine. What should I do to arrange that I see those packets
+ in their entirety?
+
+ A: In at least some cases, this appears to be the result of PGPnet
+ running on the network interface on which you're capturing; turn it
+ off on that interface.
+
+ Q 8.8: I'm capturing packets on {Windows 95, Windows 98, Windows Me};
+ why are the time stamps on packets wrong?
+
+ A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap
+ 3.0 and later releases.
+
+ Q 8.9: I'm trying to capture 802.11 traffic on Windows; why am I not
+ seeing any packets?
A: At least some 802.11 card drivers on Windows appear not to see any
- packets if they're running in promiscuous mode. Try turning promiscuous mode
- off; you'll only be able to see packets sent by and received by your
- machine, not third-party traffic, and it'll look like Ethernet traffic and
- won't include any management or control frames, but that's a limitation of
- the card drivers.
-
- See MicroLogix's list of cards supported with WinPcap for information on
- support of various adapters and drivers with WinPcap.
-
- Q 8.10: I'm trying to capture 802.11 traffic on Windows; why am I seeing
- packets received by the machine on which I'm capturing traffic, but not
- packets sent by that machine?
-
- A: This appears to be another problem with promiscuous mode; try turning it
- off.
-
- Q 8.11: I'm trying to capture Ethernet VLAN traffic on Windows, and I'm
- capturing on a "raw" Ethernet device rather than a "VLAN interface", so that
- I can see the VLAN headers; why am I seeing packets received by the machine
- on which I'm capturing traffic, but not packets sent by that machine?
-
- A: The way the Windows networking code works probably means that packets are
- sent on a "VLAN interface" rather than the "raw" device, so packets sent by
- the machine will only be seen when you capture on the "VLAN interface". If
- so, you will be unable to see outgoing packets when capturing on the "raw"
- device, so you are stuck with a choice between seeing VLAN headers and
- seeing outgoing packets.
+ packets if they're running in promiscuous mode. Try turning
+ promiscuous mode off; you'll only be able to see packets sent by and
+ received by your machine, not third-party traffic, and it'll look like
+ Ethernet traffic and won't include any management or control frames,
+ but that's a limitation of the card drivers.
+
+ See MicroLogix's list of cards supported with WinPcap for information
+ on support of various adapters and drivers with WinPcap.
+
+ Q 8.10: I'm trying to capture 802.11 traffic on Windows; why am I
+ seeing packets received by the machine on which I'm capturing traffic,
+ but not packets sent by that machine?
+
+ A: This appears to be another problem with promiscuous mode; try
+ turning it off.
+
+ Q 8.11: I'm trying to capture Ethernet VLAN traffic on Windows, and
+ I'm capturing on a "raw" Ethernet device rather than a "VLAN
+ interface", so that I can see the VLAN headers; why am I seeing
+ packets received by the machine on which I'm capturing traffic, but
+ not packets sent by that machine?
+
+ A: The way the Windows networking code works probably means that
+ packets are sent on a "VLAN interface" rather than the "raw" device,
+ so packets sent by the machine will only be seen when you capture on
+ the "VLAN interface". If so, you will be unable to see outgoing
+ packets when capturing on the "raw" device, so you are stuck with a
+ choice between seeing VLAN headers and seeing outgoing packets.
9. Capturing packets on UN*Xes
- Q 9.1: I'm running Ethereal on a UNIX-flavored OS; why does some network
- interface on my machine not show up in the list of interfaces in the
- "Interface:" field in the dialog box popped up by "Capture->Start", and/or
- why does Ethereal give me an error if I try to capture on that interface?
-
- A: You may need to run Ethereal from an account with sufficient privileges
- to capture packets, such as the super-user account, or may need to give your
- account sufficient privileges to capture packets. Only those interfaces that
- Ethereal can open for capturing show up in that list; if you don't have
- sufficient privileges to capture on any interfaces, no interfaces will show
- up in the list. See the Wireshark Wiki item on capture privileges for details
- on how to give a particular account or account group capture privileges on
- platforms where that can be done.
-
- If you are running Ethereal from an account with sufficient privileges, then
- note that Ethereal 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, Ethereal 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 Ethereal works with libcap 0.7.2 and later.
+ Q 9.1: I'm running Wireshark on a UNIX-flavored OS; why does some
+ network interface on my machine not show up in the list of interfaces
+ in the "Interface:" field in the dialog box popped up by
+ "Capture->Start", and/or why does Wireshark give me an error if I try
+ to capture on that interface?
+
+ A: You may need to run Wireshark from an account with sufficient
+ privileges to capture packets, such as the super-user account, or may
+ need to give your account sufficient privileges to capture packets.
+ Only those interfaces that Wireshark can open for capturing show up in
+ that list; if you don't have sufficient privileges to capture on any
+ interfaces, no interfaces will show up in the list. See the Wireshark
+ Wiki item on capture privileges for details on how to give a
+ particular account or account group capture privileges on platforms
+ where that can be done.
+
+ If you are running Wireshark from an account with sufficient
+ privileges, then note that Wireshark relies on the libpcap library,
+ and on the facilities that come with the OS on which it's running in
+ order to do captures. On some OSes, those facilities aren't present by
+ default; see the Wireshark Wiki item on adding capture support for
+ details.
- 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.
+ 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.
- If the attempt to capture on it succeeds, the interface is somehow not being
- reported by the mechanism Ethereal uses to get a list of interfaces; please
- report this to wireshark-dev@wireshark.org giving full details of the problem,
- including
- * the operating system you're using, and the version of that operating
- system (for Linux, give both the version number of the kernel and the
- name and version number of the distribution you're using);
+ On Solaris, note that libpcap 0.6.2 and earlier didn't support Token
+ Ring interfaces; the current version, 0.7.2, does support Token Ring,
+ and the current version of Wireshark works with libcap 0.7.2 and
+ later.
+
+ If an interface doesn't show up in the list of interfaces in the
+ "Interface:" field, and you know the name of the interface, try
+ entering that name in the "Interface:" field and capturing on that
+ device.
+
+ If the attempt to capture on it succeeds, the interface is somehow not
+ being reported by the mechanism Wireshark uses to get a list of
+ interfaces; please report this to wireshark-dev@wireshark.org giving
+ full details of the problem, including
+ * the operating system you're using, and the version of that
+ operating system (for Linux, give both the version number of the
+ kernel and the name and version number of the distribution you're
+ using);
* the type of network device you're using.
- If you are having trouble capturing on a particular network interface, and
- you've made sure that (on platforms that require it) you've arranged that
- packet capture support is present, as per the above, first try capturing on
- that device with tcpdump.
+ If you are having trouble capturing on a particular network interface,
+ and you've made sure that (on platforms that require it) you've
+ arranged that packet capture support is present, as per the above,
+ first try capturing on that device with tcpdump.
If you can capture on the interface with tcpdump, send mail to
- wireshark-users@wireshark.org giving full details of the problem, including
- * the operating system you're using, and the version of that operating
- system (for Linux, give both the version number of the kernel and the
- name and version number of the distribution you're using);
+ wireshark-users@wireshark.org giving full details of the problem,
+ including
+ * the operating system you're using, and the version of that
+ operating system (for Linux, give both the version number of the
+ kernel and the name and version number of the distribution you're
+ using);
* the type of network device you're using;
- * the error message you get from Ethereal.
+ * the error message you get from Wireshark.
If you cannot capture on the interface with tcpdump, this is almost
certainly a problem with one or more of:
* the libpcap library;
so you should report the problem to the company or organization that
- produces the OS (in the case of a Linux distribution, report the problem to
- whoever produces the distribution).
+ produces the OS (in the case of a Linux distribution, report the
+ problem to whoever produces the distribution).
You may also want to ask the wireshark-users@wireshark.org and the
- tcpdump-workers@tcpdump.org mailing lists to see if anybody happens to know
- about the problem and know a workaround or fix for the problem. In your
- mail, please give full details of the problem, as described above, and also
- indicate that the problem occurs with tcpdump not just with Ethereal.
-
- Q 9.2: I'm running Ethereal on a UNIX-flavored OS; why do no network
- interfaces show up in the list of interfaces in the "Interface:" field in
- the dialog box popped up by "Capture->Start"?
+ tcpdump-workers@tcpdump.org mailing lists to see if anybody happens to
+ know about the problem and know a workaround or fix for the problem.
+ In your mail, please give full details of the problem, as described
+ above, and also indicate that the problem occurs with tcpdump not just
+ with Wireshark.
+
+ Q 9.2: I'm running Wireshark on a UNIX-flavored OS; why do no network
+ interfaces show up in the list of interfaces in the "Interface:" field
+ in the dialog box popped up by "Capture->Start"?
- A: This is really the same question as the previous one; see the response to
- that question.
+ A: This is really the same question as the previous one; see the
+ response to that question.
- Q 9.3: I'm capturing packets on Linux; why do the time stamps have only
- 100ms resolution, rather than 1us resolution?
+ Q 9.3: I'm capturing packets on Linux; why do the time stamps have
+ only 100ms resolution, rather than 1us resolution?
- A: Ethereal gets time stamps from libpcap/WinPcap, and libpcap/WinPcap get
- them from the OS kernel, so Ethereal - and any other program using libpcap,
- such as tcpdump - is at the mercy of the time stamping code in the OS for
- time stamps.
+ A: Wireshark gets time stamps from libpcap/WinPcap, and
+ libpcap/WinPcap get them from the OS kernel, so Wireshark - and any
+ other program using libpcap, such as tcpdump - is at the mercy of the
+ time stamping code in the OS for time stamps.
- At least on x86-based machines, Linux can get high-resolution time stamps on
- newer processors with the Time Stamp Counter (TSC) register; for example,
- Intel x86 processors, starting with the Pentium Pro, and including all x86
- processors since then, have had a TSC, and other vendors probably added the
- TSC at some point to their families of x86 processors.
+ 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.
+ The Linux kernel must be configured with the CONFIG_X86_TSC option
+ enabled in order to use the TSC. Make sure this option is enabled in
+ your kernel.
- In addition, some Linux distributions may have bugs in their versions of the
- kernel that cause packets not to be given high-resolution time stamps even
- if the TSC is enabled. See, for example, bug 61111 for Red Hat Linux 7.2. If
- your distribution has a bug such as this, you may have to run a standard
- kernel from kernel.org in order to get high-resolution time stamps.
+ In addition, some Linux distributions may have bugs in their versions
+ of the kernel that cause packets not to be given high-resolution time
+ stamps even if the TSC is enabled. See, for example, bug 61111 for Red
+ Hat Linux 7.2. If your distribution has a bug such as this, you may
+ have to run a standard kernel from kernel.org in order to get
+ high-resolution time stamps.
10. Capturing packets on wireless LANs
- Q 10.1: How can I capture raw 802.11 frames, including non-data (management,
- beacon) frames?
+ Q 10.1: How can I capture raw 802.11 frames, including non-data
+ (management, beacon) frames?
- A: That depends on the operating system on which you're running, and on the
- 802.11 interface on which you're capturing.
+ 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.
+ 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.
+ 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.
+ 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 Ethereal (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.
+ 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.
A: Whether you will be able to capture in monitor mode depends on the
operating system, adapter, and driver you're using. See the previous
- question for information on monitor mode, including a link to the Ethereal
- Wiki page that gives details on 802.11 capturing.
+ question for information on monitor mode, including a link to the
+ Wireshark Wiki page that gives details on 802.11 capturing.
11. Viewing traffic
Q 11.1: Why am I seeing lots of packets with incorrect TCP checksums?
- A: If the packets that have incorrect TCP checksums are all being sent by
- the machine on which Wireshark is running, this is probably because the
- network interface on which you're capturing does TCP checksum offloading.
- That means that the TCP checksum is added to the packet by the network
- interface, not by the OS's TCP/IP stack; when capturing on an interface,
- packets being sent by the host on which you're capturing are directly handed
- to the capture interface by the OS, which means that they are handed to the
- capture interface without a TCP checksum being added to them.
-
- The only way to prevent this from happening would be to disable TCP checksum
- offloading, but
+ A: If the packets that have incorrect TCP checksums are all being sent
+ by the machine on which Wireshark is running, this is probably because
+ the network interface on which you're capturing does TCP checksum
+ offloading. That means that the TCP checksum is added to the packet by
+ the network interface, not by the OS's TCP/IP stack; when capturing on
+ an interface, packets being sent by the host on which you're capturing
+ are directly handed to the capture interface by the OS, which means
+ that they are handed to the capture interface without a TCP checksum
+ being added to them.
+
+ The only way to prevent this from happening would be to disable TCP
+ checksum offloading, but
1. that might not even be possible on some OSes;
2. that could reduce networking performance significantly.
- However, you can disable the check that Ethereal does of the TCP checksum,
- so that it won't report any packets as having TCP checksum errors, and so
- that it won't refuse to do TCP reassembly due to a packet having an
- incorrect TCP checksum. That can be set as an Ethereal preference by
- selecting "Preferences" from the "Edit" menu, opening up the "Protocols"
- list in the left-hand pane of the "Preferences" dialog box, selecting "TCP",
- from that list, turning off the "Check the validity of the TCP checksum when
- possible" option, clicking "Save" if you want to save that setting in your
- preference file, and clicking "OK".
+ However, you can disable the check that Wireshark does of the TCP
+ checksum, so that it won't report any packets as having TCP checksum
+ errors, and so that it won't refuse to do TCP reassembly due to a
+ packet having an incorrect TCP checksum. That can be set as an
+ Wireshark preference by selecting "Preferences" from the "Edit" menu,
+ opening up the "Protocols" list in the left-hand pane of the
+ "Preferences" dialog box, selecting "TCP", from that list, turning off
+ the "Check the validity of the TCP checksum when possible" option,
+ clicking "Save" if you want to save that setting in your preference
+ file, and clicking "OK".
It can also be set on the Wireshark or TShark command line with a -o
tcp.check_checksum:false command-line flag, or manually set in your
preferences file by adding a tcp.check_checksum:false line.
- Q 11.2: I've just installed Ethereal, and the traffic on my local LAN is
- boring. Where can I find more interesting captures?
+ Q 11.2: I've just installed Wireshark, and the traffic on my local LAN
+ is boring. Where can I find more interesting captures?
A: We have a collection of strange and exotic sample capture files at
http://wiki.wireshark.org/SampleCaptures
- Q 11.3: Why doesn't Ethereal correctly identify RTP packets? It shows them
- only as UDP.
+ Q 11.3: Why doesn't Wireshark correctly identify RTP packets? It shows
+ them only as UDP.
- A: Ethereal can identify a UDP datagram as containing a packet of a
+ A: Wireshark can identify a UDP datagram as containing a packet of a
particular protocol running atop UDP only if
- 1. The protocol in question has a particular standard port number, and the
- UDP source or destination port number is that port
- 2. Packets of that protocol can be identified by looking for a "signature"
- of some type in the packet - i.e., some data that, if Ethereal finds it
- in some particular part of a packet, means that the packet is almost
- certainly a packet of that type.
- 3. Some other traffic earlier in the capture indicated that, for example,
- UDP traffic between two particular addresses and ports will be RTP
- traffic.
-
- RTP doesn't have a standard port number, so 1) doesn't work; it doesn't, as
- far as I know, have any "signature", so 2) doesn't work.
-
- That leaves 3). If there's RTSP traffic that sets up an RTP session, then,
- at least in some cases, the RTSP dissector will set things up so that
- subsequent RTP traffic will be identified. Currently, that's the only place
- we do that; there may be other places.
-
- However, there will always be places where Wireshark is simply incapable of
- deducing that a given UDP flow is RTP; a mechanism would be needed to allow
- the user to specify that a given conversation should be treated as RTP. As
- of Ethereal 0.8.16, such a mechanism exists; if you select a UDP or TCP
- packet, the right mouse button menu will have a "Decode As..." menu item,
- which will pop up a dialog box letting you specify that the source port, the
- destination port, or both the source and destination ports of the packet
- should be dissected as some particular protocol.
-
- Q 11.4: Why doesn't Ethereal show Yahoo Messenger packets in captures that
- contain Yahoo Messenger traffic?
-
- A: Ethereal only recognizes as Yahoo Messenger traffic packets to or from
- TCP port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP segments that
- start with the middle of a Yahoo Messenger packet that takes more than one
- TCP segment will not be recognized as Yahoo Messenger packets (even if the
- TCP segment also contains the beginning of another Yahoo Messenger packet).
+ 1. The protocol in question has a particular standard port number,
+ and the UDP source or destination port number is that port
+ 2. Packets of that protocol can be identified by looking for a
+ "signature" of some type in the packet - i.e., some data that, if
+ Wireshark finds it in some particular part of a packet, means that
+ the packet is almost certainly a packet of that type.
+ 3. Some other traffic earlier in the capture indicated that, for
+ example, UDP traffic between two particular addresses and ports
+ will be RTP traffic.
+
+ RTP doesn't have a standard port number, so 1) doesn't work; it
+ doesn't, as far as I know, have any "signature", so 2) doesn't work.
+
+ That leaves 3). If there's RTSP traffic that sets up an RTP session,
+ then, at least in some cases, the RTSP dissector will set things up so
+ that subsequent RTP traffic will be identified. Currently, that's the
+ only place we do that; there may be other places.
+
+ However, there will always be places where Wireshark is simply
+ incapable of deducing that a given UDP flow is RTP; a mechanism would
+ be needed to allow the user to specify that a given conversation
+ should be treated as RTP. As of Wireshark 0.8.16, such a mechanism
+ exists; if you select a UDP or TCP packet, the right mouse button menu
+ will have a "Decode As..." menu item, which will pop up a dialog box
+ letting you specify that the source port, the destination port, or
+ both the source and destination ports of the packet should be
+ dissected as some particular protocol.
+
+ Q 11.4: Why doesn't Wireshark show Yahoo Messenger packets in captures
+ that contain Yahoo Messenger traffic?
+
+ A: Wireshark only recognizes as Yahoo Messenger traffic packets to or
+ from TCP port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP
+ segments that start with the middle of a Yahoo Messenger packet that
+ takes more than one TCP segment will not be recognized as Yahoo
+ Messenger packets (even if the TCP segment also contains the beginning
+ of another Yahoo Messenger packet).
12. Filtering traffic
- Q 12.1: I saved a filter and tried to use its name to filter the display;
- why do I get an "Unexpected end of filter string" error?
+ Q 12.1: I saved a filter and tried to use its name to filter the
+ display; why do I get an "Unexpected end of filter string" error?
- A: You cannot use the name of a saved display filter as a filter. To filter
- the display, you can enter a display filter expression - not the name of a
- saved display filter - in the "Filter:" box at the bottom of the display,
- and type the key or press the "Apply" button (that does not require you to
- have a saved filter), or, if you want to use a saved filter, you can press
- the "Filter:" button, select the filter in the dialog box that pops up, and
- press the "OK" button.
+ A: You cannot use the name of a saved display filter as a filter. To
+ filter the display, you can enter a display filter expression - not
+ the name of a saved display filter - in the "Filter:" box at the
+ bottom of the display, and type the key or press the "Apply" button
+ (that does not require you to have a saved filter), or, if you want to
+ use a saved filter, you can press the "Filter:" button, select the
+ filter in the dialog box that pops up, and press the "OK" button.
- Q 12.2: How can I search for, or filter, packets that have a particular
- string anywhere in them?
+ Q 12.2: How can I search for, or filter, packets that have a
+ particular string anywhere in them?
- A: If you want to do this when capturing, you can't. That's a feature that
- would be hard to implement in capture filters without changes to the capture
- filter code, which, on many platforms, is in the OS kernel and, on other
- platforms, is in the libpcap library.
+ A: If you want to do this when capturing, you can't. That's a feature
+ that would be hard to implement in capture filters without changes to
+ the capture filter code, which, on many platforms, is in the OS kernel
+ and, on other platforms, is in the libpcap library.
- In releases prior to 0.9.14, you also can't search for, or filter, packets
- containing a particular string even after you've captured them.
+ In 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).
+ particular string; this has been added to the "Find Frame" dialog
+ ("Find Frame" under the "Edit" menu, or control-F).
In 0.9.15 and later, you can search for those packets using either the
mechanism introduced in 0.9.14 or using the new "contains" operator in
- filter expressions, which lets you search the entire packet or text string
- or byte string fields in the packet; the "contains" operator can also be
- used in expressions used to filter the display.
+ filter expressions, which lets you search the entire packet or text
+ string or byte string fields in the packet; the "contains" operator
+ can also be used in expressions used to filter the display.
Q 12.3: How do I filter a capture to see traffic for virus XXX?
- A: For some viruses/worms there might be a capture filter to recognize the
- virus traffic. Check the CaptureFilters page on the Wireshark Wiki to see if
- anybody's added such a filter.
+ 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 Ethereal 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.
+ 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.
-
- Please send support questions about Ethereal to the
- wireshark-users[AT]wireshark.org mailing list.
- For corrections/additions/suggestions for this web page (and not Ethereal
- support questions), please send email to wireshark-web[AT]wireshark.org.
- Last modified: Thu, February 23 2006.
- "Ethereal" and the "e" logo are registered trademarks of Ethereal, Inc.
INDEX
+
1. General Questions:
-1.1 What is Wireshark?
+ 1.1 What is Wireshark?
-1.2 What's up with the name change? Is Wireshark a fork?
+ 1.2 What's up with the name change? Is Wireshark a fork?
-1.3 Where can I get help?
+ 1.3 Where can I get help?
-1.4 How much does Wireshark cost?
+ 1.4 How much does Wireshark cost?
-1.5 Can I use Wireshark commercially?
+ 1.5 Can I use Wireshark commercially?
-1.6 Can I use Wireshark as part of my commercial product?
+ 1.6 Can I use Wireshark as part of my commercial product?
-1.7 What protocols are currently supported?
+ 1.7 What protocols are currently supported?
-1.8 Are there any plans to support {your favorite protocol}?
+ 1.8 Are there any plans to support {your favorite protocol}?
-1.9 Can Wireshark read capture files from {your favorite network
-analyzer}?
+ 1.9 Can Wireshark read capture files from {your favorite network
+ analyzer}?
-1.10 What devices can Wireshark use to capture packets?
+ 1.10 What devices can Wireshark use to capture packets?
-1.11 Does Wireshark work on Windows Me?
+ 1.11 Does Wireshark work on Windows Me?
-1.12 Does Wireshark work on Windows XP?
+ 1.12 Does Wireshark work on Windows XP?
2. Downloading Wireshark:
-2.1 Why do I get an error when I try to run the Win32 installer?
+ 2.1 Why do I get an error when I try to run the Win32 installer?
3. Installing Wireshark:
-3.1 I installed the Wireshark RPM (or other package); why did it
-install TShark but not Wireshark?
+ 3.1 I installed the Wireshark RPM (or other package); why did it
+ install TShark but not Wireshark?
4. Building Wireshark:
-4.1 I have libpcap installed; why did the configure script not find
-pcap.h or bpf.h?
+ 4.1 I have libpcap installed; why did the configure script not find
+ pcap.h or bpf.h?
-4.2 Why do I get the error
+ 4.2 Why do I get the error
- dftest_DEPENDENCIES was already defined in condition TRUE, which
- implies condition HAVE_PLUGINS_TRUE
+ dftest_DEPENDENCIES was already defined in condition TRUE, which
+ implies condition HAVE_PLUGINS_TRUE
-when I try to build Wireshark from SVN or a SVN snapshot?
+ when I try to build Wireshark from SVN or a SVN snapshot?
-4.3 Why does the linker fail with a number of "Output line too long."
-messages followed by linker errors when I try to buil Wireshark?
+ 4.3 Why does the linker fail with a number of "Output line too long."
+ messages followed by linker errors when I try to buil Wireshark?
-4.4 When I try to build Wireshark on Solaris, why does the link fail
-complaining that plugin_list is undefined?
+ 4.4 When I try to build Wireshark on Solaris, why does the link fail
+ complaining that plugin_list is undefined?
-4.5 When I try to build Wireshark on Windows, why does the build fail
-because of conflicts between winsock.h and winsock2.h?
+ 4.5 When I try to build Wireshark on Windows, why does the build fail
+ because of conflicts between winsock.h and winsock2.h?
5. Starting Wireshark:
-5.1 Why does Wireshark crash with a Bus Error when I try to run it on
-Solaris 8?
+ 5.1 Why does Wireshark crash with a Bus Error when I try to run it on
+ Solaris 8?
-5.2 When I run Wireshark on Windows NT, why does it die with a Dr.
-Watson error, reporting an "Integer division by zero" exception, when
-I start it?
+ 5.2 When I run Wireshark on Windows NT, why does it die with a Dr.
+ Watson error, reporting an "Integer division by zero" exception, when
+ I start it?
-5.3 When I try to run Wireshark, why does it complain about
-sprint_realloc_objid being undefined?
+ 5.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.4 When I try to run Wireshark on Windows, why does it fail to run
+ with a complaint that it can't find packet.dll?
-5.5 I've installed Wireshark from Fink on Mac OS X; why is it very
-slow to start up?
+ 5.5 I've installed Wireshark from Fink on Mac OS X; why is it very
+ slow to start up?
6. Crashes and other fatal errors:
-6.1 I have an XXX network card on my machine; if I try to capture on
-it, why does my machine crash or reset itself?
+ 6.1 I have an XXX network card on my machine; if I try to capture on
+ it, why does my machine crash or reset itself?
-6.2 Why does my machine crash or reset itself when I select "Start"
-from the "Capture" menu or select "Preferences" from the "Edit" menu?
+ 6.2 Why does my machine crash or reset itself when I select "Start"
+ from the "Capture" menu or select "Preferences" from the "Edit" menu?
7. Capturing packets:
-7.1 When I use Wireshark to capture packets, why do I see only packets
-to and from my machine, or not see all the traffic I'm expecting to
-see from or to the machine I'm trying to monitor?
+ 7.1 When I use Wireshark to capture packets, why do I see only packets
+ to and from my machine, or not see all the traffic I'm expecting to
+ see from or to the machine I'm trying to monitor?
-7.2 When I capture with Wireshark, why can't I see any TCP packets
-other than packets to and from my machine, even though another
-analyzer on the network sees those packets?
+ 7.2 When I capture with Wireshark, why can't I see any TCP packets
+ other than packets to and from my machine, even though another
+ analyzer on the network sees those packets?
-7.3 Why am I only seeing ARP packets when I try to capture traffic?
+ 7.3 Why am I only seeing ARP packets when I try to capture traffic?
-7.4 Why am I not seeing any traffic when I try to capture traffic?
+ 7.4 Why am I not seeing any traffic when I try to capture traffic?
-7.5 Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
+ 7.5 Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
-7.6 How do I put an interface into promiscuous mode?
+ 7.6 How do I put an interface into promiscuous mode?
-7.7 I can set a display filter just fine; why don't capture filters
-work?
+ 7.7 I can set a display filter just fine; why don't capture filters
+ work?
-7.8 I'm entering valid capture filters; why do I still get "parse
-error" errors?
+ 7.8 I'm entering valid capture filters; why do I still get "parse
+ error" errors?
-7.9 How can I capture packets with CRC errors?
+ 7.9 How can I capture packets with CRC errors?
-7.10 How can I capture entire frames, including the FCS?
+ 7.10 How can I capture entire frames, including the FCS?
-7.11 I'm capturing packets on a machine on a VLAN; why don't the
-packets I'm capturing have VLAN tags?
+ 7.11 I'm capturing packets on a machine on a VLAN; why don't the
+ packets I'm capturing have VLAN tags?
-7.12 Why does Wireshark hang after I stop a capture?
+ 7.12 Why does Wireshark hang after I stop a capture?
8. Capturing packets on Windows:
-8.1 I'm running Wireshark on Windows; why does some network interface
-on my machine not show up in the list of interfaces in the
-"Interface:" field in the dialog box popped up by "Capture->Start",
-and/or why does Wireshark give me an error if I try to capture on that
-interface?
-
-8.2 I'm running Wireshark on Windows; why do no network interfaces
-show up in the list of interfaces in the "Interface:" field in the
-dialog box popped up by "Capture->Start"?
-
-8.3 I'm running Wireshark on Windows; why doesn't my serial port/ADSL
-modem/ISDN modem show up in the list of interfaces in the "Interface:"
-field in the dialog box popped up by "Capture->Start"?
-
-8.4 I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows XP/
-Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN, etc.)
-interface, and it shows up in the "Interface" item in the "Capture
-Options" dialog box. Why can no packets be sent on or received from
-that network while I'm trying to capture traffic on that interface?
-
-8.5 I'm running Wireshark on Windows 95/98/Me, on a machine with more
-than one network adapter of the same type; why does Wireshark show all
-of those adapters with the same name, not letting me use any of those
-adapters other than the first one?
-
-8.6 I'm running Wireshark on Windows; why am I not seeing any traffic
-being sent by the machine running Wireshark?
-
-8.7 When I capture on Windows in promiscuous mode, I can see packets
-other than those sent to or from my machine; however, those packets
-show up with a "Short Frame" indication, unlike packets to or from my
-machine. What should I do to arrange that I see those packets in their
-entirety?
-
-8.8 I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why
-are the time stamps on packets wrong?
-
-8.9 I'm trying to capture 802.11 traffic on Windows; why am I not
-seeing any packets?
-
-8.10 I'm trying to capture 802.11 traffic on Windows; why am I seeing
-packets received by the machine on which I'm capturing traffic, but
-not packets sent by that machine?
-
-8.11 I'm trying to capture Ethernet VLAN traffic on Windows, and I'm
-capturing on a "raw" Ethernet device rather than a "VLAN interface",
-so that I can see the VLAN headers; why am I seeing packets received
-by the machine on which I'm capturing traffic, but not packets sent by
-that machine?
+ 8.1 I'm running Wireshark on Windows; why does some network interface
+ on my machine not show up in the list of interfaces in the
+ "Interface:" field in the dialog box popped up by "Capture->Start",
+ and/or why does Wireshark give me an error if I try to capture on that
+ interface?
+
+ 8.2 I'm running Wireshark on Windows; why do no network interfaces
+ show up in the list of interfaces in the "Interface:" field in the
+ dialog box popped up by "Capture->Start"?
+
+ 8.3 I'm running Wireshark on Windows; why doesn't my serial port/ADSL
+ modem/ISDN modem show up in the list of interfaces in the "Interface:"
+ field in the dialog box popped up by "Capture->Start"?
+
+ 8.4 I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows
+ XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN,
+ etc.) interface, and it shows up in the "Interface" item in the
+ "Capture Options" dialog box. Why can no packets be sent on or
+ received from that network while I'm trying to capture traffic on that
+ interface?
+
+ 8.5 I'm running Wireshark on Windows 95/98/Me, on a machine with more
+ than one network adapter of the same type; why does Wireshark show all
+ of those adapters with the same name, not letting me use any of those
+ adapters other than the first one?
+
+ 8.6 I'm running Wireshark on Windows; why am I not seeing any traffic
+ being sent by the machine running Wireshark?
+
+ 8.7 When I capture on Windows in promiscuous mode, I can see packets
+ other than those sent to or from my machine; however, those packets
+ show up with a "Short Frame" indication, unlike packets to or from my
+ machine. What should I do to arrange that I see those packets in their
+ entirety?
+
+ 8.8 I'm capturing packets on {Windows 95, Windows 98, Windows Me}; why
+ are the time stamps on packets wrong?
+
+ 8.9 I'm trying to capture 802.11 traffic on Windows; why am I not
+ seeing any packets?
+
+ 8.10 I'm trying to capture 802.11 traffic on Windows; why am I seeing
+ packets received by the machine on which I'm capturing traffic, but
+ not packets sent by that machine?
+
+ 8.11 I'm trying to capture Ethernet VLAN traffic on Windows, and I'm
+ capturing on a "raw" Ethernet device rather than a "VLAN interface",
+ so that I can see the VLAN headers; why am I seeing packets received
+ by the machine on which I'm capturing traffic, but not packets sent by
+ that machine?
9. Capturing packets on UN*Xes:
-9.1 I'm running Wireshark on a UNIX-flavored OS; why does some network
-interface on my machine not show up in the list of interfaces in the
-"Interface:" field in the dialog box popped up by "Capture->Start",
-and/or why does Wireshark give me an error if I try to capture on that
-interface?
+ 9.1 I'm running Wireshark on a UNIX-flavored OS; why does some network
+ interface on my machine not show up in the list of interfaces in the
+ "Interface:" field in the dialog box popped up by "Capture->Start",
+ and/or why does Wireshark give me an error if I try to capture on that
+ interface?
-9.2 I'm running Wireshark on a UNIX-flavored OS; why do no network
-interfaces show up in the list of interfaces in the "Interface:" field
-in the dialog box popped up by "Capture->Start"?
+ 9.2 I'm running Wireshark on a UNIX-flavored OS; why do no network
+ interfaces show up in the list of interfaces in the "Interface:" field
+ in the dialog box popped up by "Capture->Start"?
-9.3 I'm capturing packets on Linux; why do the time stamps have only
-100ms resolution, rather than 1us resolution?
+ 9.3 I'm capturing packets on Linux; why do the time stamps have only
+ 100ms resolution, rather than 1us resolution?
10. Capturing packets on wireless LANs:
-10.1 How can I capture raw 802.11 frames, including non-data
-(management, beacon) frames?
+ 10.1 How can I capture raw 802.11 frames, including non-data
+ (management, beacon) frames?
-10.2 How do I capture on an 802.11 device in monitor mode?
+ 10.2 How do I capture on an 802.11 device in monitor mode?
11. Viewing traffic:
-11.1 Why am I seeing lots of packets with incorrect TCP checksums?
+ 11.1 Why am I seeing lots of packets with incorrect TCP checksums?
-11.2 I've just installed Wireshark, and the traffic on my local LAN is
-boring. Where can I find more interesting captures?
+ 11.2 I've just installed Wireshark, and the traffic on my local LAN is
+ boring. Where can I find more interesting captures?
-11.3 Why doesn't Wireshark correctly identify RTP packets? It shows
-them only as UDP.
+ 11.3 Why doesn't Wireshark correctly identify RTP packets? It shows
+ them only as UDP.
-11.4 Why doesn't Wireshark show Yahoo Messenger packets in captures
-that contain Yahoo Messenger traffic?
+ 11.4 Why doesn't Wireshark show Yahoo Messenger packets in captures
+ that contain Yahoo Messenger traffic?
12. Filtering traffic:
-12.1 I saved a filter and tried to use its name to filter the display;
-why do I get an "Unexpected end of filter string" error?
+ 12.1 I saved a filter and tried to use its name to filter the display;
+ why do I get an "Unexpected end of filter string" error?
-12.2 How can I search for, or filter, packets that have a particular
-string anywhere in them?
+ 12.2 How can I search for, or filter, packets that have a particular
+ string anywhere in them?
-12.3 How do I filter a capture to see traffic for virus XXX?
+ 12.3 How do I filter a capture to see traffic for virus XXX?
1. General Questions
-Q 1.1: What is Wireshark?
+ Q 1.1: What is Wireshark?
-A: Gerald Combs, the creator of Ethereal®, has initiated the Wireshark
-network protocol analyzer project, a successor to Ethereal®. The
-Ethereal® core developer team has moved with Gerald to the Wireshark
-project. Consequently, Wireshark is positioned to be the world's most
-popular network protocol analyzer. It has a rich and powerful feature
-set, and runs on most computing platforms including Windows, OS X, and
-Linux. It is freely available as open source, and is released under
-the GNU General Public License.
+ A: Gerald Combs, the creator of Ethereal®, has initiated the Wireshark
+ network protocol analyzer project, a successor to Ethereal®. The
+ Ethereal® core developer team has moved with Gerald to the Wireshark
+ project. Consequently, Wireshark is positioned to be the world's most
+ popular network protocol analyzer. It has a rich and powerful feature
+ set, and runs on most computing platforms including Windows, OS X, and
+ Linux. It is freely available as open source, and is released under
+ the GNU General Public License.
-For more information, please see the About Wireshark page.
+ For more information, please see the About Wireshark page.
-Q 1.2: What's up with the name change? Is Wireshark a fork?
+ Q 1.2: What's up with the name change? Is Wireshark a fork?
-A: In May of 2006, the original author of Ethereal® went to work for
-CACE Technologies (best known for WinPcap). At that time he started
-the Wireshark open-source project.
-
-Wireshark is almost (but not quite) a fork. Normally a "fork" of an
-open source project results in two names, web sites, development
-teams, support infrastructures, etc. This is the case with Wireshark
-except for one notable exception -- every member of the core
-development team is now working on Wireshark.
-
-Q 1.3: Where can I get help?
-
-A: Community support is available on the wireshark-users mailing list.
-Subscription information and archives for all of Wireshark's mailing
-lists can be found at http://www.wireshark.org/lists. An IRC channel
-dedicated to Wireshark can be found at irc://irc.freenode.net/ethereal
-.
-
-Commercial support, training, and development services are available
-from CACE Technologies.
-
-Q 1.4: How much does Wireshark cost?
-
-A: Wireshark is "free software"; you can download it without paying
-any license fee. The version of Wireshark you download isn't a "demo"
-version, with limitations not present in a "full" version; it is the
-full version.
-
-The license under which Wireshark is issued is the GNU General Public
-License. See the GNU GPL FAQ for some more information.
-
-Q 1.5: Can I use Wireshark commercially?
-
-A: Yes, if, for example, you mean "I work for a commercial
-organization; can I use Wireshark to capture and analyze network
-traffic in our company's networks or in our customer's networks?"
-
-If you mean "Can I use Wireshark as part of my commercial product?",
-see the next entry in the FAQ.
-
-Q 1.6: Can I use Wireshark as part of my commercial product?
-
-A: As noted, Wireshark is licensed under the GNU General Public
-License. The GPL imposes conditions on your use of GPL'ed code in your
-own products; you cannot, for example, make a "derived work" from
-Wireshark, by making modifications to it, and then sell the resulting
-derived work and not allow recipients to give away the resulting work.
-You must also make the changes you've made to the Wireshark source
-available to all recipients of your modified version; those changes
-must also be licensed under the terms of the GPL. See the GPL FAQ for
-more details; in particular, note the answer to the question about
-modifying a GPLed program and selling it commercially, and the
-question about linking GPLed code with other code to make a
-proprietary program.
-
-You can combine a GPLed program such as Wireshark and a commercial
-program as long as they communicate "at arm's length", as per this
-item in the GPL FAQ.
-
-Q 1.7: What protocols are currently supported?
-
-A: There are currently hundreds of supported protocols and media.
-Details can be found in the wireshark(1) man page.
-
-Q 1.8: Are there any plans to support {your favorite protocol}?
-
-A: Support for particular protocols is added to Wireshark as a result
-of people contributing that support; no formal plans for adding
-support for particular protocols in particular future releases exist.
-
-Q 1.9: Can Wireshark read capture files from {your favorite network
-analyzer}?
-
-A: Support for particular protocols is added to Wireshark as a result
-of people contributing that support; no formal plans for adding
-support for particular protocols in particular future releases exist.
-
-If a network analyzer writes out files in a format already supported
-by Wireshark (e.g., in libpcap format), Wireshark may already be able
-to read them, unless the analyzer has added its own proprietary
-extensions to that format.
-
-If a network analyzer writes out files in its own format, or has added
-proprietary extensions to another format, in order to make Wireshark
-read captures from that network analyzer, we would either have to have
-a specification for the file format, or the extensions, sufficient to
-give us enough information to read the parts of the file relevant to
-Wireshark, or would need at least one capture file in that format AND
-a detailed textual analysis of the packets in that capture file
-(showing packet time stamps, packet lengths, and the top-level packet
-header) in order to reverse-engineer the file format.
-
-Note that there is no guarantee that we will be able to
-reverse-engineer a capture file format.
-
-Q 1.10: What devices can Wireshark use to capture packets?
-
-A: Wireshark can read live data from Ethernet, Token-Ring, FDDI,
-serial (PPP and SLIP) (if the OS on which it's running allows
-Wireshark to do so), 802.11 wireless LAN (if the OS on which it's
-running allows Wireshark to do so), ATM connections (if the OS on
-which it's running allows Wireshark to do so), and the "any" device
-supported on Linux by recent versions of libpcap. See the list of
-supported capture media on various OSes for details (several items in
-there say "Unknown", which doesn't mean "Wireshark can't capture on
-them", it means "we don't know whether it can capture on them"; we
-expect that it will be able to capture on many of them, but we haven't
-tried it ourselves - if you try one of those types and it works,
-please send an update to ).
-
-It can also read a variety of capture file formats, including:
-
- • AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet
- Grabber captures
- • AIX's iptrace captures
- • Accellent's 5Views LAN agent output
- • Cinco Networks NetXRay captures
- • Cisco Secure Intrusion Detection System IPLog output
- • CoSine L2 debug output
- • DBS Etherwatch VMS text output
- • Endace Measurement Systems' ERF format captures
- • EyeSDN USB S0 traces
- • HP-UX nettl captures
- • ISDN4BSD project i4btrace captures
- • Linux Bluez Bluetooth stack hcidump -w traces
- • Lucent/Ascend router debug output
- • Microsoft Network Monitor captures
- • Network Associates Windows-based Sniffer captures
- • Network General/Network Associates DOS-based Sniffer (compressed
- or uncompressed) captures
- • Network Instruments Observer version 9 captures
- • Novell LANalyzer captures
- • RADCOM's WAN/LAN analyzer captures
- • Shomiti/Finisar Surveyor captures
- • Toshiba's ISDN routers dump output
- • VMS TCPIPtrace/TCPtrace/UCX$TRACE output
- • Visual Networks' Visual UpTime traffic capture
- • libpcap, tcpdump and various other tools using tcpdump's capture
- format
- • snoop and atmsnoop output
-
-so that it can read traces from various network types, as captured by
-other applications or equipment, even if it cannot itself capture on
-those network types.
-
-Q 1.11: Does Wireshark work on Windows Me?
-
-A: Yes, but if you want to capture packets, you will need to install
-the latest version of WinPcap, as 2.02 and earlier versions of WinPcap
-didn't support Windows Me. You should also install the latest version
-of Wireshark as well.
-
-Q 1.12: Does Wireshark work on Windows XP?
-
-A: Yes, but if you want to capture packets, you will need to install
-the latest version of WinPcap, as 2.2 and earlier versions of WinPcap
-didn't support Windows XP.
+ A: In May of 2006, the original author of Ethereal® went to work for
+ CACE Technologies (best known for WinPcap). At that time he started
+ the Wireshark open-source project.
+
+ Wireshark is almost (but not quite) a fork. Normally a "fork" of an
+ open source project results in two names, web sites, development
+ teams, support infrastructures, etc. This is the case with Wireshark
+ except for one notable exception -- every member of the core
+ development team is now working on Wireshark.
+
+ Q 1.3: Where can I get help?
+
+ A: Community support is available on the wireshark-users mailing list.
+ Subscription information and archives for all of Wireshark's mailing
+ lists can be found at http://www.wireshark.org/lists. An IRC channel
+ dedicated to Wireshark can be found at
+ irc://irc.freenode.net/ethereal.
+
+ Commercial support, training, and development services are available
+ from CACE Technologies.
+
+ Q 1.4: How much does Wireshark cost?
+
+ A: Wireshark is "free software"; you can download it without paying
+ any license fee. The version of Wireshark you download isn't a "demo"
+ version, with limitations not present in a "full" version; it is the
+ full version.
+
+ The license under which Wireshark is issued is the GNU General Public
+ License. See the GNU GPL FAQ for some more information.
+
+ Q 1.5: Can I use Wireshark commercially?
+
+ A: Yes, if, for example, you mean "I work for a commercial
+ organization; can I use Wireshark to capture and analyze network
+ traffic in our company's networks or in our customer's networks?"
+
+ If you mean "Can I use Wireshark as part of my commercial product?",
+ see the next entry in the FAQ.
+
+ Q 1.6: Can I use Wireshark as part of my commercial product?
+
+ A: As noted, Wireshark is licensed under the GNU General Public
+ License. The GPL imposes conditions on your use of GPL'ed code in your
+ own products; you cannot, for example, make a "derived work" from
+ Wireshark, by making modifications to it, and then sell the resulting
+ derived work and not allow recipients to give away the resulting work.
+ You must also make the changes you've made to the Wireshark source
+ available to all recipients of your modified version; those changes
+ must also be licensed under the terms of the GPL. See the GPL FAQ for
+ more details; in particular, note the answer to the question about
+ modifying a GPLed program and selling it commercially, and the
+ question about linking GPLed code with other code to make a
+ proprietary program.
+
+ You can combine a GPLed program such as Wireshark and a commercial
+ program as long as they communicate "at arm's length", as per this
+ item in the GPL FAQ.
+
+ Q 1.7: What protocols are currently supported?
+
+ A: There are currently hundreds of supported protocols and media.
+ Details can be found in the wireshark(1) man page.
+
+ Q 1.8: Are there any plans to support {your favorite protocol}?
+
+ A: Support for particular protocols is added to Wireshark as a result
+ of people contributing that support; no formal plans for adding
+ support for particular protocols in particular future releases exist.
+
+ Q 1.9: Can Wireshark read capture files from {your favorite network
+ analyzer}?
+
+ A: Support for particular protocols is added to Wireshark as a result
+ of people contributing that support; no formal plans for adding
+ support for particular protocols in particular future releases exist.
+
+ If a network analyzer writes out files in a format already supported
+ by Wireshark (e.g., in libpcap format), Wireshark may already be able
+ to read them, unless the analyzer has added its own proprietary
+ extensions to that format.
+
+ If a network analyzer writes out files in its own format, or has added
+ proprietary extensions to another format, in order to make Wireshark
+ read captures from that network analyzer, we would either have to have
+ a specification for the file format, or the extensions, sufficient to
+ give us enough information to read the parts of the file relevant to
+ Wireshark, or would need at least one capture file in that format AND
+ a detailed textual analysis of the packets in that capture file
+ (showing packet time stamps, packet lengths, and the top-level packet
+ header) in order to reverse-engineer the file format.
+
+ Note that there is no guarantee that we will be able to
+ reverse-engineer a capture file format.
+
+ Q 1.10: What devices can Wireshark use to capture packets?
+
+ A: Wireshark can read live data from Ethernet, Token-Ring, FDDI,
+ serial (PPP and SLIP) (if the OS on which it's running allows
+ Wireshark to do so), 802.11 wireless LAN (if the OS on which it's
+ running allows Wireshark to do so), ATM connections (if the OS on
+ which it's running allows Wireshark to do so), and the "any" device
+ supported on Linux by recent versions of libpcap. See the list of
+ supported capture media on various OSes for details (several items in
+ there say "Unknown", which doesn't mean "Wireshark can't capture on
+ them", it means "we don't know whether it can capture on them"; we
+ expect that it will be able to capture on many of them, but we haven't
+ tried it ourselves - if you try one of those types and it works,
+ please send an update to ).
+
+ It can also read a variety of capture file formats, including:
+ * AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet
+ Grabber captures
+ * AIX's iptrace captures
+ * Accellent's 5Views LAN agent output
+ * Cinco Networks NetXRay captures
+ * Cisco Secure Intrusion Detection System IPLog output
+ * CoSine L2 debug output
+ * DBS Etherwatch VMS text output
+ * Endace Measurement Systems' ERF format captures
+ * EyeSDN USB S0 traces
+ * HP-UX nettl captures
+ * ISDN4BSD project i4btrace captures
+ * Linux Bluez Bluetooth stack hcidump -w traces
+ * Lucent/Ascend router debug output
+ * Microsoft Network Monitor captures
+ * Network Associates Windows-based Sniffer captures
+ * Network General/Network Associates DOS-based Sniffer (compressed
+ or uncompressed) captures
+ * Network Instruments Observer version 9 captures
+ * Novell LANalyzer captures
+ * RADCOM's WAN/LAN analyzer captures
+ * Shomiti/Finisar Surveyor captures
+ * Toshiba's ISDN routers dump output
+ * VMS TCPIPtrace/TCPtrace/UCX$TRACE output
+ * Visual Networks' Visual UpTime traffic capture
+ * libpcap, tcpdump and various other tools using tcpdump's capture
+ format
+ * snoop and atmsnoop output
+
+ so that it can read traces from various network types, as captured by
+ other applications or equipment, even if it cannot itself capture on
+ those network types.
+
+ Q 1.11: Does Wireshark work on Windows Me?
+
+ A: Yes, but if you want to capture packets, you will need to install
+ the latest version of WinPcap, as 2.02 and earlier versions of WinPcap
+ didn't support Windows Me. You should also install the latest version
+ of Wireshark as well.
+
+ Q 1.12: Does Wireshark work on Windows XP?
+
+ A: Yes, but if you want to capture packets, you will need to install
+ the latest version of WinPcap, as 2.2 and earlier versions of WinPcap
+ didn't support Windows XP.
2. Downloading Wireshark
-Q 2.1: Why do I get an error when I try to run the Win32 installer?
+ 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.
+ A: The program you used to download it may have downloaded it
+ incorrectly. Web browsers sometimes may do this.
-Try downloading it with, for example:
+ Try downloading it with, for example:
+ * Wget, for which Windows binaries are available on the SunSITE FTP
+ server at sunsite.tk or Heiko Herold's windows wget spot - wGetGUI
+ offers a GUI interface that uses wget;
+ * WS_FTP from Ipswitch,
+ * the ftp command that comes with Windows.
- • Wget, for which Windows binaries are available on the SunSITE FTP
- server at sunsite.tk or Heiko Herold's windows wget spot - wGetGUI
- offers a GUI interface that uses wget;
- • WS_FTP from Ipswitch,
- • the ftp command that comes with Windows.
-
-If you use the ftp command, make sure you do the transfer in binary
-mode rather than ASCII mode, by using the binary command before
-transferring the file.
+ If you use the ftp command, make sure you do the transfer in binary
+ mode rather than ASCII mode, by using the binary command before
+ transferring the file.
3. Installing Wireshark
-Q 3.1: I installed the Wireshark RPM (or other package); why did it
-install TShark but not Wireshark?
+ Q 3.1: I installed the Wireshark RPM (or other package); why did it
+ install TShark but not Wireshark?
-A: Many distributions have separate Wireshark packages, one for
-non-GUI components such as TShark, editcap, dumpcap, etc. and one for
-the GUI. If this is the case on your system, there's probably a
-separate package named wireshark-gnome or wireshark-gtk+. Find it and
-install it.
+ A: Many distributions have separate Wireshark packages, one for
+ non-GUI components such as TShark, editcap, dumpcap, etc. and one for
+ the GUI. If this is the case on your system, there's probably a
+ separate package named wireshark-gnome or wireshark-gtk+. Find it and
+ install it.
4. Building Wireshark
-Q 4.1: I have libpcap installed; why did the configure script not find
-pcap.h or bpf.h?
-
-A: Are you sure pcap.h and bpf.h are installed? The official
-distribution of libpcap only installs the libpcap.a library file when
-"make install" is run. To install pcap.h and bpf.h, you must run "make
-install-incl". If you're running Debian or Redhat, make sure you have
-the "libpcap-dev" or "libpcap-devel" packages installed.
-
-It's also possible that pcap.h and bpf.h have been installed in a
-strange location. If this is the case, you may have to tweak
-aclocal.m4.
-
-Q 4.2: Why do I get the error
-
- dftest_DEPENDENCIES was already defined in condition TRUE, which
- implies condition HAVE_PLUGINS_TRUE
-
-when I try to build Wireshark from SVN or a SVN snapshot?
-
-A: You probably have automake 1.5 installed on your machine (the
-command automake --version will report the version of automake on your
-machine). There is a bug in that version of automake that causes this
-problem; upgrade to a later version of automake (1.6 or later).
-
-Q 4.3: Why does the linker fail with a number of "Output line too
-long." messages followed by linker errors when I try to buil
-Wireshark?
-
-A: The version of the sed command on your system is incapable of
-handling very long lines. On Solaris, for example, /usr/bin/sed has a
-line length limit too low to allow libtool to work; /usr/xpg4/bin/sed
-can handle it, as can GNU sed if you have it installed.
-
-On Solaris, changing your command search path to search /usr/xpg4/bin
-before /usr/bin should make the problem go away; on any platform on
-which you have this problem, installing GNU sed and changing your
-command path to search the directory in which it is installed before
-searching the directory with the version of sed that came with the OS
-should make the problem go away.
-
-Q 4.4: When I try to build Wireshark on Solaris, why does the link
-fail complaining that plugin_list is undefined?
-
-A: This appears to be due to a problem with some versions of the GTK+
-and GLib packages from www.sunfreeware.org; un-install those packages,
-and try getting the 1.2.10 versions from that site, or the versions
-from The Written Word, or the versions from Sun's GNOME distribution,
-or the versions from the supplemental software CD that comes with the
-Solaris media kit, or build them from source from the GTK Web site.
-Then re-run the configuration script, and try rebuilding Wireshark.
-(If you get the 1.2.10 versions from www.sunfreeware.org, and the
-problem persists, un-install them and try installing one of the other
-versions mentioned.)
-
-Q 4.5: When I try to build Wireshark on Windows, why does the build
-fail because of conflicts between winsock.h and winsock2.h?
-
-A: As of Wireshark 0.9.5, you must install WinPcap 2.3 or later, and
-the corresponding version of the developer's pack, in order to be able
-to compile Wireshark; it will not compile with older versions of the
-developer's pack. The symptoms of this failure are conflicts between
-definitions in winsock.h and in winsock2.h; Wireshark uses winsock2.h,
-but pre-2.3 versions of the WinPcap developer's packet use winsock.h.
-(2.3 uses winsock2.h, so if Wireshark were to use winsock.h, it would
-not be able to build with current versions of the WinPcap developer's
-pack.)
-
-Note that the installed version of the developer's pack should be the
-same version as the version of WinPcap you have installed.
+ Q 4.1: I have libpcap installed; why did the configure script not find
+ pcap.h or bpf.h?
+
+ A: Are you sure pcap.h and bpf.h are installed? The official
+ distribution of libpcap only installs the libpcap.a library file when
+ "make install" is run. To install pcap.h and bpf.h, you must run "make
+ install-incl". If you're running Debian or Redhat, make sure you have
+ the "libpcap-dev" or "libpcap-devel" packages installed.
+
+ It's also possible that pcap.h and bpf.h have been installed in a
+ strange location. If this is the case, you may have to tweak
+ aclocal.m4.
+
+ Q 4.2: Why do I get the error
+
+ dftest_DEPENDENCIES was already defined in condition TRUE, which
+ implies condition HAVE_PLUGINS_TRUE
+
+ when I try to build Wireshark from SVN or a SVN snapshot?
+
+ A: You probably have automake 1.5 installed on your machine (the
+ command automake --version will report the version of automake on your
+ machine). There is a bug in that version of automake that causes this
+ problem; upgrade to a later version of automake (1.6 or later).
+
+ Q 4.3: Why does the linker fail with a number of "Output line too
+ long." messages followed by linker errors when I try to buil
+ Wireshark?
+
+ A: The version of the sed command on your system is incapable of
+ handling very long lines. On Solaris, for example, /usr/bin/sed has a
+ line length limit too low to allow libtool to work; /usr/xpg4/bin/sed
+ can handle it, as can GNU sed if you have it installed.
+
+ On Solaris, changing your command search path to search /usr/xpg4/bin
+ before /usr/bin should make the problem go away; on any platform on
+ which you have this problem, installing GNU sed and changing your
+ command path to search the directory in which it is installed before
+ searching the directory with the version of sed that came with the OS
+ should make the problem go away.
+
+ Q 4.4: When I try to build Wireshark on Solaris, why does the link
+ fail complaining that plugin_list is undefined?
+
+ A: This appears to be due to a problem with some versions of the GTK+
+ and GLib packages from www.sunfreeware.org; un-install those packages,
+ and try getting the 1.2.10 versions from that site, or the versions
+ from The Written Word, or the versions from Sun's GNOME distribution,
+ or the versions from the supplemental software CD that comes with the
+ Solaris media kit, or build them from source from the GTK Web site.
+ Then re-run the configuration script, and try rebuilding Wireshark.
+ (If you get the 1.2.10 versions from www.sunfreeware.org, and the
+ problem persists, un-install them and try installing one of the other
+ versions mentioned.)
+
+ Q 4.5: When I try to build Wireshark on Windows, why does the build
+ fail because of conflicts between winsock.h and winsock2.h?
+
+ A: As of Wireshark 0.9.5, you must install WinPcap 2.3 or later, and
+ the corresponding version of the developer's pack, in order to be able
+ to compile Wireshark; it will not compile with older versions of the
+ developer's pack. The symptoms of this failure are conflicts between
+ definitions in winsock.h and in winsock2.h; Wireshark uses winsock2.h,
+ but pre-2.3 versions of the WinPcap developer's packet use winsock.h.
+ (2.3 uses winsock2.h, so if Wireshark were to use winsock.h, it would
+ not be able to build with current versions of the WinPcap developer's
+ pack.)
+
+ Note that the installed version of the developer's pack should be the
+ same version as the version of WinPcap you have installed.
5. Starting Wireshark
-Q 5.1: Why does Wireshark crash with a Bus Error when I try to run it
-on Solaris 8?
-
-A: Some versions of the GTK+ library from www.sunfreeware.org appear
-to be buggy, causing Wireshark to drop core with a Bus Error.
-Un-install those packages, and try getting the 1.2.10 version from
-that site, or the version from The Written Word, or the version from
-Sun's GNOME distribution, or the version from the supplemental
-software CD that comes with the Solaris media kit, or build it from
-source from the GTK Web site. Update the GLib library to the 1.2.10
-version, from the same source, as well. (If you get the 1.2.10
-versions from www.sunfreeware.org, and the problem persists,
-un-install them and try installing one of the other versions
-mentioned.)
-
-Similar problems may exist with older versions of GTK+ for earlier
-versions of Solaris.
-
-Q 5.2: When I run Wireshark on Windows NT, why does it die with a Dr.
-Watson error, reporting an "Integer division by zero" exception, when
-I start it?
-
-A: In at least some case, this appears to be due to using the default
-VGA driver; if that's not the correct driver for your video card, try
-running the correct driver for your video card.
-
-Q 5.3: When I try to run Wireshark, why does it complain about
-sprint_realloc_objid being undefined?
-
-A: Wireshark can only be linked with version 4.2.2 or later of UCD
-SNMP. Your version of Wireshark was dynamically linked with such a
-version of UCD SNMP; however, you have an older version of UCD SNMP
-installed, which means that when Wireshark is run, it tries to link to
-the older version, and fails. You will have to replace that version of
-UCD SNMP with version 4.2.2 or a later version.
-
-Q 5.4: When I try to run Wireshark on Windows, why does it fail to run
-with a complaint that it can't find packet.dll?
-
-A: In older versions of Wireshark, there were two binary distributions
-available for Windows, one that supported capturing packets, and one
-that didn't. The version that supported capturing packets required
-that you install the WinPcap driver; if you didn't install it, it
-would fail to run because it couldn't find packet.dll.
-
-The current version of Wireshark has only one binary distribution for
-Windows; that version will check whether WinPcap is installed and, if
-it's not, will disable support for packet capture.
-
-The WinPcap driver and libraries can be downloaded from the WinPcap
-Web site or the Wiretapped.net mirror of the WinPcap site.
-
-Q 5.5: I've installed Wireshark from Fink on Mac OS X; why is it very
-slow to start up?
-
-A: When an application is installed on OS X, prior to 10.4, it is
-usually "prebound" to speed up launching the application. (That's what
-the "Optimizing" phase of installation is.) Fink normally performs
-prebinding automatically when you install a package. However, in some
-rare cases, for whatever reason the prebinding caches get corrupt, and
-then not only does prebinding fail, but startup actually becomes much
-slower, because the system tries in vain to perform prebinding "on the
-fly" as you launch the application. This fails, causing sometimes huge
-delays. To fix the prebinding caches, run the command
-
+ Q 5.1: Why does Wireshark crash with a Bus Error when I try to run it
+ on Solaris 8?
+
+ A: Some versions of the GTK+ library from www.sunfreeware.org appear
+ to be buggy, causing Wireshark to drop core with a Bus Error.
+ Un-install those packages, and try getting the 1.2.10 version from
+ that site, or the version from The Written Word, or the version from
+ Sun's GNOME distribution, or the version from the supplemental
+ software CD that comes with the Solaris media kit, or build it from
+ source from the GTK Web site. Update the GLib library to the 1.2.10
+ version, from the same source, as well. (If you get the 1.2.10
+ versions from www.sunfreeware.org, and the problem persists,
+ un-install them and try installing one of the other versions
+ mentioned.)
+
+ Similar problems may exist with older versions of GTK+ for earlier
+ versions of Solaris.
+
+ Q 5.2: When I run Wireshark on Windows NT, why does it die with a Dr.
+ Watson error, reporting an "Integer division by zero" exception, when
+ I start it?
+
+ A: In at least some case, this appears to be due to using the default
+ VGA driver; if that's not the correct driver for your video card, try
+ running the correct driver for your video card.
+
+ Q 5.3: When I try to run Wireshark, why does it complain about
+ sprint_realloc_objid being undefined?
+
+ A: Wireshark can only be linked with version 4.2.2 or later of UCD
+ SNMP. Your version of Wireshark was dynamically linked with such a
+ version of UCD SNMP; however, you have an older version of UCD SNMP
+ installed, which means that when Wireshark is run, it tries to link to
+ the older version, and fails. You will have to replace that version of
+ UCD SNMP with version 4.2.2 or a later version.
+
+ Q 5.4: When I try to run Wireshark on Windows, why does it fail to run
+ with a complaint that it can't find packet.dll?
+
+ A: In older versions of Wireshark, there were two binary distributions
+ available for Windows, one that supported capturing packets, and one
+ that didn't. The version that supported capturing packets required
+ that you install the WinPcap driver; if you didn't install it, it
+ would fail to run because it couldn't find packet.dll.
+
+ The current version of Wireshark has only one binary distribution for
+ Windows; that version will check whether WinPcap is installed and, if
+ it's not, will disable support for packet capture.
+
+ The WinPcap driver and libraries can be downloaded from the WinPcap
+ Web site or the Wiretapped.net mirror of the WinPcap site.
+
+ Q 5.5: I've installed Wireshark from Fink on Mac OS X; why is it very
+ slow to start up?
+
+ A: When an application is installed on OS X, prior to 10.4, it is
+ usually "prebound" to speed up launching the application. (That's what
+ the "Optimizing" phase of installation is.) Fink normally performs
+ prebinding automatically when you install a package. However, in some
+ rare cases, for whatever reason the prebinding caches get corrupt, and
+ then not only does prebinding fail, but startup actually becomes much
+ slower, because the system tries in vain to perform prebinding "on the
+ fly" as you launch the application. This fails, causing sometimes huge
+ delays. To fix the prebinding caches, run the command
sudo /sw/var/lib/fink/prebound/update-package-prebinding.pl -f
6. Crashes and other fatal errors
-Q 6.1: I have an XXX network card on my machine; if I try to capture
-on it, why does my machine crash or reset itself?
-
-A: This is almost certainly a problem with one or more of:
-
- • the operating system you're using;
- • the device driver for the interface you're using;
- • the libpcap/WinPcap library and, if this is Windows, the WinPcap
- device driver;
-
-so:
-
- • if you are using Windows, see the WinPcap support page - check the
- "Submitting bugs" section;
- • if you are using some Linux distribution, some version of BSD, or
- some other UNIX-flavored OS, you should report the problem to the
- company or organization that produces the OS (in the case of a
- Linux distribution, report the problem to whoever produces the
- distribution).
-
-Q 6.2: Why does my machine crash or reset itself when I select "Start"
-from the "Capture" menu or select "Preferences" from the "Edit" menu?
-
-A: Both of those operations cause Wireshark to try to build a list of
-the interfaces that it can open; it does so by getting a list of
-interfaces and trying to open them. There is probably an OS, driver,
-or, for Windows, WinPcap bug that causes the system to crash when this
-happens; see the previous question.
+ Q 6.1: I have an XXX network card on my machine; if I try to capture
+ on it, why does my machine crash or reset itself?
+
+ A: This is almost certainly a problem with one or more of:
+ * the operating system you're using;
+ * the device driver for the interface you're using;
+ * the libpcap/WinPcap library and, if this is Windows, the WinPcap
+ device driver;
+
+ so:
+ * if you are using Windows, see the WinPcap support page - check the
+ "Submitting bugs" section;
+ * if you are using some Linux distribution, some version of BSD, or
+ some other UNIX-flavored OS, you should report the problem to the
+ company or organization that produces the OS (in the case of a
+ Linux distribution, report the problem to whoever produces the
+ distribution).
+
+ Q 6.2: Why does my machine crash or reset itself when I select "Start"
+ from the "Capture" menu or select "Preferences" from the "Edit" menu?
+
+ A: Both of those operations cause Wireshark to try to build a list of
+ the interfaces that it can open; it does so by getting a list of
+ interfaces and trying to open them. There is probably an OS, driver,
+ or, for Windows, WinPcap bug that causes the system to crash when this
+ happens; see the previous question.
7. Capturing packets
-Q 7.1: When I use Wireshark to capture packets, why do I see only
-packets to and from my machine, or not see all the traffic I'm
-expecting to see from or to the machine I'm trying to monitor?
-
-A: This might be because the interface on which you're capturing is
-plugged into an Ethernet or Token Ring switch; on a switched network,
-unicast traffic between two ports will not necessarily appear on other
-ports - only broadcast and multicast traffic will be sent to all
-ports.
-
-Note that even if your machine is plugged into a hub, the "hub" may be
-a switched hub, in which case you're still on a switched network.
-
-Note also that on the Linksys Web site, they say that their
-auto-sensing hubs "broadcast the 10Mb packets to the port that operate
-at 10Mb only and broadcast the 100Mb packets to the ports that operate
-at 100Mb only", which would indicate that if you sniff on a 10Mb port,
-you will not see traffic coming sent to a 100Mb port, and vice versa.
-This problem has also been reported for Netgear dual-speed hubs, and
-may exist for other "auto-sensing" or "dual-speed" hubs.
-
-Some switches have the ability to replicate all traffic on all ports
-to a single port so that you can plug your analyzer into that single
-port to sniff all traffic. You would have to check the documentation
-for the switch to see if this is possible and, if so, to see how to do
-this. See the switch reference page on the Wireshark Wiki for
-information on some switches. (Note that it's a Wiki, so you can
-update or fix that information, or add additional information on those
-switches or information on new switches, yourself.)
-
-Note also that many firewall/NAT boxes have a switch built into them;
-this includes many of the "cable/DSL router" boxes. If you have a box
-of that sort, that has a switch with some number of Ethernet ports
-into which you plug machines on your network, and another Ethernet
-port used to connect to a cable or DSL modem, you can, at least, sniff
-traffic between the machines on your network and the Internet by
-plugging the Ethernet port on the router going to the modem, the
-Ethernet port on the modem, and the machine on which you're running
-Wireshark into a hub (make sure it's not a switching hub, and that, if
-it's a dual-speed hub, all three of those ports are running at the
-same speed.
-
-If your machine is not plugged into a switched network or a dual-speed
-hub, or it is plugged into a switched network but the port is set up
-to have all traffic replicated to it, the problem might be that the
-network interface on which you're capturing doesn't support
-"promiscuous" mode, or because your OS can't put the interface into
-promiscuous mode. Normally, network interfaces supply to the host
-only:
-
- • packets sent to one of that host's link-layer addresses;
- • broadcast packets;
- • multicast packets sent to a multicast address that the host has
- configured the interface to accept.
-
-Most network interfaces can also be put in "promiscuous" mode, in
-which they supply to the host all network packets they see. Wireshark
-will try to put the interface on which it's capturing into promiscuous
-mode unless the "Capture packets in promiscuous mode" option is turned
-off in the "Capture Options" dialog box, and TShark will try to put
-the interface on which it's capturing into promiscuous mode unless the
--p option was specified. However, some network interfaces don't
-support promiscuous mode, and some OSes might not allow interfaces to
-be put into promiscuous mode.
-
-If the interface is not running in promiscuous mode, it won't see any
-traffic that isn't intended to be seen by your machine. It will see
-broadcast packets, and multicast packets sent to a multicast MAC
-address the interface is set up to receive.
-
-You should ask the vendor of your network interface whether it
-supports promiscuous mode. If it does, you should ask whoever supplied
-the driver for the interface (the vendor, or the supplier of the OS
-you're running on your machine) whether it supports promiscuous mode
-with that network interface.
-
-In the case of token ring interfaces, the drivers for some of them, on
-Windows, may require you to enable promiscuous mode in order to
-capture in promiscuous mode. See the Wireshark Wiki item on Token Ring
-capturing for details.
-
-In the case of wireless LAN interfaces, it appears that, when those
-interfaces are promiscuously sniffing, they're running in a
-significantly different mode from the mode that they run in when
-they're just acting as network interfaces (to the extent that it would
-be a significant effor for those drivers to support for promiscuously
-sniffing and acting as regular network interfaces at the same time),
-so it may be that Windows drivers for those interfaces don't support
-promiscuous mode.
-
-Q 7.2: When I capture with Wireshark, why can't I see any TCP packets
-other than packets to and from my machine, even though another
-analyzer on the network sees those packets?
-
-A: You're probably not seeing any packets other than unicast packets
-to or from your machine, and broadcast and multicast packets; a switch
-will normally send to a port only unicast traffic sent to the MAC
-address for the interface on that port, and broadcast and multicast
-traffic - it won't send to that port unicast traffic sent to a MAC
-address for some other interface - and a network interface not in
-promiscuous mode will receive only unicast traffic sent to the MAC
-address for that interface, broadcast traffic, and multicast traffic
-sent to a multicast MAC address the interface is set up to receive.
-
-TCP doesn't use broadcast or multicast, so you will only see your own
-TCP traffic, but UDP services may use broadcast or multicast so you'll
-see some UDP traffic - however, this is not a problem with TCP
-traffic, it's a problem with unicast traffic, as you also won't see
-all UDP traffic between other machines.
-
-I.e., this is probably the same question as this earlier one; see the
-response to that question.
-
-Q 7.3: Why am I only seeing ARP packets when I try to capture traffic?
-
-A: You're probably on a switched network, and running Wireshark on a
-machine that's not sending traffic to the switch and not being sent
-any traffic from other machines on the switch. ARP packets are often
-broadcast packets, which are sent to all switch ports.
-
-I.e., this is probably the same question as this earlier one; see the
-response to that question.
-
-Q 7.4: Why am I not seeing any traffic when I try to capture traffic?
-
-A: Is the machine running Wireshark sending out any traffic on the
-network interface on which you're capturing, or receiving any traffic
-on that network, or is there any broadcast traffic on the network or
-multicast traffic to a multicast group to which the machine running
-Wireshark belongs?
-
-If not, this may just be a problem with promiscuous sniffing, either
-due to running on a switched network or a dual-speed hub, or due to
-problems with the interface not supporting promiscuous mode; see the
-response to this earlier question.
-
-Otherwise, on Windows, see the response to this question and, on a
-UNIX-flavored OS, see the response to this question.
-
-Q 7.5: Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
-
-A: Wireshark can only capture on devices supported by libpcap/WinPcap.
-On most OSes, only devices that can act as network interfaces of the
-type that support IP are supported as capture devices for libpcap/
-WinPcap, although the device doesn't necessarily have to be running as
-an IP interface in order to support traffic capture.
-
-On Linux and FreeBSD, libpcap 0.8 and later support the API for Endace
-Measurement Systems' DAG cards, so that a system with one of those
-cards, and its driver and libraries, installed can capture traffic
-with those cards with libpcap-based applications. You would either
-have to have a version of Wireshark built with that version of
-libpcap, or a dynamically-linked version of Wireshark and a shared
-libpcap library with DAG support, in order to do so with Wireshark.
-You should ask Endace whether that could be used to capture traffic
-on, for example, your T1/E1 link. See the SS7 capture setup page on
-the Wireshark Wiki for current information on capturing SS7 traffic on
-TDM links.
-
-Q 7.6: How do I put an interface into promiscuous mode?
-
-A: By not disabling promiscuous mode when running Wireshark or TShark.
-
-Note, however, that:
-
- • the form of promiscuous mode that libpcap (the library that
- programs such as tcpdump, Wireshark, etc. use to do packet
- capture) turns on will not necessarily be shown if you run
- ifconfig on the interface on a UNIX system;
- • some network interfaces might not support promiscuous mode, and
- some drivers might not allow promiscuous mode to be turned on -
- see this earlier question for more information on that;
- • the fact that you're not seeing any traffic, or are only seeing
- broadcast traffic, or aren't seeing any non-broadcast traffic
- other than traffic to or from the machine running Wireshark, does
- not mean that promiscuous mode isn't on - see this earlier
- question for more information on that.
-
-I.e., this is probably the same question as this earlier one; see the
-response to that question.
-
-Q 7.7: I can set a display filter just fine; why don't capture filters
-work?
-
-A: Capture filters currently use a different syntax than display
-filters. Here's the corresponding section from the wireshark(1) man
-page:
-
-"Display filters in Wireshark are very powerful; more fields are
-filterable in Wireshark than in other protocol analyzers, and the
-syntax you can use to create your filters is richer. As Wireshark
-progresses, expect more and more protocol fields to be allowed in
-display filters.
-
-Packet capturing is performed with the pcap library. The capture
-filter syntax follows the rules of the pcap library. This syntax is
-different from the display filter syntax."
-
-The capture filter syntax used by libpcap can be found in the tcpdump
-(8) man page.
-
-Q 7.8: I'm entering valid capture filters; why do I still get "parse
-error" errors?
-
-A: There is a bug in some versions of libpcap/WinPcap that cause it to
-report parse errors even for valid expressions if a previous filter
-expression was invalid and got a parse error.
-
-Try exiting and restarting Wireshark; if you are using a version of
-libpcap/WinPcap with this bug, this will "erase" its memory of the
-previous parse error. If the capture filter that got the "parse error"
-now works, the earlier error with that filter was probably due to this
-bug.
-
-The bug was fixed in libpcap 0.6; 0.4[.x] and 0.5[.x] versions of
-libpcap have this bug, but 0.6[.x] and later versions don't.
-
-Versions of WinPcap prior to 2.3 are based on pre-0.6 versions of
-libpcap, and have this bug; WinPcap 2.3 is based on libpcap 0.6.2, and
-doesn't have this bug.
-
-If you are running Wireshark on a UNIX-flavored platform, run
-"wireshark -v", or select "About Wireshark..." from the "Help" menu in
-Wireshark, to see what version of libpcap it's using. If it's not 0.6
-or later, you will need either to upgrade your OS to get a later
-version of libpcap, or will need to build and install a later version
-of libpcap from the tcpdump.org Web site and then recompile Wireshark
-from source with that later version of libpcap.
-
-If you are running Wireshark on Windows with a pre-2.3 version of
-WinPcap, you will need to un-install WinPcap and then download and
-install WinPcap 2.3.
-
-Q 7.9: How can I capture packets with CRC errors?
-
-A: Wireshark can capture only the packets that the packet capture
-library - libpcap on UNIX-flavored OSes, and the WinPcap port to
-Windows of libpcap on Windows - can capture, and libpcap/WinPcap can
-capture only the packets that the OS's raw packet capture mechanism
-(or the WinPcap driver, and the underlying OS networking code and
-network interface drivers, on Windows) will allow it to capture.
-
-Unless the OS always supplies packets with errors such as invalid CRCs
-to the raw packet capture mechanism, or can be configured to do so,
-invalid CRCs to the raw packet capture mechanism, Wireshark - and
-other programs that capture raw packets, such as tcpdump - cannot
-capture those packets. You will have to determine whether your OS
-needs to be so configured and, if so, can be so configured, configure
-it if necessary and possible, and make whatever changes to libpcap and
-the packet capture program you're using are necessary, if any, to
-support capturing those packets.
-
-Most OSes probably do not support capturing packets with invalid CRCs
-on Ethernet, and probably do not support it on most other link-layer
-types. Some drivers on some OSes do support it, such as some Ethernet
-drivers on FreeBSD; in those OSes, you might always get those packets,
-or you might only get them if you capture in promiscuous mode (you'd
-have to determine which is the case).
-
-Note that libpcap does not currently supply to programs that use it an
-indication of whether the packet's CRC was invalid (because the
-drivers themselves do not supply that information to the raw packet
-capture mechanism); therefore, Wireshark will not indicate which
-packets had CRC errors unless the FCS was captured (see the next
-question) and you're using Wireshark 0.9.15 and later, in which case
-Wireshark will check the CRC and indicate whether it's correct or not.
-
-Q 7.10: How can I capture entire frames, including the FCS?
-
-A: Wireshark can only capture data that the packet capture library -
-libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of
-libpcap on Windows - can capture, and libpcap/WinPcap can capture only
-the data that the OS's raw packet capture mechanism (or the WinPcap
-driver, and the underlying OS networking code and network interface
-drivers, on Windows) will allow it to capture.
-
-For any particular link-layer network type, unless the OS supplies the
-FCS of a frame as part of the frame, or can be configured to do so,
-Wireshark - and other programs that capture raw packets, such as
-tcpdump - cannot capture the FCS of a frame. You will have to
-determine whether your OS needs to be so configured and, if so, can be
-so configured, configure it if necessary and possible, and make
-whatever changes to libpcap and the packet capture program you're
-using are necessary, if any, to support capturing the FCS of a frame.
-
-Most OSes do not support capturing the FCS of a frame on Ethernet, and
-probably do not support it on most other link-layer types. Some
-drivres on some OSes do support it, such as some (all?) Ethernet
-drivers on NetBSD and possibly the driver for Apple's gigabit Ethernet
-interface in Mac OS X; in those OSes, you might always get the FCS, or
-you might only get the FCS if you capture in promiscuous mode (you'd
-have to determine which is the case).
-
-Versions of Wireshark prior to 0.9.15 will not treat an Ethernet FCS
-in a captured packet as an FCS. 0.9.15 and later will attempt to
-determine whether there's an FCS at the end of the frame and, if it
-thinks there is, will display it as such, and will check whether it's
-the correct CRC-32 value or not.
-
-Q 7.11: I'm capturing packets on a machine on a VLAN; why don't the
-packets I'm capturing have VLAN tags?
-
-A: You might be capturing on what might be called a "VLAN interface" -
-the way a particular OS makes VLANs plug into the networking stack
-might, for example, be to have a network device object for the
-physical interface, which takes VLAN packets, strips off the VLAN
-header and constructs an Ethernet header, and passes that packet to an
-internal network device object for the VLAN, which then passes the
-packets onto various higher-level protocol implementations.
-
-In order to see the raw Ethernet packets, rather than "de-VLANized"
-packets, you would have to capture not on the virtual interface for
-the VLAN, but on the interface corresponding to the physical network
-device, if possible. See the Wireshark Wiki item on VLAN capturing for
-details.
-
-Q 7.12: Why does Wireshark hang after I stop a capture?
-
-A: The most likely reason for this is that Wireshark is trying to look
-up an IP address in the capture to convert it to a name (so that, for
-example, it can display the name in the source address or destination
-address columns), and that lookup process is taking a very long time.
-
-Wireshark calls a routine in the OS of the machine on which it's
-running to convert of IP addresses to the corresponding names. That
-routine probably does one or more of:
-
- • a search of a system file listing IP addresses and names;
- • a lookup using DNS;
- • on UNIX systems, a lookup using NIS;
- • on Windows systems, a NetBIOS-over-TCP query.
-
-If a DNS server that's used in an address lookup is not responding,
-the lookup will fail, but will only fail after a timeout while the
-system routine waits for a reply.
-
-In addition, on Windows systems, if the DNS lookup of the address
-fails, either because the server isn't responding or because there are
-no records in the DNS that could be used to map the address to a name,
-a NetBIOS-over-TCP query will be made. That query involves sending a
-message to the NetBIOS-over-TCP name service on that machine, asking
-for the name and other information about the machine. If the machine
-isn't running software that responds to those queries - for example,
-many non-Windows machines wouldn't be running that software - the
-lookup will only fail after a timeout. Those timeouts can cause the
-lookup to take a long time.
-
-If you disable network address-to-name translation - for example, by
-turning off the "Enable network name resolution" option in the
-"Capture Options" dialog box for starting a network capture - the
-lookups of the address won't be done, which may speed up the process
-of reading the capture file after the capture is stopped. You can make
-that setting the default by selecting "Preferences" from the "Edit"
-menu, turning off the "Enable network name resolution" option in the
-"Name resolution" options in the preferences disalog box, and using
-the "Save" button in that dialog box; note that this will save all
-your current preference settings.
-
-If Wireshark hangs when reading a capture even with network name
-resolution turned off, there might, for example, be a bug in one of
-Wireshark's dissectors for a protocol causing it to loop infinitely.
-If you're not running the most recent release of Wireshark, you should
-first upgrade to that release, as, if there's a bug of that sort, it
-might've been fixed in a release after the one you're running. If the
-hang occurs in the most recent release of Wireshark, the bug should be
-reported to the Wireshark developers' mailing list at
-wireshark-dev@wireshark.org.
-
-On UNIX-flavored OSes, please try to force Wireshark to dump core, by
-sending it a SIGABRT signal (usually signal 6) with the kill command,
-and then get a stack trace if you have a debugger installed. A stack
-trace can be obtained by using your debugger (gdb in this example),
-the Wireshark binary, and the resulting core file. Here's an example
-of how to use the gdb command backtrace to do so.
-
+ Q 7.1: When I use Wireshark to capture packets, why do I see only
+ packets to and from my machine, or not see all the traffic I'm
+ expecting to see from or to the machine I'm trying to monitor?
+
+ A: This might be because the interface on which you're capturing is
+ plugged into an Ethernet or Token Ring switch; on a switched network,
+ unicast traffic between two ports will not necessarily appear on other
+ ports - only broadcast and multicast traffic will be sent to all
+ ports.
+
+ Note that even if your machine is plugged into a hub, the "hub" may be
+ a switched hub, in which case you're still on a switched network.
+
+ Note also that on the Linksys Web site, they say that their
+ auto-sensing hubs "broadcast the 10Mb packets to the port that operate
+ at 10Mb only and broadcast the 100Mb packets to the ports that operate
+ at 100Mb only", which would indicate that if you sniff on a 10Mb port,
+ you will not see traffic coming sent to a 100Mb port, and vice versa.
+ This problem has also been reported for Netgear dual-speed hubs, and
+ may exist for other "auto-sensing" or "dual-speed" hubs.
+
+ Some switches have the ability to replicate all traffic on all ports
+ to a single port so that you can plug your analyzer into that single
+ port to sniff all traffic. You would have to check the documentation
+ for the switch to see if this is possible and, if so, to see how to do
+ this. See the switch reference page on the Wireshark Wiki for
+ information on some switches. (Note that it's a Wiki, so you can
+ update or fix that information, or add additional information on those
+ switches or information on new switches, yourself.)
+
+ Note also that many firewall/NAT boxes have a switch built into them;
+ this includes many of the "cable/DSL router" boxes. If you have a box
+ of that sort, that has a switch with some number of Ethernet ports
+ into which you plug machines on your network, and another Ethernet
+ port used to connect to a cable or DSL modem, you can, at least, sniff
+ traffic between the machines on your network and the Internet by
+ plugging the Ethernet port on the router going to the modem, the
+ Ethernet port on the modem, and the machine on which you're running
+ Wireshark into a hub (make sure it's not a switching hub, and that, if
+ it's a dual-speed hub, all three of those ports are running at the
+ same speed.
+
+ If your machine is not plugged into a switched network or a dual-speed
+ hub, or it is plugged into a switched network but the port is set up
+ to have all traffic replicated to it, the problem might be that the
+ network interface on which you're capturing doesn't support
+ "promiscuous" mode, or because your OS can't put the interface into
+ promiscuous mode. Normally, network interfaces supply to the host
+ only:
+ * packets sent to one of that host's link-layer addresses;
+ * broadcast packets;
+ * multicast packets sent to a multicast address that the host has
+ configured the interface to accept.
+
+ Most network interfaces can also be put in "promiscuous" mode, in
+ which they supply to the host all network packets they see. Wireshark
+ will try to put the interface on which it's capturing into promiscuous
+ mode unless the "Capture packets in promiscuous mode" option is turned
+ off in the "Capture Options" dialog box, and TShark will try to put
+ the interface on which it's capturing into promiscuous mode unless the
+ -p option was specified. However, some network interfaces don't
+ support promiscuous mode, and some OSes might not allow interfaces to
+ be put into promiscuous mode.
+
+ If the interface is not running in promiscuous mode, it won't see any
+ traffic that isn't intended to be seen by your machine. It will see
+ broadcast packets, and multicast packets sent to a multicast MAC
+ address the interface is set up to receive.
+
+ You should ask the vendor of your network interface whether it
+ supports promiscuous mode. If it does, you should ask whoever supplied
+ the driver for the interface (the vendor, or the supplier of the OS
+ you're running on your machine) whether it supports promiscuous mode
+ with that network interface.
+
+ In the case of token ring interfaces, the drivers for some of them, on
+ Windows, may require you to enable promiscuous mode in order to
+ capture in promiscuous mode. See the Wireshark Wiki item on Token Ring
+ capturing for details.
+
+ In the case of wireless LAN interfaces, it appears that, when those
+ interfaces are promiscuously sniffing, they're running in a
+ significantly different mode from the mode that they run in when
+ they're just acting as network interfaces (to the extent that it would
+ be a significant effor for those drivers to support for promiscuously
+ sniffing and acting as regular network interfaces at the same time),
+ so it may be that Windows drivers for those interfaces don't support
+ promiscuous mode.
+
+ Q 7.2: When I capture with Wireshark, why can't I see any TCP packets
+ other than packets to and from my machine, even though another
+ analyzer on the network sees those packets?
+
+ A: You're probably not seeing any packets other than unicast packets
+ to or from your machine, and broadcast and multicast packets; a switch
+ will normally send to a port only unicast traffic sent to the MAC
+ address for the interface on that port, and broadcast and multicast
+ traffic - it won't send to that port unicast traffic sent to a MAC
+ address for some other interface - and a network interface not in
+ promiscuous mode will receive only unicast traffic sent to the MAC
+ address for that interface, broadcast traffic, and multicast traffic
+ sent to a multicast MAC address the interface is set up to receive.
+
+ TCP doesn't use broadcast or multicast, so you will only see your own
+ TCP traffic, but UDP services may use broadcast or multicast so you'll
+ see some UDP traffic - however, this is not a problem with TCP
+ traffic, it's a problem with unicast traffic, as you also won't see
+ all UDP traffic between other machines.
+
+ I.e., this is probably the same question as this earlier one; see the
+ response to that question.
+
+ Q 7.3: Why am I only seeing ARP packets when I try to capture traffic?
+
+ A: You're probably on a switched network, and running Wireshark on a
+ machine that's not sending traffic to the switch and not being sent
+ any traffic from other machines on the switch. ARP packets are often
+ broadcast packets, which are sent to all switch ports.
+
+ I.e., this is probably the same question as this earlier one; see the
+ response to that question.
+
+ Q 7.4: Why am I not seeing any traffic when I try to capture traffic?
+
+ A: Is the machine running Wireshark sending out any traffic on the
+ network interface on which you're capturing, or receiving any traffic
+ on that network, or is there any broadcast traffic on the network or
+ multicast traffic to a multicast group to which the machine running
+ Wireshark belongs?
+
+ If not, this may just be a problem with promiscuous sniffing, either
+ due to running on a switched network or a dual-speed hub, or due to
+ problems with the interface not supporting promiscuous mode; see the
+ response to this earlier question.
+
+ Otherwise, on Windows, see the response to this question and, on a
+ UNIX-flavored OS, see the response to this question.
+
+ Q 7.5: Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
+
+ A: Wireshark can only capture on devices supported by libpcap/WinPcap.
+ On most OSes, only devices that can act as network interfaces of the
+ type that support IP are supported as capture devices for
+ libpcap/WinPcap, although the device doesn't necessarily have to be
+ running as an IP interface in order to support traffic capture.
+
+ On Linux and FreeBSD, libpcap 0.8 and later support the API for Endace
+ Measurement Systems' DAG cards, so that a system with one of those
+ cards, and its driver and libraries, installed can capture traffic
+ with those cards with libpcap-based applications. You would either
+ have to have a version of Wireshark built with that version of
+ libpcap, or a dynamically-linked version of Wireshark and a shared
+ libpcap library with DAG support, in order to do so with Wireshark.
+ You should ask Endace whether that could be used to capture traffic
+ on, for example, your T1/E1 link. See the SS7 capture setup page on
+ the Wireshark Wiki for current information on capturing SS7 traffic on
+ TDM links.
+
+ Q 7.6: How do I put an interface into promiscuous mode?
+
+ A: By not disabling promiscuous mode when running Wireshark or TShark.
+
+ Note, however, that:
+ * the form of promiscuous mode that libpcap (the library that
+ programs such as tcpdump, Wireshark, etc. use to do packet
+ capture) turns on will not necessarily be shown if you run
+ ifconfig on the interface on a UNIX system;
+ * some network interfaces might not support promiscuous mode, and
+ some drivers might not allow promiscuous mode to be turned on -
+ see this earlier question for more information on that;
+ * the fact that you're not seeing any traffic, or are only seeing
+ broadcast traffic, or aren't seeing any non-broadcast traffic
+ other than traffic to or from the machine running Wireshark, does
+ not mean that promiscuous mode isn't on - see this earlier
+ question for more information on that.
+
+ I.e., this is probably the same question as this earlier one; see the
+ response to that question.
+
+ Q 7.7: I can set a display filter just fine; why don't capture filters
+ work?
+
+ A: Capture filters currently use a different syntax than display
+ filters. Here's the corresponding section from the wireshark(1) man
+ page:
+
+ "Display filters in Wireshark are very powerful; more fields are
+ filterable in Wireshark than in other protocol analyzers, and the
+ syntax you can use to create your filters is richer. As Wireshark
+ progresses, expect more and more protocol fields to be allowed in
+ display filters.
+
+ Packet capturing is performed with the pcap library. The capture
+ filter syntax follows the rules of the pcap library. This syntax is
+ different from the display filter syntax."
+
+ The capture filter syntax used by libpcap can be found in the
+ tcpdump(8) man page.
+
+ Q 7.8: I'm entering valid capture filters; why do I still get "parse
+ error" errors?
+
+ A: There is a bug in some versions of libpcap/WinPcap that cause it to
+ report parse errors even for valid expressions if a previous filter
+ expression was invalid and got a parse error.
+
+ Try exiting and restarting Wireshark; if you are using a version of
+ libpcap/WinPcap with this bug, this will "erase" its memory of the
+ previous parse error. If the capture filter that got the "parse error"
+ now works, the earlier error with that filter was probably due to this
+ bug.
+
+ The bug was fixed in libpcap 0.6; 0.4[.x] and 0.5[.x] versions of
+ libpcap have this bug, but 0.6[.x] and later versions don't.
+
+ Versions of WinPcap prior to 2.3 are based on pre-0.6 versions of
+ libpcap, and have this bug; WinPcap 2.3 is based on libpcap 0.6.2, and
+ doesn't have this bug.
+
+ If you are running Wireshark on a UNIX-flavored platform, run
+ "wireshark -v", or select "About Wireshark..." from the "Help" menu in
+ Wireshark, to see what version of libpcap it's using. If it's not 0.6
+ or later, you will need either to upgrade your OS to get a later
+ version of libpcap, or will need to build and install a later version
+ of libpcap from the tcpdump.org Web site and then recompile Wireshark
+ from source with that later version of libpcap.
+
+ If you are running Wireshark on Windows with a pre-2.3 version of
+ WinPcap, you will need to un-install WinPcap and then download and
+ install WinPcap 2.3.
+
+ Q 7.9: How can I capture packets with CRC errors?
+
+ A: Wireshark can capture only the packets that the packet capture
+ library - libpcap on UNIX-flavored OSes, and the WinPcap port to
+ Windows of libpcap on Windows - can capture, and libpcap/WinPcap can
+ capture only the packets that the OS's raw packet capture mechanism
+ (or the WinPcap driver, and the underlying OS networking code and
+ network interface drivers, on Windows) will allow it to capture.
+
+ Unless the OS always supplies packets with errors such as invalid CRCs
+ to the raw packet capture mechanism, or can be configured to do so,
+ invalid CRCs to the raw packet capture mechanism, Wireshark - and
+ other programs that capture raw packets, such as tcpdump - cannot
+ capture those packets. You will have to determine whether your OS
+ needs to be so configured and, if so, can be so configured, configure
+ it if necessary and possible, and make whatever changes to libpcap and
+ the packet capture program you're using are necessary, if any, to
+ support capturing those packets.
+
+ Most OSes probably do not support capturing packets with invalid CRCs
+ on Ethernet, and probably do not support it on most other link-layer
+ types. Some drivers on some OSes do support it, such as some Ethernet
+ drivers on FreeBSD; in those OSes, you might always get those packets,
+ or you might only get them if you capture in promiscuous mode (you'd
+ have to determine which is the case).
+
+ Note that libpcap does not currently supply to programs that use it an
+ indication of whether the packet's CRC was invalid (because the
+ drivers themselves do not supply that information to the raw packet
+ capture mechanism); therefore, Wireshark will not indicate which
+ packets had CRC errors unless the FCS was captured (see the next
+ question) and you're using Wireshark 0.9.15 and later, in which case
+ Wireshark will check the CRC and indicate whether it's correct or not.
+
+ Q 7.10: How can I capture entire frames, including the FCS?
+
+ A: Wireshark can only capture data that the packet capture library -
+ libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of
+ libpcap on Windows - can capture, and libpcap/WinPcap can capture only
+ the data that the OS's raw packet capture mechanism (or the WinPcap
+ driver, and the underlying OS networking code and network interface
+ drivers, on Windows) will allow it to capture.
+
+ For any particular link-layer network type, unless the OS supplies the
+ FCS of a frame as part of the frame, or can be configured to do so,
+ Wireshark - and other programs that capture raw packets, such as
+ tcpdump - cannot capture the FCS of a frame. You will have to
+ determine whether your OS needs to be so configured and, if so, can be
+ so configured, configure it if necessary and possible, and make
+ whatever changes to libpcap and the packet capture program you're
+ using are necessary, if any, to support capturing the FCS of a frame.
+
+ Most OSes do not support capturing the FCS of a frame on Ethernet, and
+ probably do not support it on most other link-layer types. Some
+ drivres on some OSes do support it, such as some (all?) Ethernet
+ drivers on NetBSD and possibly the driver for Apple's gigabit Ethernet
+ interface in Mac OS X; in those OSes, you might always get the FCS, or
+ you might only get the FCS if you capture in promiscuous mode (you'd
+ have to determine which is the case).
+
+ Versions of Wireshark prior to 0.9.15 will not treat an Ethernet FCS
+ in a captured packet as an FCS. 0.9.15 and later will attempt to
+ determine whether there's an FCS at the end of the frame and, if it
+ thinks there is, will display it as such, and will check whether it's
+ the correct CRC-32 value or not.
+
+ Q 7.11: I'm capturing packets on a machine on a VLAN; why don't the
+ packets I'm capturing have VLAN tags?
+
+ A: You might be capturing on what might be called a "VLAN interface" -
+ the way a particular OS makes VLANs plug into the networking stack
+ might, for example, be to have a network device object for the
+ physical interface, which takes VLAN packets, strips off the VLAN
+ header and constructs an Ethernet header, and passes that packet to an
+ internal network device object for the VLAN, which then passes the
+ packets onto various higher-level protocol implementations.
+
+ In order to see the raw Ethernet packets, rather than "de-VLANized"
+ packets, you would have to capture not on the virtual interface for
+ the VLAN, but on the interface corresponding to the physical network
+ device, if possible. See the Wireshark Wiki item on VLAN capturing for
+ details.
+
+ Q 7.12: Why does Wireshark hang after I stop a capture?
+
+ A: The most likely reason for this is that Wireshark is trying to look
+ up an IP address in the capture to convert it to a name (so that, for
+ example, it can display the name in the source address or destination
+ address columns), and that lookup process is taking a very long time.
+
+ Wireshark calls a routine in the OS of the machine on which it's
+ running to convert of IP addresses to the corresponding names. That
+ routine probably does one or more of:
+ * a search of a system file listing IP addresses and names;
+ * a lookup using DNS;
+ * on UNIX systems, a lookup using NIS;
+ * on Windows systems, a NetBIOS-over-TCP query.
+
+ If a DNS server that's used in an address lookup is not responding,
+ the lookup will fail, but will only fail after a timeout while the
+ system routine waits for a reply.
+
+ In addition, on Windows systems, if the DNS lookup of the address
+ fails, either because the server isn't responding or because there are
+ no records in the DNS that could be used to map the address to a name,
+ a NetBIOS-over-TCP query will be made. That query involves sending a
+ message to the NetBIOS-over-TCP name service on that machine, asking
+ for the name and other information about the machine. If the machine
+ isn't running software that responds to those queries - for example,
+ many non-Windows machines wouldn't be running that software - the
+ lookup will only fail after a timeout. Those timeouts can cause the
+ lookup to take a long time.
+
+ If you disable network address-to-name translation - for example, by
+ turning off the "Enable network name resolution" option in the
+ "Capture Options" dialog box for starting a network capture - the
+ lookups of the address won't be done, which may speed up the process
+ of reading the capture file after the capture is stopped. You can make
+ that setting the default by selecting "Preferences" from the "Edit"
+ menu, turning off the "Enable network name resolution" option in the
+ "Name resolution" options in the preferences disalog box, and using
+ the "Save" button in that dialog box; note that this will save all
+ your current preference settings.
+
+ If Wireshark hangs when reading a capture even with network name
+ resolution turned off, there might, for example, be a bug in one of
+ Wireshark's dissectors for a protocol causing it to loop infinitely.
+ If you're not running the most recent release of Wireshark, you should
+ first upgrade to that release, as, if there's a bug of that sort, it
+ might've been fixed in a release after the one you're running. If the
+ hang occurs in the most recent release of Wireshark, the bug should be
+ reported to the Wireshark developers' mailing list at
+ wireshark-dev@wireshark.org.
+
+ On UNIX-flavored OSes, please try to force Wireshark to dump core, by
+ sending it a SIGABRT signal (usually signal 6) with the kill command,
+ and then get a stack trace if you have a debugger installed. A stack
+ trace can be obtained by using your debugger (gdb in this example),
+ the Wireshark binary, and the resulting core file. Here's an example
+ of how to use the gdb command backtrace to do so.
$ gdb wireshark core
(gdb) backtrace
..... prints the stack trace
(gdb) quit
$
-The core dump file may be named "wireshark.core" rather than "core" on
-some platforms (e.g., BSD systems).
-
-Also, if at all possible, please send a copy of the capture file that
-caused the problem; when capturing packets, Wireshark normally writes
-captured packets to a temporary file, which will probably be in /tmp
-or /var/tmp on UNIX-flavored OSes, \TEMP on the main system disk
-(normally C:) on Windows 9x/Me/NT 4.0, and \Documents and Settings\
-your login name\Local Settings\Temp on the main system disk on Windows
-2000/Windows XP/Windows Server 2003, so the capture file will probably
-be there. It will have a name beginning with ether, with some mixture
-of letters and numbers after that. Please don't send a trace file
-greater than 1 MB when compressed; instead, make it available via FTP
-or HTTP, or say it's available but leave it up to a developer to ask
-for it. If the trace file contains sensitive information (e.g.,
-passwords), then please do not send it.
+ The core dump file may be named "wireshark.core" rather than "core" on
+ some platforms (e.g., BSD systems).
+
+ Also, if at all possible, please send a copy of the capture file that
+ caused the problem; when capturing packets, Wireshark normally writes
+ captured packets to a temporary file, which will probably be in /tmp
+ or /var/tmp on UNIX-flavored OSes, \TEMP on the main system disk
+ (normally C:) on Windows 9x/Me/NT 4.0, and \Documents and
+ Settings\your login name\Local Settings\Temp on the main system disk
+ on Windows 2000/Windows XP/Windows Server 2003, so the capture file
+ will probably be there. It will have a name beginning with ether, with
+ some mixture of letters and numbers after that. Please don't send a
+ trace file greater than 1 MB when compressed; instead, make it
+ available via FTP or HTTP, or say it's available but leave it up to a
+ developer to ask for it. If the trace file contains sensitive
+ information (e.g., passwords), then please do not send it.
8. Capturing packets on Windows
-Q 8.1: I'm running Wireshark on Windows; why does some network
-interface on my machine not show up in the list of interfaces in the
-"Interface:" field in the dialog box popped up by "Capture->Start",
-and/or why does Wireshark give me an error if I try to capture on that
-interface?
-
-A: If you are running Wireshark on Windows NT 4.0, Windows 2000,
-Windows XP, or Windows Server 2003, and this is the first time you
-have run a WinPcap-based program (such as Wireshark, or TShark, or
-WinDump, or Analyzer, or...) since the machine was rebooted, you need
-to run that program from an account with administrator privileges;
-once you have run such a program, you will not need administrator
-privileges to run any such programs until you reboot.
-
-If you are running on Windows 95/98/Me, or if you are running on
-Windows NT 4.0/Windows 2000/Windows XP/Windows Server 2003 and have
-administrator privileges or a WinPcap-based program has been run with
-those privileges since the machine rebooted, this problem might clear
-up if you completely un-install WinPcap and then re-install it.
-
-If that doesn't work, then note that Wireshark relies on the WinPcap
-library, on the WinPcap device driver, and on the facilities that come
-with the OS on which it's running in order to do captures.
-
-Therefore, if the OS, the WinPcap library, or the WinPcap driver don't
-support capturing on a particular network interface device, Wireshark
-won't be able to capture on that device.
-
-Note that:
-
- 1. 2.02 and earlier versions of the WinPcap driver and library that
- Wireshark uses for packet capture didn't support Token Ring
- interfaces; versions 2.1 and later support Token Ring, and the
- current version of Wireshark works with (and, in fact, requires)
- WinPcap 2.1 or later.
-
- If you are having problems capturing on Token Ring interfaces, and
- you have WinPcap 2.02 or an earlier version of WinPcap installed,
- you should uninstall WinPcap, download and install the current
- version of WinPcap, and then install the latest version of
- Wireshark.
-
- 2. On Windows 95, 98, or Me, sometimes more than one interface will
- be given the same name; if that is the case, you will only be able
- to capture on one of those interfaces - it's not clear to which
- one the name, when used in a WinPcap-based application, will
- refer. For example, if you have a PPP serial interface and a VPN
- interface, they might show up with the same name, for example
- "ppp-mac", and if you try to capture on "ppp-mac", it might not
- capture on the interface you're currently using. In that case, you
- might, for example, have to remove the VPN interface from the
- system in order to capture on the PPP serial interface.
-
- 3. WinPcap 2.3 has problems supporting PPP WAN interfaces on Windows
- NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to
- avoid those problems, support for PPP WAN interfaces on those
- versions of Windows has been disabled in WinPcap 3.0. Regular
- dial-up lines, ISDN lines, ADSL connections using PPPoE or PPPoA,
- and various other lines such as T1/E1 lines are all PPP
- interfaces, so those interfaces might not show up on the list of
- interfaces in the "Capture Options" dialog on those OSes.
-
- On Windows 2000, Windows XP, and Windows Server 2003, but not
- Windows NT 4.0 or Windows Vista Beta 1, you should be able to
- capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta
- releases called it the "NdisWanAdapter"; if you're using a 3.1
- beta release, you should un-install it and install the final 3.1
- release.) See the Wireshark Wiki item on PPP capturing for
- details.
-
- 4. WinPcap prior to 3.0 does not support multiprocessor machines
- (note that machines with a single multi-threaded processor, such
- as Intel's new multi-threaded x86 processors, are multiprocessor
- machines as far as the OS and WinPcap are concerned), and recent
- 2.x versions of WinPcap refuse to operate if they detect that
- they're running on a multiprocessor machine, which means that they
- may not show any network interfaces. You will need to use WinPcap
- 3.0 to capture on a multiprocessor machine.
-
-If an interface doesn't show up in the list of interfaces in the
-"Interface:" field, and you know the name of the interface, try
-entering that name in the "Interface:" field and capturing on that
-device.
-
-If the attempt to capture on it succeeds, the interface is somehow not
-being reported by the mechanism Wireshark uses to get a list of
-interfaces. Try listing the interfaces with WinDump; see the WinDump
-Web site for information on using WinDump.
-
-You would run WinDump with the -D flag; if it lists the interface,
-please report this to wireshark-dev@wireshark.org giving full details
-of the problem, including
-
- • the operating system you're using, and the version of that
- operating system;
- • the type of network device you're using;
- • the output of WinDump.
-
-If WinDump does not list the interface, this is almost certainly a
-problem with one or more of:
-
- • the operating system you're using;
- • the device driver for the interface you're using;
- • the WinPcap library and/or the WinPcap device driver;
-
-so first check the WinPcap FAQ or the Wiretapped.net mirror of that
-FAQ, to see if your problem is mentioned there. If not, then see the
-WinPcap support page - check the "Submitting bugs" section.
-
-If you are having trouble capturing on a particular network interface,
-first try capturing on that device with WinDump; see the WinDump Web
-site for information on using WinDump.
-
-If you can capture on the interface with WinDump, send mail to
-wireshark-users@wireshark.org giving full details of the problem,
-including
-
- • the operating system you're using, and the version of that
- operating system;
- • the type of network device you're using;
- • the error message you get from Wireshark.
-
-If you cannot capture on the interface with WinDump, this is almost
-certainly a problem with one or more of:
-
- • the operating system you're using;
- • the device driver for the interface you're using;
- • the WinPcap library and/or the WinPcap device driver;
-
-so first check the WinPcap FAQ or the Wiretapped.net mirror of that
-FAQ, to see if your problem is mentioned there. If not, then see the
-WinPcap support page - check the "Submitting bugs" section.
-
-You may also want to ask the wireshark-users@wireshark.org and the
-winpcap-users@winpcap.org mailing lists to see if anybody happens to
-know about the problem and know a workaround or fix for the problem.
-(Note that you will have to subscribe to that list in order to be
-allowed to mail to it; see the WinPcap support page for information on
-the mailing list.) In your mail, please give full details of the
-problem, as described above, and also indicate that the problem occurs
-with WinDump, not just with Wireshark.
-
-Q 8.2: I'm running Wireshark on Windows; why do no network interfaces
-show up in the list of interfaces in the "Interface:" field in the
-dialog box popped up by "Capture->Start"?
-
-A: This is really the same question as the previous one; see the
-response to that question.
-
-Q 8.3: I'm running Wireshark on Windows; why doesn't my serial port/
-ADSL modem/ISDN modem show up in the list of interfaces in the
-"Interface:" field in the dialog box popped up by "Capture->Start"?
-
-A: Internet access on those devices is often done with the
-Point-to-Point (PPP) protocol; WinPcap 2.3 has problems supporting PPP
-WAN interfaces on Windows NT 4.0, Windows 2000, Windows XP, and
-Windows Server 2003, and, to avoid those problems, support for PPP WAN
-interfaces on those versions of Windows has been disabled in WinPcap
-3.0.
-
-On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
-NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
-"GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
-the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
-un-install it and install the final 3.1 release.) See the Wireshark
-Wiki item on PPP capturing for details.
-
-Q 8.4: I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows XP
-/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN, etc.)
-interface, and it shows up in the "Interface" item in the "Capture
-Options" dialog box. Why can no packets be sent on or received from
-that network while I'm trying to capture traffic on that interface?
-
-A: Some versions of WinPcap have problems with PPP WAN interfaces on
-Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003; one
-symptom that may be seen is that attempts to capture in promiscuous
-mode on the interface cause the interface to be incapable of sending
-or receiving packets. You can disable promiscuous mode using the -p
-command-line flag or the item in the "Capture Preferences" dialog box,
-but this may mean that outgoing packets, or incoming packets, won't be
-seen in the capture.
-
-On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
-NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
-"GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
-the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
-un-install it and install the final 3.1 release.) See the Wireshark
-Wiki item on PPP capturing for details.
-
-Q 8.5: I'm running Wireshark on Windows 95/98/Me, on a machine with
-more than one network adapter of the same type; why does Wireshark
-show all of those adapters with the same name, not letting me use any
-of those adapters other than the first one?
-
-A: Unfortunately, Windows 95/98/Me gives the same name to multiple
-instances of the type of same network adapter. Therefore, WinPcap
-cannot distinguish between them, so a WinPcap-based application can
-capture only on the first such interface; Wireshark is a libpcap/
-WinPcap-based application.
-
-Q 8.6: I'm running Wireshark on Windows; why am I not seeing any
-traffic being sent by the machine running Wireshark?
-
-A: If you are running some form of VPN client software, it might be
-causing this problem; people have seen this problem when they have
-Check Point's VPN software installed on their machine. If that's the
-cause of the problem, you will have to remove the VPN software in
-order to have Wireshark (or any other application using WinPcap) see
-outgoing packets; unfortunately, neither we nor the WinPcap developers
-know any way to make WinPcap and the VPN software work well together.
-
-Also, some drivers for Windows (especially some wireless network
-interface drivers) apparently do not, when running in promiscuous
-mode, arrange that outgoing packets are delivered to the software that
-requested that the interface run promiscuously; try turning
-promiscuous mode off.
-
-Q 8.7: When I capture on Windows in promiscuous mode, I can see
-packets other than those sent to or from my machine; however, those
-packets show up with a "Short Frame" indication, unlike packets to or
-from my machine. What should I do to arrange that I see those packets
-in their entirety?
-
-A: In at least some cases, this appears to be the result of PGPnet
-running on the network interface on which you're capturing; turn it
-off on that interface.
-
-Q 8.8: I'm capturing packets on {Windows 95, Windows 98, Windows Me};
-why are the time stamps on packets wrong?
-
-A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap
-3.0 and later releases.
-
-Q 8.9: I'm trying to capture 802.11 traffic on Windows; why am I not
-seeing any packets?
-
-A: At least some 802.11 card drivers on Windows appear not to see any
-packets if they're running in promiscuous mode. Try turning
-promiscuous mode off; you'll only be able to see packets sent by and
-received by your machine, not third-party traffic, and it'll look like
-Ethernet traffic and won't include any management or control frames,
-but that's a limitation of the card drivers.
-
-See MicroLogix's list of cards supported with WinPcap for information
-on support of various adapters and drivers with WinPcap.
-
-Q 8.10: I'm trying to capture 802.11 traffic on Windows; why am I
-seeing packets received by the machine on which I'm capturing traffic,
-but not packets sent by that machine?
-
-A: This appears to be another problem with promiscuous mode; try
-turning it off.
-
-Q 8.11: I'm trying to capture Ethernet VLAN traffic on Windows, and
-I'm capturing on a "raw" Ethernet device rather than a "VLAN
-interface", so that I can see the VLAN headers; why am I seeing
-packets received by the machine on which I'm capturing traffic, but
-not packets sent by that machine?
-
-A: The way the Windows networking code works probably means that
-packets are sent on a "VLAN interface" rather than the "raw" device,
-so packets sent by the machine will only be seen when you capture on
-the "VLAN interface". If so, you will be unable to see outgoing
-packets when capturing on the "raw" device, so you are stuck with a
-choice between seeing VLAN headers and seeing outgoing packets.
+ Q 8.1: I'm running Wireshark on Windows; why does some network
+ interface on my machine not show up in the list of interfaces in the
+ "Interface:" field in the dialog box popped up by "Capture->Start",
+ and/or why does Wireshark give me an error if I try to capture on that
+ interface?
+
+ A: If you are running Wireshark on Windows NT 4.0, Windows 2000,
+ Windows XP, or Windows Server 2003, and this is the first time you
+ have run a WinPcap-based program (such as Wireshark, or TShark, or
+ WinDump, or Analyzer, or...) since the machine was rebooted, you need
+ to run that program from an account with administrator privileges;
+ once you have run such a program, you will not need administrator
+ privileges to run any such programs until you reboot.
+
+ If you are running on Windows 95/98/Me, or if you are running on
+ Windows NT 4.0/Windows 2000/Windows XP/Windows Server 2003 and have
+ administrator privileges or a WinPcap-based program has been run with
+ those privileges since the machine rebooted, this problem might clear
+ up if you completely un-install WinPcap and then re-install it.
+
+ If that doesn't work, then note that Wireshark relies on the WinPcap
+ library, on the WinPcap device driver, and on the facilities that come
+ with the OS on which it's running in order to do captures.
+
+ Therefore, if the OS, the WinPcap library, or the WinPcap driver don't
+ support capturing on a particular network interface device, Wireshark
+ won't be able to capture on that device.
+
+ Note that:
+ 1. 2.02 and earlier versions of the WinPcap driver and library that
+ Wireshark uses for packet capture didn't support Token Ring
+ interfaces; versions 2.1 and later support Token Ring, and the
+ current version of Wireshark works with (and, in fact, requires)
+ WinPcap 2.1 or later.
+ If you are having problems capturing on Token Ring interfaces, and
+ you have WinPcap 2.02 or an earlier version of WinPcap installed,
+ you should uninstall WinPcap, download and install the current
+ version of WinPcap, and then install the latest version of
+ Wireshark.
+ 2. On Windows 95, 98, or Me, sometimes more than one interface will
+ be given the same name; if that is the case, you will only be able
+ to capture on one of those interfaces - it's not clear to which
+ one the name, when used in a WinPcap-based application, will
+ refer. For example, if you have a PPP serial interface and a VPN
+ interface, they might show up with the same name, for example
+ "ppp-mac", and if you try to capture on "ppp-mac", it might not
+ capture on the interface you're currently using. In that case, you
+ might, for example, have to remove the VPN interface from the
+ system in order to capture on the PPP serial interface.
+ 3. WinPcap 2.3 has problems supporting PPP WAN interfaces on Windows
+ NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to
+ avoid those problems, support for PPP WAN interfaces on those
+ versions of Windows has been disabled in WinPcap 3.0. Regular
+ dial-up lines, ISDN lines, ADSL connections using PPPoE or PPPoA,
+ and various other lines such as T1/E1 lines are all PPP
+ interfaces, so those interfaces might not show up on the list of
+ interfaces in the "Capture Options" dialog on those OSes.
+ On Windows 2000, Windows XP, and Windows Server 2003, but not
+ Windows NT 4.0 or Windows Vista Beta 1, you should be able to
+ capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta
+ releases called it the "NdisWanAdapter"; if you're using a 3.1
+ beta release, you should un-install it and install the final 3.1
+ release.) See the Wireshark Wiki item on PPP capturing for
+ details.
+ 4. WinPcap prior to 3.0 does not support multiprocessor machines
+ (note that machines with a single multi-threaded processor, such
+ as Intel's new multi-threaded x86 processors, are multiprocessor
+ machines as far as the OS and WinPcap are concerned), and recent
+ 2.x versions of WinPcap refuse to operate if they detect that
+ they're running on a multiprocessor machine, which means that they
+ may not show any network interfaces. You will need to use WinPcap
+ 3.0 to capture on a multiprocessor machine.
+
+ If an interface doesn't show up in the list of interfaces in the
+ "Interface:" field, and you know the name of the interface, try
+ entering that name in the "Interface:" field and capturing on that
+ device.
+
+ If the attempt to capture on it succeeds, the interface is somehow not
+ being reported by the mechanism Wireshark uses to get a list of
+ interfaces. Try listing the interfaces with WinDump; see the WinDump
+ Web site for information on using WinDump.
+
+ You would run WinDump with the -D flag; if it lists the interface,
+ please report this to wireshark-dev@wireshark.org giving full details
+ of the problem, including
+ * the operating system you're using, and the version of that
+ operating system;
+ * the type of network device you're using;
+ * the output of WinDump.
+
+ If WinDump does not list the interface, this is almost certainly a
+ problem with one or more of:
+ * the operating system you're using;
+ * the device driver for the interface you're using;
+ * the WinPcap library and/or the WinPcap device driver;
+
+ so first check the WinPcap FAQ or the Wiretapped.net mirror of that
+ FAQ, to see if your problem is mentioned there. If not, then see the
+ WinPcap support page - check the "Submitting bugs" section.
+
+ If you are having trouble capturing on a particular network interface,
+ first try capturing on that device with WinDump; see the WinDump Web
+ site for information on using WinDump.
+
+ If you can capture on the interface with WinDump, send mail to
+ wireshark-users@wireshark.org giving full details of the problem,
+ including
+ * the operating system you're using, and the version of that
+ operating system;
+ * the type of network device you're using;
+ * the error message you get from Wireshark.
+
+ If you cannot capture on the interface with WinDump, this is almost
+ certainly a problem with one or more of:
+ * the operating system you're using;
+ * the device driver for the interface you're using;
+ * the WinPcap library and/or the WinPcap device driver;
+
+ so first check the WinPcap FAQ or the Wiretapped.net mirror of that
+ FAQ, to see if your problem is mentioned there. If not, then see the
+ WinPcap support page - check the "Submitting bugs" section.
+
+ You may also want to ask the wireshark-users@wireshark.org and the
+ winpcap-users@winpcap.org mailing lists to see if anybody happens to
+ know about the problem and know a workaround or fix for the problem.
+ (Note that you will have to subscribe to that list in order to be
+ allowed to mail to it; see the WinPcap support page for information on
+ the mailing list.) In your mail, please give full details of the
+ problem, as described above, and also indicate that the problem occurs
+ with WinDump, not just with Wireshark.
+
+ Q 8.2: I'm running Wireshark on Windows; why do no network interfaces
+ show up in the list of interfaces in the "Interface:" field in the
+ dialog box popped up by "Capture->Start"?
+
+ A: This is really the same question as the previous one; see the
+ response to that question.
+
+ Q 8.3: I'm running Wireshark on Windows; why doesn't my serial
+ port/ADSL modem/ISDN modem show up in the list of interfaces in the
+ "Interface:" field in the dialog box popped up by "Capture->Start"?
+
+ A: Internet access on those devices is often done with the
+ Point-to-Point (PPP) protocol; WinPcap 2.3 has problems supporting PPP
+ WAN interfaces on Windows NT 4.0, Windows 2000, Windows XP, and
+ Windows Server 2003, and, to avoid those problems, support for PPP WAN
+ interfaces on those versions of Windows has been disabled in WinPcap
+ 3.0.
+
+ On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
+ NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
+ "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
+ the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
+ un-install it and install the final 3.1 release.) See the Wireshark
+ Wiki item on PPP capturing for details.
+
+ Q 8.4: I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows
+ XP/Windows Server 2003; my machine has a PPP (dial-up POTS, ISDN,
+ etc.) interface, and it shows up in the "Interface" item in the
+ "Capture Options" dialog box. Why can no packets be sent on or
+ received from that network while I'm trying to capture traffic on that
+ interface?
+
+ A: Some versions of WinPcap have problems with PPP WAN interfaces on
+ Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003; one
+ symptom that may be seen is that attempts to capture in promiscuous
+ mode on the interface cause the interface to be incapable of sending
+ or receiving packets. You can disable promiscuous mode using the -p
+ command-line flag or the item in the "Capture Preferences" dialog box,
+ but this may mean that outgoing packets, or incoming packets, won't be
+ seen in the capture.
+
+ On Windows 2000, Windows XP, and Windows Server 2003, but not Windows
+ NT 4.0 or Windows Vista Beta 1, you should be able to capture on the
+ "GenericDialupAdapter" with WinPcap 3.1. (3.1 beta releases called it
+ the "NdisWanAdapter"; if you're using a 3.1 beta release, you should
+ un-install it and install the final 3.1 release.) See the Wireshark
+ Wiki item on PPP capturing for details.
+
+ Q 8.5: I'm running Wireshark on Windows 95/98/Me, on a machine with
+ more than one network adapter of the same type; why does Wireshark
+ show all of those adapters with the same name, not letting me use any
+ of those adapters other than the first one?
+
+ A: Unfortunately, Windows 95/98/Me gives the same name to multiple
+ instances of the type of same network adapter. Therefore, WinPcap
+ cannot distinguish between them, so a WinPcap-based application can
+ capture only on the first such interface; Wireshark is a
+ libpcap/WinPcap-based application.
+
+ Q 8.6: I'm running Wireshark on Windows; why am I not seeing any
+ traffic being sent by the machine running Wireshark?
+
+ A: If you are running some form of VPN client software, it might be
+ causing this problem; people have seen this problem when they have
+ Check Point's VPN software installed on their machine. If that's the
+ cause of the problem, you will have to remove the VPN software in
+ order to have Wireshark (or any other application using WinPcap) see
+ outgoing packets; unfortunately, neither we nor the WinPcap developers
+ know any way to make WinPcap and the VPN software work well together.
+
+ Also, some drivers for Windows (especially some wireless network
+ interface drivers) apparently do not, when running in promiscuous
+ mode, arrange that outgoing packets are delivered to the software that
+ requested that the interface run promiscuously; try turning
+ promiscuous mode off.
+
+ Q 8.7: When I capture on Windows in promiscuous mode, I can see
+ packets other than those sent to or from my machine; however, those
+ packets show up with a "Short Frame" indication, unlike packets to or
+ from my machine. What should I do to arrange that I see those packets
+ in their entirety?
+
+ A: In at least some cases, this appears to be the result of PGPnet
+ running on the network interface on which you're capturing; turn it
+ off on that interface.
+
+ Q 8.8: I'm capturing packets on {Windows 95, Windows 98, Windows Me};
+ why are the time stamps on packets wrong?
+
+ A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap
+ 3.0 and later releases.
+
+ Q 8.9: I'm trying to capture 802.11 traffic on Windows; why am I not
+ seeing any packets?
+
+ A: At least some 802.11 card drivers on Windows appear not to see any
+ packets if they're running in promiscuous mode. Try turning
+ promiscuous mode off; you'll only be able to see packets sent by and
+ received by your machine, not third-party traffic, and it'll look like
+ Ethernet traffic and won't include any management or control frames,
+ but that's a limitation of the card drivers.
+
+ See MicroLogix's list of cards supported with WinPcap for information
+ on support of various adapters and drivers with WinPcap.
+
+ Q 8.10: I'm trying to capture 802.11 traffic on Windows; why am I
+ seeing packets received by the machine on which I'm capturing traffic,
+ but not packets sent by that machine?
+
+ A: This appears to be another problem with promiscuous mode; try
+ turning it off.
+
+ Q 8.11: I'm trying to capture Ethernet VLAN traffic on Windows, and
+ I'm capturing on a "raw" Ethernet device rather than a "VLAN
+ interface", so that I can see the VLAN headers; why am I seeing
+ packets received by the machine on which I'm capturing traffic, but
+ not packets sent by that machine?
+
+ A: The way the Windows networking code works probably means that
+ packets are sent on a "VLAN interface" rather than the "raw" device,
+ so packets sent by the machine will only be seen when you capture on
+ the "VLAN interface". If so, you will be unable to see outgoing
+ packets when capturing on the "raw" device, so you are stuck with a
+ choice between seeing VLAN headers and seeing outgoing packets.
9. Capturing packets on UN*Xes
-Q 9.1: I'm running Wireshark on a UNIX-flavored OS; why does some
-network interface on my machine not show up in the list of interfaces
-in the "Interface:" field in the dialog box popped up by "Capture->
-Start", and/or why does Wireshark give me an error if I try to capture
-on that interface?
-
-A: You may need to run Wireshark from an account with sufficient
-privileges to capture packets, such as the super-user account, or may
-need to give your account sufficient privileges to capture packets.
-Only those interfaces that Wireshark can open for capturing show up in
-that list; if you don't have sufficient privileges to capture on any
-interfaces, no interfaces will show up in the list. See the Wireshark
-Wiki item on capture privileges for details on how to give a
-particular account or account group capture privileges on platforms
-where that can be done.
-
-If you are running Wireshark from an account with sufficient
-privileges, then note that Wireshark relies on the libpcap library,
-and on the facilities that come with the OS on which it's running in
-order to do captures. On some OSes, those facilities aren't present by
-default; see the Wireshark Wiki item on adding capture support for
-details.
-
-And, even if you're running with an account that has sufficient
-privileges to capture, and capture support is present in your OS, if
-the OS or the libpcap library don't support capturing on a particular
-network interface device or particular types of devices, Wireshark
-won't be able to capture on that device.
-
-On Solaris, note that libpcap 0.6.2 and earlier didn't support Token
-Ring interfaces; the current version, 0.7.2, does support Token Ring,
-and the current version of Wireshark works with libcap 0.7.2 and
-later.
-
-If an interface doesn't show up in the list of interfaces in the
-"Interface:" field, and you know the name of the interface, try
-entering that name in the "Interface:" field and capturing on that
-device.
-
-If the attempt to capture on it succeeds, the interface is somehow not
-being reported by the mechanism Wireshark uses to get a list of
-interfaces; please report this to wireshark-dev@wireshark.org giving
-full details of the problem, including
-
- • the operating system you're using, and the version of that
- operating system (for Linux, give both the version number of the
- kernel and the name and version number of the distribution you're
- using);
- • the type of network device you're using.
-
-If you are having trouble capturing on a particular network interface,
-and you've made sure that (on platforms that require it) you've
-arranged that packet capture support is present, as per the above,
-first try capturing on that device with tcpdump.
-
-If you can capture on the interface with tcpdump, send mail to
-wireshark-users@wireshark.org giving full details of the problem,
-including
-
- • the operating system you're using, and the version of that
- operating system (for Linux, give both the version number of the
- kernel and the name and version number of the distribution you're
- using);
- • the type of network device you're using;
- • the error message you get from Wireshark.
-
-If you cannot capture on the interface with tcpdump, this is almost
-certainly a problem with one or more of:
-
- • the operating system you're using;
- • the device driver for the interface you're using;
- • the libpcap library;
-
-so you should report the problem to the company or organization that
-produces the OS (in the case of a Linux distribution, report the
-problem to whoever produces the distribution).
-
-You may also want to ask the wireshark-users@wireshark.org and the
-tcpdump-workers@tcpdump.org mailing lists to see if anybody happens to
-know about the problem and know a workaround or fix for the problem.
-In your mail, please give full details of the problem, as described
-above, and also indicate that the problem occurs with tcpdump not just
-with Wireshark.
-
-Q 9.2: I'm running Wireshark on a UNIX-flavored OS; why do no network
-interfaces show up in the list of interfaces in the "Interface:" field
-in the dialog box popped up by "Capture->Start"?
-
-A: This is really the same question as the previous one; see the
-response to that question.
-
-Q 9.3: I'm capturing packets on Linux; why do the time stamps have
-only 100ms resolution, rather than 1us resolution?
-
-A: Wireshark gets time stamps from libpcap/WinPcap, and libpcap/
-WinPcap get them from the OS kernel, so Wireshark - and any other
-program using libpcap, such as tcpdump - is at the mercy of the time
-stamping code in the OS for time stamps.
-
-At least on x86-based machines, Linux can get high-resolution time
-stamps on newer processors with the Time Stamp Counter (TSC) register;
-for example, Intel x86 processors, starting with the Pentium Pro, and
-including all x86 processors since then, have had a TSC, and other
-vendors probably added the TSC at some point to their families of x86
-processors.
-
-The Linux kernel must be configured with the CONFIG_X86_TSC option
-enabled in order to use the TSC. Make sure this option is enabled in
-your kernel.
-
-In addition, some Linux distributions may have bugs in their versions
-of the kernel that cause packets not to be given high-resolution time
-stamps even if the TSC is enabled. See, for example, bug 61111 for Red
-Hat Linux 7.2. If your distribution has a bug such as this, you may
-have to run a standard kernel from kernel.org in order to get
-high-resolution time stamps.
+ Q 9.1: I'm running Wireshark on a UNIX-flavored OS; why does some
+ network interface on my machine not show up in the list of interfaces
+ in the "Interface:" field in the dialog box popped up by
+ "Capture->Start", and/or why does Wireshark give me an error if I try
+ to capture on that interface?
+
+ A: You may need to run Wireshark from an account with sufficient
+ privileges to capture packets, such as the super-user account, or may
+ need to give your account sufficient privileges to capture packets.
+ Only those interfaces that Wireshark can open for capturing show up in
+ that list; if you don't have sufficient privileges to capture on any
+ interfaces, no interfaces will show up in the list. See the Wireshark
+ Wiki item on capture privileges for details on how to give a
+ particular account or account group capture privileges on platforms
+ where that can be done.
+
+ If you are running Wireshark from an account with sufficient
+ privileges, then note that Wireshark relies on the libpcap library,
+ and on the facilities that come with the OS on which it's running in
+ order to do captures. On some OSes, those facilities aren't present by
+ default; see the Wireshark Wiki item on adding capture support for
+ details.
+
+ And, even if you're running with an account that has sufficient
+ privileges to capture, and capture support is present in your OS, if
+ the OS or the libpcap library don't support capturing on a particular
+ network interface device or particular types of devices, Wireshark
+ won't be able to capture on that device.
+
+ On Solaris, note that libpcap 0.6.2 and earlier didn't support Token
+ Ring interfaces; the current version, 0.7.2, does support Token Ring,
+ and the current version of Wireshark works with libcap 0.7.2 and
+ later.
+
+ If an interface doesn't show up in the list of interfaces in the
+ "Interface:" field, and you know the name of the interface, try
+ entering that name in the "Interface:" field and capturing on that
+ device.
+
+ If the attempt to capture on it succeeds, the interface is somehow not
+ being reported by the mechanism Wireshark uses to get a list of
+ interfaces; please report this to wireshark-dev@wireshark.org giving
+ full details of the problem, including
+ * the operating system you're using, and the version of that
+ operating system (for Linux, give both the version number of the
+ kernel and the name and version number of the distribution you're
+ using);
+ * the type of network device you're using.
+
+ If you are having trouble capturing on a particular network interface,
+ and you've made sure that (on platforms that require it) you've
+ arranged that packet capture support is present, as per the above,
+ first try capturing on that device with tcpdump.
+
+ If you can capture on the interface with tcpdump, send mail to
+ wireshark-users@wireshark.org giving full details of the problem,
+ including
+ * the operating system you're using, and the version of that
+ operating system (for Linux, give both the version number of the
+ kernel and the name and version number of the distribution you're
+ using);
+ * the type of network device you're using;
+ * the error message you get from Wireshark.
+
+ If you cannot capture on the interface with tcpdump, this is almost
+ certainly a problem with one or more of:
+ * the operating system you're using;
+ * the device driver for the interface you're using;
+ * the libpcap library;
+
+ so you should report the problem to the company or organization that
+ produces the OS (in the case of a Linux distribution, report the
+ problem to whoever produces the distribution).
+
+ You may also want to ask the wireshark-users@wireshark.org and the
+ tcpdump-workers@tcpdump.org mailing lists to see if anybody happens to
+ know about the problem and know a workaround or fix for the problem.
+ In your mail, please give full details of the problem, as described
+ above, and also indicate that the problem occurs with tcpdump not just
+ with Wireshark.
+
+ Q 9.2: I'm running Wireshark on a UNIX-flavored OS; why do no network
+ interfaces show up in the list of interfaces in the "Interface:" field
+ in the dialog box popped up by "Capture->Start"?
+
+ A: This is really the same question as the previous one; see the
+ response to that question.
+
+ Q 9.3: I'm capturing packets on Linux; why do the time stamps have
+ only 100ms resolution, rather than 1us resolution?
+
+ A: Wireshark gets time stamps from libpcap/WinPcap, and
+ libpcap/WinPcap get them from the OS kernel, so Wireshark - and any
+ other program using libpcap, such as tcpdump - is at the mercy of the
+ time stamping code in the OS for time stamps.
+
+ At least on x86-based machines, Linux can get high-resolution time
+ stamps on newer processors with the Time Stamp Counter (TSC) register;
+ for example, Intel x86 processors, starting with the Pentium Pro, and
+ including all x86 processors since then, have had a TSC, and other
+ vendors probably added the TSC at some point to their families of x86
+ processors.
+
+ The Linux kernel must be configured with the CONFIG_X86_TSC option
+ enabled in order to use the TSC. Make sure this option is enabled in
+ your kernel.
+
+ In addition, some Linux distributions may have bugs in their versions
+ of the kernel that cause packets not to be given high-resolution time
+ stamps even if the TSC is enabled. See, for example, bug 61111 for Red
+ Hat Linux 7.2. If your distribution has a bug such as this, you may
+ have to run a standard kernel from kernel.org in order to get
+ high-resolution time stamps.
10. Capturing packets on wireless LANs
-Q 10.1: How can I capture raw 802.11 frames, including non-data
-(management, beacon) frames?
+ Q 10.1: How can I capture raw 802.11 frames, including non-data
+ (management, beacon) frames?
-A: That depends on the operating system on which you're running, and
-on the 802.11 interface on which you're capturing.
+ 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.
+ 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.
+ 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.
+ 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.
+ 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.
+ 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?
+ Q 10.2: How do I capture on an 802.11 device in monitor mode?
-A: Whether you will be able to capture in monitor mode depends on the
-operating system, adapter, and driver you're using. See the previous
-question for information on monitor mode, including a link to the
-Wireshark Wiki page that gives details on 802.11 capturing.
+ A: Whether you will be able to capture in monitor mode depends on the
+ operating system, adapter, and driver you're using. See the previous
+ question for information on monitor mode, including a link to the
+ Wireshark Wiki page that gives details on 802.11 capturing.
11. Viewing traffic
-Q 11.1: Why am I seeing lots of packets with incorrect TCP checksums?
-
-A: If the packets that have incorrect TCP checksums are all being sent
-by the machine on which Wireshark is running, this is probably because
-the network interface on which you're capturing does TCP checksum
-offloading. That means that the TCP checksum is added to the packet by
-the network interface, not by the OS's TCP/IP stack; when capturing on
-an interface, packets being sent by the host on which you're capturing
-are directly handed to the capture interface by the OS, which means
-that they are handed to the capture interface without a TCP checksum
-being added to them.
-
-The only way to prevent this from happening would be to disable TCP
-checksum offloading, but
-
- 1. that might not even be possible on some OSes;
- 2. that could reduce networking performance significantly.
-
-However, you can disable the check that Wireshark does of the TCP
-checksum, so that it won't report any packets as having TCP checksum
-errors, and so that it won't refuse to do TCP reassembly due to a
-packet having an incorrect TCP checksum. That can be set as an
-Wireshark preference by selecting "Preferences" from the "Edit" menu,
-opening up the "Protocols" list in the left-hand pane of the
-"Preferences" dialog box, selecting "TCP", from that list, turning off
-the "Check the validity of the TCP checksum when possible" option,
-clicking "Save" if you want to save that setting in your preference
-file, and clicking "OK".
-
-It can also be set on the Wireshark or TShark command line with a -o
-tcp.check_checksum:false command-line flag, or manually set in your
-preferences file by adding a tcp.check_checksum:false line.
-
-Q 11.2: I've just installed Wireshark, and the traffic on my local LAN
-is boring. Where can I find more interesting captures?
-
-A: We have a collection of strange and exotic sample capture files at
-http://wiki.wireshark.org/SampleCaptures
-
-Q 11.3: Why doesn't Wireshark correctly identify RTP packets? It shows
-them only as UDP.
-
-A: Wireshark can identify a UDP datagram as containing a packet of a
-particular protocol running atop UDP only if
-
- 1. The protocol in question has a particular standard port number,
- and the UDP source or destination port number is that port
- 2. Packets of that protocol can be identified by looking for a
- "signature" of some type in the packet - i.e., some data that, if
- Wireshark finds it in some particular part of a packet, means that
- the packet is almost certainly a packet of that type.
- 3. Some other traffic earlier in the capture indicated that, for
- example, UDP traffic between two particular addresses and ports
- will be RTP traffic.
-
-RTP doesn't have a standard port number, so 1) doesn't work; it
-doesn't, as far as I know, have any "signature", so 2) doesn't work.
-
-That leaves 3). If there's RTSP traffic that sets up an RTP session,
-then, at least in some cases, the RTSP dissector will set things up so
-that subsequent RTP traffic will be identified. Currently, that's the
-only place we do that; there may be other places.
-
-However, there will always be places where Wireshark is simply
-incapable of deducing that a given UDP flow is RTP; a mechanism would
-be needed to allow the user to specify that a given conversation
-should be treated as RTP. As of Wireshark 0.8.16, such a mechanism
-exists; if you select a UDP or TCP packet, the right mouse button menu
-will have a "Decode As..." menu item, which will pop up a dialog box
-letting you specify that the source port, the destination port, or
-both the source and destination ports of the packet should be
-dissected as some particular protocol.
-
-Q 11.4: Why doesn't Wireshark show Yahoo Messenger packets in captures
-that contain Yahoo Messenger traffic?
-
-A: Wireshark only recognizes as Yahoo Messenger traffic packets to or
-from TCP port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP
-segments that start with the middle of a Yahoo Messenger packet that
-takes more than one TCP segment will not be recognized as Yahoo
-Messenger packets (even if the TCP segment also contains the beginning
-of another Yahoo Messenger packet).
+ Q 11.1: Why am I seeing lots of packets with incorrect TCP checksums?
+
+ A: If the packets that have incorrect TCP checksums are all being sent
+ by the machine on which Wireshark is running, this is probably because
+ the network interface on which you're capturing does TCP checksum
+ offloading. That means that the TCP checksum is added to the packet by
+ the network interface, not by the OS's TCP/IP stack; when capturing on
+ an interface, packets being sent by the host on which you're capturing
+ are directly handed to the capture interface by the OS, which means
+ that they are handed to the capture interface without a TCP checksum
+ being added to them.
+
+ The only way to prevent this from happening would be to disable TCP
+ checksum offloading, but
+ 1. that might not even be possible on some OSes;
+ 2. that could reduce networking performance significantly.
+
+ However, you can disable the check that Wireshark does of the TCP
+ checksum, so that it won't report any packets as having TCP checksum
+ errors, and so that it won't refuse to do TCP reassembly due to a
+ packet having an incorrect TCP checksum. That can be set as an
+ Wireshark preference by selecting "Preferences" from the "Edit" menu,
+ opening up the "Protocols" list in the left-hand pane of the
+ "Preferences" dialog box, selecting "TCP", from that list, turning off
+ the "Check the validity of the TCP checksum when possible" option,
+ clicking "Save" if you want to save that setting in your preference
+ file, and clicking "OK".
+
+ It can also be set on the Wireshark or TShark command line with a -o
+ tcp.check_checksum:false command-line flag, or manually set in your
+ preferences file by adding a tcp.check_checksum:false line.
+
+ Q 11.2: I've just installed Wireshark, and the traffic on my local LAN
+ is boring. Where can I find more interesting captures?
+
+ A: We have a collection of strange and exotic sample capture files at
+ http://wiki.wireshark.org/SampleCaptures
+
+ Q 11.3: Why doesn't Wireshark correctly identify RTP packets? It shows
+ them only as UDP.
+
+ A: Wireshark can identify a UDP datagram as containing a packet of a
+ particular protocol running atop UDP only if
+ 1. The protocol in question has a particular standard port number,
+ and the UDP source or destination port number is that port
+ 2. Packets of that protocol can be identified by looking for a
+ "signature" of some type in the packet - i.e., some data that, if
+ Wireshark finds it in some particular part of a packet, means that
+ the packet is almost certainly a packet of that type.
+ 3. Some other traffic earlier in the capture indicated that, for
+ example, UDP traffic between two particular addresses and ports
+ will be RTP traffic.
+
+ RTP doesn't have a standard port number, so 1) doesn't work; it
+ doesn't, as far as I know, have any "signature", so 2) doesn't work.
+
+ That leaves 3). If there's RTSP traffic that sets up an RTP session,
+ then, at least in some cases, the RTSP dissector will set things up so
+ that subsequent RTP traffic will be identified. Currently, that's the
+ only place we do that; there may be other places.
+
+ However, there will always be places where Wireshark is simply
+ incapable of deducing that a given UDP flow is RTP; a mechanism would
+ be needed to allow the user to specify that a given conversation
+ should be treated as RTP. As of Wireshark 0.8.16, such a mechanism
+ exists; if you select a UDP or TCP packet, the right mouse button menu
+ will have a "Decode As..." menu item, which will pop up a dialog box
+ letting you specify that the source port, the destination port, or
+ both the source and destination ports of the packet should be
+ dissected as some particular protocol.
+
+ Q 11.4: Why doesn't Wireshark show Yahoo Messenger packets in captures
+ that contain Yahoo Messenger traffic?
+
+ A: Wireshark only recognizes as Yahoo Messenger traffic packets to or
+ from TCP port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP
+ segments that start with the middle of a Yahoo Messenger packet that
+ takes more than one TCP segment will not be recognized as Yahoo
+ Messenger packets (even if the TCP segment also contains the beginning
+ of another Yahoo Messenger packet).
12. Filtering traffic
-Q 12.1: I saved a filter and tried to use its name to filter the
-display; why do I get an "Unexpected end of filter string" error?
-
-A: You cannot use the name of a saved display filter as a filter. To
-filter the display, you can enter a display filter expression - not
-the name of a saved display filter - in the "Filter:" box at the
-bottom of the display, and type the key or press the "Apply" button
-(that does not require you to have a saved filter), or, if you want to
-use a saved filter, you can press the "Filter:" button, select the
-filter in the dialog box that pops up, and press the "OK" button.
+ Q 12.1: I saved a filter and tried to use its name to filter the
+ display; why do I get an "Unexpected end of filter string" error?
-Q 12.2: How can I search for, or filter, packets that have a
-particular string anywhere in them?
+ A: You cannot use the name of a saved display filter as a filter. To
+ filter the display, you can enter a display filter expression - not
+ the name of a saved display filter - in the "Filter:" box at the
+ bottom of the display, and type the key or press the "Apply" button
+ (that does not require you to have a saved filter), or, if you want to
+ use a saved filter, you can press the "Filter:" button, select the
+ filter in the dialog box that pops up, and press the "OK" button.
-A: If you want to do this when capturing, you can't. That's a feature
-that would be hard to implement in capture filters without changes to
-the capture filter code, which, on many platforms, is in the OS kernel
-and, on other platforms, is in the libpcap library.
+ Q 12.2: How can I search for, or filter, packets that have a
+ particular string anywhere in them?
-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.
+ A: If you want to do this when capturing, you can't. That's a feature
+ that would be hard to implement in capture filters without changes to
+ the capture filter code, which, on many platforms, is in the OS kernel
+ and, on other platforms, is in the libpcap library.
-In 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 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.15 and later, you can search for those packets using either the
-mechanism introduced in 0.9.14 or using the new "contains" operator in
-filter expressions, which lets you search the entire packet or text
-string or byte string fields in the packet; the "contains" operator
-can also be used in expressions used to filter the display.
+ 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).
-Q 12.3: How do I filter a capture to see traffic for virus XXX?
+ In 0.9.15 and later, you can search for those packets using either the
+ mechanism introduced in 0.9.14 or using the new "contains" operator in
+ filter expressions, which lets you search the entire packet or text
+ string or byte string fields in the packet; the "contains" operator
+ can also be used in expressions used to filter the display.
-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.
+ Q 12.3: How do I filter a capture to see traffic for virus XXX?
-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.
+ 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.
-The Bleeding Edge of Snort has a collection of signatures for Snort to
-detect various viruses, worms, and the like.
+ 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.
git.samba.org / obnox / wireshark / wip.git / commitdiff