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