forked from the-tcpdump-group/tcpdump-htdocs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
faq.html
528 lines (459 loc) · 27.8 KB
/
faq.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!--
Created by : Luis MartinGarcia <http://www.aldabaknocking.com>
Original design : "Collaboration" by Free CSS Templates <http://www.freecsstemplates.org>
Original license : Creative Commons Attribution 2.5 License
-->
<html>
<!-- HEAD -->
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>FAQ | TCPDUMP/LIBPCAP public repository</title>
<meta name="keywords" content="tcpdump, libpcap, pcap, packet capture, sniffer, security, eavesdrop">
<meta name="description" content="Web site of Tcpdump and Libpcap">
<link href="style.css" rel="stylesheet" type="text/css" media="screen">
<link rel="canonical" href="https://www.tcpdump.org">
</head>
<!-- END OF HTML HEAD -->
<!-- BODY -->
<body>
<!-- TOP MENU -->
<div id="menu">
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="security.html">Security</a></li>
<li class="current_page_item"><a href="faq.html">FAQ</a></li>
<li><a href="linktypes.html">Link-Layer Header Types</a></li>
<li><a href="related.html">Related Projects</a></li>
<li><a href="license.html">Licenses</a></li>
<li><a href="old_releases.html">Old Releases</a></li>
<li><a href="mirrors.html">Mirrors</a></li>
</ul>
</div>
<!-- END OF TOP MENU -->
<!-- PAGE HEADER -->
<div id="splash">
<br><img src="images/logo.png" alt="">
</div>
<div id="logo">
<hr>
</div>
<!-- END OF PAGE HEADER -->
<!-- PAGE CONTENTS -->
<div id="page">
<!-- RIGHT HAND SIDE PAGE CONTENTS -->
<div id="content">
<!-- Start of QUESTION INDEX section -->
<div class="post">
<h2 class="title">
<a name="index">TCPDUMP.org Frequently Asked Questions</a>
</h2>
<div class="entry">
<ul>
<li> <a href="#q2">How come I can not compile on Solaris?</a> </li>
<li> <a href="#q3">Why is tcpdump's address space steadily growing?</a> </li>
<li> <a href="#q4">Why don't I see all the traffic I expect?</a> </li>
<li> <a href="#q5">Why don't I see TCP traffic other than traffic to and
from my machine?</a> </li>
<li> <a href="#q6">Why do I only see ARP packets when I try to capture
traffic?</a></li>
<li> <a href="#q7">How do I put an interface into promiscuous mode?
</a></li>
<li> <a href="#q8">When is a packet time-stamped? How accurate
are the time stamps?</a> </li>
<li> <a href="#q9">Why do my time stamps on Linux have only 100ms
resolution?</a> </li>
<li> <a href="#q10">Why are my time stamps on Windows 95/98/Me wrong?</a> </li>
</ul>
</div>
</div>
<!-- End of QUESTION INDEX section -->
<!-- Start of QUESTION #2 section -->
<div class="post">
<h2 class="title">
<a name="q2">How come I can not compile on Solaris?</a>
</h2>
<div class="entry">
You need to install FLEX. AT&T lex has some parameter set
too low. See <a href="https://web.archive.org/web/20010129094200/http://www.tcpdump.org:80/lists/workers/2000/msg00404.html">
the thread</a> <a href="https://web.archive.org/web/20010126233700/http://www.tcpdump.org/lists/workers/2000/msg00677.html">
summmary</a>
</div>
</div>
<!-- End of QUESTION #2 section -->
<!-- Start of QUESTION #3 section -->
<div class="post">
<h2 class="title">
<a name="q3">Why is tcpdump's address space steadily growing?</a>
</h2>
<div class="entry">
<p>
Q: A tcpdump command that's been running for a long time seems to be
leaking memory; its address space size seems to be increasing steadily
over time. Why is this happening, and how can I keep it from leaking
memory?
</p>
<p>
A: Run it with -S. Otherwise, tcpdump keeps track of all the
connections it has seen so it can generate relative sequence numbers
rather than absolute sequence numbers. This looks like a leak, but is
in fact just state accumulation.
</p>
</div>
</div>
<!-- End of QUESTION #3 section -->
<!-- Start of QUESTION #4 section -->
<div class="post">
<h2 class="title">
<a name="q4">Why don't I see all the traffic I expect?</a>
</h2>
<div class="entry">
<p>
Q: When I use tcpdump to capture packets, why do I see
only packets to or from my machine, or why do I not see all the traffic
I'm expecting to see from or to the machine I'm trying to
monitor?
</p>
<p>
This might be because the interface on which you're capturing is plugged
into a 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.
</p>
<p>
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.
</p>
<p>
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 <em>vice
versa</em>. This problem has also been reported for Netgear dual-speed
hubs, and may exist for other "auto-sensing" or "dual-speed" hubs.
</p>
<p>
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 <a href="http://wiki.wireshark.org/SwitchReference">the switch
reference page</a> on <a href="http://wiki.wireshark.org/">the Wireshark
Wiki</a> 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.)
</p>
<p>
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 tcpdump 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.
</p>
<p>
If your machine is <em>not</em> 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:
</p>
<ul>
<li>
packets sent to one of that host's link-layer addresses;
</li>
<li>
broadcast packets;
</li>
<li>
multicast packets sent to a multicast address that the
host has configured the interface to accept.
</li>
</ul>
<p>
Most network interfaces can also be put in "promiscuous" mode, in which
they supply to the host all network packets they see. Tcpdump will try
to put the interface on which it's capturing into promiscuous mode
unless the <tt>-p</tt> option was specified. However, some network
interfaces don't support promiscuous mode, and some OSes might not allow
interfaces to be put into promiscuous mode.
</p>
<p>
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
<strong>will</strong> see broadcast packets, and multicast packets sent
to a multicast MAC address the interface is set up to receive.
</p>
<p>
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.
</p>
<p>
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. Ask the vendor of the card how to do this, or see,
for example, <a
href="http://www.madge.com/_assets/downloads/lsshelp8.0/LSSHelp/AdvFeat/Promisc/Promisc2.htm">this
information on promiscuous mode on some Madge token ring adapters</a>
(note that those cards can have promiscuous mode disabled permanently,
in which case you <em>can't</em> enable it).
</p>
<p>
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 <em>and</em> acting as regular network interfaces at the same
time), so it may be that Windows drivers for those interfaces don't
support promiscuous mode.
</p>
</div>
</div>
<!-- End of QUESTION #4 section -->
<!-- Start of QUESTION #5 section -->
<div class="post">
<h2 class="title">
<a name="q5">Why don't I see TCP traffic other than traffic to and from my machine?</a>
</h2>
<div class="entry">
<p>
Q: Why can't I see any TCP packets other than packets to or from my
machine, even though another sniffer on the network sees those packets?
</p>
<p>
You're probably not seeing <em>any</em> 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.
</p>
<p>
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.
</p>
<p>
I.e., this is probably <a href="#q4">the same question
as this earlier one</a>; see the response to that question.
</p>
</div>
</div>
<!-- End of QUESTION #5 section -->
<!-- Start of QUESTION #6 section -->
<div class="post">
<h2 class="title">
<a name="q6">Why do I only see ARP packets when I try to capture traffic?</a>
</h2>
<div class="entry">
<p>
Q: I'm trying to capture traffic on my network; why am I only seeing ARP
packets?
</p>
<p>
You're probably on a switched network, and running tcpdump 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.
</p>
<p>
I.e., this is probably <a href="#q4">the same question
as this earlier one</a>; see the response to that question.
</p>
</div>
</div>
<!-- End of QUESTION #6 section -->
<!-- Start of QUESTION #7 section -->
<div class="post">
<h2 class="title">
<a name="q7">How do I put an interface into promiscuous mode?</a>
</h2>
<div class="entry">
<p>
Q: I'm trying to capture all the traffic on my network; how do I put my
interface into promiscuous mode?
</p>
<p>
By not disabling promiscuous mode when running tcpdump. Note, however, that:
</p>
<ul>
<li>
the form of promiscuous mode that libpcap (the library that
programs such as tcpdump use to do packet capture)
turns on will <strong>not</strong> necessarily be shown if you run
<tt>ifconfig</tt> on the interface on a UNIX system;
</li>
<li>
some network interfaces might not support promiscuous mode, and some
drivers might not allow promiscuous mode to be turned on - see <a
href="#q4">this earlier question</a> for more information on
that;
</li>
<li>
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 tcpdump, does not mean that
promiscuous mode isn't on - see <a href="#q4">this earlier
question</a> for more information on that.
</li>
</ul>
<p>
You're probably on a switched network, and running tcpdump 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.
</p>
<p>
I.e., this is probably <a href="#q4">the same question
as this earlier one</a>; see the response to that question.
</p>
</div>
</div>
<!-- End of QUESTION #7 section -->
<!-- Start of QUESTION #8 section -->
<div class="post">
<h2 class="title">
<a name="q8">When is a packet time-stamped? How accurate are the time stamps?</a>
</h2>
<div class="entry">
<p>
Q: When is a packet time-stamped? How accurate are the time stamps?
</p>
<p>
Tcpdump gets time stamps from libpcap, and libpcap gets them from the OS
kernel, so tcpdump - and any other program using libpcap, such as
Wireshark or snoop - is at the mercy of the time stamping code in the OS
for time stamps.
</p>
<p>
In most OSes on which tcpdump and libpcap run, the packet is time
stamped as part of the process of the network interface's device driver,
or the networking stack, handling it. This means that the packet is not
time stamped at the instant that it arrives at the network interface;
after the packet arrives at the network interface, there will be a delay
until an interrupt is delivered or the network interface is polled
(i.e., the network interface might not interrupt the host immediately -
the driver may be set up to poll the interface if network traffic is
heavy, to reduce the number of interrupts and process more packets per
interrupt), and there will be a further delay between the point at which
the interrupt starts being processed and the time stamp is generated.
</p>
<p>
On some OSes, such as HP-UX, the OS kernel does not time stamp the
packet at all; instead, it's time stamped by libpcap at the time it
reads the packet from the OS kernel, which means that there will be an
even greater delay between the time the packet arrives and the time that
it's time-stamped.
</p>
<p>
Thus, the packet time stamp is not necessarily a very accurate
indication of the time it arrived at the machine that captured the
packet.
</p>
</div>
</div>
<!-- End of QUESTION #8 section -->
<!-- Start of QUESTION #9 section -->
<div class="post">
<h2 class="title">
<a name="q9">Why do my time stamps on Linux have only 100ms resolution?</a>
</h2>
<div class="entry">
<p>
Q: I'm running tcpdump on Linux; why do my time stamps have
only 100ms resolution, rather than 1us resolution?
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</div>
</div>
<!-- End of QUESTION #9 section -->
<!-- Start of QUESTION #10 section -->
<div class="post">
<h2 class="title">
<a name="q10">Why are my time stamps on Windows wrong?</a>
</h2>
<div class="entry">
<p>
Q: I'm capturing packets on Windows, why are the time stamps on packets wrong?
</p>
<p>
This is due to a bug in WinPcap. The bug should be fixed in the WinPcap
3.0 beta release - note that it's an beta release, so it may be
buggier than the current production release of WinPcap; please report
those bugs to the WinPcap developers, and help them try to track down
the problem, so that they can fix it for the final release.
</p>
</div>
</div>
<!-- End of QUESTION #10 section -->
</div>
<!-- RIGHT HAND SIDE PAGE CONTENTS -->
<!-- LEFT SIDEBAR -->
<div id="sidebar">
<ul>
<li>
<h2>Contents</h2>
<ul>
<li><a href="index.html#documentation">Documentation</a></li>
<li><a href="index.html#latest-releases">Latest Releases</a></li>
<li><a href="index.html#source">Current Development Version</a></li>
<li><a href="index.html#mailing-lists">Mailing List</a></li>
<li><a href="index.html#patches">Patches, Bug Reports and Feature Requests</a></li>
<li><a href="index.html#contribute">How to Contribute</a></li>
</ul>
</li>
</ul>
</div>
<!-- END OF LEFT SIDEBAR -->
</div>
<!-- END OF PAGE CONTENTS -->
<!-- FOOTER -->
<div id="footer">
<p>
© 2010-2021 The Tcpdump Group. Designed by
<a href="http://www.aldabaknocking.com/">Luis MartinGarcia</a>;
based on a template by <a href="https://templated.co/">TEMPLATED</a>.
<a href="https://validator.w3.org/check?uri=referer">[Valid HTML
4.01]</a> <a href="https://jigsaw.w3.org/css-validator/check/referer">
[Valid CSS]</a>
</p>
</div>
<!-- END OF FOOTER -->
</body>
<!-- END OF HTML BODY -->
</html>