From a8f1f4b330e6a28a1d11ed1fe2a6433970a8d039 Mon Sep 17 00:00:00 2001 From: Gerald Combs Date: Wed, 7 Jun 2006 12:54:00 +0000 Subject: [PATCH] Better update for the FAQ. We can now use the URL http://www.wireshark.org/faq_plain.html, which doesn't have any images or menus. svn path=/trunk/; revision=18382 --- FAQ | 2855 +++++++++++++++++++------------------------------- help/faq.txt | 2514 ++++++++++++++++++++++---------------------- make-faq | 3 +- 3 files changed, 2304 insertions(+), 3068 deletions(-) diff --git a/FAQ b/FAQ index a8db25ba04..a76ee0a1de 100644 --- a/FAQ +++ b/FAQ @@ -11,202 +11,192 @@ 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. Downloading Wireshark: 2.1 Why do I get an error when I try to run the Win32 installer? - 2.2 Why can't I get to the WinPcap Web site in order to download WinPcap? +3. Installing Wireshark: -3. Installing Ethereal: + 3.1 I installed the Wireshark RPM (or other package); why did it + install TShark but not Wireshark? - 3.1 I installed an Ethereal RPM; why did it install TShark but not - Ethereal? +4. Building Wireshark: -4. Building Ethereal: - - 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? + 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 Ethereal: +5. Starting Wireshark: - 5.1 Why does Ethereal 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 TShark with the "-x" option, why does it crash with an - error + 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? - "** ERROR **: file print.c: line 691 (print_line): should not be reached. - - 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.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.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.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? - - 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 + 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? - 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.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? @@ -214,873 +204,151 @@ 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? + Q 1.5: Can I use Wireshark 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?" + 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 Ethereal as part of my commercial product?", see the - next entry in the FAQ. + If you mean "Can I use Wireshark 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? + 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 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. + 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 Ethereal and a commercial program as - long as they communicate "at arm's length", as per this item in the GPL FAQ. + 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.5: What protocols are currently supported? + Q 1.7: 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. + A: There are currently hundreds of supported protocols and media. + Details can be found in the wireshark(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.8: Are there any plans to support {your favorite protocol}? - Q 1.6: 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. - 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.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. + 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. + 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? + Q 1.10: What devices can Wireshark 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). + 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 @@ -1099,8 +367,8 @@ cies * 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 @@ -1108,765 +376,736 @@ cies * 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. + 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? + Q 1.11: Does Wireshark work on Windows Me? - 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. + 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. - 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. + Q 1.12: Does Wireshark work on Windows XP? - Q 1.10: Does Ethereal 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.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.02 and earlier versions of WinPcap didn't - support Windows Me. You should also install the latest version of Ethereal - as well. - - Q 1.11: Does Ethereal 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 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 + 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? - 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). + 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? + 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. + 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. + 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? + 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 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.) + 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 Ethereal on Windows, why does the build fail - because of conflicts between winsock.h and winsock2.h? + 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 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.) + 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. + 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 +5. Starting Wireshark - Q 5.1: Why does Ethereal crash with a Bus Error when I try to run it on - Solaris 8? + 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 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.) + 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. + 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 + 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? - "** ERROR **: file print.c: line 691 (print_line): should not be reached. + 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. - 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 + 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. + 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.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? + 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 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. + 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 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 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, the local mirror of the WinPcap Web site, or the Wiretapped.net mirror - of the WinPcap site. + The WinPcap driver and libraries can be downloaded from the WinPcap + Web site or the Wiretapped.net mirror of the WinPcap site. - Q 5.6: Why do I get the error + Q 5.5: I've installed Wireshark from Fink on Mac OS X; why is it very + slow to start up? - 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: 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). + * 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.3: Why does my machine crash or reset itself when I select "Start" from - the "Capture" menu or select "Preferences" from the "Edit" menu? + 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 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. + 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? + 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. + 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 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. + 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.) + 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 + 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. + 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? + 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. + 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. + 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. + 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, 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. + 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). + 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. + 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, 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. + 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). + 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. + 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? + 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. + 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. + 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? + 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. + 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: + 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. + 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. + 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 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. + 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 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 + 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). + 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, 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. + 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? + 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 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. + 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 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. + 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. + "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. + 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; + 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: @@ -1874,195 +1113,209 @@ cies * 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. + 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 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"? + 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. + 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"? + 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. + 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. + 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? + 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. + 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. + 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? + 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. + 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? + 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 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. + 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. + 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? + 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. + 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? + 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. + 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? + 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. + 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. + See MicroLogix's list of cards supported with WinPcap for information + on support of various adapters and drivers with WinPcap. - Q 8.10: I'm trying to capture 802.11 traffic on Windows; why am I seeing - packets received by the machine on which I'm capturing traffic, but not - packets sent by that machine? + Q 8.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. + 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? + 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. + 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? + 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 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. + 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 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. + 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, Ethereal won't be able to capture 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. - 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. + 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. + "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; 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); + 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: @@ -2071,76 +1324,81 @@ cies * 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. + 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 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"? + 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. @@ -2148,138 +1406,137 @@ cies 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. + 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 + 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. + 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. + 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. + 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. + 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 Ethereal show Yahoo Messenger packets in captures that - contain Yahoo Messenger traffic? + Q 11.4: Why doesn't Wireshark 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). + 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. diff --git a/help/faq.txt b/help/faq.txt index ce7fe5bad6..a76ee0a1de 100644 --- a/help/faq.txt +++ b/help/faq.txt @@ -8,1557 +8,1535 @@ 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.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.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.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.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.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.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? + 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.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. + 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. + 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? + 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 -. + 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. + Commercial support, training, and development services are available + from CACE Technologies. -Q 1.4: How much does Wireshark 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 Wireshark 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. + 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? + 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?" + 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. + 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? + 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. + 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. + 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? + 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. + 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}? + 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. + 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}? + 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. + 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 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. + 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. + 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? + 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 ). + 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: + 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 - • 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. -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? -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. -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? -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 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? + 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 + Q 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? -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). + 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? + 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. + 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. + 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? + 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.) + 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? + 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.) + 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. + 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? + 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.) + 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. + 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? + 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. + 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? + 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. + 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? + 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. + 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 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. + 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.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? + 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: + 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 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). -so: + 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? - • 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. + 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). + 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. + 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? + 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. + 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 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. + 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. + 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: + 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. - 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 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 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. + 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. - 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. + 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. - 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. + 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; - 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. + 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. - 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 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 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 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 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. + 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; -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 + 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. - • 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. + 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. -If WinDump does not list the interface, this is almost certainly a -problem with one or more of: + 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"? - • the operating system you're using; - • the device driver for the interface you're using; - • the WinPcap library and/or the WinPcap device driver; + A: This is really the same question as the previous one; see the + response to that question. -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. + 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"? -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. + 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. -If you can capture on the interface with WinDump, send mail to -wireshark-users@wireshark.org giving full details of the problem, -including + 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. - • 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. + 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? -If you cannot capture on the interface with WinDump, this is almost -certainly a problem with one or more of: + 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. - • the operating system you're using; - • the device driver for the interface you're using; - • the WinPcap library and/or the WinPcap device driver; + 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. -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. + 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? -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. + 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.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"? + Q 8.6: I'm running Wireshark on Windows; why am I not seeing any + traffic being sent by the machine running Wireshark? -A: This is really the same question as the previous one; see the -response to that question. + 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. -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"? + 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. -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. + 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? -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. + 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.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? + Q 8.8: I'm capturing packets on {Windows 95, Windows 98, Windows Me}; + why are the time stamps on packets wrong? -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. + A: This is due to a bug in WinPcap. The bug should be fixed in WinPcap + 3.0 and later releases. -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.9: I'm trying to capture 802.11 traffic on Windows; why am I not + seeing any packets? -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: 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. -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. + See MicroLogix's list of cards supported with WinPcap for information + on support of various adapters and drivers with WinPcap. -Q 8.6: I'm running Wireshark on Windows; why am I not seeing any -traffic being sent by the machine running Wireshark? + 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: 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. + A: This appears to be another problem with promiscuous mode; try + turning it off. -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.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? -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. + 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? + 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. + 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 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. + 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. + 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 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 + 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. - • 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); + * the type of network device you're using; + * the error message you get from Wireshark. -If you can capture on the interface with tcpdump, send mail to -wireshark-users@wireshark.org giving full details of the problem, -including + 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; - • 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. + 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). -If you cannot capture on the interface with tcpdump, this is almost -certainly a problem with one or more of: + 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. - • the operating system you're using; - • the device driver for the interface you're using; - • the libpcap library; + 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"? -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). + A: This is really the same question as the previous one; see the + response to that question. -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.3: I'm capturing packets on Linux; why do the time stamps have + only 100ms resolution, rather than 1us resolution? -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: 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. -A: This is really the same question as the previous one; see the -response to that question. + 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. -Q 9.3: I'm capturing packets on Linux; why do the time stamps have -only 100ms resolution, rather than 1us resolution? + 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. -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. + 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? + 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. + 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 + 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. - 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". -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. -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? -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 -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. -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. -A: Wireshark can identify a UDP datagram as containing a packet of a -particular protocol running atop UDP only if + 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. - 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. + 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. -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. + 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. -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. + Q 11.4: Why doesn't Wireshark show Yahoo Messenger packets in captures + that contain Yahoo Messenger traffic? -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). + 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). + In 0.9.14, you can search for, but not filter, packets that have a + particular string; this has been added to the "Find Frame" dialog + ("Find Frame" under the "Edit" menu, or control-F). -In 0.9.15 and later, you can search for those packets using either the -mechanism introduced in 0.9.14 or using the new "contains" operator in -filter expressions, which lets you search the entire packet or text -string or byte string fields in the packet; the "contains" operator -can also be used in expressions used to filter the display. + In 0.9.15 and later, you can search for those packets using either the + mechanism introduced in 0.9.14 or using the new "contains" operator in + filter expressions, which lets you search the entire packet or text + string or byte string fields in the packet; the "contains" operator + can also be used in expressions used to filter the display. -Q 12.3: How do I filter a capture to see traffic for virus XXX? + 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 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. + 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. diff --git a/make-faq b/make-faq index 8ff0396573..d41c05e4dd 100755 --- a/make-faq +++ b/make-faq @@ -19,7 +19,8 @@ cat >FAQ <>FAQ +lynx -dump -nolist "http://www.wireshark.org/faq_plain.html" | \ + sed -e '1,/^Index/d' >>FAQ echo echo "Now verfiy everything is OK and copy FAQ to help/faq.txt"