forked from the-tcpdump-group/tcpdump-htdocs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
faq.html
904 lines (817 loc) · 49.9 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
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
<!DOCTYPE html>
<!--
Created by : Luis MartinGarcia <http://www.aldabaknocking.com>
Original design : "Collaboration" by Free CSS Templates (later "TEMPLATED")
Original license : Creative Commons Attribution 2.5 License
-->
<html lang="en">
<!-- HEAD -->
<head>
<meta charset="utf-8">
<title>FAQ | TCPDUMP & LIBPCAP</title>
<meta name="description" content="Web site of Tcpdump and Libpcap">
<link href="style.css" rel="stylesheet" type="text/css" media="screen">
<link href="images/T-32x32.png" rel="shortcut icon" type="image/png">
</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="manpages/">Man Pages</a></li>
<li><a href="ci.html">CI</a></li>
<li><a href="linktypes.html">Link-Layer Header Types</a></li>
<li><a href="bpfexam/">BPF Exam</a></li>
<li><a href="related.html">See Also</a></li>
<li><a href="old_releases.html">Old Releases</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">
<!-- Start of QUESTION INDEX section -->
<div class="post">
<h2 class="title" id="index">
Frequently Asked Questions
</h2>
<!--
** NOTE TO EDITORS: To add a new FAQ entry, please assign a brand new qNN
** element id regardless of the new entry position in the list (so valid
** pre-existing HREFs on this web site and the Internet do not point to
** the new entry). Consider placing new entries at the top.
-->
<div class="entry">
<ul>
<li> <a href="#q15">I get packets from libpcap after a long delay, is this a bug?</a> </li>
<li> <a href="#q14">Why is the <code>pcap-int.h</code> header file missing from libpcap?</a> </li>
<li> <a href="#q13">Why my VLAN/MPLS packet filter does not work?</a> </li>
<li> <a href="#q12">How to decode a protocol on a non-standard port?</a> </li>
<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>
<!-- (Was Q10, removed.) -->
<li> <a href="#q11">How to update the man pages?</a> </li>
<li> <a href="#q16">What should and what should not be in the change log?</a> </li>
</ul>
</div>
</div>
<!-- End of QUESTION INDEX section -->
<!-- Start of QUESTION #15 section -->
<div class="post">
<h2 class="title" id="q15">
I get packets from libpcap after a long delay, is this a bug?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
I have a program that uses libpcap on Linux, it works as expected with
old versions of Linux kernel and/or old versions of libpcap; with modern
Linux kernels and modern libpcap versions the program waits on libpcap
for a much longer time (or even indefinitely). Is this a libpcap bug?
</p>
<p>
<span class=initial>A:</span>
This is a consequence of certain developments in Linux kernel and
libpcap; from a libpcap user's point of view the key concept involved is
"immediate mode", even though the latter is not Linux-specific.
</p>
<p>
In immediate mode libpcap receives captured packets from the OS kernel
one at a time, which results in a higher CPU overhead and a more likely
packet loss; in buffered mode it receives multiple packets at once, but
only after the buffer is full or its timeout has expired, which might
take much longer than expected—see "packet buffer timeout" in
<a href="manpages/pcap.3pcap.html"><b>pcap</b></a>(3PCAP) for a more
detailed explanation. For many use cases one particular mode works
much better than the other, also in buffered mode different values of
the timeout produce different results.
</p>
<p>
Linux kernel for a long time supported immediate mode only; since the
introduction of <code>TPACKET_V3</code> in version 3.2 it supports both
immediate and buffered modes. libpcap in version 1.5.0
added support for the buffered mode on Linux and made it the default
mode on Linux (subject to compile- and runtime conditions, as discussed
<a href="https://github.com/the-tcpdump-group/libpcap/issues/454">
here</a>). This did not change libpcap API behaviour, as far as the man
pages documented it, but in a number of cases it did change the default
user experience on Linux, as was discussed in great detail in libpcap
(<a href="https://github.com/the-tcpdump-group/libpcap/issues/335">335</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/350">350</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/354">354</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/382">382</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/472">472</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/550">550</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/572">572</a>)
and other bug reports.
</p>
<p>
The best approach would be not to rely on the default behaviour, but to
study the use case and the documentation, and to have the program
explicitly request the most appropriate mode using
<a href="manpages/pcap_set_immediate_mode.3pcap.html">
<b>pcap_set_immediate_mode</b></a>(3PCAP)
and the most appropriate timeout value (beware that zero is a
platform-dependent edge case) using
<a href="manpages/pcap_set_timeout.3pcap.html">
<b>pcap_set_timeout</b></a>(3PCAP) or
<a href="manpages/pcap_open_live.3pcap.html">
<b>pcap_open_live</b></a>(3PCAP).
For example, tcpdump does that conditionally at runtime to
achieve lower latency decoding live packets on one hand, and higher
throughput writing packets to a file on the other.
</p>
</div>
</div>
<!-- End of QUESTION #15 section -->
<!-- Start of QUESTION #14 section -->
<div class="post">
<h2 class="title" id="q14">
Why is the <code>pcap-int.h</code> header file missing from libpcap?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
I am trying to compile a program that uses libpcap, this works fine
when I use a complete source tree of libpcap. When I use the libpcap
development package provided with the operating system, on some systems
the compilation fails because of a missing header file
(<code>pcap-int.h</code> or another header that it includes). What is
the problem and how to solve it?
</p>
<p>
<span class=initial>A:</span>
In libpcap the <code>pcap-int.h</code> file has always been an internal
header, which means its contents may change at any time in any way.
Programs should never include libpcap internal headers directly and libpcap
packages should never install internal header files. However, some libpcap
packages do install <code>pcap-int.h</code> and some programs do include it
and, consequently, fail to compile with libpcap packages that [correctly] do
not install the internal headers.
</p>
<p>
The right solution is to fix the program not to include
<code>pcap-int.h</code>, as discussed in greater detail in libpcap
(<a href="https://github.com/the-tcpdump-group/libpcap/issues/457">457</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/560">560</a>)
and tcpslice
(<a href="https://github.com/the-tcpdump-group/tcpslice/pull/6">6</a>)
bug reports.
</p>
</div>
</div>
<!-- End of QUESTION #14 section -->
<!-- Start of QUESTION #13 section -->
<div class="post">
<h2 class="title" id="q13">
Why my VLAN/MPLS packet filter does not work?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
My packet filter expression includes the <code>vlan</code> or
<code>mpls</code> keyword(s); what it actually matches and what I expect
it to match are somewhat (or completely) different things, is this a bug?
</p>
<p>
<span class=initial>A:</span>
Most often this is not a bug, but a result of misunderstanding of how these
keywords work. The matter is, to test the packet for one or another
matching condition, filter primitives need to read data at specific offsets
from the beginning of the packet. As
<span class=manref><a href="manpages/pcap-filter.7.html"><b>pcap-filter</b></a>(7)</span>
mentions it,
some keywords automatically increment that offset for all subsequent
keywords in the filter expression—this stands for every <code>vlan</code>,
<code>mpls</code> or <code>geneve</code> keyword and for the first
<code>pppoes</code> or <code>lane</code> keyword.
</p>
<p>
On one hand, this simplifies expression syntax required to skip the outer
header(s) once and to test multiple conditions in the inner header(s), e.g.:
</p>
<pre>
vlan and src net (192.0.2.0/24 or 2001:db8::/32) and port 53
</pre>
<p>
On the other hand, and rather counterintuitively, the filter expression
</p>
<pre>
vlan 100 or vlan 200
</pre>
<p>
means "a packet with at least one 802.1Q tag and the outermost VLAN ID 100 or
a packet with at least two 802.1Q tags and the second outermost VLAN ID 200".
Unfortunately, the current syntax of those primitives does not support
expressions such as <code>vlan (100 or 200)</code>, which means that each
VLAN/MPLS/Geneve layer can be tested at most once.
</p>
<p>
In some cases it may be possible to achieve the desired effect by rearranging
the same primitives in the filter expression to place <code>vlan</code> or
<code>mpls</code> before or after other primitives, see tcpdump
(<a href="https://github.com/the-tcpdump-group/tcpdump/issues/113">113</a>,
<a href="https://github.com/the-tcpdump-group/tcpdump/issues/115">115</a>,
<a href="https://github.com/the-tcpdump-group/tcpdump/issues/606">606</a>,
<a href="https://github.com/the-tcpdump-group/tcpdump/issues/900">900</a>)
and libpcap
(<a href="https://github.com/the-tcpdump-group/libpcap/issues/408">408</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/798">798</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/916">916</a>,
<a href="https://github.com/the-tcpdump-group/libpcap/issues/1070">1070</a>)
bug reports for specific examples. Alternatively, it may be possible
(although not trivial) to rewrite the expression using different primitives,
as explained in
<a href="https://ask.wireshark.org/question/24957/capture-filter-pppoes-does-not-work-as-expected/">
this post</a>.
</p>
<p>
</p>
</div>
</div>
<!-- End of QUESTION #13 section -->
<!-- Start of QUESTION #12 section -->
<div class="post">
<h2 class="title" id="q12">
How to decode a protocol on a non-standard port?
</h2>
<div class="entry">
<p>
<span class=initial>A:</span>
This may be possible under certain conditions. First of all, the
network protocol of interest must be one of the protocols supported by
the <code>-T</code> flag of tcpdump. You can find the complete list in
<a href="manpages/tcpdump.1.html"><b>tcpdump</b></a>(1) (most of these
protocols are UDP-based).
</p>
<p>
If the protocol is supported, keep in mind that using <code>-T type</code>
will usually override the protocol detection for many unrelated packets
as well. For the best results you would need to apply a packet filter
to leave only the correct packets in scope. For example, to decode
RADIUS authentication packets on non-standard port 21812, you would need
to run tcpdump in a way similar to the following:
</p>
<pre>
tcpdump -T radius -nv udp port 21812
</pre>
<p>
If this approach does not solve the problem, you can consider
<a href="index.html#patches">contributing code</a> to extend tcpdump (see
<a href="https://github.com/the-tcpdump-group/tcpdump/issues/495">this
discussion</a>) or using a different packet analyzer. For example,
<a class=away
href="https://mta.openssl.org/pipermail/openssl-users/2017-April/005624.html">this
mailing list post</a> explains how to use <code>tshark</code> to examine
the SSL protocol exchange of an FTPS connection that uses a non-standard
TCP port. In the specific case of SSL/TLS, it is also possible to use
<code>ssldump</code>.
</p>
</div>
</div>
<!-- End of QUESTION #12 section -->
<!-- Start of QUESTION #2 section -->
<div class="post">
<h2 class="title" id="q2">
How come I can not compile on Solaris?
</h2>
<div class="entry">
<p>
<span class=initial>A:</span>
You need to install <code>flex</code>. AT&T
<code>lex</code> 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">
summary</a>. See also libpcap
<a href="https://github.com/the-tcpdump-group/libpcap/blob/master/INSTALL.md">
generic</a> and
<a href="https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.solaris.md">
Solaris-related</a> installation notes.
</p>
</div>
</div>
<!-- End of QUESTION #2 section -->
<!-- Start of QUESTION #3 section -->
<div class="post">
<h2 class="title" id="q3">
Why is tcpdump's address space steadily growing?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
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>
<span class=initial>A:</span>
Run it with <code>-S</code>. 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" id="q4">
Why don't I see all the traffic I expect?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
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>
<span class=initial>A:</span>
This might be because the interface on that 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 class=away href="https://gitlab.com/wireshark/wireshark/-/wikis/SwitchReference">
the switch reference page</a> on the Wireshark
Wiki for information on some switches. (Note that it's a Wiki, so
you can update or fix that information, or add additional information on
those switches or information on new switches, yourself.)
</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 that 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 that it's capturing into promiscuous mode
unless the <code>-p</code> 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 class=away
href="https://web.archive.org/web/20100415164103/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" id="q5">
Why don't I see TCP traffic other than traffic to and from my machine?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
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>
<span class=initial>A:</span>
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" id="q6">
Why do I only see ARP packets when I try to capture traffic?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
I'm trying to capture traffic on my network; why am I only seeing ARP
packets?
</p>
<p>
<span class=initial>A:</span>
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" id="q7">
How do I put an interface into promiscuous mode?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
I'm trying to capture all the traffic on my network; how do I put my
interface into promiscuous mode?
</p>
<p>
<span class=initial>A:</span>
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
<code>ifconfig</code> 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" id="q8">
When is a packet time-stamped? How accurate are the time stamps?
</h2>
<div class="entry">
<p>
<span class=initial>A:</span>
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 that 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" id="q9">
Why do my time stamps on Linux have only 100ms resolution?
</h2>
<div class="entry">
<p>
<span class=initial>Q:</span>
I'm running tcpdump on Linux; why do my time stamps have
only 100ms resolution, rather than 1µs resolution?
</p>
<p>
<span class=initial>A:</span>
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 <code>CONFIG_X86_TSC</code> 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,
<a class=away href="https://bugzilla.redhat.com/show_bug.cgi?id=61111">
bug 61111 for Red Hat Linux 7.2</a>.
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 -->
<!-- (Was Q10, removed.) -->
<!-- Start of QUESTION #11 section -->
<div class="post">
<h2 class="title" id="q11">
How to update the man pages?
</h2>
<div class="entry">
<p>
<span class=initial>A:</span>
All man pages for libpcap, tcpdump and tcpslice come from the same git
repository as the software they document. Most man pages are stored in
their original format (e.g. <code>pcap-config.1</code>,
<code>pcap_strerror.3pcap</code>,
<code>tcpslice.1</code>). Some man pages depend on
particulars handled by a build system. In such case there is a
corresponding source <code>.in</code> file in the
repository, which the build system converts to an output file in the
working copy (with GNU Autoconf this can be done again later by
running <code>./config.status</code>), e.g:
</p>
<ul>
<li><code>tcpdump.1.in</code> →
<code>tcpdump.1</code></li>
<li><code>pcap-filter.manmisc.in</code> →
<code>pcap-filter.manmisc</code></li>
<li><code>pcap_dump_open.3pcap.in</code> →
<code>pcap_dump_open.3pcap</code></li>
</ul>
<p>
A few words about the man page dates. Less the comments, every man page
usually starts with a command similar to the following:
</p>
<pre>
.TH PCAP_INIT 3PCAP "11 April 2020"
</pre>
<p>
Both the text and the HTML versions of the man page display this date,
which informs the readers about substantial changes to the content (to
make it easy, for example, to tell if a specific function's man page is
different between two particular versions of libpcap). With this in
mind, when updating a man page, please update the date if and only if
the changes include any of the following:
</p>
<ul>
<li>a C function's arguments or return value</li>
<li>a program's command-line arguments, i/o data or exit status</li>
<li>other documented behaviour or usage semantics</li>
<li>backward compatibility</li>
</ul>
<p>
The man pages use a mixture of formatting languages. When making
changes, please try to keep the style consistent. Below are a few
examples of common use cases.
</p>
<pre>
.\" Add a comment.
.\" Start a new paragraph.
.PP
.\" Start a new section.
.SH BACKWARD COMPATIBILITY
.\" Use a bold font for the rest of the line, including any
.\" punctuation marks.
.B \-\-list\-interfaces
.B \-\-help
.B 21h36m 26d1h54m.
.\" Idem, italics.
.I tcpdump
.I libpcap
.I snaplen
.\" Use a bold font for the first word and regular font for
.\" the second word, including any punctuation marks.
.BR date (1).
.BR "ifconfig \-a" );
.\" Refer to a special constant, e.g. input or output of a
.\" C function.
.B PCAP_ERROR_IFACE_NOT_UP
.BR NULL ,
.B \-1
.B DLT_EN10MB
.\" Refer to another man page for the first time in this page.
.BR pcap_dump (3PCAP)
.BR select (2)
.BR pcap-filter (@MAN_MISC_INFO@)
.\" The 2nd and subsequent times.
.BR pcap_dump ()
.BR select ()
.BR pcap-filter ()
.\" Prevent a long word (a man page name, an e-mail address
.\" or an URL), especially one that contains dashes, from
.\" hyphenation. This keeps the plain text output readable.
.BR \%pcap-tstamp (7);
.BR \%pcap-savefile (@MAN_FILE_FORMATS@)
.BR \%pcap_open_offline_with_tstamp_precision (3PCAP)
Example web site is \%https://example.org/
Example e-mail is \%nobody@example.org.
</pre>
</div>
</div>
<!-- End of QUESTION #11 section -->
<!-- Start of QUESTION #16 section -->
<div class="post">
<h2 class="title" id="q16">
What should and what should not be in the change log?
</h2>
<div class="entry">
<p>
<span class=initial>A:</span>
The change log purpose is to help the end users understand what a
particular software release means for their particular use case. With
this in mind, when preparing files for a commit, please consider
whether to include a change log entry and what to say in the entry to
document the change well. The following guidelines can be used as a
starting point.
</p>
<p>
Any of the following likely has to have a change log entry:
</p>
<ul>
<li>bug fixes</li>
<li>new features</li>
<li>API changes</li>
<li>difference in observed or documented behaviour</li>
<li>difference in the intended usage</li>
<li>difference in backward compatibility</li>
<li><a href="#q11">substantial</a> changes to the man page(s)</li>
<li>difference in build dependencies (Autoconf, CMake, compilers,
libraries)</li>
<li>difference in the result of <code>make install</code></li>
<li>difference in runtime dependencies (OS kernel or configuration,
libraries)</li>
<li>difference in integration level of specific OSes</li>
<li>changes to the <code>VERSION</code> file</li>
</ul>
<p>
Any of the following likely does not require a change log entry:
</p>
<ul>
<li>cosmetic improvements (comments, typos, formatting)</li>
<li>changes to integration of external development tools (CI, code
analysis)</li>
<li>changes to build matrix scripts</li>
<li>changes to repository-specific files such as <code>.mailmap</code>,
<code>.gitignore</code> and <code>.gitattributes</code></li>
<li>changes that have been replaced by later changes within the same
release</li>
<li>changes that fix minor issues with earlier changes that have
already been described for the same release</li>
<li>changes that do not result in meaningful difference in the release
tarball</li>
<li>changes to the <code>CREDITS</code> file</li>
<li>changes to the <code>CHANGES</code> file itself</li>
</ul>
</div>
</div>
<!-- End of QUESTION #5 section -->
</div>
<!-- END OF PAGE CONTENTS -->
<!-- FOOTER -->
<div id="footer">
<p>
© 2010–2023 The Tcpdump Group. Designed by
<a class=away href="https://www.luismg.com/">Luis MartinGarcia</a>;
based on a template by TEMPLATED.
</p>
</div>
<!-- END OF FOOTER -->
</body>
<!-- END OF HTML BODY -->
</html>