EditPageHistoryDiffInfoLikePages

Annotated edit history of tcpdump(8) version 2, including all changes. View license author blame.

Rev	Author	#	Line
1	perry	1	TCPDUMP
		2	!!!TCPDUMP
		3	NAME
		4	SYNOPSIS
		5	DESCRIPTION
		6	OPTIONS
		7	EXAMPLES
		8	OUTPUT FORMAT
		9	SEE ALSO
		10	AUTHORS
		11	BUGS
		12	----
		13	!!NAME
		14
		15
		16	tcpdump - dump traffic on a network
		17	!!SYNOPSIS
		18
		19
		20	__tcpdump__ [[ __-adeflnNOpqRStvxX__ ] [[ __-c__
		21	''count'' ] [[ __-F__ ''file'' ]
		22
		23
		24	[[ __-i__ ''interface'' ] [[ __-m__ ''module'' ] [[
		25	__-r__ ''file'' ]
		26
		27
		28	[[ __-s__ ''snaplen'' ] [[ __-T__ ''type'' ] [[
		29	__-w__ ''file'' ]
		30
		31
		32	[[ __-E__ ''algo:secret'' ] [[ ''expression''
		33	]
		34	!!DESCRIPTION
		35
		36
		37	''Tcpdump'' prints out the headers of packets on a
		38	network interface that match the boolean
		39	''expression''.
		40
		41
		42	__Under SunOS with nit or bpf:__ To run ''tcpdump''
		43	you must have read access to ''/dev/nit'' or
		44	''/dev/bpf*''. __Under Solaris with dlpi:__ You must
		45	have read/write access to the network pseudo device, e.g.
		46	''/dev/le''. __Under HP-UX with dlpi:__ You must be
		47	root or it must be installed setuid to root. __Under IRIX
		48	with snoop:__ You must be root or it must be installed
		49	setuid to root. __Under Linux:__ You must be root or it
		50	must be installed setuid to root. __Under Ultrix and
		51	Digital UNIX:__ Once the super-user has enabled
		52	promiscuous-mode operation using pfconfig(8), any
		53	user may run __tcpdump__. __Under BSD:__ You must have
		54	read access to ''/dev/bpf*''.
		55	!!OPTIONS
		56
		57
		58	__-a__
		59
		60
		61	Attempt to convert network and broadcast addresses to
		62	names.
		63
		64
		65	__-c__
		66
		67
		68	Exit after receiving ''count'' packets.
		69
		70
		71	__-d__
		72
		73
		74	Dump the compiled packet-matching code in a human readable
		75	form to standard output and stop.
		76
		77
		78	__-dd__
		79
		80
		81	Dump packet-matching code as a __C__ program
		82	fragment.
		83
		84
		85	__-ddd__
		86
		87
		88	Dump packet-matching code as decimal numbers (preceded with
		89	a count).
		90
		91
		92	__-e__
		93
		94
		95	Print the link-level header on each dump line.
		96
		97
		98	__-E__
		99
		100
		101	Use ''algo:secret'' for decrypting IPsec ESP packets.
		102	Algorithms may be __des-cbc__, __3des-cbc__,
		103	__blowfish-cbc__, __rc3-cbc__, __cast128-cbc__, or
		104	__none__. The default is __des-cbc__. The ability to
		105	decrypt packets is only present if ''tcpdump'' was
		106	compiled with cryptography enabled. ''secret'' the ascii
		107	text for ESP secret key. We cannot take arbitrary binary
		108	value at this moment. The option assumes RFC2406 ESP, not
		109	RFC1827 ESP. The option is only for debugging purposes, and
		110	the use of this option with truly `secret' key is
		111	discouraged. By presenting IPsec secret key onto command
		112	line you make it visible to others, via ps(1) and
		113	other occasions.
		114
		115
		116	__-f__
		117
		118
		119	Print `foreign' internet addresses numerically rather than
		120	symbolically (this option is intended to get around serious
		121	brain damage in Sun's yp server -- usually it hangs forever
		122	translating non-local internet numbers).
		123
		124
		125	__-F__
		126
		127
		128	Use ''file'' as input for the filter expression. An
		129	additional expression given on the command line is
		130	ignored.
		131
		132
		133	__-i__
		134
		135
		136	Listen on ''interface''. If unspecified, ''tcpdump''
		137	searches the system interface list for the lowest numbered,
		138	configured up interface (excluding loopback). Ties are
		139	broken by choosing the earliest match.
		140
		141
		142	On Linux systems with 2.2 or later kernels, an
		143	''interface'' argument of ``any'' can be used to capture
		144	packets from all interfaces. Note that captures on the
		145	``any'' device will not be done in promiscuous
		146	mode.
		147
		148
		149	__-l__
		150
		151
		152	Make stdout line buffered. Useful if you want to see the
		153	data while capturing it. E.g.,
		154	``tcpdump -l | tee dat'' or ``tcpdump -l
		155
		156
		157	__-n__
		158
		159
		160	Don't convert addresses (i.e., host addresses, port numbers,
		161	etc.) to names.
		162
		163
		164	__-N__
		165
		166
		167	Don't print domain name qualification of host names. E.g.,
		168	if you give this flag then ''tcpdump'' will print ``nic''
		169	instead of ``nic.ddn.mil''.
		170
		171
		172	__-m__
		173
		174
		175	Load SMI MIB module definitions from file ''module''.
		176	This option can be used several times to load several MIB
		177	modules into ''tcpdump''.
		178
		179
		180	__-O__
		181
		182
		183	Do not run the packet-matching code optimizer. This is
		184	useful only if you suspect a bug in the
		185	optimizer.
		186
		187
		188	__-p__
		189
		190
		191	''Don't'' put the interface into promiscuous mode. Note
		192	that the interface might be in promiscuous mode for some
		193	other reason; hence, `-p' cannot be used as an abbreviation
		194	for `ether host {local-hw-addr} or ether
		195	broadcast'.
		196
		197
		198	__-q__
		199
		200
		201	Quick (quiet?) output. Print less protocol information so
		202	output lines are shorter.
		203
		204
		205	__-r__
		206
		207
		208	Read packets from ''file'' (which was created with the -w
		209	option). Standard input is used if ''file'' is
		210	``-''.
		211
		212
		213	__-s__
		214
		215
		216	Snarf ''snaplen'' bytes of data from each packet rather
		217	than the default of 68 (with SunOS's NIT, the minimum is
		218	actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP
		219	but may truncate protocol information from name server and
		220	NFS packets (see below). Packets truncated because of a
		221	limited snapshot are indicated in the output with
		222	``[[|''proto'']'', where ''proto'' is the name of the
		223	protocol level at which the truncation has occurred. Note
		224	that taking larger snapshots both increases the amount of
		225	time it takes to process packets and, effectively, decreases
		226	the amount of packet buffering. This may cause packets to be
		227	lost. You should limit ''snaplen'' to the smallest number
		228	that will capture the protocol information you're interested
		229	in. Setting ''snaplen'' to 0 means use the required
		230	length to catch whole packets.
		231
		232
		233	__-T__
		234
		235
		236	Force packets selected by expression''
		237	''type''. Currently known
2	perry	238	types are __cnfp__ (Cisco !NetFlow protocol), __rpc__
1	perry	239	(Remote Procedure Call), __rtp__ (Real-Time Applications
		240	protocol), __rtcp__ (Real-Time Applications control
		241	protocol), __snmp__ (Simple Network Management Protocol),
		242	__vat__ (Visual Audio Tool), and __wb__ (distributed
		243	White Board).
		244
		245
		246	__-R__
		247
		248
		249	Assume ESP/AH packets to be based on old specification
		250	(RFC1825 to RFC1829). If specified, ''tcpdump'' will not
		251	print replay prevention field. Since there is no protocol
		252	version field in ESP/AH specification, ''tcpdump'' cannot
		253	deduce the version of ESP/AH protocol.
		254
		255
		256	__-S__
		257
		258
		259	Print absolute, rather than relative, TCP sequence
		260	numbers.
		261
		262
		263	__-t__
		264
		265
		266	''Don't'' print a timestamp on each dump
		267	line.
		268
		269
		270	__-tt__
		271
		272
		273	Print an unformatted timestamp on each dump
		274	line.
		275
		276
		277	__-v__
		278
		279
		280	(Slightly more) verbose output. For example, the time to
		281	live, identification, total length and options in an IP
		282	packet are printed. Also enables additional packet integrity
		283	checks such as verifying the IP and ICMP header
		284	checksum.
		285
		286
		287	__-vv__
		288
		289
		290	Even more verbose output. For example, additional fields are
		291	printed from NFS reply packets.
		292
		293
		294	__-vvv__
		295
		296
		297	Even more verbose output. For example, telnet __SB__ ...
		298	__SE__ options are printed in full. With __-X__ telnet
		299	options are printed in hex as well.
		300
		301
		302	__-w__
		303
		304
		305	Write the raw packets to ''file'' rather than parsing and
		306	printing them out. They can later be printed with the -r
		307	option. Standard output is used if ''file'' is
		308	``-''.
		309
		310
		311	__-x__
		312
		313
		314	Print each packet (minus its link level header) in hex. The
		315	smaller of the entire packet or ''snaplen'' bytes will be
		316	printed.
		317
		318
		319	__-X__
		320
		321
		322	When printing hex, print ascii too. Thus if __-x__ is
		323	also set, the packet is printed in hex/ascii. This is very
		324	handy for analysing new protocols. Even if __-x__ is not
		325	also set, some parts of some packets may be printed in
		326	hex/ascii.
		327
		328
		329	''expression''
		330
		331
		332	selects which packets will be dumped. If no
		333	''expression'' is given, all packets on the net will be
		334	dumped. Otherwise, only packets for which ''expression''
		335	is `true' will be dumped.
		336
		337
		338	The ''expression'' consists of one or more
		339	''primitives.'' Primitives usually consist of an
		340	''id'' (name or number) preceded by one or more
		341	qualifiers. There are three different kinds of
		342	qualifier:
		343
		344
		345	''type''
		346
		347
		348	qualifiers say what kind of thing the id name or number
		349	refers to. Possible types are __host__, __net__ and
		350	__port__. E.g., `host foo', `net 128.3', `port 20'. If
		351	there is no type qualifier, __host__ is
		352	assumed.
		353
		354
		355	''dir''
		356
		357
		358	qualifiers specify a particular transfer direction to and/or
		359	from ''id''. Possible directions are __src__,
		360	__dst__, __src or dst__ and __src and dst__. E.g.,
		361	`src foo', `dst net 128.3', `src or dst port ftp-data'. If
		362	there is no dir qualifier, __src or dst__ is assumed. For
		363	`null' link layers (i.e. point to point protocols such as
		364	slip) the __inbound__ and __outbound__ qualifiers can
		365	be used to specify a desired direction.
		366
		367
		368	''proto''
		369
		370
		371	qualifiers restrict the match to a particular protocol.
		372	Possible protos are: __ether__, __fddi__, __tr__,
		373	__ip__, __ip6__, __arp__, __rarp__,
		374	__decnet__, __tcp__ and __udp__. E.g., `ether src
		375	foo', `arp net 128.3', `tcp port 21'. If there is no proto
		376	qualifier, all protocols consistent with the type are
		377	assumed. E.g., `src foo' means `(ip or arp or rarp) src foo'
		378	(except the latter is not legal syntax), `net bar' means
		379	`(ip or arp or rarp) net bar' and `port 53' means `(tcp or
		380	udp) port 53'.
		381
		382
		383	[[`fddi' is actually an alias for `ether'; the parser treats
		384	them identically as meaning ``the data link level used on
		385	the specified network interface.'' FDDI headers contain
		386	Ethernet-like source and destination addresses, and often
		387	contain Ethernet-like packet types, so you can filter on
		388	these FDDI fields just as with the analogous Ethernet
		389	fields. FDDI headers also contain other fields, but you
		390	cannot name them explicitly in a filter
		391	expression.
		392
		393
		394	Similarly, `tr' is an alias for `ether'; the previous
		395	paragraph's statements about FDDI headers also apply to
		396	Token Ring headers.]
		397
		398
		399	In addition to the above, there are some special `primitive'
		400	keywords that don't follow the pattern: __gateway__,
		401	__broadcast__, __less__, __greater__ and arithmetic
		402	expressions. All of these are described below.
		403
		404
		405	More complex filter expressions are built up by using the
		406	words __and__, __or__ and __not__ to combine
		407	primitives. E.g., `host foo and not port ftp and not port
		408	ftp-data'. To save typing, identical qualifier lists can be
		409	omitted. E.g., `tcp dst port ftp or ftp-data or domain' is
		410	exactly the same as `tcp dst port ftp or tcp dst port
		411	ftp-data or tcp dst port domain'.
		412
		413
		414	Allowable primitives are:
		415
		416
		417	__dst host__ ''host''
		418
		419
		420	True if the IPv4/v6 destination field of the packet is
		421	''host'', which may be either an address or a
		422	name.
		423
		424
		425	__src host__ ''host''
		426
		427
		428	True if the IPv4/v6 source field of the packet is
		429	''host''.
		430
		431
		432	__host__ ''host''
		433
		434
		435	True if either the IPv4/v6 source or destination of the
		436	packet is ''host''. Any of the above host expressions can
		437	be prepended with the keywords, __ip__, __arp__,
		438	__rarp__, or __ip6__ as in:
		439
		440
		441	__ip host__ ''host
		442	''
		443
		444
		445	which is equivalent to:
		446
		447
		448	__ether proto__ ''ip'' __and host__ ''host
		449	''
		450
		451
		452	If ''host'' is a name with multiple IP addresses, each
		453	address will be checked for a match.
		454
		455
		456	__ether dst__ ''ehost''
		457
		458
		459	True if the ethernet destination address is ''ehost''.
		460	''Ehost'' may be either a name from /etc/ethers or a
		461	number (see ''ethers''(3N) for numeric
		462	format).
		463
		464
		465	__ether src__ ''ehost''
		466
		467
		468	True if the ethernet source address is
		469	''ehost''.
		470
		471
		472	__ether host__ ''ehost''
		473
		474
		475	True if either the ethernet source or destination address is
		476	''ehost''.
		477
		478
		479	__gateway__ ''host''
		480
		481
		482	True if the packet used ''host'' as a gateway. I.e., the
		483	ethernet source or destination address was ''host'' but
		484	neither the IP source nor the IP destination was
		485	''host''. ''Host'' must be a name and must be found in
		486	both /etc/hosts and /etc/ethers. (An equivalent expression
		487	is
		488
		489
		490	__ether host__ ''ehost'' __and not host__ ''host
		491	''
		492
		493
		494	which can be used with either names or numbers for ''host /
		495	ehost''.) This syntax does not work in IPv6-enabled
		496	configuration at this moment.
		497
		498
		499	__dst net__ ''net''
		500
		501
		502	True if the IPv4/v6 destination address of the packet has a
		503	network number of ''net''. ''Net'' may be either a
		504	name from /etc/networks or a network number (see
		505	''networks(4)'' for details).
		506
		507
		508	__src net__ ''net''
		509
		510
		511	True if the IPv4/v6 source address of the packet has a
		512	network number of ''net''.
		513
		514
		515	__net__ ''net''
		516
		517
		518	True if either the IPv4/v6 source or destination address of
		519	the packet has a network number of ''net''.
		520
		521
		522	__net__ ''net'' __mask__ ''mask''
		523
		524
		525	True if the IP address matches ''net'' with the specific
		526	netmask. May be qualified with __src__ or __dst__.
		527	Note that this syntax is not valid for IPv6
		528	''net''.
		529
		530
		531	__net__ ''net''/''len''
		532
		533
		534	True if the IPv4/v6 address matches ''net'' a netmask
		535	''len'' bits wide. May be qualified with __src__ or
		536	__dst__.
		537
		538
		539	__dst port__ ''port''
		540
		541
		542	True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and
		543	has a destination port value of ''port''. The ''port''
		544	can be a number or a name used in /etc/services (see
		545	''tcp''(4P) and ''udp''(4P)). If a name is used, both
		546	the port number and protocol are checked. If a number or
		547	ambiguous name is used, only the port number is checked
		548	(e.g., __dst port 513__ will print both tcp/login traffic
		549	and udp/who traffic, and __port domain__ will print both
		550	tcp/domain and udp/domain traffic).
		551
		552
		553	__src port__ ''port''
		554
		555
		556	True if the packet has a source port value of
		557	''port''.
		558
		559
		560	__port__ ''port''
		561
		562
		563	True if either the source or destination port of the packet
		564	is ''port''. Any of the above port expressions can be
		565	prepended with the keywords, __tcp__ or __udp__, as
		566	in:
		567
		568
		569	__tcp src port__ ''port
		570	''
		571
		572
		573	which matches only tcp packets whose source port is
		574	''port''.
		575
		576
		577	__less__ ''length''
		578
		579
		580	True if the packet has a length less than or equal to
		581	''length''. This is equivalent to:
		582
		583
		584	__len __ ''length''__.
		585	__
		586
		587
		588	__greater__ ''length''
		589
		590
		591	True if the packet has a length greater than or equal to
		592	''length''. This is equivalent to:
		593
		594
		595	__len __ ''length''__.
		596	__
		597
		598
		599	__ip proto__ ''protocol''
		600
		601
		602	True if the packet is an IP packet (see ''ip''(4P)) of
		603	protocol type ''protocol''. ''Protocol'' can be a
		604	number or one of the names ''icmp'', ''icmp6'',
		605	''igmp'', ''igrp'', ''pim'', ''ah'', ''esp'',
		606	''udp'', or ''tcp''. Note that the identifiers
		607	''tcp'', ''udp'', and ''icmp'' are also keywords
		608	and must be escaped via backslash (), which is \ in the
		609	C-shell. Note that this primitive does not chase protocol
		610	header chain.
		611
		612
		613	__ip6 proto__ ''protocol''
		614
		615
		616	True if the packet is an IPv6 packet of protocol type
		617	''protocol''. Note that this primitive does not chase
		618	protocol header chain.
		619
		620
		621	__ip6 protochain__ ''protocol''
		622
		623
		624	True if the packet is IPv6 packet, and contains protocol
		625	header with type ''protocol'' in its protocol header
		626	chain. For example,
		627
		628
		629	__ip6 protochain 6
		630	__
		631
		632
		633	matches any IPv6 packet with TCP protocol header in the
		634	protocol header chain. The packet may contain, for example,
		635	authentication header, routing header, or hop-by-hop option
		636	header, between IPv6 header and TCP header. The BPF code
		637	emitted by this primitive is complex and cannot be optimized
		638	by BPF optimizer code in ''tcpdump'', so this can be
		639	somewhat slow.
		640
		641
		642	__ip protochain__ ''protocol''
		643
		644
		645	Equivalent to __ip6 protochain__ ''protocol'', but
		646	this is for IPv4.
		647
		648
		649	__ether broadcast__
		650
		651
		652	True if the packet is an ethernet broadcast packet. The
		653	''ether'' keyword is optional.
		654
		655
		656	__ip broadcast__
		657
		658
		659	True if the packet is an IP broadcast packet. It checks for
		660	both the all-zeroes and all-ones broadcast conventions, and
		661	looks up the local subnet mask.
		662
		663
		664	__ether multicast__
		665
		666
		667	True if the packet is an ethernet multicast packet. The
		668	''ether'' keyword is optional. This is shorthand for
		669	`__ether[[0] __'.
		670
		671
		672	__ip multicast__
		673
		674
		675	True if the packet is an IP multicast packet.
		676
		677
		678	__ip6 multicast__
		679
		680
		681	True if the packet is an IPv6 multicast packet.
		682
		683
		684	__ether proto__ ''protocol''
		685
		686
		687	True if the packet is of ether type ''protocol''.
		688	''Protocol'' can be a number or one of the names
		689	''ip'', ''ip6'', ''arp'', ''rarp'',
		690	''atalk'', ''aarp'', ''decnet'', ''sca'',
		691	''lat'', ''mopdl'', ''moprc'', or ''iso''. Note
		692	these identifiers are also keywords and must be escaped via
		693	backslash (). [[In the case of FDDI (e.g., `__fddi protocol
		694	arp__'), the protocol identification comes from the 802.2
		695	Logical Link Control (LLC) header, which is usually layered
		696	on top of the FDDI header. ''Tcpdump'' assumes, when
		697	filtering on the protocol identifier, that all FDDI packets
		698	include an LLC header, and that the LLC header is in
		699	so-called SNAP format. The same applies to Token
		700	Ring.]
		701
		702
		703	__decnet src__ ''host''
		704
		705
		706	True if the DECNET source address is ''host'', which may
		707	be an address of the form ``10.123'', or a DECNET host name.
		708	[[DECNET host name support is only available on Ultrix
		709	systems that are configured to run DECNET.]
		710
		711
		712	__decnet dst__ ''host''
		713
		714
		715	True if the DECNET destination address is
		716	''host''.
		717
		718
		719	__decnet host__ ''host''
		720
		721
		722	True if either the DECNET source or destination address is
		723	''host''.
		724
		725
		726	__ip__, __ip6__, __arp__, __rarp__,
		727	__atalk__, __aarp__, __decnet__,
		728	__iso__
		729
		730
		731	Abbreviations for:
		732
		733
		734	__ether proto__ ''p
		735	''
		736
		737
		738	where ''p'' is one of the above protocols.
		739
		740
		741	__lat__, __moprc__, __mopdl__
		742
		743
		744	Abbreviations for:
		745
		746
		747	__ether proto__ ''p
		748	''
		749
		750
		751	where ''p'' is one of the above protocols. Note that
		752	''tcpdump'' does not currently know how to parse these
		753	protocols.
		754
		755
		756	__vlan__ ''[[vlan_id]''
		757
		758
		759	True if the packet is an IEEE 802.1Q VLAN packet. If
		760	''[[vlan_id]'' is specified, only true is the packet has
		761	the specified ''vlan_id''. Note that the first
		762	__vlan__ keyword encountered in ''expression'' changes
		763	the decoding offsets for the remainder of ''expression''
		764	on the assumption that the packet is a VLAN
		765	packet.
		766
		767
		768	__tcp__, __udp__, __icmp__
		769
		770
		771	Abbreviations for:
		772
		773
		774	__ip proto__ ''p'' __or ip6 proto__ ''p
		775	''
		776
		777
		778	where ''p'' is one of the above protocols.
		779
		780
		781	__iso proto__ ''protocol''
		782
		783
		784	True if the packet is an OSI packet of protocol type
		785	''protocol''. ''Protocol'' can be a number or one of
		786	the names ''clnp'', ''esis'', or
		787	''isis''.
		788
		789
		790	__clnp__, __esis__, __isis__
		791
		792
		793	Abbreviations for:
		794
		795
		796	__iso proto__ ''p
		797	''
		798
		799
		800	where ''p'' is one of the above protocols. Note that
		801	''tcpdump'' does an incomplete job of parsing these
		802	protocols.
		803
		804
		805	''expr relop expr''
		806
		807
		808	True if the relation holds, where ''relop'' is one of
		809	''expr'' is an
		810	arithmetic expression composed of integer constants
		811	(expressed in standard C syntax), the normal binary
		812	operators [[+, -, *, /,
		813	''
		814
		815
		816	''proto'' __[[__ ''expr'' __:__ ''size'' __]
		817	__
		818
		819
		820	''Proto'' is one of __ether, fddi, tr, ip, arp, rarp,
		821	tcp, udp, icmp__ or __ip6__, and indicates the protocol
		822	layer for the index operation. Note that ''tcp, udp'' and
		823	other upper-layer protocol types only apply to IPv4, not
		824	IPv6 (this will be fixed in the future). The byte offset,
		825	relative to the indicated protocol layer, is given by
		826	''expr''. ''Size'' is optional and indicates the
		827	number of bytes in the field of interest; it can be either
		828	one, two, or four, and defaults to one. The length operator,
		829	indicated by the keyword __len__, gives the length of the
		830	packet.
		831
		832
		833	For example, `__ether[[0] __' catches all
		834	multicast traffic. The expression `__ip[[0]
		835	__' catches all IP packets with options. The expression
		836	`__ip[[6:2] __' catches only unfragmented
		837	datagrams and frag zero of fragmented datagrams. This check
		838	is implicitly applied to the __tcp__ and __udp__ index
		839	operations. For instance, __tcp[[0]__ always means the
		840	first byte of the TCP ''header'', and never means the
		841	first byte of an intervening fragment.
		842
		843
		844	Primitives may be combined using:
		845
		846
		847	A parenthesized group of primitives and operators
		848	(parentheses are special to the Shell and must be
		849	escaped).
		850
		851
		852	Negation (`__!__' or `__not__').
		853
		854
		855	Concatenation (`____' or
		856	`__and__').
		857
		858
		859	Alternation (`__||__' or `__or__').
		860
		861
		862	Negation has highest precedence. Alternation and
		863	concatenation have equal precedence and associate left to
		864	right. Note that explicit __and__ tokens, not
		865	juxtaposition, are now required for
		866	concatenation.
		867
		868
		869	If an identifier is given without a keyword, the most recent
		870	keyword is assumed. For example,
		871
		872
		873	__not host vs and ace
		874	__
		875
		876
		877	is short for
		878
		879
		880	__not host vs and host ace
		881	__
		882
		883
		884	which should not be confused with
		885
		886
		887	__not ( host vs or ace )
		888	__
		889
		890
		891	Expression arguments can be passed to ''tcpdump'' as
		892	either a single argument or as multiple arguments, whichever
		893	is more convenient. Generally, if the expression contains
		894	Shell metacharacters, it is easier to pass it as a single,
		895	quoted argument. Multiple arguments are concatenated with
		896	spaces before being parsed.
		897	!!EXAMPLES
		898
		899
		900	To print all packets arriving at or departing from
		901	''sundown'':
		902
		903
		904	__tcpdump host sundown
		905	__
		906
		907
		908	To print traffic between ''helios'' and either ''hot''
		909	or ''ace'':
		910
		911
		912	__tcpdump host helios and hot or ace )
		913	__
		914
		915
		916	To print all IP packets between ''ace'' and any host
		917	except ''helios'':
		918
		919
		920	__tcpdump ip host ace and not helios
		921	__
		922
		923
		924	To print all traffic between local hosts and hosts at
		925	Berkeley:
		926
		927
		928	__tcpdump net ucb-ether
		929	__
		930
		931
		932	To print all ftp traffic through internet gateway
		933	''snup'': (note that the expression is quoted to prevent
		934	the shell from (mis-)interpreting the
		935	parentheses):
		936
		937
		938	__tcpdump 'gateway snup and (port ftp or ftp-data)'
		939	__
		940
		941
		942	To print traffic neither sourced from nor destined for local
		943	hosts (if you gateway to one other net, this stuff should
		944	never make it onto your local net).
		945
		946
		947	__tcpdump ip and not net__ ''localnet
		948	''
		949
		950
		951	To print the start and end packets (the SYN and FIN packets)
		952	of each TCP conversation that involves a non-local
		953	host.
		954
		955
		956	__tcpdump 'tcp[[13] __ ''localnet''__'
		957	__
		958
		959
		960	To print IP packets longer than 576 bytes sent through
		961	gateway ''snup'':
		962
		963
		964	__tcpdump 'gateway snup and ip[[2:2]
		965	__
		966
		967
		968	To print IP broadcast or multicast packets that were
		969	''not'' sent via ethernet broadcast or
		970	multicast:
		971
		972
		973	__tcpdump 'ether[[0]
		974	__
		975
		976
		977	To print all ICMP packets that are not echo requests/replies
		978	(i.e., not ping packets):
		979
		980
		981	__tcpdump 'icmp[[0] != 8 and icmp[[0] != 0'
		982	__
		983	!!OUTPUT FORMAT
		984
		985
		986	The output of ''tcpdump'' is protocol dependent. The
		987	following gives a brief description and examples of most of
		988	the formats.
		989
		990
		991	__Link Level Headers__
		992
		993
		994	If the '-e' option is given, the link level header is
		995	printed out. On ethernets, the source and destination
		996	addresses, protocol, and packet length are
		997	printed.
		998
		999
		1000	On FDDI networks, the '-e' option causes ''tcpdump'' to
		1001	print the `frame control' field, the source and destination
		1002	addresses, and the packet length. (The `frame control' field
		1003	governs the interpretation of the rest of the packet. Normal
		1004	packets (such as those containing IP datagrams) are `async'
		1005	packets, with a priority value between 0 and 7; for example,
		1006	`__async4__'. Such packets are assumed to contain an
		1007	802.2 Logical Link Control (LLC) packet; the LLC header is
		1008	printed if it is ''not'' an ISO datagram or a so-called
		1009	SNAP packet.
		1010
		1011
		1012	On Token Ring networks, the '-e' option causes
		1013	''tcpdump'' to print the `access control' and `frame
		1014	control' fields, the source and destination addresses, and
		1015	the packet length. As on FDDI networks, packets are assumed
		1016	to contain an LLC packet. Regardless of whether the '-e'
		1017	option is specified or not, the source routing information
		1018	is printed for source-routed packets.
		1019
		1020
		1021	''(N.B.: The following description assumes familiarity with
		1022	the SLIP compression algorithm described in
		1023	RFC-1144.)''
		1024
		1025
		1026	On SLIP links, a direction indicator (``I'' for inbound,
		1027	``O'' for outbound), packet type, and compression
		1028	information are printed out. The packet type is printed
		1029	first. The three types are ''ip'', ''utcp'', and
		1030	''ctcp''. No further link information is printed for
		1031	''ip'' packets. For TCP packets, the connection
		1032	identifier is printed following the type. If the packet is
		1033	compressed, its encoded header is printed out. The special
		1034	cases are printed out as __*S+__''n'' and
		1035	__*SA+__''n'', where ''n'' is the amount by which
		1036	the sequence number (or sequence number and ack) has
		1037	changed. If it is not a special case, zero or more changes
		1038	are printed. A change is indicated by U (urgent pointer), W
		1039	(window), A (ack), S (sequence number), and I (packet ID),
		1040	followed by a delta (+n or -n), or a new value (=n).
		1041	Finally, the amount of data in the packet and compressed
		1042	header length are printed.
		1043
		1044
		1045	For example, the following line shows an outbound compressed
		1046	TCP packet, with an implicit connection identifier; the ack
		1047	has changed by 6, the sequence number by 49, and the packet
		1048	ID by 6; there are 3 bytes of data and 6 bytes of compressed
		1049	header:
		1050
		1051
		1052	__O ctcp * A+6 S+49 I+6 3 (6)
		1053	__
		1054
		1055
		1056	__ARP/RARP Packets__
		1057
		1058
		1059	Arp/rarp output shows the type of request and its arguments.
		1060	The format is intended to be self explanatory. Here is a
		1061	short sample taken from the start of an `rlogin' from host
		1062	''rtsg'' to host ''csam'':
		1063
		1064
		1065	arp who-has csam tell rtsg
		1066	arp reply csam is-at CSAM
		1067
		1068
		1069	The first line says that rtsg sent an arp packet asking for
		1070	the ethernet address of internet host csam. Csam replies
		1071	with its ethernet address (in this example, ethernet
		1072	addresses are in caps and internet addresses in lower
		1073	case).
		1074
		1075
		1076	This would look less redundant if we had done __tcpdump
		1077	-n__:
		1078
		1079
		1080	arp who-has 128.3.254.6 tell 128.3.254.68
		1081	arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
		1082
		1083
		1084	If we had done __tcpdump -e__, the fact that the first
		1085	packet is broadcast and the second is point-to-point would
		1086	be visible:
		1087
		1088
		1089	RTSG Broadcast 0806 64: arp who-has csam tell rtsg
		1090	CSAM RTSG 0806 64: arp reply csam is-at CSAM
		1091
		1092
		1093	For the first packet this says the ethernet source address
		1094	is RTSG, the destination is the ethernet broadcast address,
		1095	the type field contained hex 0806 (type ETHER_ARP) and the
		1096	total length was 64 bytes.
		1097
		1098
		1099	__TCP Packets__
		1100
		1101
		1102	''(N.B.:The following description assumes familiarity with
		1103	the TCP protocol described in RFC-793. If you are not
		1104	familiar with the protocol, neither this description nor
		1105	tcpdump will be of much use to you.)''
		1106
		1107
		1108	The general format of a tcp protocol line is:
		1109
		1110
		1111	''src
		1112	''
		1113
		1114
		1115	''Src'' and ''dst'' are the source and destination IP
		1116	addresses and ports. ''Flags'' are some combination of S
		1117	(SYN), F (FIN), P (PUSH) or R (RST) or a single `.' (no
		1118	flags). ''Data-seqno'' describes the portion of sequence
		1119	space covered by the data in this packet (see example
		1120	below). ''Ack'' is sequence number of the next data
		1121	expected the other direction on this connection.
		1122	''Window'' is the number of bytes of receive buffer space
		1123	available the other direction on this connection. ''Urg''
		1124	indicates there is `urgent' data in the packet.
		1125	''Options'' are tcp options enclosed in angle brackets
		1126	(e.g., ''
		1127
		1128
		1129	''Src, dst'' and ''flags'' are always present. The
		1130	other fields depend on the contents of the packet's tcp
		1131	protocol header and are output only if
		1132	appropriate.
		1133
		1134
		1135	Here is the opening portion of an rlogin from host
		1136	''rtsg'' to host ''csam''.
		1137
		1138
		1139	rtsg.1023
		1140
		1141
		1142	The first line says that tcp port 1023 on rtsg sent a packet
		1143	to port ''login'' on csam. The __S__ indicates that
		1144	the ''SYN'' flag was set. The packet sequence number was
		1145	768512 and it contained no data. (The notation is
		1146	`first:last(nbytes)' which means `sequence numbers
		1147	''first'' up to but not including ''last'' which is
		1148	''nbytes'' bytes of user data'.) There was no
		1149	piggy-backed ack, the available receive window was 4096
		1150	bytes and there was a max-segment-size option requesting an
		1151	mss of 1024 bytes.
		1152
		1153
		1154	Csam replies with a similar packet except it includes a
		1155	piggy-backed ack for rtsg's SYN. Rtsg then acks csam's SYN.
		1156	The `.' means no flags were set. The packet contained no
		1157	data so there is no data sequence number. Note that the ack
		1158	sequence number is a small integer (1). The first time
		1159	''tcpdump'' sees a tcp `conversation', it prints the
		1160	sequence number from the packet. On subsequent packets of
		1161	the conversation, the difference between the current
		1162	packet's sequence number and this initial sequence number is
		1163	printed. This means that sequence numbers after the first
		1164	can be interpreted as relative byte positions in the
		1165	conversation's data stream (with the first data byte each
		1166	direction being `1'). `-S' will override this feature,
		1167	causing the original sequence numbers to be
		1168	output.
		1169
		1170
		1171	On the 6th line, rtsg sends csam 19 bytes of data (bytes 2
		1172	through 20 in the rtsg csam side of the conversation). The
		1173	PUSH flag is set in the packet. On the 7th line, csam says
		1174	it's received data sent by rtsg up to but not including byte
		1175	21. Most of this data is apparently sitting in the socket
		1176	buffer since csam's receive window has gotten 19 bytes
		1177	smaller. Csam also sends one byte of data to rtsg in this
		1178	packet. On the 8th and 9th lines, csam sends two bytes of
		1179	urgent, pushed data to rtsg.
		1180
		1181
		1182	If the snapshot was small enough that ''tcpdump'' didn't
		1183	capture the full TCP header, it interprets as much of the
		1184	header as it can and then reports ``[[|''tcp'']'' to
		1185	indicate the remainder could not be interpreted. If the
		1186	header contains a bogus option (one with a length that's
		1187	either too small or beyond the end of the header),
		1188	''tcpdump'' reports it as ``[[''bad opt'']'' and does
		1189	not interpret any further options (since it's impossible to
		1190	tell where they start). If the header length indicates
		1191	options are present but the IP datagram length is not long
		1192	enough for the options to actually be there, ''tcpdump''
		1193	reports it as ``[[''bad hdr length'']''.
		1194
		1195
		1196	__Capturing TCP packets with particular flag combinations
		1197	(SYN-ACK, URG-ACK, etc.)__
		1198
		1199
		1200	There are 6 bits in the control bits section of the TCP
		1201	header:
		1202
		1203
		1204	''URG | ACK | PSH | RST | SYN | FIN''
		1205
		1206
		1207	Let's assume that we want to watch packets used in
		1208	establishing a TCP connection. Recall that TCP uses a 3-way
		1209	handshake protocol when it initializes a new connection; the
		1210	connection sequence with regard to the TCP control bits
		1211	is
		1212
		1213
		1214	1) Caller sends SYN
		1215
		1216
		1217	2) Recipient responds with SYN, ACK
		1218
		1219
		1220	3) Caller sends ACK
		1221
		1222
		1223	Now we're interested in capturing packets that have only the
		1224	SYN bit set (Step 1). Note that we don't want packets from
		1225	step 2 (SYN-ACK), just a plain initial SYN. What we need is
		1226	a correct filter expression for ''tcpdump''.
		1227
		1228
		1229	Recall the structure of a TCP header without
		1230	options:
		1231
		1232
		1233	0 15 31
		1234	-----------------------------------------------------------------
		1235	| source port | destination port |
		1236	-----------------------------------------------------------------
		1237	| sequence number |
		1238	-----------------------------------------------------------------
		1239	| acknowledgment number |
		1240	-----------------------------------------------------------------
		1241	| HL | reserved |U|A|P|R|S|F| window size |
		1242	-----------------------------------------------------------------
		1243	| TCP checksum | urgent pointer |
		1244	-----------------------------------------------------------------
		1245	A TCP header usually holds 20 octets of data, unless options are present. The fist line of the graph contains octets 0 - 3, the second line shows octets 4 - 7 etc.
		1246
		1247
		1248	Starting to count with 0, the relevant TCP control bits are
		1249	contained in octet 13:
		1250
		1251
		1252	0 7| 15| 23| 31
		1253	----------------|---------------|---------------|----------------
		1254	| HL | reserved |U|A|P|R|S|F| window size |
		1255	----------------|---------------|---------------|----------------
		1256	| | 13th octet | | |
		1257	Let's have a closer look at octet no. 13:
		1258
		1259
		1260	| |
		1261	|---------------|
		1262	| |U|A|P|R|S|F|
		1263	|---------------|
		1264	|7 5 3 0|
		1265	We see that this octet contains 2 bytes from the reserved field. According to RFC 793 this field is reserved for future use and must be 0. The remaining 6 bits are the TCP control bits we are interested in. We have numbered the bits in this octet from 0 to 7, right to left, so the PSH bit is bit number 3, while the URG bit is number 5.
		1266
		1267
		1268	Recall that we want to capture packets with only SYN set.
		1269	Let's see what happens to octet 13 if a TCP datagram arrives
		1270	with the SYN bit set in its header:
		1271
		1272
		1273	| |U|A|P|R|S|F|
		1274	|---------------|
		1275	|0 0 0 0 0 0 1 0|
		1276	|---------------|
		1277	|7 6 5 4 3 2 1 0|
		1278	We already mentioned that bits number 7 and 6 belong to the reserved field, so they must must be 0. Looking at the control bits section we see that only bit number 1 (SYN) is set.
		1279
		1280
		1281	Assuming that octet number 13 is an 8-bit unsigned integer
		1282	in network byte order, the binary value of this octet
		1283	is
		1284
		1285
		1286	00000010
		1287
		1288
		1289	and its decimal representation is
		1290
		1291
		1292	7 6 5 4 3 2 1 0
		1293	0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2
		1294	We're almost done, because now we know that if only SYN is set, the value of the 13th octet in the TCP header, when interpreted as a 8-bit unsigned integer in network byte order, must be exactly 2.
		1295
		1296
		1297	This relationship can be expressed as
		1298
		1299
		1300	__tcp[[13] == 2__
		1301
		1302
		1303	We can use this expression as the filter for ''tcpdump''
		1304	in order to watch packets which have only SYN
		1305	set:
		1306
		1307
		1308	__tcpdump -i xl0 tcp[[13] == 2__
		1309
		1310
		1311	The expression says
		1312
		1313
		1314	Now, let's assume that we need to capture SYN packets, but
		1315	we don't care if ACK or any other TCP control bit is set at
		1316	the same time. Let's see what happens to octet 13 when a TCP
		1317	datagram with SYN-ACK set arrives:
		1318
		1319
		1320	| |U|A|P|R|S|F|
		1321	|---------------|
		1322	|0 0 0 1 0 0 1 0|
		1323	|---------------|
		1324	|7 6 5 4 3 2 1 0|
		1325	Now bits 1 and 4 are set in the 13th octet. The binary value of octet 13 is
		1326
		1327
		1328	00010010
		1329
		1330
		1331	which translates to decimal
		1332
		1333
		1334	7 6 5 4 3 2 1 0
		1335	0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18
		1336	Now we can't just use 'tcp[[13] == 18' in the ''tcpdump'' filter expression, because that would select only those packets that have SYN-ACK set, but not those with only SYN set. Remember that we don't care if ACK or any other control bit is set as long as SYN is set.
		1337
		1338
		1339	In order to achieve our goal, we need to logically AND the
		1340	binary value of octet 13 with some other value to preserve
		1341	the SYN bit. We know that we want SYN to be set in any case,
		1342	so we'll logically AND the value in the 13th octet with the
		1343	binary value of a SYN:
		1344
		1345
		1346	00010010 SYN-ACK 00000010 SYN
		1347	AND 00000010 (we want SYN) AND 00000010 (we want SYN)
		1348	-------- --------
		1349	= 00000010 = 00000010
		1350	We see that this AND operation delivers the same result regardless whether ACK or another TCP control bit is set. The decimal representation of the AND value as well as the result of this operation is 2 (binary 00000010), so we know that for packets with SYN set the following relation must hold true:
		1351
		1352
		1353	( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
		1354
		1355
		1356	This points us to the ''tcpdump'' filter
		1357	expression
		1358
		1359
		1360	__tcpdump -i xl0 'tcp[[13] __
		1361
		1362
		1363	Note that you should use single quotes or a backslash in the
		1364	expression to hide the AND ('
		1365
		1366
		1367	__UDP Packets__
		1368
		1369
		1370	UDP format is illustrated by this rwho packet:
		1371
		1372
		1373	actinide.who
		1374
		1375
		1376	This says that port ''who'' on host ''actinide'' sent
		1377	a udp datagram to port ''who'' on host ''broadcast'',
		1378	the Internet broadcast address. The packet contained 84
		1379	bytes of user data.
		1380
		1381
		1382	Some UDP services are recognized (from the source or
		1383	destination port number) and the higher level protocol
		1384	information printed. In particular, Domain Name service
		1385	requests (RFC-1034/1035) and Sun RPC calls (RFC-1050) to
		1386	NFS.
		1387
		1388
		1389	__UDP Name Server Requests__
		1390
		1391
		1392	''(N.B.:The following description assumes familiarity with
		1393	the Domain Service protocol described in RFC-1035. If you
		1394	are not familiar with the protocol, the following
		1395	description will appear to be written in
		1396	greek.)''
		1397
		1398
		1399	Name server requests are formatted as
		1400
		1401
		1402	''src
		1403	''h2opolo.1538
		1404	''
		1405
		1406
		1407	Host ''h2opolo'' asked the domain server on ''helios''
		1408	for an address record (qtype=A) associated with the name
		1409	''ucbvax.berkeley.edu.'' The query id was `3'. The `+'
		1410	indicates the ''recursion desired'' flag was set. The
		1411	query length was 37 bytes, not including the UDP and IP
		1412	protocol headers. The query operation was the normal one,
		1413	''Query'', so the op field was omitted. If the op had
		1414	been anything else, it would have been printed between the
		1415	`3' and the `+'. Similarly, the qclass was the normal one,
		1416	''C_IN'', and omitted. Any other qclass would have been
		1417	printed immediately after the `A'.
		1418
		1419
		1420	A few anomalies are checked and may result in extra fields
		1421	enclosed in square brackets: If a query contains an answer,
		1422	name server or authority section, ''ancount'',
		1423	''nscount'', or ''arcount'' are printed as
		1424	`[[''n''a]', `[[''n''n]' or `[[''n''au]' where
		1425	''n'' is the appropriate count. If any of the response
		1426	bits are set (AA, RA or rcode) or any of the `must be zero'
		1427	bits are set in bytes two and three, `[[b2''x'']'
		1428	is printed, where ''x'' is the hex value of header bytes
		1429	two and three.
		1430
		1431
		1432	__UDP Name Server Responses__
		1433
		1434
		1435	Name server responses are formatted as
		1436
		1437
		1438	''src
		1439	''helios.domain
		1440	''
		1441
		1442
		1443	In the first example, ''helios'' responds to query id 3
		1444	from ''h2opolo'' with 3 answer records, 3 name server
		1445	records and 7 authority records. The first answer record is
		1446	type A (address) and its data is internet address
		1447	128.32.137.3. The total size of the response was 273 bytes,
		1448	excluding UDP and IP headers. The op (Query) and response
2	perry	1449	code (!NoError) were omitted, as was the class (C_IN) of the
1	perry	1450	A record.
		1451
		1452
		1453	In the second example, ''helios'' responds to query 2
		1454	with a response code of non-existent domain (NXDomain) with
		1455	no answers, one name server and no authority records. The
		1456	`*' indicates that the ''authoritative answer'' bit was
		1457	set. Since there were no answers, no type, class or data
		1458	were printed.
		1459
		1460
		1461	Other flag characters that might appear are `-' (recursion
		1462	available, RA, ''not'' set) and `|' (truncated message,
		1463	TC, set). If the `question' section doesn't contain exactly
		1464	one entry, `[[''n''q]' is printed.
		1465
		1466
		1467	Note that name server requests and responses tend to be
		1468	large and the default ''snaplen'' of 68 bytes may not
		1469	capture enough of the packet to print. Use the __-s__
		1470	flag to increase the snaplen if you need to seriously
		1471	investigate name server traffic. `__-s 128__' has worked
		1472	well for me.
		1473
		1474
		1475	__SMB/CIFS decoding__
		1476
		1477
		1478	''tcpdump'' now includes fairly extensive SMB/CIFS/NBT
		1479	decoding for data on UDP/137, UDP/138 and TCP/139. Some
		1480	primitive decoding of IPX and NetBEUI SMB data is also
		1481	done.
		1482
		1483
		1484	By default a fairly minimal decode is done, with a much more
		1485	detailed decode done if -v is used. Be warned that with -v a
		1486	single SMB packet may take up a page or more, so only use -v
		1487	if you really want all the gory details.
		1488
		1489
		1490	If you are decoding SMB sessions containing unicode strings
		1491	then you may wish to set the environment variable
		1492	USE_UNICODE to 1. A patch to auto-detect unicode srings
		1493	would be welcome.
		1494
		1495
		1496	For information on SMB packet formats and what all te fields
		1497	mean see www.cifs.org or the pub/samba/specs/ directory on
		1498	your favourite samba.org mirror site. The SMB patches were
		1499	written by Andrew Tridgell (tridge@samba.org).
		1500
		1501
		1502	__NFS Requests and Replies__
		1503
		1504
		1505	Sun NFS (Network File System) requests and replies are
		1506	printed as:
		1507
		1508
		1509	''src.xid
		1510	''sushi.6709
		1511	''
		1512
		1513
		1514	In the first line, host ''sushi'' sends a transaction
		1515	with id ''6709'' to ''wrl'' (note that the number
		1516	following the src host is a transaction id, ''not'' the
		1517	source port). The request was 112 bytes, excluding the UDP
		1518	and IP headers. The operation was a ''readlink'' (read
		1519	symbolic link) on file handle (''fh'')
		1520	21,24/10.731657119. (If one is lucky, as in this case, the
		1521	file handle can be interpreted as a major,minor device
		1522	number pair, followed by the inode number and generation
		1523	number.) ''Wrl'' replies `ok' with the contents of the
		1524	link.
		1525
		1526
		1527	In the third line, ''sushi'' asks ''wrl'' to lookup
		1528	the name `''xcolors''' in directory file 9,74/4096.6878.
		1529	Note that the data printed depends on the operation type.
		1530	The format is intended to be self explanatory if read in
		1531	conjunction with an NFS protocol spec.
		1532
		1533
		1534	If the -v (verbose) flag is given, additional information is
		1535	printed. For example:
		1536
		1537
		1538	sushi.1372a
		1539
		1540
		1541	(-v also prints the IP header TTL, ID, length, and
		1542	fragmentation fields, which have been omitted from this
		1543	example.) In the first line, ''sushi'' asks ''wrl'' to
		1544	read 8192 bytes from file 21,11/12.195, at byte offset
		1545	24576. ''Wrl'' replies `ok'; the packet shown on the
		1546	second line is the first fragment of the reply, and hence is
		1547	only 1472 bytes long (the other bytes will follow in
		1548	subsequent fragments, but these fragments do not have NFS or
		1549	even UDP headers and so might not be printed, depending on
		1550	the filter expression used). Because the -v flag is given,
		1551	some of the file attributes (which are returned in addition
		1552	to the file data) are printed: the file type (``REG'', for
		1553	regular file), the file mode (in octal), the uid and gid,
		1554	and the file size.
		1555
		1556
		1557	If the -v flag is given more than once, even more details
		1558	are printed.
		1559
		1560
		1561	Note that NFS requests are very large and much of the detail
		1562	won't be printed unless ''snaplen'' is increased. Try
		1563	using `__-s 192__' to watch NFS traffic.
		1564
		1565
		1566	NFS reply packets do not explicitly identify the RPC
		1567	operation. Instead, ''tcpdump'' keeps track of ``recent''
		1568	requests, and matches them to the replies using the
		1569	transaction ID. If a reply does not closely follow the
		1570	corresponding request, it might not be
		1571	parsable.
		1572
		1573
		1574	__AFS Requests and Replies__
		1575
		1576
		1577	Transarc AFS (Andrew File System) requests and replies are
		1578	printed as:
		1579
		1580
		1581	''src.sport
		1582	''elvis.7001
		1583	''
		1584
		1585
		1586	In the first line, host elvis sends a RX packet to pike.
		1587	This was a RX data packet to the fs (fileserver) service,
		1588	and is the start of an RPC call. The RPC call was a rename,
		1589	with the old directory file id of 536876964/1/1 and an old
		1590	filename of `.newsrc.new', and a new directory file id of
		1591	536876964/1/1 and a new filename of `.newsrc'. The host pike
		1592	responds with a RPC reply to the rename call (which was
		1593	successful, because it was a data packet and not an abort
		1594	packet).
		1595
		1596
		1597	In general, all AFS RPCs are decoded at least by RPC call
		1598	name. Most AFS RPCs have at least some of the arguments
		1599	decoded (generally only the `interesting' arguments, for
		1600	some definition of interesting).
		1601
		1602
		1603	The format is intended to be self-describing, but it will
		1604	probably not be useful to people who are not familiar with
		1605	the workings of AFS and RX.
		1606
		1607
		1608	If the -v (verbose) flag is given twice, acknowledgement
		1609	packets and additional header information is printed, such
		1610	as the the RX call ID, call number, sequence number, serial
		1611	number, and the RX packet flags.
		1612
		1613
		1614	If the -v flag is given twice, additional information is
		1615	printed, such as the the RX call ID, serial number, and the
		1616	RX packet flags. The MTU negotiation information is also
		1617	printed from RX ack packets.
		1618
		1619
		1620	If the -v flag is given three times, the security index and
		1621	service id are printed.
		1622
		1623
		1624	Error codes are printed for abort packets, with the
		1625	exception of Ubik beacon packets (because abort packets are
		1626	used to signify a yes vote for the Ubik
		1627	protocol).
		1628
		1629
		1630	Note that AFS requests are very large and many of the
		1631	arguments won't be printed unless ''snaplen'' is
		1632	increased. Try using `__-s 256__' to watch AFS
		1633	traffic.
		1634
		1635
		1636	AFS reply packets do not explicitly identify the RPC
		1637	operation. Instead, ''tcpdump'' keeps track of ``recent''
		1638	requests, and matches them to the replies using the call
		1639	number and service ID. If a reply does not closely follow
		1640	the corresponding request, it might not be
		1641	parsable.
		1642
		1643
		1644	__KIP Appletalk (DDP in UDP)__
		1645
		1646
		1647	Appletalk DDP packets encapsulated in UDP datagrams are
		1648	de-encapsulated and dumped as DDP packets (i.e., all the UDP
		1649	header information is discarded). The file
		1650	''/etc/atalk.names'' is used to translate appletalk net
		1651	and node numbers to names. Lines in this file have the
		1652	form
		1653
		1654
		1655	''number name
		1656	''1.254 ether
		1657	16.1 icsd-net
		1658	1.254.110 ace
		1659
		1660
		1661	The first two lines give the names of appletalk networks.
		1662	The third line gives the name of a particular host (a host
		1663	is distinguished from a net by the 3rd octet in the number -
		1664	a net number ''must'' have two octets and a host number
		1665	''must'' have three octets.) The number and name should
		1666	be separated by whitespace (blanks or tabs). The
		1667	''/etc/atalk.names'' file may contain blank lines or
		1668	comment lines (lines starting with a `#').
		1669
		1670
		1671	Appletalk addresses are printed in the form
		1672
		1673
		1674	''net.host.port
		1675	''144.1.209.2
		1676	''
		1677
		1678
		1679	(If the ''/etc/atalk.names'' doesn't exist or doesn't
		1680	contain an entry for some appletalk host/net number,
		1681	addresses are printed in numeric form.) In the first
		1682	example, NBP (DDP port 2) on net 144.1 node 209 is sending
		1683	to whatever is listening on port 220 of net icsd node 112.
		1684	The second line is the same except the full name of the
		1685	source node is known (`office'). The third line is a send
		1686	from port 235 on net jssmag node 149 to broadcast on the
		1687	icsd-net NBP port (note that the broadcast address (255) is
		1688	indicated by a net name with no host number - for this
		1689	reason it's a good idea to keep node names and net names
		1690	distinct in /etc/atalk.names).
		1691
		1692
		1693	NBP (name binding protocol) and ATP (Appletalk transaction
		1694	protocol) packets have their contents interpreted. Other
		1695	protocols just dump the protocol name (or number if no name
		1696	is registered for the protocol) and packet
		1697	size.
		1698
		1699
		1700	__NBP packets__ are formatted like the following
		1701	examples:
		1702
		1703
		1704	icsd-net.112.220
		1705
		1706
		1707	The first line is a name lookup request for laserwriters
		1708	sent by net icsd host 112 and broadcast on net jssmag. The
		1709	nbp id for the lookup is 190. The second line shows a reply
		1710	for this request (note that it has the same id) from host
		1711	jssmag.209 saying that it has a laserwriter resource named
		1712
		1713
		1714	__ATP packet__ formatting is demonstrated by the
		1715	following example:
		1716
		1717
		1718	jssmag.209.165
		1719
		1720
		1721	Jssmag.209 initiates transaction id 12266 with host helios
		1722	by requesting up to 8 packets (the `
		1723
		1724
		1725	Helios responds with 8 512-byte packets. The `:digit'
		1726	following the transaction id gives the packet sequence
		1727	number in the transaction and the number in parens is the
		1728	amount of data in the packet, excluding the atp header. The
		1729	`*' on packet 7 indicates that the EOM bit was
		1730	set.
		1731
		1732
		1733	Jssmag.209 then requests that packets 3
		1734	not'' set.
		1735
		1736
		1737	__IP Fragmentation__
		1738
		1739
		1740	Fragmented Internet datagrams are printed as
		1741
		1742
		1743	__(frag__ ''id''__:__''size''__@__''offset''__+)
		1744	(frag__ ''id''__:__''size''__@__''offset''__)
		1745	__
		1746
		1747
		1748	(The first form indicates there are more fragments. The
		1749	second indicates this is the last fragment.)
		1750
		1751
		1752	''Id'' is the fragment id. ''Size'' is the fragment
		1753	size (in bytes) excluding the IP header. ''Offset'' is
		1754	this fragment's offset (in bytes) in the original
		1755	datagram.
		1756
		1757
		1758	The fragment information is output for each fragment. The
		1759	first fragment contains the higher level protocol header and
		1760	the frag info is printed after the protocol info. Fragments
		1761	after the first contain no higher level protocol header and
		1762	the frag info is printed after the source and destination
		1763	addresses. For example, here is part of an ftp from
		1764	arizona.edu to lbl-rtsg.arpa over a CSNET connection that
		1765	doesn't appear to handle 576 byte datagrams:
		1766
		1767
		1768	arizona.ftp-data
		1769
		1770
		1771	There are a couple of things to note here: First, addresses
		1772	in the 2nd line don't include port numbers. This is because
		1773	the TCP protocol information is all in the first fragment
		1774	and we have no idea what the port or sequence numbers are
		1775	when we print the later fragments. Second, the tcp sequence
		1776	information in the first line is printed as if there were
		1777	308 bytes of user data when, in fact, there are 512 bytes
		1778	(308 in the first frag and 204 in the second). If you are
		1779	looking for holes in the sequence space or trying to match
		1780	up acks with packets, this can fool you.
		1781
		1782
		1783	A packet with the IP ''don't fragment'' flag is marked
		1784	with a trailing __(DF)__.
		1785
		1786
		1787	__Timestamps__
		1788
		1789
		1790	By default, all output lines are preceded by a timestamp.
		1791	The timestamp is the current clock time in the
		1792	form
		1793
		1794
		1795	''hh:mm:ss.frac
		1796	''
		1797
		1798
		1799	and is as accurate as the kernel's clock. The timestamp
		1800	reflects the time the kernel first saw the packet. No
		1801	attempt is made to account for the time lag between when the
		1802	ethernet interface removed the packet from the wire and when
		1803	the kernel serviced the `new packet' interrupt.
		1804	!!SEE ALSO
		1805
		1806
		1807	traffic(1C), nit(4P), bpf(4), pcap(3)
		1808	!!AUTHORS
		1809
		1810
		1811	The original authors are:
		1812
		1813
2	perry	1814	Van Jacobson, Craig Leres and Steven !McCanne, all of the
1	perry	1815	Lawrence Berkeley National Laboratory, University of
		1816	California, Berkeley, CA.
		1817
		1818
		1819	It is currently being maintained by
		1820	tcpdump.org.
		1821
		1822
		1823	The current version is available via http:
		1824
		1825
		1826	''http://www.tcpdump.org/''
		1827
		1828
		1829	The original distribution is available via anonymous
		1830	ftp:
		1831
		1832
		1833	''ftp://ftp.ee.lbl.gov/tcpdump.tar.Z''
		1834
		1835
		1836	IPv6/IPsec support is added by WIDE/KAME project. This
		1837	program uses Eric Young's SSLeay library, under specific
		1838	configuration.
		1839	!!BUGS
		1840
		1841
		1842	Please send problems, bugs, questions, desirable
		1843	enhancements, etc. to:
		1844
		1845
		1846	tcpdump-workers@tcpdump.org
		1847
		1848
		1849	Please send source code contributions, etc. to:
		1850
		1851
		1852	patches@tcpdump.org
		1853
		1854
		1855	NIT doesn't let you watch your own outbound traffic, BPF
		1856	will. We recommend that you use the latter.
		1857
		1858
		1859	On Linux systems with 2.0[[.x] kernels:
		1860
		1861
		1862	packets on the loopback device will be seen
		1863	twice;
		1864
		1865
		1866	packet filtering cannot be done in the kernel, so that all
		1867	packets must be copied from the kernel in order to be
		1868	filtered in user mode;
		1869
		1870
		1871	all of a packet, not just the part that's within the
		1872	snapshot length, will be copied from the kernel (the 2.0[[.x]
		1873	packet capture mechanism, if asked to copy only part of a
		1874	packet to userland, will not report the true length of the
		1875	packet; this would cause most IP packets to get an error
		1876	from __tcpdump__).
		1877
		1878
		1879	We recommend that you upgrade to a 2.2 or later
		1880	kernel.
		1881
		1882
		1883	Some attempt should be made to reassemble IP fragments or,
		1884	at least to compute the right length for the higher level
		1885	protocol.
		1886
		1887
		1888	Name server inverse queries are not dumped correctly: the
		1889	(empty) question section is printed rather than real query
		1890	in the answer section. Some believe that inverse queries are
		1891	themselves a bug and prefer to fix the program generating
		1892	them rather than ''tcpdump''.
		1893
		1894
		1895	A packet trace that crosses a daylight savings time change
		1896	will give skewed time stamps (the time change is
		1897	ignored).
		1898
		1899
		1900	Filter expressions that manipulate FDDI or Token Ring
		1901	headers assume that all FDDI and Token Ring packets are
		1902	SNAP-encapsulated Ethernet packets. This is true for IP,
		1903	ARP, and DECNET Phase IV, but is not true for protocols such
		1904	as ISO CLNS. Therefore, the filter may inadvertently accept
		1905	certain packets that do not properly match the filter
		1906	expression.
		1907
		1908
		1909	Filter expressions on fields other than those that
		1910	manipulate Token Ring headers will not correctly handle
		1911	source-routed Token Ring packets.
		1912
		1913
		1914	__ip6 proto__ should chase header chain, but at this
		1915	moment it does not. __ip6 protochain__ is supplied for
		1916	this behavior.
		1917
		1918
		1919	Arithmetic expression against transport layer headers, like
		1920	__tcp[[0]__, does not work against IPv6 packets. It only
		1921	looks at IPv4 packets.
		1922	----