nexmon – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | Index |
2 | |||
3 | 1. General Questions: |
||
4 | |||
5 | 1.1 What is Wireshark? |
||
6 | |||
7 | 1.2 What's up with the name change? Is Wireshark a fork? |
||
8 | |||
9 | 1.3 Where can I get help? |
||
10 | |||
11 | 1.4 What kind of shark is Wireshark? |
||
12 | |||
13 | 1.5 How is Wireshark pronounced, spelled and capitalized? |
||
14 | |||
15 | 1.6 How much does Wireshark cost? |
||
16 | |||
17 | 1.7 But I just paid someone on eBay for a copy of Wireshark! |
||
18 | Did I get ripped off? |
||
19 | |||
20 | 1.8 Can I use Wireshark commercially? |
||
21 | |||
22 | 1.9 Can I use Wireshark as part of my commercial product? |
||
23 | |||
24 | 1.10 What protocols are currently supported? |
||
25 | |||
26 | 1.11 Are there any plans to support {your favorite protocol}? |
||
27 | |||
28 | 1.12 Can Wireshark read capture files from {your favorite |
||
29 | network analyzer}? |
||
30 | |||
31 | 1.13 What devices can Wireshark use to capture packets? |
||
32 | |||
33 | 1.14 Does Wireshark work on Windows Vista or Windows Server |
||
34 | 2008? |
||
35 | |||
36 | 2. Installing Wireshark: |
||
37 | |||
38 | 2.1 I installed the Wireshark RPM (or other package); why did |
||
39 | it install TShark but not Wireshark? |
||
40 | |||
41 | 3. Building Wireshark: |
||
42 | |||
43 | 3.1 I have libpcap installed; why did the configure script not |
||
44 | find pcap.h or bpf.h? |
||
45 | |||
46 | 3.2 Why do I get the error dftest_DEPENDENCIES was already |
||
47 | defined in condition TRUE, which implies condition |
||
48 | HAVE_PLUGINS_TRUE when I try to build Wireshark from SVN or a |
||
49 | SVN snapshot? |
||
50 | |||
51 | 3.3 Why does the linker fail with a number of "Output line too |
||
52 | long." messages followed by linker errors when I try to build |
||
53 | Wireshark? |
||
54 | |||
55 | 3.4 When I try to build Wireshark on Solaris, why does the link |
||
56 | fail complaining that plugin_list is undefined? |
||
57 | |||
58 | 3.5 When I try to build Wireshark on Windows, why does the |
||
59 | build fail because of conflicts between winsock.h and |
||
60 | winsock2.h? |
||
61 | |||
62 | 4. Starting Wireshark: |
||
63 | |||
64 | 4.1 Why does Wireshark crash with a Bus Error when I try to run |
||
65 | it on Solaris 8? |
||
66 | |||
67 | 4.2 When I try to run Wireshark, why does it complain about |
||
68 | sprint_realloc_objid being undefined? |
||
69 | |||
70 | 4.3 I've installed Wireshark from Fink on OS X; why is it very |
||
71 | slow to start up? |
||
72 | |||
73 | 5. Crashes and other fatal errors: |
||
74 | |||
75 | 5.1 I have an XXX network card on my machine; if I try to |
||
76 | capture on it, why does my machine crash or reset itself? |
||
77 | |||
78 | 5.2 Why does my machine crash or reset itself when I select |
||
79 | "Start" from the "Capture" menu or select "Preferences" from |
||
80 | the "Edit" menu? |
||
81 | |||
82 | 6. Capturing packets: |
||
83 | |||
84 | 6.1 When I use Wireshark to capture packets, why do I see only |
||
85 | packets to and from my machine, or not see all the traffic I'm |
||
86 | expecting to see from or to the machine I'm trying to monitor? |
||
87 | |||
88 | 6.2 When I capture with Wireshark, why can't I see any TCP |
||
89 | packets other than packets to and from my machine, even though |
||
90 | another analyzer on the network sees those packets? |
||
91 | |||
92 | 6.3 Why am I only seeing ARP packets when I try to capture |
||
93 | traffic? |
||
94 | |||
95 | 6.4 Why am I not seeing any traffic when I try to capture |
||
96 | traffic? |
||
97 | |||
98 | 6.5 Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)? |
||
99 | |||
100 | 6.6 How do I put an interface into promiscuous mode? |
||
101 | |||
102 | 6.7 I can set a display filter just fine; why don't capture |
||
103 | filters work? |
||
104 | |||
105 | 6.8 I'm entering valid capture filters; why do I still get |
||
106 | "parse error" errors? |
||
107 | |||
108 | 6.9 How can I capture packets with CRC errors? |
||
109 | |||
110 | 6.10 How can I capture entire frames, including the FCS? |
||
111 | |||
112 | 6.11 I'm capturing packets on a machine on a VLAN; why don't |
||
113 | the packets I'm capturing have VLAN tags? |
||
114 | |||
115 | 6.12 Why does Wireshark hang after I stop a capture? |
||
116 | |||
117 | 7. Capturing packets on Windows: |
||
118 | |||
119 | 7.1 I'm running Wireshark on Windows; why does some network |
||
120 | interface on my machine not show up in the list of interfaces |
||
121 | in the "Interface:" field in the dialog box popped up by |
||
122 | "Capture->Start", and/or why does Wireshark give me an error if |
||
123 | I try to capture on that interface? |
||
124 | |||
125 | 7.2 I'm running Wireshark on Windows; why do no network |
||
126 | interfaces show up in the list of interfaces in the |
||
127 | "Interface:" field in the dialog box popped up by |
||
128 | "Capture->Start"? |
||
129 | |||
130 | 7.3 I'm running Wireshark on Windows; why doesn't my serial |
||
131 | port/ADSL modem/ISDN modem show up in the list of interfaces in |
||
132 | the "Interface:" field in the dialog box popped up by |
||
133 | "Capture->Start"? |
||
134 | |||
135 | 7.4 I'm running Wireshark on Windows NT 4.0/Windows |
||
136 | 2000/Windows XP/Windows Server 2003; my machine has a PPP |
||
137 | (dial-up POTS, ISDN, etc.) interface, and it shows up in the |
||
138 | "Interface" item in the "Capture Options" dialog box. Why can |
||
139 | no packets be sent on or received from that network while I'm |
||
140 | trying to capture traffic on that interface? |
||
141 | |||
142 | 7.5 I'm running Wireshark on Windows; why am I not seeing any |
||
143 | traffic being sent by the machine running Wireshark? |
||
144 | |||
145 | 7.6 When I capture on Windows in promiscuous mode, I can see |
||
146 | packets other than those sent to or from my machine; however, |
||
147 | those packets show up with a "Short Frame" indication, unlike |
||
148 | packets to or from my machine. What should I do to arrange that |
||
149 | I see those packets in their entirety? |
||
150 | |||
151 | 7.7 I'm trying to capture 802.11 traffic on Windows; why am I |
||
152 | not seeing any packets? |
||
153 | |||
154 | 7.8 I'm trying to capture 802.11 traffic on Windows; why am I |
||
155 | seeing packets received by the machine on which I'm capturing |
||
156 | traffic, but not packets sent by that machine? |
||
157 | |||
158 | 7.9 I'm trying to capture Ethernet VLAN traffic on Windows, and |
||
159 | I'm capturing on a "raw" Ethernet device rather than a "VLAN |
||
160 | interface", so that I can see the VLAN headers; why am I seeing |
||
161 | packets received by the machine on which I'm capturing traffic, |
||
162 | but not packets sent by that machine? |
||
163 | |||
164 | 8. Capturing packets on UN*Xes: |
||
165 | |||
166 | 8.1 I'm running Wireshark on a UNIX-flavored OS; why does some |
||
167 | network interface on my machine not show up in the list of |
||
168 | interfaces in the "Interface:" field in the dialog box popped |
||
169 | up by "Capture->Start", and/or why does Wireshark give me an |
||
170 | error if I try to capture on that interface? |
||
171 | |||
172 | 8.2 I'm running Wireshark on a UNIX-flavored OS; why do no |
||
173 | network interfaces show up in the list of interfaces in the |
||
174 | "Interface:" field in the dialog box popped up by |
||
175 | "Capture->Start"? |
||
176 | |||
177 | 8.3 I'm capturing packets on Linux; why do the time stamps have |
||
178 | only 100ms resolution, rather than 1us resolution? |
||
179 | |||
180 | 9. Capturing packets on wireless LANs: |
||
181 | |||
182 | 9.1 How can I capture raw 802.11 frames, including non-data |
||
183 | (management, beacon) frames? |
||
184 | |||
185 | 9.2 How do I capture on an 802.11 device in monitor mode? |
||
186 | |||
187 | 10. Viewing traffic: |
||
188 | |||
189 | 10.1 Why am I seeing lots of packets with incorrect TCP |
||
190 | checksums? |
||
191 | |||
192 | 10.2 I've just installed Wireshark, and the traffic on my local |
||
193 | LAN is boring. Where can I find more interesting captures? |
||
194 | |||
195 | 10.3 Why doesn't Wireshark correctly identify RTP packets? It |
||
196 | shows them only as UDP. |
||
197 | |||
198 | 10.4 Why doesn't Wireshark show Yahoo Messenger packets in |
||
199 | captures that contain Yahoo Messenger traffic? |
||
200 | |||
201 | 11. Filtering traffic: |
||
202 | |||
203 | 11.1 I saved a filter and tried to use its name to filter the |
||
204 | display; why do I get an "Unexpected end of filter string" |
||
205 | error? |
||
206 | |||
207 | 11.2 How can I search for, or filter, packets that have a |
||
208 | particular string anywhere in them? |
||
209 | |||
210 | 11.3 How do I filter a capture to see traffic for virus XXX? |
||
211 | |||
212 | 1. General Questions |
||
213 | |||
214 | Q 1.1: What is Wireshark? |
||
215 | |||
216 | A: Wireshark® is a network protocol analyzer. It lets you |
||
217 | capture and interactively browse the traffic running on a |
||
218 | computer network. It has a rich and powerful feature set and is |
||
219 | world's most popular tool of its kind. It runs on most |
||
220 | computing platforms including Windows, OS X, Linux, and UNIX. |
||
221 | Network professionals, security experts, developers, and |
||
222 | educators around the world use it regularly. It is freely |
||
223 | available as open source, and is released under the GNU General |
||
224 | Public License version 2. |
||
225 | It is developed and maintained by a global team of protocol |
||
226 | experts, and it is an example of a disruptive technology. |
||
227 | Wireshark used to be known as Ethereal®. See the next question |
||
228 | for details about the name change. If you're still using |
||
229 | Ethereal, it is strongly recommended that you upgrade to |
||
230 | Wireshark as Ethereal is unsupported and has known security |
||
231 | vulnerabilities. |
||
232 | For more information, please see the About Wireshark page. |
||
233 | |||
234 | Q 1.2: What's up with the name change? Is Wireshark a fork? |
||
235 | |||
236 | A: In May of 2006, Gerald Combs (the original author of |
||
237 | Ethereal) went to work for CACE Technologies (best known for |
||
238 | WinPcap). Unfortunately, he had to leave the Ethereal |
||
239 | trademarks behind. |
||
240 | This left the project in an awkward position. The only |
||
241 | reasonable way to ensure the continued success of the project |
||
242 | was to change the name. This is how Wireshark was born. |
||
243 | Wireshark is almost (but not quite) a fork. Normally a "fork" |
||
244 | of an open source project results in two names, web sites, |
||
245 | development teams, support infrastructures, etc. This is the |
||
246 | case with Wireshark except for one notable exception -- every |
||
247 | member of the core development team is now working on |
||
248 | Wireshark. There has been no active development on Ethereal |
||
249 | since the name change. Several parts of the Ethereal web site |
||
250 | (such as the mailing lists, source code repository, and build |
||
251 | farm) have gone offline. |
||
252 | More information on the name change can be found here: |
||
253 | |||
254 | * Original press release |
||
255 | * NewsForge article |
||
256 | * Many other articles in our bibliography |
||
257 | |||
258 | Q 1.3: Where can I get help? |
||
259 | |||
260 | A: Community support is available on the Q&A site and on the |
||
261 | wireshark-users mailing list. Subscription information and |
||
262 | archives for all of Wireshark's mailing lists can be found at |
||
263 | https://www.wireshark.org/mailman/listinfo. An IRC channel |
||
264 | dedicated to Wireshark can be found at |
||
265 | irc://irc.freenode.net/wireshark. |
||
266 | Self-paced and instructor-led training is available at |
||
267 | Wireshark University. Wireshark University also offers |
||
268 | certification via the Wireshark Certified Network Analyst |
||
269 | program. |
||
270 | |||
271 | Q 1.4: What kind of shark is Wireshark? |
||
272 | |||
273 | A: carcharodon photoshopia. |
||
274 | |||
275 | Q 1.5: How is Wireshark pronounced, spelled and capitalized? |
||
276 | |||
277 | A: Wireshark is pronounced as the word wire followed |
||
278 | immediately by the word shark. Exact pronunciation and emphasis |
||
279 | may vary depending on your locale (e.g. Arkansas). |
||
280 | It's spelled with a capital W, followed by a lower-case |
||
281 | ireshark. It is not a CamelCase word, i.e., WireShark is |
||
282 | incorrect. |
||
283 | |||
284 | Q 1.6: How much does Wireshark cost? |
||
285 | |||
286 | A: Wireshark is "free software"; you can download it without |
||
287 | paying any license fee. The version of Wireshark you download |
||
288 | isn't a "demo" version, with limitations not present in a |
||
289 | "full" version; it is the full version. |
||
290 | The license under which Wireshark is issued is the GNU General |
||
291 | Public License version 2. See the GNU GPL FAQ for some more |
||
292 | information. |
||
293 | |||
294 | Q 1.7: But I just paid someone on eBay for a copy of Wireshark! |
||
295 | Did I get ripped off? |
||
296 | |||
297 | A: That depends. Did they provide any sort of value-added |
||
298 | product or service, such as installation support, installation |
||
299 | media, training, trace file analysis, or funky-colored |
||
300 | shark-themed socks? Probably not. |
||
301 | Wireshark is available for anyone to download, absolutely free, |
||
302 | at any time. Paying for a copy implies that you should get |
||
303 | something for your money. |
||
304 | |||
305 | Q 1.8: Can I use Wireshark commercially? |
||
306 | |||
307 | A: Yes, if, for example, you mean "I work for a commercial |
||
308 | organization; can I use Wireshark to capture and analyze |
||
309 | network traffic in our company's networks or in our customer's |
||
310 | networks?" |
||
311 | If you mean "Can I use Wireshark as part of my commercial |
||
312 | product?", see the next entry in the FAQ. |
||
313 | |||
314 | Q 1.9: Can I use Wireshark as part of my commercial product? |
||
315 | |||
316 | A: As noted, Wireshark is licensed under the GNU General Public |
||
317 | License, version 2. The GPL imposes conditions on your use of |
||
318 | GPL'ed code in your own products; you cannot, for example, make |
||
319 | a "derived work" from Wireshark, by making modifications to it, |
||
320 | and then sell the resulting derived work and not allow |
||
321 | recipients to give away the resulting work. You must also make |
||
322 | the changes you've made to the Wireshark source available to |
||
323 | all recipients of your modified version; those changes must |
||
324 | also be licensed under the terms of the GPL. See the GPL FAQ |
||
325 | for more details; in particular, note the answer to the |
||
326 | question about modifying a GPLed program and selling it |
||
327 | commercially, and the question about linking GPLed code with |
||
328 | other code to make a proprietary program. |
||
329 | You can combine a GPLed program such as Wireshark and a |
||
330 | commercial program as long as they communicate "at arm's |
||
331 | length", as per this item in the GPL FAQ. |
||
332 | We recommend keeping Wireshark and your product completely |
||
333 | separate, communicating over sockets or pipes. If you're |
||
334 | loading any part of Wireshark as a DLL, you're probably doing |
||
335 | it wrong. |
||
336 | |||
337 | Q 1.10: What protocols are currently supported? |
||
338 | |||
339 | A: There are currently hundreds of supported protocols and |
||
340 | media. Details can be found in the wireshark(1) man page. |
||
341 | |||
342 | Q 1.11: Are there any plans to support {your favorite |
||
343 | protocol}? |
||
344 | |||
345 | A: Support for particular protocols is added to Wireshark as a |
||
346 | result of people contributing that support; no formal plans for |
||
347 | adding support for particular protocols in particular future |
||
348 | releases exist. |
||
349 | |||
350 | Q 1.12: Can Wireshark read capture files from {your favorite |
||
351 | network analyzer}? |
||
352 | |||
353 | A: Support for particular capture file formats is added to |
||
354 | Wireshark as a result of people contributing that support; no |
||
355 | formal plans for adding support for particular capture file |
||
356 | formats in particular future releases exist. |
||
357 | If a network analyzer writes out files in a format already |
||
358 | supported by Wireshark (e.g., in libpcap format), Wireshark may |
||
359 | already be able to read them, unless the analyzer has added its |
||
360 | own proprietary extensions to that format. |
||
361 | If a network analyzer writes out files in its own format, or |
||
362 | has added proprietary extensions to another format, in order to |
||
363 | make Wireshark read captures from that network analyzer, we |
||
364 | would either have to have a specification for the file format, |
||
365 | or the extensions, sufficient to give us enough information to |
||
366 | read the parts of the file relevant to Wireshark, or would need |
||
367 | at least one capture file in that format AND a detailed textual |
||
368 | analysis of the packets in that capture file (showing packet |
||
369 | time stamps, packet lengths, and the top-level packet header) |
||
370 | in order to reverse-engineer the file format. |
||
371 | Note that there is no guarantee that we will be able to |
||
372 | reverse-engineer a capture file format. |
||
373 | |||
374 | Q 1.13: What devices can Wireshark use to capture packets? |
||
375 | |||
376 | A: Wireshark can read live data from Ethernet, Token-Ring, |
||
377 | FDDI, serial (PPP and SLIP) (if the OS on which it's running |
||
378 | allows Wireshark to do so), 802.11 wireless LAN (if the OS on |
||
379 | which it's running allows Wireshark to do so), ATM connections |
||
380 | (if the OS on which it's running allows Wireshark to do so), |
||
381 | and the "any" device supported on Linux by recent versions of |
||
382 | libpcap. |
||
383 | See the list of supported capture media on various OSes for |
||
384 | details (several items in there say "Unknown", which doesn't |
||
385 | mean "Wireshark can't capture on them", it means "we don't know |
||
386 | whether it can capture on them"; we expect that it will be able |
||
387 | to capture on many of them, but we haven't tried it ourselves - |
||
388 | if you try one of those types and it works, please update the |
||
389 | wiki page accordingly. |
||
390 | It can also read a variety of capture file formats, including: |
||
391 | |||
392 | * AG Group/WildPackets/Savvius |
||
393 | EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet Grabber |
||
394 | captures |
||
395 | * AIX's iptrace captures |
||
396 | * Accellent's 5Views LAN agent output |
||
397 | * Cinco Networks NetXRay captures |
||
398 | * Cisco Secure Intrusion Detection System IPLog output |
||
399 | * CoSine L2 debug output |
||
400 | * DBS Etherwatch VMS text output |
||
401 | * Endace Measurement Systems' ERF format captures |
||
402 | * EyeSDN USB S0 traces |
||
403 | * HP-UX nettl captures |
||
404 | * ISDN4BSD project i4btrace captures |
||
405 | * Linux Bluez Bluetooth stack hcidump -w traces |
||
406 | * Lucent/Ascend router debug output |
||
407 | * Microsoft Network Monitor captures |
||
408 | * Network Associates Windows-based Sniffer captures |
||
409 | * Network General/Network Associates DOS-based Sniffer |
||
410 | (compressed or uncompressed) captures |
||
411 | * Network Instruments Observer version 9 captures |
||
412 | * Novell LANalyzer captures |
||
413 | * RADCOM's WAN/LAN analyzer captures |
||
414 | * Shomiti/Finisar Surveyor captures |
||
415 | * Toshiba's ISDN routers dump output |
||
416 | * VMS TCPIPtrace/TCPtrace/UCX$TRACE output |
||
417 | * Visual Networks' Visual UpTime traffic capture |
||
418 | * libpcap, tcpdump and various other tools using tcpdump's |
||
419 | capture format |
||
420 | * snoop and atmsnoop output |
||
421 | |||
422 | so that it can read traces from various network types, as |
||
423 | captured by other applications or equipment, even if it cannot |
||
424 | itself capture on those network types. |
||
425 | |||
426 | Q 1.14: Does Wireshark work on Windows Vista or Windows Server |
||
427 | 2008? |
||
428 | |||
429 | A: Yes, but if you want to capture packets as a normal user, |
||
430 | you must make sure npf.sys is loaded. Wireshark's installer |
||
431 | enables this by default. This is not a concern if you run |
||
432 | Wireshark as Administrator, but this is discouraged. See the |
||
433 | CapturePrivileges page on the wiki for more details. |
||
434 | |||
435 | 2. Installing Wireshark |
||
436 | |||
437 | Q 2.1: I installed the Wireshark RPM (or other package); why |
||
438 | did it install TShark but not Wireshark? |
||
439 | |||
440 | A: Many distributions have separate Wireshark packages, one for |
||
441 | non-GUI components such as TShark, editcap, dumpcap, etc. and |
||
442 | one for the GUI. If this is the case on your system, there's |
||
443 | probably a separate package named wireshark-gnome or |
||
444 | wireshark-gtk+. Find it and install it. |
||
445 | |||
446 | 3. Building Wireshark |
||
447 | |||
448 | Q 3.1: I have libpcap installed; why did the configure script |
||
449 | not find pcap.h or bpf.h? |
||
450 | |||
451 | A: Are you sure pcap.h and bpf.h are installed? The official |
||
452 | distribution of libpcap only installs the libpcap.a library |
||
453 | file when "make install" is run. To install pcap.h and bpf.h, |
||
454 | you must run "make install-incl". If you're running Debian or |
||
455 | Redhat, make sure you have the "libpcap-dev" or "libpcap-devel" |
||
456 | packages installed. |
||
457 | It's also possible that pcap.h and bpf.h have been installed in |
||
458 | a strange location. If this is the case, you may have to tweak |
||
459 | aclocal.m4. |
||
460 | |||
461 | Q 3.2: Why do I get the error dftest_DEPENDENCIES was already |
||
462 | defined in condition TRUE, which implies condition |
||
463 | HAVE_PLUGINS_TRUE when I try to build Wireshark from SVN or a |
||
464 | SVN snapshot? |
||
465 | |||
466 | A: You probably have automake 1.5 installed on your machine |
||
467 | (the command automake --version will report the version of |
||
468 | automake on your machine). There is a bug in that version of |
||
469 | automake that causes this problem; upgrade to a later version |
||
470 | of automake (1.6 or later). |
||
471 | |||
472 | Q 3.3: Why does the linker fail with a number of "Output line |
||
473 | too long." messages followed by linker errors when I try to |
||
474 | build Wireshark? |
||
475 | |||
476 | A: The version of the sed command on your system is incapable |
||
477 | of handling very long lines. On Solaris, for example, |
||
478 | /usr/bin/sed has a line length limit too low to allow libtool |
||
479 | to work; /usr/xpg4/bin/sed can handle it, as can GNU sed if you |
||
480 | have it installed. |
||
481 | On Solaris, changing your command search path to search |
||
482 | /usr/xpg4/bin before /usr/bin should make the problem go away; |
||
483 | on any platform on which you have this problem, installing GNU |
||
484 | sed and changing your command path to search the directory in |
||
485 | which it is installed before searching the directory with the |
||
486 | version of sed that came with the OS should make the problem go |
||
487 | away. |
||
488 | |||
489 | Q 3.4: When I try to build Wireshark on Solaris, why does the |
||
490 | link fail complaining that plugin_list is undefined? |
||
491 | |||
492 | A: This appears to be due to a problem with some versions of |
||
493 | the GTK+ and GLib packages from www.sunfreeware.org; un-install |
||
494 | those packages, and try getting the 1.2.10 versions from that |
||
495 | site, or the versions from The Written Word, or the versions |
||
496 | from Sun's GNOME distribution, or the versions from the |
||
497 | supplemental software CD that comes with the Solaris media kit, |
||
498 | or build them from source from the GTK Web site. Then re-run |
||
499 | the configuration script, and try rebuilding Wireshark. (If you |
||
500 | get the 1.2.10 versions from www.sunfreeware.org, and the |
||
501 | problem persists, un-install them and try installing one of the |
||
502 | other versions mentioned.) |
||
503 | |||
504 | Q 3.5: When I try to build Wireshark on Windows, why does the |
||
505 | build fail because of conflicts between winsock.h and |
||
506 | winsock2.h? |
||
507 | |||
508 | A: As of Wireshark 0.9.5, you must install WinPcap 2.3 or |
||
509 | later, and the corresponding version of the developer's pack, |
||
510 | in order to be able to compile Wireshark; it will not compile |
||
511 | with older versions of the developer's pack. The symptoms of |
||
512 | this failure are conflicts between definitions in winsock.h and |
||
513 | in winsock2.h; Wireshark uses winsock2.h, but pre-2.3 versions |
||
514 | of the WinPcap developer's packet use winsock.h. (2.3 uses |
||
515 | winsock2.h, so if Wireshark were to use winsock.h, it would not |
||
516 | be able to build with current versions of the WinPcap |
||
517 | developer's pack.) |
||
518 | Note that the installed version of the developer's pack should |
||
519 | be the same version as the version of WinPcap you have |
||
520 | installed. |
||
521 | |||
522 | 4. Starting Wireshark |
||
523 | |||
524 | Q 4.1: Why does Wireshark crash with a Bus Error when I try to |
||
525 | run it on Solaris 8? |
||
526 | |||
527 | A: Some versions of the GTK+ library from www.sunfreeware.org |
||
528 | appear to be buggy, causing Wireshark to drop core with a Bus |
||
529 | Error. Un-install those packages, and try getting the 1.2.10 |
||
530 | version from that site, or the version from The Written Word, |
||
531 | or the version from Sun's GNOME distribution, or the version |
||
532 | from the supplemental software CD that comes with the Solaris |
||
533 | media kit, or build it from source from the GTK Web site. |
||
534 | Update the GLib library to the 1.2.10 version, from the same |
||
535 | source, as well. (If you get the 1.2.10 versions from |
||
536 | www.sunfreeware.org, and the problem persists, un-install them |
||
537 | and try installing one of the other versions mentioned.) |
||
538 | Similar problems may exist with older versions of GTK+ for |
||
539 | earlier versions of Solaris. |
||
540 | |||
541 | Q 4.2: When I try to run Wireshark, why does it complain about |
||
542 | sprint_realloc_objid being undefined? |
||
543 | |||
544 | A: Wireshark can only be linked with version 4.2.2 or later of |
||
545 | UCD SNMP. Your version of Wireshark was dynamically linked with |
||
546 | such a version of UCD SNMP; however, you have an older version |
||
547 | of UCD SNMP installed, which means that when Wireshark is run, |
||
548 | it tries to link to the older version, and fails. You will have |
||
549 | to replace that version of UCD SNMP with version 4.2.2 or a |
||
550 | later version. |
||
551 | |||
552 | Q 4.3: I've installed Wireshark from Fink on OS X; why is it |
||
553 | very slow to start up? |
||
554 | |||
555 | A: When an application is installed on OS X, prior to 10.4, it |
||
556 | is usually "prebound" to speed up launching the application. |
||
557 | (That's what the "Optimizing" phase of installation is.) |
||
558 | Fink normally performs prebinding automatically when you |
||
559 | install a package. However, in some rare cases, for whatever |
||
560 | reason the prebinding caches get corrupt, and then not only |
||
561 | does prebinding fail, but startup actually becomes much slower, |
||
562 | because the system tries in vain to perform prebinding "on the |
||
563 | fly" as you launch the application. This fails, causing |
||
564 | sometimes huge delays. |
||
565 | To fix the prebinding caches, run the command |
||
566 | |||
567 | |||
568 | sudo /sw/var/lib/fink/prebound/update-package-prebinding.pl -f |
||
569 | |||
570 | |||
571 | 5. Crashes and other fatal errors |
||
572 | |||
573 | Q 5.1: I have an XXX network card on my machine; if I try to |
||
574 | capture on it, why does my machine crash or reset itself? |
||
575 | |||
576 | A: This is almost certainly a problem with one or more of: |
||
577 | |||
578 | * the operating system you're using; |
||
579 | * the device driver for the interface you're using; |
||
580 | * the libpcap/WinPcap library and, if this is Windows, the |
||
581 | WinPcap device driver; |
||
582 | |||
583 | so: |
||
584 | |||
585 | * if you are using Windows, see the WinPcap support page - |
||
586 | check the "Submitting bugs" section; |
||
587 | * if you are using some Linux distribution, some version of |
||
588 | BSD, or some other UNIX-flavored OS, you should report the |
||
589 | problem to the company or organization that produces the OS |
||
590 | (in the case of a Linux distribution, report the problem to |
||
591 | whoever produces the distribution). |
||
592 | |||
593 | Q 5.2: Why does my machine crash or reset itself when I select |
||
594 | "Start" from the "Capture" menu or select "Preferences" from |
||
595 | the "Edit" menu? |
||
596 | |||
597 | A: Both of those operations cause Wireshark to try to build a |
||
598 | list of the interfaces that it can open; it does so by getting |
||
599 | a list of interfaces and trying to open them. There is probably |
||
600 | an OS, driver, or, for Windows, WinPcap bug that causes the |
||
601 | system to crash when this happens; see the previous question. |
||
602 | |||
603 | 6. Capturing packets |
||
604 | |||
605 | Q 6.1: When I use Wireshark to capture packets, why do I see |
||
606 | only packets to and from my machine, or not see all the traffic |
||
607 | I'm expecting to see from or to the machine I'm trying to |
||
608 | monitor? |
||
609 | |||
610 | A: This might be because the interface on which you're |
||
611 | capturing is plugged into an Ethernet or Token Ring switch; on |
||
612 | a switched network, unicast traffic between two ports will not |
||
613 | necessarily appear on other ports - only broadcast and |
||
614 | multicast traffic will be sent to all ports. |
||
615 | Note that even if your machine is plugged into a hub, the "hub" |
||
616 | may be a switched hub, in which case you're still on a switched |
||
617 | network. |
||
618 | Note also that on the Linksys Web site, they say that their |
||
619 | auto-sensing hubs "broadcast the 10Mb packets to the port that |
||
620 | operate at 10Mb only and broadcast the 100Mb packets to the |
||
621 | ports that operate at 100Mb only", which would indicate that if |
||
622 | you sniff on a 10Mb port, you will not see traffic coming sent |
||
623 | to a 100Mb port, and vice versa. This problem has also been |
||
624 | reported for Netgear dual-speed hubs, and may exist for other |
||
625 | "auto-sensing" or "dual-speed" hubs. |
||
626 | Some switches have the ability to replicate all traffic on all |
||
627 | ports to a single port so that you can plug your analyzer into |
||
628 | that single port to sniff all traffic. You would have to check |
||
629 | the documentation for the switch to see if this is possible |
||
630 | and, if so, to see how to do this. See the switch reference |
||
631 | page on the Wireshark Wiki for information on some switches. |
||
632 | (Note that it's a Wiki, so you can update or fix that |
||
633 | information, or add additional information on those switches or |
||
634 | information on new switches, yourself.) |
||
635 | Note also that many firewall/NAT boxes have a switch built into |
||
636 | them; this includes many of the "cable/DSL router" boxes. If |
||
637 | you have a box of that sort, that has a switch with some number |
||
638 | of Ethernet ports into which you plug machines on your network, |
||
639 | and another Ethernet port used to connect to a cable or DSL |
||
640 | modem, you can, at least, sniff traffic between the machines on |
||
641 | your network and the Internet by plugging the Ethernet port on |
||
642 | the router going to the modem, the Ethernet port on the modem, |
||
643 | and the machine on which you're running Wireshark into a hub |
||
644 | (make sure it's not a switching hub, and that, if it's a |
||
645 | dual-speed hub, all three of those ports are running at the |
||
646 | same speed. |
||
647 | If your machine is not plugged into a switched network or a |
||
648 | dual-speed hub, or it is plugged into a switched network but |
||
649 | the port is set up to have all traffic replicated to it, the |
||
650 | problem might be that the network interface on which you're |
||
651 | capturing doesn't support "promiscuous" mode, or because your |
||
652 | OS can't put the interface into promiscuous mode. Normally, |
||
653 | network interfaces supply to the host only: |
||
654 | |||
655 | * packets sent to one of that host's link-layer addresses; |
||
656 | * broadcast packets; |
||
657 | * multicast packets sent to a multicast address that the host |
||
658 | has configured the interface to accept. |
||
659 | |||
660 | Most network interfaces can also be put in "promiscuous" mode, |
||
661 | in which they supply to the host all network packets they see. |
||
662 | Wireshark will try to put the interface on which it's capturing |
||
663 | into promiscuous mode unless the "Capture packets in |
||
664 | promiscuous mode" option is turned off in the "Capture Options" |
||
665 | dialog box, and TShark will try to put the interface on which |
||
666 | it's capturing into promiscuous mode unless the -p option was |
||
667 | specified. However, some network interfaces don't support |
||
668 | promiscuous mode, and some OSes might not allow interfaces to |
||
669 | be put into promiscuous mode. |
||
670 | If the interface is not running in promiscuous mode, it won't |
||
671 | see any traffic that isn't intended to be seen by your machine. |
||
672 | It will see broadcast packets, and multicast packets sent to a |
||
673 | multicast MAC address the interface is set up to receive. |
||
674 | You should ask the vendor of your network interface whether it |
||
675 | supports promiscuous mode. If it does, you should ask whoever |
||
676 | supplied the driver for the interface (the vendor, or the |
||
677 | supplier of the OS you're running on your machine) whether it |
||
678 | supports promiscuous mode with that network interface. |
||
679 | In the case of token ring interfaces, the drivers for some of |
||
680 | them, on Windows, may require you to enable promiscuous mode in |
||
681 | order to capture in promiscuous mode. See the Wireshark Wiki |
||
682 | item on Token Ring capturing for details. |
||
683 | In the case of wireless LAN interfaces, it appears that, when |
||
684 | those interfaces are promiscuously sniffing, they're running in |
||
685 | a significantly different mode from the mode that they run in |
||
686 | when they're just acting as network interfaces (to the extent |
||
687 | that it would be a significant effort for those drivers to |
||
688 | support for promiscuously sniffing and acting as regular |
||
689 | network interfaces at the same time), so it may be that Windows |
||
690 | drivers for those interfaces don't support promiscuous mode. |
||
691 | |||
692 | Q 6.2: When I capture with Wireshark, why can't I see any TCP |
||
693 | packets other than packets to and from my machine, even though |
||
694 | another analyzer on the network sees those packets? |
||
695 | |||
696 | A: You're probably not seeing any packets other than unicast |
||
697 | packets to or from your machine, and broadcast and multicast |
||
698 | packets; a switch will normally send to a port only unicast |
||
699 | traffic sent to the MAC address for the interface on that port, |
||
700 | and broadcast and multicast traffic - it won't send to that |
||
701 | port unicast traffic sent to a MAC address for some other |
||
702 | interface - and a network interface not in promiscuous mode |
||
703 | will receive only unicast traffic sent to the MAC address for |
||
704 | that interface, broadcast traffic, and multicast traffic sent |
||
705 | to a multicast MAC address the interface is set up to receive. |
||
706 | TCP doesn't use broadcast or multicast, so you will only see |
||
707 | your own TCP traffic, but UDP services may use broadcast or |
||
708 | multicast so you'll see some UDP traffic - however, this is not |
||
709 | a problem with TCP traffic, it's a problem with unicast |
||
710 | traffic, as you also won't see all UDP traffic between other |
||
711 | machines. |
||
712 | I.e., this is probably the same question as this earlier one; |
||
713 | see the response to that question. |
||
714 | |||
715 | Q 6.3: Why am I only seeing ARP packets when I try to capture |
||
716 | traffic? |
||
717 | |||
718 | A: You're probably on a switched network, and running Wireshark |
||
719 | on a machine that's not sending traffic to the switch and not |
||
720 | being sent any traffic from other machines on the switch. ARP |
||
721 | packets are often broadcast packets, which are sent to all |
||
722 | switch ports. |
||
723 | I.e., this is probably the same question as this earlier one; |
||
724 | see the response to that question. |
||
725 | |||
726 | Q 6.4: Why am I not seeing any traffic when I try to capture |
||
727 | traffic? |
||
728 | |||
729 | A: Is the machine running Wireshark sending out any traffic on |
||
730 | the network interface on which you're capturing, or receiving |
||
731 | any traffic on that network, or is there any broadcast traffic |
||
732 | on the network or multicast traffic to a multicast group to |
||
733 | which the machine running Wireshark belongs? |
||
734 | If not, this may just be a problem with promiscuous sniffing, |
||
735 | either due to running on a switched network or a dual-speed |
||
736 | hub, or due to problems with the interface not supporting |
||
737 | promiscuous mode; see the response to this earlier question. |
||
738 | Otherwise, on Windows, see the response to this question and, |
||
739 | on a UNIX-flavored OS, see the response to this question. |
||
740 | |||
741 | Q 6.5: Can Wireshark capture on (my T1/E1 line, SS7 links, |
||
742 | etc.)? |
||
743 | |||
744 | A: Wireshark can only capture on devices supported by |
||
745 | libpcap/WinPcap. On most OSes, only devices that can act as |
||
746 | network interfaces of the type that support IP are supported as |
||
747 | capture devices for libpcap/WinPcap, although the device |
||
748 | doesn't necessarily have to be running as an IP interface in |
||
749 | order to support traffic capture. |
||
750 | On Linux and FreeBSD, libpcap 0.8 and later support the API for |
||
751 | Endace Measurement Systems' DAG cards, so that a system with |
||
752 | one of those cards, and its driver and libraries, installed can |
||
753 | capture traffic with those cards with libpcap-based |
||
754 | applications. You would either have to have a version of |
||
755 | Wireshark built with that version of libpcap, or a |
||
756 | dynamically-linked version of Wireshark and a shared libpcap |
||
757 | library with DAG support, in order to do so with Wireshark. You |
||
758 | should ask Endace whether that could be used to capture traffic |
||
759 | on, for example, your T1/E1 link. |
||
760 | See the SS7 capture setup page on the Wireshark Wiki for |
||
761 | current information on capturing SS7 traffic on TDM links. |
||
762 | |||
763 | Q 6.6: How do I put an interface into promiscuous mode? |
||
764 | |||
765 | A: By not disabling promiscuous mode when running Wireshark or |
||
766 | TShark. |
||
767 | Note, however, that: |
||
768 | |||
769 | * the form of promiscuous mode that libpcap (the library that |
||
770 | programs such as tcpdump, Wireshark, etc. use to do packet |
||
771 | capture) turns on will not necessarily be shown if you run |
||
772 | ifconfig on the interface on a UNIX system; |
||
773 | * some network interfaces might not support promiscuous mode, |
||
774 | and some drivers might not allow promiscuous mode to be |
||
775 | turned on - see this earlier question for more information |
||
776 | on that; |
||
777 | * the fact that you're not seeing any traffic, or are only |
||
778 | seeing broadcast traffic, or aren't seeing any |
||
779 | non-broadcast traffic other than traffic to or from the |
||
780 | machine running Wireshark, does not mean that promiscuous |
||
781 | mode isn't on - see this earlier question for more |
||
782 | information on that. |
||
783 | |||
784 | I.e., this is probably the same question as this earlier one; |
||
785 | see the response to that question. |
||
786 | |||
787 | Q 6.7: I can set a display filter just fine; why don't capture |
||
788 | filters work? |
||
789 | |||
790 | A: Capture filters currently use a different syntax than |
||
791 | display filters. Here's the corresponding section from the |
||
792 | wireshark(1) man page: |
||
793 | "Display filters in Wireshark are very powerful; more fields |
||
794 | are filterable in Wireshark than in other protocol analyzers, |
||
795 | and the syntax you can use to create your filters is richer. As |
||
796 | Wireshark progresses, expect more and more protocol fields to |
||
797 | be allowed in display filters. |
||
798 | Packet capturing is performed with the pcap library. The |
||
799 | capture filter syntax follows the rules of the pcap library. |
||
800 | This syntax is different from the display filter syntax." |
||
801 | The capture filter syntax used by libpcap can be found in the |
||
802 | tcpdump(8) man page. |
||
803 | |||
804 | Q 6.8: I'm entering valid capture filters; why do I still get |
||
805 | "parse error" errors? |
||
806 | |||
807 | A: There is a bug in some versions of libpcap/WinPcap that |
||
808 | cause it to report parse errors even for valid expressions if a |
||
809 | previous filter expression was invalid and got a parse error. |
||
810 | Try exiting and restarting Wireshark; if you are using a |
||
811 | version of libpcap/WinPcap with this bug, this will "erase" its |
||
812 | memory of the previous parse error. If the capture filter that |
||
813 | got the "parse error" now works, the earlier error with that |
||
814 | filter was probably due to this bug. |
||
815 | The bug was fixed in libpcap 0.6; 0.4[.x] and 0.5[.x] versions |
||
816 | of libpcap have this bug, but 0.6[.x] and later versions don't. |
||
817 | Versions of WinPcap prior to 2.3 are based on pre-0.6 versions |
||
818 | of libpcap, and have this bug; WinPcap 2.3 is based on libpcap |
||
819 | 0.6.2, and doesn't have this bug. |
||
820 | If you are running Wireshark on a UNIX-flavored platform, run |
||
821 | "wireshark -v", or select "About Wireshark..." from the "Help" |
||
822 | menu in Wireshark, to see what version of libpcap it's using. |
||
823 | If it's not 0.6 or later, you will need either to upgrade your |
||
824 | OS to get a later version of libpcap, or will need to build and |
||
825 | install a later version of libpcap from the tcpdump.org Web |
||
826 | site and then recompile Wireshark from source with that later |
||
827 | version of libpcap. |
||
828 | If you are running Wireshark on Windows with a pre-2.3 version |
||
829 | of WinPcap, you will need to un-install WinPcap and then |
||
830 | download and install WinPcap 2.3. |
||
831 | |||
832 | Q 6.9: How can I capture packets with CRC errors? |
||
833 | |||
834 | A: Wireshark can capture only the packets that the packet |
||
835 | capture library - libpcap on UNIX-flavored OSes, and the |
||
836 | WinPcap port to Windows of libpcap on Windows - can capture, |
||
837 | and libpcap/WinPcap can capture only the packets that the OS's |
||
838 | raw packet capture mechanism (or the WinPcap driver, and the |
||
839 | underlying OS networking code and network interface drivers, on |
||
840 | Windows) will allow it to capture. |
||
841 | Unless the OS always supplies packets with errors such as |
||
842 | invalid CRCs to the raw packet capture mechanism, or can be |
||
843 | configured to do so, invalid CRCs to the raw packet capture |
||
844 | mechanism, Wireshark - and other programs that capture raw |
||
845 | packets, such as tcpdump - cannot capture those packets. You |
||
846 | will have to determine whether your OS needs to be so |
||
847 | configured and, if so, can be so configured, configure it if |
||
848 | necessary and possible, and make whatever changes to libpcap |
||
849 | and the packet capture program you're using are necessary, if |
||
850 | any, to support capturing those packets. |
||
851 | Most OSes probably do not support capturing packets with |
||
852 | invalid CRCs on Ethernet, and probably do not support it on |
||
853 | most other link-layer types. Some drivers on some OSes do |
||
854 | support it, such as some Ethernet drivers on FreeBSD; in those |
||
855 | OSes, you might always get those packets, or you might only get |
||
856 | them if you capture in promiscuous mode (you'd have to |
||
857 | determine which is the case). |
||
858 | Note that libpcap does not currently supply to programs that |
||
859 | use it an indication of whether the packet's CRC was invalid |
||
860 | (because the drivers themselves do not supply that information |
||
861 | to the raw packet capture mechanism); therefore, Wireshark will |
||
862 | not indicate which packets had CRC errors unless the FCS was |
||
863 | captured (see the next question) and you're using Wireshark |
||
864 | 0.9.15 and later, in which case Wireshark will check the CRC |
||
865 | and indicate whether it's correct or not. |
||
866 | |||
867 | Q 6.10: How can I capture entire frames, including the FCS? |
||
868 | |||
869 | A: Wireshark can only capture data that the packet capture |
||
870 | library - libpcap on UNIX-flavored OSes, and the WinPcap port |
||
871 | to Windows of libpcap on Windows - can capture, and |
||
872 | libpcap/WinPcap can capture only the data that the OS's raw |
||
873 | packet capture mechanism (or the WinPcap driver, and the |
||
874 | underlying OS networking code and network interface drivers, on |
||
875 | Windows) will allow it to capture. |
||
876 | For any particular link-layer network type, unless the OS |
||
877 | supplies the FCS of a frame as part of the frame, or can be |
||
878 | configured to do so, Wireshark - and other programs that |
||
879 | capture raw packets, such as tcpdump - cannot capture the FCS |
||
880 | of a frame. You will have to determine whether your OS needs to |
||
881 | be so configured and, if so, can be so configured, configure it |
||
882 | if necessary and possible, and make whatever changes to libpcap |
||
883 | and the packet capture program you're using are necessary, if |
||
884 | any, to support capturing the FCS of a frame. |
||
885 | Most OSes do not support capturing the FCS of a frame on |
||
886 | Ethernet, and probably do not support it on most other |
||
887 | link-layer types. Some drivres on some OSes do support it, such |
||
888 | as some (all?) Ethernet drivers on NetBSD and possibly the |
||
889 | driver for Apple's gigabit Ethernet interface in OS X; in those |
||
890 | OSes, you might always get the FCS, or you might only get the |
||
891 | FCS if you capture in promiscuous mode (you'd have to determine |
||
892 | which is the case). |
||
893 | Versions of Wireshark prior to 0.9.15 will not treat an |
||
894 | Ethernet FCS in a captured packet as an FCS. 0.9.15 and later |
||
895 | will attempt to determine whether there's an FCS at the end of |
||
896 | the frame and, if it thinks there is, will display it as such, |
||
897 | and will check whether it's the correct CRC-32 value or not. |
||
898 | |||
899 | Q 6.11: I'm capturing packets on a machine on a VLAN; why don't |
||
900 | the packets I'm capturing have VLAN tags? |
||
901 | |||
902 | A: You might be capturing on what might be called a "VLAN |
||
903 | interface" - the way a particular OS makes VLANs plug into the |
||
904 | networking stack might, for example, be to have a network |
||
905 | device object for the physical interface, which takes VLAN |
||
906 | packets, strips off the VLAN header and constructs an Ethernet |
||
907 | header, and passes that packet to an internal network device |
||
908 | object for the VLAN, which then passes the packets onto various |
||
909 | higher-level protocol implementations. |
||
910 | In order to see the raw Ethernet packets, rather than |
||
911 | "de-VLANized" packets, you would have to capture not on the |
||
912 | virtual interface for the VLAN, but on the interface |
||
913 | corresponding to the physical network device, if possible. See |
||
914 | the Wireshark Wiki item on VLAN capturing for details. |
||
915 | |||
916 | Q 6.12: Why does Wireshark hang after I stop a capture? |
||
917 | |||
918 | A: The most likely reason for this is that Wireshark is trying |
||
919 | to look up an IP address in the capture to convert it to a name |
||
920 | (so that, for example, it can display the name in the source |
||
921 | address or destination address columns), and that lookup |
||
922 | process is taking a very long time. |
||
923 | Wireshark calls a routine in the OS of the machine on which |
||
924 | it's running to convert of IP addresses to the corresponding |
||
925 | names. That routine probably does one or more of: |
||
926 | |||
927 | * a search of a system file listing IP addresses and names; |
||
928 | * a lookup using DNS; |
||
929 | * on UNIX systems, a lookup using NIS; |
||
930 | * on Windows systems, a NetBIOS-over-TCP query. |
||
931 | |||
932 | If a DNS server that's used in an address lookup is not |
||
933 | responding, the lookup will fail, but will only fail after a |
||
934 | timeout while the system routine waits for a reply. |
||
935 | In addition, on Windows systems, if the DNS lookup of the |
||
936 | address fails, either because the server isn't responding or |
||
937 | because there are no records in the DNS that could be used to |
||
938 | map the address to a name, a NetBIOS-over-TCP query will be |
||
939 | made. That query involves sending a message to the |
||
940 | NetBIOS-over-TCP name service on that machine, asking for the |
||
941 | name and other information about the machine. If the machine |
||
942 | isn't running software that responds to those queries - for |
||
943 | example, many non-Windows machines wouldn't be running that |
||
944 | software - the lookup will only fail after a timeout. Those |
||
945 | timeouts can cause the lookup to take a long time. |
||
946 | If you disable network address-to-name translation - for |
||
947 | example, by turning off the "Enable network name resolution" |
||
948 | option in the "Capture Options" dialog box for starting a |
||
949 | network capture - the lookups of the address won't be done, |
||
950 | which may speed up the process of reading the capture file |
||
951 | after the capture is stopped. You can make that setting the |
||
952 | default by selecting "Preferences" from the "Edit" menu, |
||
953 | turning off the "Enable network name resolution" option in the |
||
954 | "Name resolution" options in the preferences disalog box, and |
||
955 | using the "Save" button in that dialog box; note that this will |
||
956 | save all your current preference settings. |
||
957 | If Wireshark hangs when reading a capture even with network |
||
958 | name resolution turned off, there might, for example, be a bug |
||
959 | in one of Wireshark's dissectors for a protocol causing it to |
||
960 | loop infinitely. If you're not running the most recent release |
||
961 | of Wireshark, you should first upgrade to that release, as, if |
||
962 | there's a bug of that sort, it might've been fixed in a release |
||
963 | after the one you're running. If the hang occurs in the most |
||
964 | recent release of Wireshark, the bug should be reported to the |
||
965 | Wireshark developers' mailing list at |
||
966 | wireshark-dev@wireshark.org. |
||
967 | On UNIX-flavored OSes, please try to force Wireshark to dump |
||
968 | core, by sending it a SIGABRT signal (usually signal 6) with |
||
969 | the kill command, and then get a stack trace if you have a |
||
970 | debugger installed. A stack trace can be obtained by using your |
||
971 | debugger (gdb in this example), the Wireshark binary, and the |
||
972 | resulting core file. Here's an example of how to use the gdb |
||
973 | command backtrace to do so. |
||
974 | |||
975 | |||
976 | $ gdb wireshark core |
||
977 | (gdb) backtrace |
||
978 | ..... prints the stack trace |
||
979 | (gdb) quit |
||
980 | $ |
||
981 | |||
982 | |||
983 | The core dump file may be named "wireshark.core" rather than |
||
984 | "core" on some platforms (e.g., BSD systems). |
||
985 | Also, if at all possible, please send a copy of the capture |
||
986 | file that caused the problem. When capturing packets, Wireshark |
||
987 | normally writes captured packets to a temporary file, which |
||
988 | will probably be in /tmp or /var/tmp on UNIX-flavored OSes, |
||
989 | \TEMP on the main system disk (normally \Documents and |
||
990 | Settings\your login name \Local Settings\Temp on the main |
||
991 | system disk on Windows Windows XP and Server 2003, and |
||
992 | \Users\your login name\AppData\Local\Temp on the main system |
||
993 | disk on Windows Vista and later, so the capture file will |
||
994 | probably be there. If you are capturing on a single interface, |
||
995 | it will have a name of the form, |
||
996 | wireshark_<iface>_YYYYmmddHHMMSS_XXXXXX.<fmt>, where <fmt> is |
||
997 | the capture file format (pcap or pcapng), and <iface> is the |
||
998 | actual name of the interface you are capturing on; otherwise, |
||
999 | if you are capturing on multiple interfaces, it will have a |
||
1000 | name of the form, |
||
1001 | wireshark_<N>_interfaces_YYYYmmddHHMMSS_XXXXXX.<fmt>, where <N> |
||
1002 | is the number of simultaneous interfaces you are capturing on. |
||
1003 | Please don't send a trace file greater than 1 MB when |
||
1004 | compressed; instead, make it available via FTP or HTTP, or say |
||
1005 | it's available but leave it up to a developer to ask for it. If |
||
1006 | the trace file contains sensitive information (e.g., |
||
1007 | passwords), then please do not send it. |
||
1008 | |||
1009 | 7. Capturing packets on Windows |
||
1010 | |||
1011 | Q 7.1: I'm running Wireshark on Windows; why does some network |
||
1012 | interface on my machine not show up in the list of interfaces |
||
1013 | in the "Interface:" field in the dialog box popped up by |
||
1014 | "Capture->Start", and/or why does Wireshark give me an error if |
||
1015 | I try to capture on that interface? |
||
1016 | |||
1017 | A: If you are running Wireshark on Windows XP, or Windows |
||
1018 | Server 2003, and this is the first time you have run a |
||
1019 | WinPcap-based program (such as Wireshark, or TShark, or |
||
1020 | WinDump, or Analyzer, or...) since the machine was rebooted, |
||
1021 | you need to run that program from an account with administrator |
||
1022 | privileges; once you have run such a program, you will not need |
||
1023 | administrator privileges to run any such programs until you |
||
1024 | reboot. |
||
1025 | If you are running on Windows Windows XP or Windows Server 2003 |
||
1026 | and have administrator privileges or a WinPcap-based program |
||
1027 | has been run with those privileges since the machine rebooted, |
||
1028 | this problem might clear up if you completely un-install |
||
1029 | WinPcap and then re-install it. |
||
1030 | If that doesn't work, then note that Wireshark relies on the |
||
1031 | WinPcap library, on the WinPcap device driver, and on the |
||
1032 | facilities that come with the OS on which it's running in order |
||
1033 | to do captures. |
||
1034 | Therefore, if the OS, the WinPcap library, or the WinPcap |
||
1035 | driver don't support capturing on a particular network |
||
1036 | interface device, Wireshark won't be able to capture on that |
||
1037 | device. |
||
1038 | WinPcap 2.3 has problems supporting PPP WAN interfaces on |
||
1039 | Windows NT 4.0, Windows 2000, Windows XP, and Windows Server |
||
1040 | 2003, and, to avoid those problems, support for PPP WAN |
||
1041 | interfaces on those versions of Windows has been disabled in |
||
1042 | WinPcap 3.0. Regular dial-up lines, ISDN lines, ADSL |
||
1043 | connections using PPPoE or PPPoA, and various other lines such |
||
1044 | as T1/E1 lines are all PPP interfaces, so those interfaces |
||
1045 | might not show up on the list of interfaces in the "Capture |
||
1046 | Options" dialog on those OSes. |
||
1047 | On Windows 2000, Windows XP, and Windows Server 2003, but not |
||
1048 | Windows NT 4.0 or Windows Vista Beta 1, you should be able to |
||
1049 | capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1 |
||
1050 | beta releases called it the "NdisWanAdapter"; if you're using a |
||
1051 | 3.1 beta release, you should un-install it and install the |
||
1052 | final 3.1 release.) See the Wireshark Wiki item on PPP |
||
1053 | capturing for details. |
||
1054 | WinPcap prior to 3.0 does not support multiprocessor machines |
||
1055 | (note that machines with a single multi-threaded processor, |
||
1056 | such as Intel's new multi-threaded x86 processors, are |
||
1057 | multiprocessor machines as far as the OS and WinPcap are |
||
1058 | concerned), and recent 2.x versions of WinPcap refuse to |
||
1059 | operate if they detect that they're running on a multiprocessor |
||
1060 | machine, which means that they may not show any network |
||
1061 | interfaces. You will need to use WinPcap 3.0 to capture on a |
||
1062 | multiprocessor machine. |
||
1063 | If an interface doesn't show up in the list of interfaces in |
||
1064 | the "Interface:" field, and you know the name of the interface, |
||
1065 | try entering that name in the "Interface:" field and capturing |
||
1066 | on that device. |
||
1067 | If the attempt to capture on it succeeds, the interface is |
||
1068 | somehow not being reported by the mechanism Wireshark uses to |
||
1069 | get a list of interfaces. Try listing the interfaces with |
||
1070 | WinDump; see the WinDump Web site for information on using |
||
1071 | WinDump. |
||
1072 | You would run WinDump with the -D flag; if it lists the |
||
1073 | interface, please report this to wireshark-dev@wireshark.org |
||
1074 | giving full details of the problem, including |
||
1075 | |||
1076 | * the operating system you're using, and the version of that |
||
1077 | operating system; |
||
1078 | * the type of network device you're using; |
||
1079 | * the output of WinDump. |
||
1080 | |||
1081 | If WinDump does not list the interface, this is almost |
||
1082 | certainly a problem with one or more of: |
||
1083 | |||
1084 | * the operating system you're using; |
||
1085 | * the device driver for the interface you're using; |
||
1086 | * the WinPcap library and/or the WinPcap device driver; |
||
1087 | |||
1088 | so first check the WinPcap FAQ to see if your problem is |
||
1089 | mentioned there. If not, then see the WinPcap support page - |
||
1090 | check the "Submitting bugs" section. |
||
1091 | If you are having trouble capturing on a particular network |
||
1092 | interface, first try capturing on that device with WinDump; see |
||
1093 | the WinDump Web site for information on using WinDump. |
||
1094 | If you can capture on the interface with WinDump, send mail to |
||
1095 | wireshark-users@wireshark.org giving full details of the |
||
1096 | problem, including |
||
1097 | |||
1098 | * the operating system you're using, and the version of that |
||
1099 | operating system; |
||
1100 | * the type of network device you're using; |
||
1101 | * the error message you get from Wireshark. |
||
1102 | |||
1103 | If you cannot capture on the interface with WinDump, this is |
||
1104 | almost certainly a problem with one or more of: |
||
1105 | |||
1106 | * the operating system you're using; |
||
1107 | * the device driver for the interface you're using; |
||
1108 | * the WinPcap library and/or the WinPcap device driver; |
||
1109 | |||
1110 | so first check the WinPcap FAQ to see if your problem is |
||
1111 | mentioned there. If not, then see the WinPcap support page - |
||
1112 | check the "Submitting bugs" section. |
||
1113 | You may also want to ask the wireshark-users@wireshark.org and |
||
1114 | the winpcap-users@winpcap.org mailing lists to see if anybody |
||
1115 | happens to know about the problem and know a workaround or fix |
||
1116 | for the problem. (Note that you will have to subscribe to that |
||
1117 | list in order to be allowed to mail to it; see the WinPcap |
||
1118 | support page for information on the mailing list.) In your |
||
1119 | mail, please give full details of the problem, as described |
||
1120 | above, and also indicate that the problem occurs with WinDump, |
||
1121 | not just with Wireshark. |
||
1122 | |||
1123 | Q 7.2: I'm running Wireshark on Windows; why do no network |
||
1124 | interfaces show up in the list of interfaces in the |
||
1125 | "Interface:" field in the dialog box popped up by |
||
1126 | "Capture->Start"? |
||
1127 | |||
1128 | A: This is really the same question as a previous one; see the |
||
1129 | response to that question. |
||
1130 | |||
1131 | Q 7.3: I'm running Wireshark on Windows; why doesn't my serial |
||
1132 | port/ADSL modem/ISDN modem show up in the list of interfaces in |
||
1133 | the "Interface:" field in the dialog box popped up by |
||
1134 | "Capture->Start"? |
||
1135 | |||
1136 | A: Internet access on those devices is often done with the |
||
1137 | Point-to-Point (PPP) protocol; WinPcap 2.3 has problems |
||
1138 | supporting PPP WAN interfaces on Windows NT 4.0, Windows 2000, |
||
1139 | Windows XP, and Windows Server 2003, and, to avoid those |
||
1140 | problems, support for PPP WAN interfaces on those versions of |
||
1141 | Windows has been disabled in WinPcap 3.0. |
||
1142 | On Windows 2000, Windows XP, and Windows Server 2003, but not |
||
1143 | Windows NT 4.0 or Windows Vista Beta 1, you should be able to |
||
1144 | capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1 |
||
1145 | beta releases called it the "NdisWanAdapter"; if you're using a |
||
1146 | 3.1 beta release, you should un-install it and install the |
||
1147 | final 3.1 release.) See the Wireshark Wiki item on PPP |
||
1148 | capturing for details. |
||
1149 | |||
1150 | Q 7.4: I'm running Wireshark on Windows NT 4.0/Windows |
||
1151 | 2000/Windows XP/Windows Server 2003; my machine has a PPP |
||
1152 | (dial-up POTS, ISDN, etc.) interface, and it shows up in the |
||
1153 | "Interface" item in the "Capture Options" dialog box. Why can |
||
1154 | no packets be sent on or received from that network while I'm |
||
1155 | trying to capture traffic on that interface? |
||
1156 | |||
1157 | A: Some versions of WinPcap have problems with PPP WAN |
||
1158 | interfaces on Windows NT 4.0, Windows 2000, Windows XP, and |
||
1159 | Windows Server 2003; one symptom that may be seen is that |
||
1160 | attempts to capture in promiscuous mode on the interface cause |
||
1161 | the interface to be incapable of sending or receiving packets. |
||
1162 | You can disable promiscuous mode using the -p command-line flag |
||
1163 | or the item in the "Capture Preferences" dialog box, but this |
||
1164 | may mean that outgoing packets, or incoming packets, won't be |
||
1165 | seen in the capture. |
||
1166 | On Windows 2000, Windows XP, and Windows Server 2003, but not |
||
1167 | Windows NT 4.0 or Windows Vista Beta 1, you should be able to |
||
1168 | capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1 |
||
1169 | beta releases called it the "NdisWanAdapter"; if you're using a |
||
1170 | 3.1 beta release, you should un-install it and install the |
||
1171 | final 3.1 release.) See the Wireshark Wiki item on PPP |
||
1172 | capturing for details. |
||
1173 | |||
1174 | Q 7.5: I'm running Wireshark on Windows; why am I not seeing |
||
1175 | any traffic being sent by the machine running Wireshark? |
||
1176 | |||
1177 | A: If you are running some form of VPN client software, it |
||
1178 | might be causing this problem; people have seen this problem |
||
1179 | when they have Check Point's VPN software installed on their |
||
1180 | machine. If that's the cause of the problem, you will have to |
||
1181 | remove the VPN software in order to have Wireshark (or any |
||
1182 | other application using WinPcap) see outgoing packets; |
||
1183 | unfortunately, neither we nor the WinPcap developers know any |
||
1184 | way to make WinPcap and the VPN software work well together. |
||
1185 | Also, some drivers for Windows (especially some wireless |
||
1186 | network interface drivers) apparently do not, when running in |
||
1187 | promiscuous mode, arrange that outgoing packets are delivered |
||
1188 | to the software that requested that the interface run |
||
1189 | promiscuously; try turning promiscuous mode off. |
||
1190 | |||
1191 | Q 7.6: When I capture on Windows in promiscuous mode, I can see |
||
1192 | packets other than those sent to or from my machine; however, |
||
1193 | those packets show up with a "Short Frame" indication, unlike |
||
1194 | packets to or from my machine. What should I do to arrange that |
||
1195 | I see those packets in their entirety? |
||
1196 | |||
1197 | A: In at least some cases, this appears to be the result of |
||
1198 | PGPnet running on the network interface on which you're |
||
1199 | capturing; turn it off on that interface. |
||
1200 | |||
1201 | Q 7.7: I'm trying to capture 802.11 traffic on Windows; why am |
||
1202 | I not seeing any packets? |
||
1203 | |||
1204 | A: At least some 802.11 card drivers on Windows appear not to |
||
1205 | see any packets if they're running in promiscuous mode. Try |
||
1206 | turning promiscuous mode off; you'll only be able to see |
||
1207 | packets sent by and received by your machine, not third-party |
||
1208 | traffic, and it'll look like Ethernet traffic and won't include |
||
1209 | any management or control frames, but that's a limitation of |
||
1210 | the card drivers. |
||
1211 | See the archived MicroLogix's list of cards supported with |
||
1212 | WinPcap for information on support of various adapters and |
||
1213 | drivers with WinPcap. |
||
1214 | |||
1215 | Q 7.8: I'm trying to capture 802.11 traffic on Windows; why am |
||
1216 | I seeing packets received by the machine on which I'm capturing |
||
1217 | traffic, but not packets sent by that machine? |
||
1218 | |||
1219 | A: This appears to be another problem with promiscuous mode; |
||
1220 | try turning it off. |
||
1221 | |||
1222 | Q 7.9: I'm trying to capture Ethernet VLAN traffic on Windows, |
||
1223 | and I'm capturing on a "raw" Ethernet device rather than a |
||
1224 | "VLAN interface", so that I can see the VLAN headers; why am I |
||
1225 | seeing packets received by the machine on which I'm capturing |
||
1226 | traffic, but not packets sent by that machine? |
||
1227 | |||
1228 | A: The way the Windows networking code works probably means |
||
1229 | that packets are sent on a "VLAN interface" rather than the |
||
1230 | "raw" device, so packets sent by the machine will only be seen |
||
1231 | when you capture on the "VLAN interface". If so, you will be |
||
1232 | unable to see outgoing packets when capturing on the "raw" |
||
1233 | device, so you are stuck with a choice between seeing VLAN |
||
1234 | headers and seeing outgoing packets. |
||
1235 | |||
1236 | 8. Capturing packets on UN*Xes |
||
1237 | |||
1238 | Q 8.1: I'm running Wireshark on a UNIX-flavored OS; why does |
||
1239 | some network interface on my machine not show up in the list of |
||
1240 | interfaces in the "Interface:" field in the dialog box popped |
||
1241 | up by "Capture->Start", and/or why does Wireshark give me an |
||
1242 | error if I try to capture on that interface? |
||
1243 | |||
1244 | A: You may need to run Wireshark from an account with |
||
1245 | sufficient privileges to capture packets, such as the |
||
1246 | super-user account, or may need to give your account sufficient |
||
1247 | privileges to capture packets. Only those interfaces that |
||
1248 | Wireshark can open for capturing show up in that list; if you |
||
1249 | don't have sufficient privileges to capture on any interfaces, |
||
1250 | no interfaces will show up in the list. See the Wireshark Wiki |
||
1251 | item on capture privileges for details on how to give a |
||
1252 | particular account or account group capture privileges on |
||
1253 | platforms where that can be done. |
||
1254 | If you are running Wireshark from an account with sufficient |
||
1255 | privileges, then note that Wireshark relies on the libpcap |
||
1256 | library, and on the facilities that come with the OS on which |
||
1257 | it's running in order to do captures. On some OSes, those |
||
1258 | facilities aren't present by default; see the Wireshark Wiki |
||
1259 | item on adding capture support for details. |
||
1260 | And, even if you're running with an account that has sufficient |
||
1261 | privileges to capture, and capture support is present in your |
||
1262 | OS, if the OS or the libpcap library don't support capturing on |
||
1263 | a particular network interface device or particular types of |
||
1264 | devices, Wireshark won't be able to capture on that device. |
||
1265 | On Solaris, note that libpcap 0.6.2 and earlier didn't support |
||
1266 | Token Ring interfaces; the current version, 0.7.2, does support |
||
1267 | Token Ring, and the current version of Wireshark works with |
||
1268 | libpcap 0.7.2 and later. |
||
1269 | If an interface doesn't show up in the list of interfaces in |
||
1270 | the "Interface:" field, and you know the name of the interface, |
||
1271 | try entering that name in the "Interface:" field and capturing |
||
1272 | on that device. |
||
1273 | If the attempt to capture on it succeeds, the interface is |
||
1274 | somehow not being reported by the mechanism Wireshark uses to |
||
1275 | get a list of interfaces; please report this to |
||
1276 | wireshark-dev@wireshark.org giving full details of the problem, |
||
1277 | including |
||
1278 | |||
1279 | * the operating system you're using, and the version of that |
||
1280 | operating system (for Linux, give both the version number |
||
1281 | of the kernel and the name and version number of the |
||
1282 | distribution you're using); |
||
1283 | * the type of network device you're using. |
||
1284 | |||
1285 | If you are having trouble capturing on a particular network |
||
1286 | interface, and you've made sure that (on platforms that require |
||
1287 | it) you've arranged that packet capture support is present, as |
||
1288 | per the above, first try capturing on that device with tcpdump. |
||
1289 | If you can capture on the interface with tcpdump, send mail to |
||
1290 | wireshark-users@wireshark.org giving full details of the |
||
1291 | problem, including |
||
1292 | |||
1293 | * the operating system you're using, and the version of that |
||
1294 | operating system (for Linux, give both the version number |
||
1295 | of the kernel and the name and version number of the |
||
1296 | distribution you're using); |
||
1297 | * the type of network device you're using; |
||
1298 | * the error message you get from Wireshark. |
||
1299 | |||
1300 | If you cannot capture on the interface with tcpdump, this is |
||
1301 | almost certainly a problem with one or more of: |
||
1302 | |||
1303 | * the operating system you're using; |
||
1304 | * the device driver for the interface you're using; |
||
1305 | * the libpcap library; |
||
1306 | |||
1307 | so you should report the problem to the company or organization |
||
1308 | that produces the OS (in the case of a Linux distribution, |
||
1309 | report the problem to whoever produces the distribution). |
||
1310 | You may also want to ask the wireshark-users@wireshark.org and |
||
1311 | the tcpdump-workers@lists.tcpdump.org mailing lists to see if |
||
1312 | anybody happens to know about the problem and know a workaround |
||
1313 | or fix for the problem. In your mail, please give full details |
||
1314 | of the problem, as described above, and also indicate that the |
||
1315 | problem occurs with tcpdump not just with Wireshark. |
||
1316 | |||
1317 | Q 8.2: I'm running Wireshark on a UNIX-flavored OS; why do no |
||
1318 | network interfaces show up in the list of interfaces in the |
||
1319 | "Interface:" field in the dialog box popped up by |
||
1320 | "Capture->Start"? |
||
1321 | |||
1322 | A: This is really the same question as the previous one; see |
||
1323 | the response to that question. |
||
1324 | |||
1325 | Q 8.3: I'm capturing packets on Linux; why do the time stamps |
||
1326 | have only 100ms resolution, rather than 1us resolution? |
||
1327 | |||
1328 | A: Wireshark gets time stamps from libpcap/WinPcap, and |
||
1329 | libpcap/WinPcap get them from the OS kernel, so Wireshark - and |
||
1330 | any other program using libpcap, such as tcpdump - is at the |
||
1331 | mercy of the time stamping code in the OS for time stamps. |
||
1332 | At least on x86-based machines, Linux can get high-resolution |
||
1333 | time stamps on newer processors with the Time Stamp Counter |
||
1334 | (TSC) register; for example, Intel x86 processors, starting |
||
1335 | with the Pentium Pro, and including all x86 processors since |
||
1336 | then, have had a TSC, and other vendors probably added the TSC |
||
1337 | at some point to their families of x86 processors. The Linux |
||
1338 | kernel must be configured with the CONFIG_X86_TSC option |
||
1339 | enabled in order to use the TSC. Make sure this option is |
||
1340 | enabled in your kernel. |
||
1341 | In addition, some Linux distributions may have bugs in their |
||
1342 | versions of the kernel that cause packets not to be given |
||
1343 | high-resolution time stamps even if the TSC is enabled. See, |
||
1344 | for example, bug 61111 for Red Hat Linux 7.2. If your |
||
1345 | distribution has a bug such as this, you may have to run a |
||
1346 | standard kernel from kernel.org in order to get high-resolution |
||
1347 | time stamps. |
||
1348 | |||
1349 | 9. Capturing packets on wireless LANs |
||
1350 | |||
1351 | Q 9.1: How can I capture raw 802.11 frames, including non-data |
||
1352 | (management, beacon) frames? |
||
1353 | |||
1354 | A: That depends on the operating system on which you're |
||
1355 | running, and on the 802.11 interface on which you're capturing. |
||
1356 | This would probably require that you capture in promiscuous |
||
1357 | mode or in the mode called "monitor mode" or "RFMON mode". On |
||
1358 | some platforms, or with some cards, this might require that you |
||
1359 | capture in monitor mode - promiscuous mode might not be |
||
1360 | sufficient. If you want to capture traffic on networks other |
||
1361 | than the one with which you're associated, you will have to |
||
1362 | capture in monitor mode. |
||
1363 | Not all operating systems support capturing non-data packets |
||
1364 | and, even on operating systems that do support it, not all |
||
1365 | drivers, and thus not all interfaces, support it. Even on those |
||
1366 | that do, monitor mode might not be supported by the operating |
||
1367 | system or by the drivers for all interfaces. |
||
1368 | NOTE: an interface running in monitor mode will, on most if not |
||
1369 | all platforms, not be able to act as a regular network |
||
1370 | interface; putting it into monitor mode will, in effect, take |
||
1371 | your machine off of whatever network it's on as long as the |
||
1372 | interface is in monitor mode, allowing it only to passively |
||
1373 | capture packets. |
||
1374 | This means that you should disable name resolution when |
||
1375 | capturing in monitor mode; otherwise, when Wireshark (or |
||
1376 | TShark, or tcpdump) tries to display IP addresses as host |
||
1377 | names, it will probably block for a long time trying to resolve |
||
1378 | the name because it will not be able to communicate with any |
||
1379 | DNS or NIS servers. |
||
1380 | See the Wireshark Wiki item on 802.11 capturing for details. |
||
1381 | |||
1382 | Q 9.2: How do I capture on an 802.11 device in monitor mode? |
||
1383 | |||
1384 | A: Whether you will be able to capture in monitor mode depends |
||
1385 | on the operating system, adapter, and driver you're using. See |
||
1386 | the previous question for information on monitor mode, |
||
1387 | including a link to the Wireshark Wiki page that gives details |
||
1388 | on 802.11 capturing. |
||
1389 | |||
1390 | 10. Viewing traffic |
||
1391 | |||
1392 | Q 10.1: Why am I seeing lots of packets with incorrect TCP |
||
1393 | checksums? |
||
1394 | |||
1395 | A: If the packets that have incorrect TCP checksums are all |
||
1396 | being sent by the machine on which Wireshark is running, this |
||
1397 | is probably because the network interface on which you're |
||
1398 | capturing does TCP checksum offloading. That means that the TCP |
||
1399 | checksum is added to the packet by the network interface, not |
||
1400 | by the OS's TCP/IP stack; when capturing on an interface, |
||
1401 | packets being sent by the host on which you're capturing are |
||
1402 | directly handed to the capture interface by the OS, which means |
||
1403 | that they are handed to the capture interface without a TCP |
||
1404 | checksum being added to them. |
||
1405 | The only way to prevent this from happening would be to disable |
||
1406 | TCP checksum offloading, but |
||
1407 | |||
1408 | 1. that might not even be possible on some OSes; |
||
1409 | 2. that could reduce networking performance significantly. |
||
1410 | |||
1411 | However, you can disable the check that Wireshark does of the |
||
1412 | TCP checksum, so that it won't report any packets as having TCP |
||
1413 | checksum errors, and so that it won't refuse to do TCP |
||
1414 | reassembly due to a packet having an incorrect TCP checksum. |
||
1415 | That can be set as an Wireshark preference by selecting |
||
1416 | "Preferences" from the "Edit" menu, opening up the "Protocols" |
||
1417 | list in the left-hand pane of the "Preferences" dialog box, |
||
1418 | selecting "TCP", from that list, turning off the "Check the |
||
1419 | validity of the TCP checksum when possible" option, clicking |
||
1420 | "Save" if you want to save that setting in your preference |
||
1421 | file, and clicking "OK". |
||
1422 | It can also be set on the Wireshark or TShark command line with |
||
1423 | a -o tcp.check_checksum:false command-line flag, or manually |
||
1424 | set in your preferences file by adding a |
||
1425 | tcp.check_checksum:false line. |
||
1426 | |||
1427 | Q 10.2: I've just installed Wireshark, and the traffic on my |
||
1428 | local LAN is boring. Where can I find more interesting |
||
1429 | captures? |
||
1430 | |||
1431 | A: We have a collection of strange and exotic sample capture |
||
1432 | files at https://wiki.wireshark.org/SampleCaptures |
||
1433 | |||
1434 | Q 10.3: Why doesn't Wireshark correctly identify RTP packets? |
||
1435 | It shows them only as UDP. |
||
1436 | |||
1437 | A: Wireshark can identify a UDP datagram as containing a packet |
||
1438 | of a particular protocol running atop UDP only if |
||
1439 | |||
1440 | 1. The protocol in question has a particular standard port |
||
1441 | number, and the UDP source or destination port number is |
||
1442 | that port |
||
1443 | 2. Packets of that protocol can be identified by looking for a |
||
1444 | "signature" of some type in the packet - i.e., some data |
||
1445 | that, if Wireshark finds it in some particular part of a |
||
1446 | packet, means that the packet is almost certainly a packet |
||
1447 | of that type. |
||
1448 | 3. Some other traffic earlier in the capture indicated that, |
||
1449 | for example, UDP traffic between two particular addresses |
||
1450 | and ports will be RTP traffic. |
||
1451 | |||
1452 | RTP doesn't have a standard port number, so 1) doesn't work; it |
||
1453 | doesn't, as far as I know, have any "signature", so 2) doesn't |
||
1454 | work. |
||
1455 | That leaves 3). If there's RTSP traffic that sets up an RTP |
||
1456 | session, then, at least in some cases, the RTSP dissector will |
||
1457 | set things up so that subsequent RTP traffic will be |
||
1458 | identified. Currently, that's the only place we do that; there |
||
1459 | may be other places. |
||
1460 | However, there will always be places where Wireshark is simply |
||
1461 | incapable of deducing that a given UDP flow is RTP; a mechanism |
||
1462 | would be needed to allow the user to specify that a given |
||
1463 | conversation should be treated as RTP. As of Wireshark 0.8.16, |
||
1464 | such a mechanism exists; if you select a UDP or TCP packet, the |
||
1465 | right mouse button menu will have a "Decode As..." menu item, |
||
1466 | which will pop up a dialog box letting you specify that the |
||
1467 | source port, the destination port, or both the source and |
||
1468 | destination ports of the packet should be dissected as some |
||
1469 | particular protocol. |
||
1470 | |||
1471 | Q 10.4: Why doesn't Wireshark show Yahoo Messenger packets in |
||
1472 | captures that contain Yahoo Messenger traffic? |
||
1473 | |||
1474 | A: Wireshark only recognizes as Yahoo Messenger traffic packets |
||
1475 | to or from TCP port 3050 that begin with "YPNS", "YHOO", or |
||
1476 | "YMSG". TCP segments that start with the middle of a Yahoo |
||
1477 | Messenger packet that takes more than one TCP segment will not |
||
1478 | be recognized as Yahoo Messenger packets (even if the TCP |
||
1479 | segment also contains the beginning of another Yahoo Messenger |
||
1480 | packet). |
||
1481 | |||
1482 | 11. Filtering traffic |
||
1483 | |||
1484 | Q 11.1: I saved a filter and tried to use its name to filter |
||
1485 | the display; why do I get an "Unexpected end of filter string" |
||
1486 | error? |
||
1487 | |||
1488 | A: You cannot use the name of a saved display filter as a |
||
1489 | filter. To filter the display, you can enter a display filter |
||
1490 | expression - not the name of a saved display filter - in the |
||
1491 | "Filter:" box at the bottom of the display, and type the |
||
1492 | <Enter> key or press the "Apply" button (that does not require |
||
1493 | you to have a saved filter), or, if you want to use a saved |
||
1494 | filter, you can press the "Filter:" button, select the filter |
||
1495 | in the dialog box that pops up, and press the "OK" button. |
||
1496 | |||
1497 | Q 11.2: How can I search for, or filter, packets that have a |
||
1498 | particular string anywhere in them? |
||
1499 | |||
1500 | A: If you want to do this when capturing, you can't. That's a |
||
1501 | feature that would be hard to implement in capture filters |
||
1502 | without changes to the capture filter code, which, on many |
||
1503 | platforms, is in the OS kernel and, on other platforms, is in |
||
1504 | the libpcap library. |
||
1505 | After capture, you can search for text by selecting Edit→Find |
||
1506 | Packet... and making sure String is selected. Alternately, you |
||
1507 | can use the "contains" display filter operator or "matches" |
||
1508 | operator if it's supported on your system. |
||
1509 | |||
1510 | Q 11.3: How do I filter a capture to see traffic for virus XXX? |
||
1511 | |||
1512 | A: For some viruses/worms there might be a capture filter to |
||
1513 | recognize the virus traffic. Check the CaptureFilters page on |
||
1514 | the Wireshark Wiki to see if anybody's added such a filter. |
||
1515 | Note that Wireshark was not designed to be an intrusion |
||
1516 | detection system; you might be able to use it as an IDS, but in |
||
1517 | most cases software designed to be an IDS, such as Snort or |
||
1518 | Prelude, will probably work better. |
||
1519 |