Català-Valencià – Catalan中文 – Chinese (Simplified)中文 – Chinese (Traditional)Česky – CzechDansk – DanishNederlands – DutchEnglish – EnglishSuomi – FinnishFrançais – FrenchDeutsch – Germanעברית – Hebrewहिंदी – HindiMagyar – HungarianBahasa Indonesia – IndonesianItaliano – Italian日本語 – Japanese한국어 – KoreanМакедонски – Macedonianमराठी – MarathiNorsk – NorwegianPolski – PolishPortuguês – PortuguesePortuguês – Portuguese (Brazil)Русский – RussianSlovenčina – SlovakSlovenščina – SlovenianEspañol – SpanishSvenska – SwedishTürkçe – TurkishУкраїнська – UkrainianOëzbekcha – Uzbek

nexmon – Blame information for rev 1

Rev	Author	Line No.	Line
1	office	1	.\" $NetBSD: tcpdump.8,v 1.9 2003/03/31 00:18:17 perry Exp $
		2	.\"
		3	.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
		4	.\" The Regents of the University of California. All rights reserved.
		5	.\" All rights reserved.
		6	.\"
		7	.\" Redistribution and use in source and binary forms, with or without
		8	.\" modification, are permitted provided that: (1) source code distributions
		9	.\" retain the above copyright notice and this paragraph in its entirety, (2)
		10	.\" distributions including binary code include the above copyright notice and
		11	.\" this paragraph in its entirety in the documentation or other materials
		12	.\" provided with the distribution, and (3) all advertising materials mentioning
		13	.\" features or use of this software display the following acknowledgement:
		14	.\" ``This product includes software developed by the University of California,
		15	.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
		16	.\" the University nor the names of its contributors may be used to endorse
		17	.\" or promote products derived from this software without specific prior
		18	.\" written permission.
		19	.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
		20	.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
		21	.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
		22	.\"
		23	.TH TCPDUMP 1 "11 July 2014"
		24	.SH NAME
		25	tcpdump \- dump traffic on a network
		26	.SH SYNOPSIS
		27	.na
		28	.B tcpdump
		29	[
		30	.B \-AbdDefhHIJKlLnNOpqRStuUvxX#
		31	] [
		32	.B \-B
		33	.I buffer_size
		34	]
		35	.br
		36	.ti +8
		37	[
		38	.B \-c
		39	.I count
		40	]
		41	.br
		42	.ti +8
		43	[
		44	.B \-C
		45	.I file_size
		46	] [
		47	.B \-G
		48	.I rotate_seconds
		49	] [
		50	.B \-F
		51	.I file
		52	]
		53	.br
		54	.ti +8
		55	[
		56	.B \-i
		57	.I interface
		58	]
		59	[
		60	.B \-j
		61	.I tstamp_type
		62	]
		63	[
		64	.B \-m
		65	.I module
		66	]
		67	[
		68	.B \-M
		69	.I secret
		70	]
		71	.br
		72	.ti +8
		73	[
		74	.B \-\-number
		75	]
		76	[
		77	.B \-Q
		78	.I in|out|inout
		79	]
		80	.ti +8
		81	[
		82	.B \-r
		83	.I file
		84	]
		85	[
		86	.B \-V
		87	.I file
		88	]
		89	[
		90	.B \-s
		91	.I snaplen
		92	]
		93	[
		94	.B \-T
		95	.I type
		96	]
		97	[
		98	.B \-w
		99	.I file
		100	]
		101	.br
		102	.ti +8
		103	[
		104	.B \-W
		105	.I filecount
		106	]
		107	.br
		108	.ti +8
		109	[
		110	.B \-E
		111	.I spi@ipaddr algo:secret,...
		112	]
		113	.br
		114	.ti +8
		115	[
		116	.B \-y
		117	.I datalinktype
		118	]
		119	[
		120	.B \-z
		121	.I postrotate-command
		122	]
		123	[
		124	.B \-Z
		125	.I user
		126	]
		127	.ti +8
		128	[
		129	.BI \-\-time\-stamp\-precision= tstamp_precision
		130	]
		131	.ti +8
		132	[
		133	.B \-\-immediate\-mode
		134	]
		135	[
		136	.B \-\-version
		137	]
		138	.ti +8
		139	[
		140	.I expression
		141	]
		142	.br
		143	.ad
		144	.SH DESCRIPTION
		145	.LP
		146	\fITcpdump\fP prints out a description of the contents of packets on a
		147	network interface that match the boolean \fIexpression\fP; the
		148	description is preceded by a time stamp, printed, by default, as hours,
		149	minutes, seconds, and fractions of a second since midnight. It can also
		150	be run with the
		151	.B \-w
		152	flag, which causes it to save the packet data to a file for later
		153	analysis, and/or with the
		154	.B \-r
		155	flag, which causes it to read from a saved packet file rather than to
		156	read packets from a network interface. It can also be run with the
		157	.B \-V
		158	flag, which causes it to read a list of saved packet files. In all cases,
		159	only packets that match
		160	.I expression
		161	will be processed by
		162	.IR tcpdump .
		163	.LP
		164	.I Tcpdump
		165	will, if not run with the
		166	.B \-c
		167	flag, continue capturing packets until it is interrupted by a SIGINT
		168	signal (generated, for example, by typing your interrupt character,
		169	typically control-C) or a SIGTERM signal (typically generated with the
		170	.BR kill (1)
		171	command); if run with the
		172	.B \-c
		173	flag, it will capture packets until it is interrupted by a SIGINT or
		174	SIGTERM signal or the specified number of packets have been processed.
		175	.LP
		176	When
		177	.I tcpdump
		178	finishes capturing packets, it will report counts of:
		179	.IP
		180	packets ``captured'' (this is the number of packets that
		181	.I tcpdump
		182	has received and processed);
		183	.IP
		184	packets ``received by filter'' (the meaning of this depends on the OS on
		185	which you're running
		186	.IR tcpdump ,
		187	and possibly on the way the OS was configured - if a filter was
		188	specified on the command line, on some OSes it counts packets regardless
		189	of whether they were matched by the filter expression and, even if they
		190	were matched by the filter expression, regardless of whether
		191	.I tcpdump
		192	has read and processed them yet, on other OSes it counts only packets that were
		193	matched by the filter expression regardless of whether
		194	.I tcpdump
		195	has read and processed them yet, and on other OSes it counts only
		196	packets that were matched by the filter expression and were processed by
		197	.IR tcpdump );
		198	.IP
		199	packets ``dropped by kernel'' (this is the number of packets that were
		200	dropped, due to a lack of buffer space, by the packet capture mechanism
		201	in the OS on which
		202	.I tcpdump
		203	is running, if the OS reports that information to applications; if not,
		204	it will be reported as 0).
		205	.LP
		206	On platforms that support the SIGINFO signal, such as most BSDs
		207	(including Mac OS X) and Digital/Tru64 UNIX, it will report those counts
		208	when it receives a SIGINFO signal (generated, for example, by typing
		209	your ``status'' character, typically control-T, although on some
		210	platforms, such as Mac OS X, the ``status'' character is not set by
		211	default, so you must set it with
		212	.BR stty (1)
		213	in order to use it) and will continue capturing packets. On platforms that
		214	do not support the SIGINFO signal, the same can be achieved by using the
		215	SIGUSR1 signal.
		216	.LP
		217	Reading packets from a network interface may require that you have
		218	special privileges; see the
		219	.B pcap (3PCAP)
		220	man page for details. Reading a saved packet file doesn't require
		221	special privileges.
		222	.SH OPTIONS
		223	.TP
		224	.B \-A
		225	Print each packet (minus its link level header) in ASCII. Handy for
		226	capturing web pages.
		227	.TP
		228	.B \-b
		229	Print the AS number in BGP packets in ASDOT notation rather than ASPLAIN
		230	notation.
		231	.TP
		232	.BI \-B " buffer_size"
		233	.PD 0
		234	.TP
		235	.BI \-\-buffer\-size= buffer_size
		236	.PD
		237	Set the operating system capture buffer size to \fIbuffer_size\fP, in
		238	units of KiB (1024 bytes).
		239	.TP
		240	.BI \-c " count"
		241	Exit after receiving \fIcount\fP packets.
		242	.TP
		243	.BI \-C " file_size"
		244	Before writing a raw packet to a savefile, check whether the file is
		245	currently larger than \fIfile_size\fP and, if so, close the current
		246	savefile and open a new one. Savefiles after the first savefile will
		247	have the name specified with the
		248	.B \-w
		249	flag, with a number after it, starting at 1 and continuing upward.
		250	The units of \fIfile_size\fP are millions of bytes (1,000,000 bytes,
		251	not 1,048,576 bytes).
		252	.TP
		253	.B \-d
		254	Dump the compiled packet-matching code in a human readable form to
		255	standard output and stop.
		256	.TP
		257	.B \-dd
		258	Dump packet-matching code as a
		259	.B C
		260	program fragment.
		261	.TP
		262	.B \-ddd
		263	Dump packet-matching code as decimal numbers (preceded with a count).
		264	.TP
		265	.B \-D
		266	.PD 0
		267	.TP
		268	.B \-\-list\-interfaces
		269	.PD
		270	Print the list of the network interfaces available on the system and on
		271	which
		272	.I tcpdump
		273	can capture packets. For each network interface, a number and an
		274	interface name, possibly followed by a text description of the
		275	interface, is printed. The interface name or the number can be supplied
		276	to the
		277	.B \-i
		278	flag to specify an interface on which to capture.
		279	.IP
		280	This can be useful on systems that don't have a command to list them
		281	(e.g., Windows systems, or UNIX systems lacking
		282	.BR "ifconfig \-a" );
		283	the number can be useful on Windows 2000 and later systems, where the
		284	interface name is a somewhat complex string.
		285	.IP
		286	The
		287	.B \-D
		288	flag will not be supported if
		289	.I tcpdump
		290	was built with an older version of
		291	.I libpcap
		292	that lacks the
		293	.B pcap_findalldevs()
		294	function.
		295	.TP
		296	.B \-e
		297	Print the link-level header on each dump line. This can be used, for
		298	example, to print MAC layer addresses for protocols such as Ethernet and
		299	IEEE 802.11.
		300	.TP
		301	.B \-E
		302	Use \fIspi@ipaddr algo:secret\fP for decrypting IPsec ESP packets that
		303	are addressed to \fIaddr\fP and contain Security Parameter Index value
		304	\fIspi\fP. This combination may be repeated with comma or newline separation.
		305	.IP
		306	Note that setting the secret for IPv4 ESP packets is supported at this time.
		307	.IP
		308	Algorithms may be
		309	\fBdes-cbc\fP,
		310	\fB3des-cbc\fP,
		311	\fBblowfish-cbc\fP,
		312	\fBrc3-cbc\fP,
		313	\fBcast128-cbc\fP, or
		314	\fBnone\fP.
		315	The default is \fBdes-cbc\fP.
		316	The ability to decrypt packets is only present if \fItcpdump\fP was compiled
		317	with cryptography enabled.
		318	.IP
		319	\fIsecret\fP is the ASCII text for ESP secret key.
		320	If preceded by 0x, then a hex value will be read.
		321	.IP
		322	The option assumes RFC2406 ESP, not RFC1827 ESP.
		323	The option is only for debugging purposes, and
		324	the use of this option with a true `secret' key is discouraged.
		325	By presenting IPsec secret key onto command line
		326	you make it visible to others, via
		327	.IR ps (1)
		328	and other occasions.
		329	.IP
		330	In addition to the above syntax, the syntax \fIfile name\fP may be used
		331	to have tcpdump read the provided file in. The file is opened upon
		332	receiving the first ESP packet, so any special permissions that tcpdump
		333	may have been given should already have been given up.
		334	.TP
		335	.B \-f
		336	Print `foreign' IPv4 addresses numerically rather than symbolically
		337	(this option is intended to get around serious brain damage in
		338	Sun's NIS server \(em usually it hangs forever translating non-local
		339	internet numbers).
		340	.IP
		341	The test for `foreign' IPv4 addresses is done using the IPv4 address and
		342	netmask of the interface on which capture is being done. If that
		343	address or netmask are not available, available, either because the
		344	interface on which capture is being done has no address or netmask or
		345	because the capture is being done on the Linux "any" interface, which
		346	can capture on more than one interface, this option will not work
		347	correctly.
		348	.TP
		349	.BI \-F " file"
		350	Use \fIfile\fP as input for the filter expression.
		351	An additional expression given on the command line is ignored.
		352	.TP
		353	.BI \-G " rotate_seconds"
		354	If specified, rotates the dump file specified with the
		355	.B \-w
		356	option every \fIrotate_seconds\fP seconds.
		357	Savefiles will have the name specified by
		358	.B \-w
		359	which should include a time format as defined by
		360	.BR strftime (3).
		361	If no time format is specified, each new file will overwrite the previous.
		362	.IP
		363	If used in conjunction with the
		364	.B \-C
		365	option, filenames will take the form of `\fIfile\fP<count>'.
		366	.TP
		367	.B \-h
		368	.PD 0
		369	.TP
		370	.B \-\-help
		371	.PD
		372	Print the tcpdump and libpcap version strings, print a usage message,
		373	and exit.
		374	.TP
		375	.B \-\-version
		376	.PD
		377	Print the tcpdump and libpcap version strings and exit.
		378	.TP
		379	.B \-H
		380	Attempt to detect 802.11s draft mesh headers.
		381	.TP
		382	.BI \-i " interface"
		383	.PD 0
		384	.TP
		385	.BI \-\-interface= interface
		386	.PD
		387	Listen on \fIinterface\fP.
		388	If unspecified, \fItcpdump\fP searches the system interface list for the
		389	lowest numbered, configured up interface (excluding loopback), which may turn
		390	out to be, for example, ``eth0''.
		391	.IP
		392	On Linux systems with 2.2 or later kernels, an
		393	.I interface
		394	argument of ``any'' can be used to capture packets from all interfaces.
		395	Note that captures on the ``any'' device will not be done in promiscuous
		396	mode.
		397	.IP
		398	If the
		399	.B \-D
		400	flag is supported, an interface number as printed by that flag can be
		401	used as the
		402	.I interface
		403	argument.
		404	.TP
		405	.B \-I
		406	.PD 0
		407	.TP
		408	.B \-\-monitor\-mode
		409	.PD
		410	Put the interface in "monitor mode"; this is supported only on IEEE
		411	802.11 Wi-Fi interfaces, and supported only on some operating systems.
		412	.IP
		413	Note that in monitor mode the adapter might disassociate from the
		414	network with which it's associated, so that you will not be able to use
		415	any wireless networks with that adapter. This could prevent accessing
		416	files on a network server, or resolving host names or network addresses,
		417	if you are capturing in monitor mode and are not connected to another
		418	network with another adapter.
		419	.IP
		420	This flag will affect the output of the
		421	.B \-L
		422	flag. If
		423	.B \-I
		424	isn't specified, only those link-layer types available when not in
		425	monitor mode will be shown; if
		426	.B \-I
		427	is specified, only those link-layer types available when in monitor mode
		428	will be shown.
		429	.TP
		430	.BI \-\-immediate\-mode
		431	Capture in "immediate mode". In this mode, packets are delivered to
		432	tcpdump as soon as they arrive, rather than being buffered for
		433	efficiency. This is the default when printing packets rather than
		434	saving packets to a ``savefile'' if the packets are being printed to a
		435	terminal rather than to a file or pipe.
		436	.TP
		437	.BI \-j " tstamp_type"
		438	.PD 0
		439	.TP
		440	.BI \-\-time\-stamp\-type= tstamp_type
		441	.PD
		442	Set the time stamp type for the capture to \fItstamp_type\fP. The names
		443	to use for the time stamp types are given in
		444	.BR pcap-tstamp (@MAN_MISC_INFO@);
		445	not all the types listed there will necessarily be valid for any given
		446	interface.
		447	.TP
		448	.B \-J
		449	.PD 0
		450	.TP
		451	.B \-\-list\-time\-stamp\-types
		452	.PD
		453	List the supported time stamp types for the interface and exit. If the
		454	time stamp type cannot be set for the interface, no time stamp types are
		455	listed.
		456	.TP
		457	.BI \-\-time\-stamp\-precision= tstamp_precision
		458	When capturing, set the time stamp precision for the capture to
		459	\fItstamp_precision\fP. Note that availability of high precision time
		460	stamps (nanoseconds) and their actual accuracy is platform and hardware
		461	dependent. Also note that when writing captures made with nanosecond
		462	accuracy to a savefile, the time stamps are written with nanosecond
		463	resolution, and the file is written with a different magic number, to
		464	indicate that the time stamps are in seconds and nanoseconds; not all
		465	programs that read pcap savefiles will be able to read those captures.
		466	.LP
		467	When reading a savefile, convert time stamps to the precision specified
		468	by \fItimestamp_precision\fP, and display them with that resolution. If
		469	the precision specified is less than the precision of time stamps in the
		470	file, the conversion will lose precision.
		471	.LP
		472	The supported values for \fItimestamp_precision\fP are \fBmicro\fP for
		473	microsecond resolution and \fBnano\fP for nanosecond resolution. The
		474	default is microsecond resolution.
		475	.TP
		476	.B \-K
		477	.PD 0
		478	.TP
		479	.B \-\-dont\-verify\-checksums
		480	.PD
		481	Don't attempt to verify IP, TCP, or UDP checksums. This is useful for
		482	interfaces that perform some or all of those checksum calculation in
		483	hardware; otherwise, all outgoing TCP checksums will be flagged as bad.
		484	.TP
		485	.B \-l
		486	Make stdout line buffered.
		487	Useful if you want to see the data
		488	while capturing it.
		489	E.g.,
		490	.IP
		491	.RS
		492	.RS
		493	.nf
		494	\fBtcpdump \-l | tee dat\fP
		495	.fi
		496	.RE
		497	.RE
		498	.IP
		499	or
		500	.IP
		501	.RS
		502	.RS
		503	.nf
		504	\fBtcpdump \-l > dat & tail \-f dat\fP
		505	.fi
		506	.RE
		507	.RE
		508	.IP
		509	Note that on Windows,``line buffered'' means ``unbuffered'', so that
		510	WinDump will write each character individually if
		511	.B \-l
		512	is specified.
		513	.IP
		514	.B \-U
		515	is similar to
		516	.B \-l
		517	in its behavior, but it will cause output to be ``packet-buffered'', so
		518	that the output is written to stdout at the end of each packet rather
		519	than at the end of each line; this is buffered on all platforms,
		520	including Windows.
		521	.TP
		522	.B \-L
		523	.PD 0
		524	.TP
		525	.B \-\-list\-data\-link\-types
		526	.PD
		527	List the known data link types for the interface, in the specified mode,
		528	and exit. The list of known data link types may be dependent on the
		529	specified mode; for example, on some platforms, a Wi-Fi interface might
		530	support one set of data link types when not in monitor mode (for
		531	example, it might support only fake Ethernet headers, or might support
		532	802.11 headers but not support 802.11 headers with radio information)
		533	and another set of data link types when in monitor mode (for example, it
		534	might support 802.11 headers, or 802.11 headers with radio information,
		535	only in monitor mode).
		536	.TP
		537	.BI \-m " module"
		538	Load SMI MIB module definitions from file \fImodule\fR.
		539	This option
		540	can be used several times to load several MIB modules into \fItcpdump\fP.
		541	.TP
		542	.BI \-M " secret"
		543	Use \fIsecret\fP as a shared secret for validating the digests found in
		544	TCP segments with the TCP-MD5 option (RFC 2385), if present.
		545	.TP
		546	.B \-n
		547	Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
		548	.TP
		549	.B \-N
		550	Don't print domain name qualification of host names.
		551	E.g.,
		552	if you give this flag then \fItcpdump\fP will print ``nic''
		553	instead of ``nic.ddn.mil''.
		554	.TP
		555	.B \-#
		556	.PD 0
		557	.TP
		558	.B \-\-number
		559	.PD
		560	Print an optional packet number at the beginning of the line.
		561	.TP
		562	.B \-O
		563	.PD 0
		564	.TP
		565	.B \-\-no\-optimize
		566	.PD
		567	Do not run the packet-matching code optimizer.
		568	This is useful only
		569	if you suspect a bug in the optimizer.
		570	.TP
		571	.B \-p
		572	.PD 0
		573	.TP
		574	.B \-\-no\-promiscuous\-mode
		575	.PD
		576	\fIDon't\fP put the interface
		577	into promiscuous mode.
		578	Note that the interface might be in promiscuous
		579	mode for some other reason; hence, `-p' cannot be used as an abbreviation for
		580	`ether host {local-hw-addr} or ether broadcast'.
		581	.TP
		582	.BI \-Q " direction"
		583	.PD 0
		584	.TP
		585	.BI \-\-direction= direction
		586	.PD
		587	Choose send/receive direction \fIdirection\fR for which packets should be
		588	captured. Possible values are `in', `out' and `inout'. Not available
		589	on all platforms.
		590	.TP
		591	.B \-q
		592	Quick (quiet?) output.
		593	Print less protocol information so output
		594	lines are shorter.
		595	.TP
		596	.B \-R
		597	Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829).
		598	If specified, \fItcpdump\fP will not print replay prevention field.
		599	Since there is no protocol version field in ESP/AH specification,
		600	\fItcpdump\fP cannot deduce the version of ESP/AH protocol.
		601	.TP
		602	.BI \-r " file"
		603	Read packets from \fIfile\fR (which was created with the
		604	.B \-w
		605	option or by other tools that write pcap or pcap-ng files).
		606	Standard input is used if \fIfile\fR is ``-''.
		607	.TP
		608	.B \-S
		609	.PD 0
		610	.TP
		611	.B \-\-absolute\-tcp\-sequence\-numbers
		612	.PD
		613	Print absolute, rather than relative, TCP sequence numbers.
		614	.TP
		615	.BI \-s " snaplen"
		616	.PD 0
		617	.TP
		618	.BI \-\-snapshot\-length= snaplen
		619	.PD
		620	Snarf \fIsnaplen\fP bytes of data from each packet rather than the
		621	default of 65535 bytes.
		622	Packets truncated because of a limited snapshot
		623	are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
		624	is the name of the protocol level at which the truncation has occurred.
		625	Note that taking larger snapshots both increases
		626	the amount of time it takes to process packets and, effectively,
		627	decreases the amount of packet buffering.
		628	This may cause packets to be
		629	lost.
		630	You should limit \fIsnaplen\fP to the smallest number that will
		631	capture the protocol information you're interested in.
		632	Setting
		633	\fIsnaplen\fP to 0 sets it to the default of 65535,
		634	for backwards compatibility with recent older versions of
		635	.IR tcpdump .
		636	.TP
		637	.BI \-T " type"
		638	Force packets selected by "\fIexpression\fP" to be interpreted the
		639	specified \fItype\fR.
		640	Currently known types are
		641	\fBaodv\fR (Ad-hoc On-demand Distance Vector protocol),
		642	\fBcarp\fR (Common Address Redundancy Protocol),
		643	\fBcnfp\fR (Cisco NetFlow protocol),
		644	\fBlmp\fR (Link Management Protocol),
		645	\fBpgm\fR (Pragmatic General Multicast),
		646	\fBpgm_zmtp1\fR (ZMTP/1.0 inside PGM/EPGM),
		647	\fBradius\fR (RADIUS),
		648	\fBrpc\fR (Remote Procedure Call),
		649	\fBrtp\fR (Real-Time Applications protocol),
		650	\fBrtcp\fR (Real-Time Applications control protocol),
		651	\fBsnmp\fR (Simple Network Management Protocol),
		652	\fBtftp\fR (Trivial File Transfer Protocol),
		653	\fBvat\fR (Visual Audio Tool),
		654	\fBwb\fR (distributed White Board),
		655	\fBzmtp1\fR (ZeroMQ Message Transport Protocol 1.0)
		656	and
		657	\fBvxlan\fR (Virtual eXtensible Local Area Network).
		658	.IP
		659	Note that the \fBpgm\fR type above affects UDP interpretation only, the native
		660	PGM is always recognised as IP protocol 113 regardless. UDP-encapsulated PGM is
		661	often called "EPGM" or "PGM/UDP".
		662	.IP
		663	Note that the \fBpgm_zmtp1\fR type above affects interpretation of both native
		664	PGM and UDP at once. During the native PGM decoding the application data of an
		665	ODATA/RDATA packet would be decoded as a ZeroMQ datagram with ZMTP/1.0 frames.
		666	During the UDP decoding in addition to that any UDP packet would be treated as
		667	an encapsulated PGM packet.
		668	.TP
		669	.B \-t
		670	\fIDon't\fP print a timestamp on each dump line.
		671	.TP
		672	.B \-tt
		673	Print the timestamp, as seconds since January 1, 1970, 00:00:00, UTC, and
		674	fractions of a second since that time, on each dump line.
		675	.TP
		676	.B \-ttt
		677	Print a delta (micro-second resolution) between current and previous line
		678	on each dump line.
		679	.TP
		680	.B \-tttt
		681	Print a timestamp, as hours, minutes, seconds, and fractions of a second
		682	since midnight, preceded by the date, on each dump line.
		683	.TP
		684	.B \-ttttt
		685	Print a delta (micro-second resolution) between current and first line
		686	on each dump line.
		687	.TP
		688	.B \-u
		689	Print undecoded NFS handles.
		690	.TP
		691	.B \-U
		692	.PD 0
		693	.TP
		694	.B \-\-packet\-buffered
		695	.PD
		696	If the
		697	.B \-w
		698	option is not specified, make the printed packet output
		699	``packet-buffered''; i.e., as the description of the contents of each
		700	packet is printed, it will be written to the standard output, rather
		701	than, when not writing to a terminal, being written only when the output
		702	buffer fills.
		703	.IP
		704	If the
		705	.B \-w
		706	option is specified, make the saved raw packet output
		707	``packet-buffered''; i.e., as each packet is saved, it will be written
		708	to the output file, rather than being written only when the output
		709	buffer fills.
		710	.IP
		711	The
		712	.B \-U
		713	flag will not be supported if
		714	.I tcpdump
		715	was built with an older version of
		716	.I libpcap
		717	that lacks the
		718	.B pcap_dump_flush()
		719	function.
		720	.TP
		721	.B \-v
		722	When parsing and printing, produce (slightly more) verbose output.
		723	For example, the time to live,
		724	identification, total length and options in an IP packet are printed.
		725	Also enables additional packet integrity checks such as verifying the
		726	IP and ICMP header checksum.
		727	.IP
		728	When writing to a file with the
		729	.B \-w
		730	option, report, every 10 seconds, the number of packets captured.
		731	.TP
		732	.B \-vv
		733	Even more verbose output.
		734	For example, additional fields are
		735	printed from NFS reply packets, and SMB packets are fully decoded.
		736	.TP
		737	.B \-vvv
		738	Even more verbose output.
		739	For example,
		740	telnet \fBSB\fP ... \fBSE\fP options
		741	are printed in full.
		742	With
		743	.B \-X
		744	Telnet options are printed in hex as well.
		745	.TP
		746	.BI \-V " file"
		747	Read a list of filenames from \fIfile\fR. Standard input is used
		748	if \fIfile\fR is ``-''.
		749	.TP
		750	.BI \-w " file"
		751	Write the raw packets to \fIfile\fR rather than parsing and printing
		752	them out.
		753	They can later be printed with the \-r option.
		754	Standard output is used if \fIfile\fR is ``-''.
		755	.IP
		756	This output will be buffered if written to a file or pipe, so a program
		757	reading from the file or pipe may not see packets for an arbitrary
		758	amount of time after they are received. Use the
		759	.B \-U
		760	flag to cause packets to be written as soon as they are received.
		761	.IP
		762	The MIME type \fIapplication/vnd.tcpdump.pcap\fP has been registered
		763	with IANA for \fIpcap\fP files. The filename extension \fI.pcap\fP
		764	appears to be the most commonly used along with \fI.cap\fP and
		765	\fI.dmp\fP. \fITcpdump\fP itself doesn't check the extension when
		766	reading capture files and doesn't add an extension when writing them
		767	(it uses magic numbers in the file header instead). However, many
		768	operating systems and applications will use the extension if it is
		769	present and adding one (e.g. .pcap) is recommended.
		770	.IP
		771	See
		772	.BR pcap-savefile (@MAN_FILE_FORMATS@)
		773	for a description of the file format.
		774	.TP
		775	.B \-W
		776	Used in conjunction with the
		777	.B \-C
		778	option, this will limit the number
		779	of files created to the specified number, and begin overwriting files
		780	from the beginning, thus creating a 'rotating' buffer.
		781	In addition, it will name
		782	the files with enough leading 0s to support the maximum number of
		783	files, allowing them to sort correctly.
		784	.IP
		785	Used in conjunction with the
		786	.B \-G
		787	option, this will limit the number of rotated dump files that get
		788	created, exiting with status 0 when reaching the limit. If used with
		789	.B \-C
		790	as well, the behavior will result in cyclical files per timeslice.
		791	.TP
		792	.B \-x
		793	When parsing and printing,
		794	in addition to printing the headers of each packet, print the data of
		795	each packet (minus its link level header) in hex.
		796	The smaller of the entire packet or
		797	.I snaplen
		798	bytes will be printed. Note that this is the entire link-layer
		799	packet, so for link layers that pad (e.g. Ethernet), the padding bytes
		800	will also be printed when the higher layer packet is shorter than the
		801	required padding.
		802	.TP
		803	.B \-xx
		804	When parsing and printing,
		805	in addition to printing the headers of each packet, print the data of
		806	each packet,
		807	.I including
		808	its link level header, in hex.
		809	.TP
		810	.B \-X
		811	When parsing and printing,
		812	in addition to printing the headers of each packet, print the data of
		813	each packet (minus its link level header) in hex and ASCII.
		814	This is very handy for analysing new protocols.
		815	.TP
		816	.B \-XX
		817	When parsing and printing,
		818	in addition to printing the headers of each packet, print the data of
		819	each packet,
		820	.I including
		821	its link level header, in hex and ASCII.
		822	.TP
		823	.BI \-y " datalinktype"
		824	.PD 0
		825	.TP
		826	.BI \-\-linktype= datalinktype
		827	.PD
		828	Set the data link type to use while capturing packets to \fIdatalinktype\fP.
		829	.TP
		830	.BI \-z " postrotate-command"
		831	Used in conjunction with the
		832	.B -C
		833	or
		834	.B -G
		835	options, this will make
		836	.I tcpdump
		837	run "
		838	.I postrotate-command file
		839	" where
		840	.I file
		841	is the savefile being closed after each rotation. For example, specifying
		842	.B \-z gzip
		843	or
		844	.B \-z bzip2
		845	will compress each savefile using gzip or bzip2.
		846	.IP
		847	Note that tcpdump will run the command in parallel to the capture, using
		848	the lowest priority so that this doesn't disturb the capture process.
		849	.IP
		850	And in case you would like to use a command that itself takes flags or
		851	different arguments, you can always write a shell script that will take the
		852	savefile name as the only argument, make the flags & arguments arrangements
		853	and execute the command that you want.
		854	.TP
		855	.BI \-Z " user"
		856	.PD 0
		857	.TP
		858	.BI \-\-relinquish\-privileges= user
		859	.PD
		860	If
		861	.I tcpdump
		862	is running as root, after opening the capture device or input savefile,
		863	but before opening any savefiles for output, change the user ID to
		864	.I user
		865	and the group ID to the primary group of
		866	.IR user .
		867	.IP
		868	This behavior can also be enabled by default at compile time.
		869	.IP "\fI expression\fP"
		870	.RS
		871	selects which packets will be dumped.
		872	If no \fIexpression\fP
		873	is given, all packets on the net will be dumped.
		874	Otherwise,
		875	only packets for which \fIexpression\fP is `true' will be dumped.
		876	.LP
		877	For the \fIexpression\fP syntax, see
		878	.BR pcap-filter (@MAN_MISC_INFO@).
		879	.LP
		880	The \fIexpression\fP argument can be passed to \fItcpdump\fP as either a single
		881	Shell argument, or as multiple Shell arguments, whichever is more convenient.
		882	Generally, if the expression contains Shell metacharacters, such as
		883	backslashes used to escape protocol names, it is easier to pass it as
		884	a single, quoted argument rather than to escape the Shell
		885	metacharacters.
		886	Multiple arguments are concatenated with spaces before being parsed.
		887	.SH EXAMPLES
		888	.LP
		889	To print all packets arriving at or departing from \fIsundown\fP:
		890	.RS
		891	.nf
		892	\fBtcpdump host sundown\fP
		893	.fi
		894	.RE
		895	.LP
		896	To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
		897	.RS
		898	.nf
		899	\fBtcpdump host helios and \\( hot or ace \\)\fP
		900	.fi
		901	.RE
		902	.LP
		903	To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
		904	.RS
		905	.nf
		906	\fBtcpdump ip host ace and not helios\fP
		907	.fi
		908	.RE
		909	.LP
		910	To print all traffic between local hosts and hosts at Berkeley:
		911	.RS
		912	.nf
		913	.B
		914	tcpdump net ucb-ether
		915	.fi
		916	.RE
		917	.LP
		918	To print all ftp traffic through internet gateway \fIsnup\fP:
		919	(note that the expression is quoted to prevent the shell from
		920	(mis-)interpreting the parentheses):
		921	.RS
		922	.nf
		923	.B
		924	tcpdump 'gateway snup and (port ftp or ftp-data)'
		925	.fi
		926	.RE
		927	.LP
		928	To print traffic neither sourced from nor destined for local hosts
		929	(if you gateway to one other net, this stuff should never make it
		930	onto your local net).
		931	.RS
		932	.nf
		933	.B
		934	tcpdump ip and not net \fIlocalnet\fP
		935	.fi
		936	.RE
		937	.LP
		938	To print the start and end packets (the SYN and FIN packets) of each
		939	TCP conversation that involves a non-local host.
		940	.RS
		941	.nf
		942	.B
		943	tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP'
		944	.fi
		945	.RE
		946	.LP
		947	To print all IPv4 HTTP packets to and from port 80, i.e. print only
		948	packets that contain data, not, for example, SYN and FIN packets and
		949	ACK-only packets. (IPv6 is left as an exercise for the reader.)
		950	.RS
		951	.nf
		952	.B
		953	tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
		954	.fi
		955	.RE
		956	.LP
		957	To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
		958	.RS
		959	.nf
		960	.B
		961	tcpdump 'gateway snup and ip[2:2] > 576'
		962	.fi
		963	.RE
		964	.LP
		965	To print IP broadcast or multicast packets that were
		966	.I not
		967	sent via Ethernet broadcast or multicast:
		968	.RS
		969	.nf
		970	.B
		971	tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
		972	.fi
		973	.RE
		974	.LP
		975	To print all ICMP packets that are not echo requests/replies (i.e., not
		976	ping packets):
		977	.RS
		978	.nf
		979	.B
		980	tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
		981	.fi
		982	.RE
		983	.SH OUTPUT FORMAT
		984	.LP
		985	The output of \fItcpdump\fP is protocol dependent.
		986	The following
		987	gives a brief description and examples of most of the formats.
		988	.de HD
		989	.sp 1.5
		990	.B
		991	..
		992	.HD
		993	Link Level Headers
		994	.LP
		995	If the '-e' option is given, the link level header is printed out.
		996	On Ethernets, the source and destination addresses, protocol,
		997	and packet length are printed.
		998	.LP
		999	On FDDI networks, the '-e' option causes \fItcpdump\fP to print
		1000	the `frame control' field, the source and destination addresses,
		1001	and the packet length.
		1002	(The `frame control' field governs the
		1003	interpretation of the rest of the packet.
		1004	Normal packets (such
		1005	as those containing IP datagrams) are `async' packets, with a priority
		1006	value between 0 and 7; for example, `\fBasync4\fR'.
		1007	Such packets
		1008	are assumed to contain an 802.2 Logical Link Control (LLC) packet;
		1009	the LLC header is printed if it is \fInot\fR an ISO datagram or a
		1010	so-called SNAP packet.
		1011	.LP
		1012	On Token Ring networks, the '-e' option causes \fItcpdump\fP to print
		1013	the `access control' and `frame control' fields, the source and
		1014	destination addresses, and the packet length.
		1015	As on FDDI networks,
		1016	packets are assumed to contain an LLC packet.
		1017	Regardless of whether
		1018	the '-e' option is specified or not, the source routing information is
		1019	printed for source-routed packets.
		1020	.LP
		1021	On 802.11 networks, the '-e' option causes \fItcpdump\fP to print
		1022	the `frame control' fields, all of the addresses in the 802.11 header,
		1023	and the packet length.
		1024	As on FDDI networks,
		1025	packets are assumed to contain an LLC packet.
		1026	.LP
		1027	\fI(N.B.: The following description assumes familiarity with
		1028	the SLIP compression algorithm described in RFC-1144.)\fP
		1029	.LP
		1030	On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
		1031	packet type, and compression information are printed out.
		1032	The packet type is printed first.
		1033	The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
		1034	No further link information is printed for \fIip\fR packets.
		1035	For TCP packets, the connection identifier is printed following the type.
		1036	If the packet is compressed, its encoded header is printed out.
		1037	The special cases are printed out as
		1038	\fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which
		1039	the sequence number (or sequence number and ack) has changed.
		1040	If it is not a special case,
		1041	zero or more changes are printed.
		1042	A change is indicated by U (urgent pointer), W (window), A (ack),
		1043	S (sequence number), and I (packet ID), followed by a delta (+n or -n),
		1044	or a new value (=n).
		1045	Finally, the amount of data in the packet and compressed header length
		1046	are printed.
		1047	.LP
		1048	For example, the following line shows an outbound compressed TCP packet,
		1049	with an implicit connection identifier; the ack has changed by 6,
		1050	the sequence number by 49, and the packet ID by 6; there are 3 bytes of
		1051	data and 6 bytes of compressed header:
		1052	.RS
		1053	.nf
		1054	\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
		1055	.fi
		1056	.RE
		1057	.HD
		1058	ARP/RARP Packets
		1059	.LP
		1060	Arp/rarp output shows the type of request and its arguments.
		1061	The
		1062	format is intended to be self explanatory.
		1063	Here is a short sample taken from the start of an `rlogin' from
		1064	host \fIrtsg\fP to host \fIcsam\fP:
		1065	.RS
		1066	.nf
		1067	.sp .5
		1068	\f(CWarp who-has csam tell rtsg
		1069	arp reply csam is-at CSAM\fR
		1070	.sp .5
		1071	.fi
		1072	.RE
		1073	The first line says that rtsg sent an arp packet asking
		1074	for the Ethernet address of internet host csam.
		1075	Csam
		1076	replies with its Ethernet address (in this example, Ethernet addresses
		1077	are in caps and internet addresses in lower case).
		1078	.LP
		1079	This would look less redundant if we had done \fItcpdump \-n\fP:
		1080	.RS
		1081	.nf
		1082	.sp .5
		1083	\f(CWarp who-has 128.3.254.6 tell 128.3.254.68
		1084	arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP
		1085	.fi
		1086	.RE
		1087	.LP
		1088	If we had done \fItcpdump \-e\fP, the fact that the first packet is
		1089	broadcast and the second is point-to-point would be visible:
		1090	.RS
		1091	.nf
		1092	.sp .5
		1093	\f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg
		1094	CSAM RTSG 0806 64: arp reply csam is-at CSAM\fR
		1095	.sp .5
		1096	.fi
		1097	.RE
		1098	For the first packet this says the Ethernet source address is RTSG, the
		1099	destination is the Ethernet broadcast address, the type field
		1100	contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
		1101	.HD
		1102	TCP Packets
		1103	.LP
		1104	\fI(N.B.:The following description assumes familiarity with
		1105	the TCP protocol described in RFC-793.
		1106	If you are not familiar
		1107	with the protocol, neither this description nor \fItcpdump\fP will
		1108	be of much use to you.)\fP
		1109	.LP
		1110	The general format of a tcp protocol line is:
		1111	.RS
		1112	.nf
		1113	.sp .5
		1114	\fIsrc > dst: flags data-seqno ack window urgent options\fP
		1115	.sp .5
		1116	.fi
		1117	.RE
		1118	\fISrc\fP and \fIdst\fP are the source and destination IP
		1119	addresses and ports.
		1120	\fIFlags\fP are some combination of S (SYN),
		1121	F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or
		1122	`.' (ACK), or `none' if no flags are set.
		1123	\fIData-seqno\fP describes the portion of sequence space covered
		1124	by the data in this packet (see example below).
		1125	\fIAck\fP is sequence number of the next data expected the other
		1126	direction on this connection.
		1127	\fIWindow\fP is the number of bytes of receive buffer space available
		1128	the other direction on this connection.
		1129	\fIUrg\fP indicates there is `urgent' data in the packet.
		1130	\fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>).
		1131	.LP
		1132	\fISrc, dst\fP and \fIflags\fP are always present.
		1133	The other fields
		1134	depend on the contents of the packet's tcp protocol header and
		1135	are output only if appropriate.
		1136	.LP
		1137	Here is the opening portion of an rlogin from host \fIrtsg\fP to
		1138	host \fIcsam\fP.
		1139	.RS
		1140	.nf
		1141	.sp .5
		1142	\s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
		1143	csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
		1144	rtsg.1023 > csam.login: . ack 1 win 4096
		1145	rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
		1146	csam.login > rtsg.1023: . ack 2 win 4096
		1147	rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
		1148	csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
		1149	csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
		1150	csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fR\s+2
		1151	.sp .5
		1152	.fi
		1153	.RE
		1154	The first line says that tcp port 1023 on rtsg sent a packet
		1155	to port \fIlogin\fP
		1156	on csam.
		1157	The \fBS\fP indicates that the \fISYN\fP flag was set.
		1158	The packet sequence number was 768512 and it contained no data.
		1159	(The notation is `first:last(nbytes)' which means `sequence
		1160	numbers \fIfirst\fP
		1161	up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.)
		1162	There was no piggy-backed ack, the available receive window was 4096
		1163	bytes and there was a max-segment-size option requesting an mss of
		1164	1024 bytes.
		1165	.LP
		1166	Csam replies with a similar packet except it includes a piggy-backed
		1167	ack for rtsg's SYN.
		1168	Rtsg then acks csam's SYN.
		1169	The `.' means the ACK flag was set.
		1170	The packet contained no data so there is no data sequence number.
		1171	Note that the ack sequence
		1172	number is a small integer (1).
		1173	The first time \fItcpdump\fP sees a
		1174	tcp `conversation', it prints the sequence number from the packet.
		1175	On subsequent packets of the conversation, the difference between
		1176	the current packet's sequence number and this initial sequence number
		1177	is printed.
		1178	This means that sequence numbers after the
		1179	first can be interpreted
		1180	as relative byte positions in the conversation's data stream (with the
		1181	first data byte each direction being `1').
		1182	`-S' will override this
		1183	feature, causing the original sequence numbers to be output.
		1184	.LP
		1185	On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
		1186	in the rtsg \(-> csam side of the conversation).
		1187	The PUSH flag is set in the packet.
		1188	On the 7th line, csam says it's received data sent by rtsg up to
		1189	but not including byte 21.
		1190	Most of this data is apparently sitting in the
		1191	socket buffer since csam's receive window has gotten 19 bytes smaller.
		1192	Csam also sends one byte of data to rtsg in this packet.
		1193	On the 8th and 9th lines,
		1194	csam sends two bytes of urgent, pushed data to rtsg.
		1195	.LP
		1196	If the snapshot was small enough that \fItcpdump\fP didn't capture
		1197	the full TCP header, it interprets as much of the header as it can
		1198	and then reports ``[|\fItcp\fP]'' to indicate the remainder could not
		1199	be interpreted.
		1200	If the header contains a bogus option (one with a length
		1201	that's either too small or beyond the end of the header), \fItcpdump\fP
		1202	reports it as ``[\fIbad opt\fP]'' and does not interpret any further
		1203	options (since it's impossible to tell where they start).
		1204	If the header
		1205	length indicates options are present but the IP datagram length is not
		1206	long enough for the options to actually be there, \fItcpdump\fP reports
		1207	it as ``[\fIbad hdr length\fP]''.
		1208	.HD
		1209	.B Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)
		1210	.PP
		1211	There are 8 bits in the control bits section of the TCP header:
		1212	.IP
		1213	.I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
		1214	.PP
		1215	Let's assume that we want to watch packets used in establishing
		1216	a TCP connection.
		1217	Recall that TCP uses a 3-way handshake protocol
		1218	when it initializes a new connection; the connection sequence with
		1219	regard to the TCP control bits is
		1220	.PP
		1221	.RS
		1222	1) Caller sends SYN
		1223	.RE
		1224	.RS
		1225	2) Recipient responds with SYN, ACK
		1226	.RE
		1227	.RS
		1228	3) Caller sends ACK
		1229	.RE
		1230	.PP
		1231	Now we're interested in capturing packets that have only the
		1232	SYN bit set (Step 1).
		1233	Note that we don't want packets from step 2
		1234	(SYN-ACK), just a plain initial SYN.
		1235	What we need is a correct filter
		1236	expression for \fItcpdump\fP.
		1237	.PP
		1238	Recall the structure of a TCP header without options:
		1239	.PP
		1240	.nf
		1241
		1242	-----------------------------------------------------------------
		1243	| source port | destination port |
		1244	-----------------------------------------------------------------
		1245	| sequence number |
		1246	-----------------------------------------------------------------
		1247	| acknowledgment number |
		1248	-----------------------------------------------------------------
		1249	| HL | rsvd |C|E|U|A|P|R|S|F| window size |
		1250	-----------------------------------------------------------------
		1251	| TCP checksum | urgent pointer |
		1252	-----------------------------------------------------------------
		1253	.fi
		1254	.PP
		1255	A TCP header usually holds 20 octets of data, unless options are
		1256	present.
		1257	The first line of the graph contains octets 0 - 3, the
		1258	second line shows octets 4 - 7 etc.
		1259	.PP
		1260	Starting to count with 0, the relevant TCP control bits are contained
		1261	in octet 13:
		1262	.PP
		1263	.nf
		1264
		1265	----------------|---------------|---------------|----------------
		1266	| HL | rsvd |C|E|U|A|P|R|S|F| window size |
		1267	----------------|---------------|---------------|----------------
		1268	| | 13th octet | | |
		1269	.fi
		1270	.PP
		1271	Let's have a closer look at octet no. 13:
		1272	.PP
		1273	.nf
		1274	| |
		1275	|---------------|
		1276	|C|E|U|A|P|R|S|F|
		1277	|---------------|
		1278	|7 5 3 0|
		1279	.fi
		1280	.PP
		1281	These are the TCP control bits we are interested
		1282	in.
		1283	We have numbered the bits in this octet from 0 to 7, right to
		1284	left, so the PSH bit is bit number 3, while the URG bit is number 5.
		1285	.PP
		1286	Recall that we want to capture packets with only SYN set.
		1287	Let's see what happens to octet 13 if a TCP datagram arrives
		1288	with the SYN bit set in its header:
		1289	.PP
		1290	.nf
		1291	|C|E|U|A|P|R|S|F|
		1292	|---------------|
		1293	|0 0 0 0 0 0 1 0|
		1294	|---------------|
		1295	|7 6 5 4 3 2 1 0|
		1296	.fi
		1297	.PP
		1298	Looking at the
		1299	control bits section we see that only bit number 1 (SYN) is set.
		1300	.PP
		1301	Assuming that octet number 13 is an 8-bit unsigned integer in
		1302	network byte order, the binary value of this octet is
		1303	.IP
		1304	00000010
		1305	.PP
		1306	and its decimal representation is
		1307	.PP
		1308	.nf
		1309	7 6 5 4 3 2 1 0
		1310	0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2
		1311	.fi
		1312	.PP
		1313	We're almost done, because now we know that if only SYN is set,
		1314	the value of the 13th octet in the TCP header, when interpreted
		1315	as a 8-bit unsigned integer in network byte order, must be exactly 2.
		1316	.PP
		1317	This relationship can be expressed as
		1318	.RS
		1319	.B
		1320	tcp[13] == 2
		1321	.RE
		1322	.PP
		1323	We can use this expression as the filter for \fItcpdump\fP in order
		1324	to watch packets which have only SYN set:
		1325	.RS
		1326	.B
		1327	tcpdump -i xl0 tcp[13] == 2
		1328	.RE
		1329	.PP
		1330	The expression says "let the 13th octet of a TCP datagram have
		1331	the decimal value 2", which is exactly what we want.
		1332	.PP
		1333	Now, let's assume that we need to capture SYN packets, but we
		1334	don't care if ACK or any other TCP control bit is set at the
		1335	same time.
		1336	Let's see what happens to octet 13 when a TCP datagram
		1337	with SYN-ACK set arrives:
		1338	.PP
		1339	.nf
		1340	|C|E|U|A|P|R|S|F|
		1341	|---------------|
		1342	|0 0 0 1 0 0 1 0|
		1343	|---------------|
		1344	|7 6 5 4 3 2 1 0|
		1345	.fi
		1346	.PP
		1347	Now bits 1 and 4 are set in the 13th octet.
		1348	The binary value of
		1349	octet 13 is
		1350	.IP
		1351	00010010
		1352	.PP
		1353	which translates to decimal
		1354	.PP
		1355	.nf
		1356	7 6 5 4 3 2 1 0
		1357	0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18
		1358	.fi
		1359	.PP
		1360	Now we can't just use 'tcp[13] == 18' in the \fItcpdump\fP filter
		1361	expression, because that would select only those packets that have
		1362	SYN-ACK set, but not those with only SYN set.
		1363	Remember that we don't care
		1364	if ACK or any other control bit is set as long as SYN is set.
		1365	.PP
		1366	In order to achieve our goal, we need to logically AND the
		1367	binary value of octet 13 with some other value to preserve
		1368	the SYN bit.
		1369	We know that we want SYN to be set in any case,
		1370	so we'll logically AND the value in the 13th octet with
		1371	the binary value of a SYN:
		1372	.PP
		1373	.nf
		1374
		1375	00010010 SYN-ACK 00000010 SYN
		1376	AND 00000010 (we want SYN) AND 00000010 (we want SYN)
		1377	-------- --------
		1378	= 00000010 = 00000010
		1379	.fi
		1380	.PP
		1381	We see that this AND operation delivers the same result
		1382	regardless whether ACK or another TCP control bit is set.
		1383	The decimal representation of the AND value as well as
		1384	the result of this operation is 2 (binary 00000010),
		1385	so we know that for packets with SYN set the following
		1386	relation must hold true:
		1387	.IP
		1388	( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
		1389	.PP
		1390	This points us to the \fItcpdump\fP filter expression
		1391	.RS
		1392	.B
		1393	tcpdump -i xl0 'tcp[13] & 2 == 2'
		1394	.RE
		1395	.PP
		1396	Some offsets and field values may be expressed as names
		1397	rather than as numeric values. For example tcp[13] may
		1398	be replaced with tcp[tcpflags]. The following TCP flag
		1399	field values are also available: tcp-fin, tcp-syn, tcp-rst,
		1400	tcp-push, tcp-act, tcp-urg.
		1401	.PP
		1402	This can be demonstrated as:
		1403	.RS
		1404	.B
		1405	tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'
		1406	.RE
		1407	.PP
		1408	Note that you should use single quotes or a backslash
		1409	in the expression to hide the AND ('&') special character
		1410	from the shell.
		1411	.HD
		1412	.B
		1413	UDP Packets
		1414	.LP
		1415	UDP format is illustrated by this rwho packet:
		1416	.RS
		1417	.nf
		1418	.sp .5
		1419	\f(CWactinide.who > broadcast.who: udp 84\fP
		1420	.sp .5
		1421	.fi
		1422	.RE
		1423	This says that port \fIwho\fP on host \fIactinide\fP sent a udp
		1424	datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
		1425	broadcast address.
		1426	The packet contained 84 bytes of user data.
		1427	.LP
		1428	Some UDP services are recognized (from the source or destination
		1429	port number) and the higher level protocol information printed.
		1430	In particular, Domain Name service requests (RFC-1034/1035) and Sun
		1431	RPC calls (RFC-1050) to NFS.
		1432	.HD
		1433	UDP Name Server Requests
		1434	.LP
		1435	\fI(N.B.:The following description assumes familiarity with
		1436	the Domain Service protocol described in RFC-1035.
		1437	If you are not familiar
		1438	with the protocol, the following description will appear to be written
		1439	in greek.)\fP
		1440	.LP
		1441	Name server requests are formatted as
		1442	.RS
		1443	.nf
		1444	.sp .5
		1445	\fIsrc > dst: id op? flags qtype qclass name (len)\fP
		1446	.sp .5
		1447	\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR
		1448	.sp .5
		1449	.fi
		1450	.RE
		1451	Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
		1452	address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP
		1453	The query id was `3'.
		1454	The `+' indicates the \fIrecursion desired\fP flag
		1455	was set.
		1456	The query length was 37 bytes, not including the UDP and
		1457	IP protocol headers.
		1458	The query operation was the normal one, \fIQuery\fP,
		1459	so the op field was omitted.
		1460	If the op had been anything else, it would
		1461	have been printed between the `3' and the `+'.
		1462	Similarly, the qclass was the normal one,
		1463	\fIC_IN\fP, and omitted.
		1464	Any other qclass would have been printed
		1465	immediately after the `A'.
		1466	.LP
		1467	A few anomalies are checked and may result in extra fields enclosed in
		1468	square brackets: If a query contains an answer, authority records or
		1469	additional records section,
		1470	.IR ancount ,
		1471	.IR nscount ,
		1472	or
		1473	.I arcount
		1474	are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP
		1475	is the appropriate count.
		1476	If any of the response bits are set (AA, RA or rcode) or any of the
		1477	`must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]'
		1478	is printed, where \fIx\fP is the hex value of header bytes two and three.
		1479	.HD
		1480	UDP Name Server Responses
		1481	.LP
		1482	Name server responses are formatted as
		1483	.RS
		1484	.nf
		1485	.sp .5
		1486	\fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP
		1487	.sp .5
		1488	\f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
		1489	helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
		1490	.sp .5
		1491	.fi
		1492	.RE
		1493	In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
		1494	with 3 answer records, 3 name server records and 7 additional records.
		1495	The first answer record is type A (address) and its data is internet
		1496	address 128.32.137.3.
		1497	The total size of the response was 273 bytes,
		1498	excluding UDP and IP headers.
		1499	The op (Query) and response code
		1500	(NoError) were omitted, as was the class (C_IN) of the A record.
		1501	.LP
		1502	In the second example, \fIhelios\fP responds to query 2 with a
		1503	response code of non-existent domain (NXDomain) with no answers,
		1504	one name server and no authority records.
		1505	The `*' indicates that
		1506	the \fIauthoritative answer\fP bit was set.
		1507	Since there were no
		1508	answers, no type, class or data were printed.
		1509	.LP
		1510	Other flag characters that might appear are `\-' (recursion available,
		1511	RA, \fInot\fP set) and `|' (truncated message, TC, set).
		1512	If the
		1513	`question' section doesn't contain exactly one entry, `[\fIn\fPq]'
		1514	is printed.
		1515	.HD
		1516	SMB/CIFS decoding
		1517	.LP
		1518	\fItcpdump\fP now includes fairly extensive SMB/CIFS/NBT decoding for data
		1519	on UDP/137, UDP/138 and TCP/139.
		1520	Some primitive decoding of IPX and
		1521	NetBEUI SMB data is also done.
		1522	.LP
		1523	By default a fairly minimal decode is done, with a much more detailed
		1524	decode done if -v is used.
		1525	Be warned that with -v a single SMB packet
		1526	may take up a page or more, so only use -v if you really want all the
		1527	gory details.
		1528	.LP
		1529	For information on SMB packet formats and what all the fields mean see
		1530	www.cifs.org or the pub/samba/specs/ directory on your favorite
		1531	samba.org mirror site.
		1532	The SMB patches were written by Andrew Tridgell
		1533	(tridge@samba.org).
		1534	.HD
		1535	NFS Requests and Replies
		1536	.LP
		1537	Sun NFS (Network File System) requests and replies are printed as:
		1538	.RS
		1539	.nf
		1540	.sp .5
		1541	\fIsrc.sport > dst.nfs: NFS request xid xid len op args\fP
		1542	\fIsrc.nfs > dst.dport: NFS reply xid xid reply stat len op results\fP
		1543	.sp .5
		1544	\f(CW
		1545	sushi.1023 > wrl.nfs: NFS request xid 26377
		1546	112 readlink fh 21,24/10.73165
		1547	wrl.nfs > sushi.1023: NFS reply xid 26377
		1548	reply ok 40 readlink "../var"
		1549	sushi.1022 > wrl.nfs: NFS request xid 8219
		1550	144 lookup fh 9,74/4096.6878 "xcolors"
		1551	wrl.nfs > sushi.1022: NFS reply xid 8219
		1552	reply ok 128 lookup fh 9,74/4134.3150
		1553	\fR
		1554	.sp .5
		1555	.fi
		1556	.RE
		1557	In the first line, host \fIsushi\fP sends a transaction with id \fI26377\fP
		1558	to \fIwrl\fP.
		1559	The request was 112 bytes,
		1560	excluding the UDP and IP headers.
		1561	The operation was a \fIreadlink\fP
		1562	(read symbolic link) on file handle (\fIfh\fP) 21,24/10.731657119.
		1563	(If one is lucky, as in this case, the file handle can be interpreted
		1564	as a major,minor device number pair, followed by the inode number and
		1565	generation number.) In the second line, \fIwrl\fP replies `ok' with
		1566	the same transaction id and the contents of the link.
		1567	.LP
		1568	In the third line, \fIsushi\fP asks (using a new transaction id) \fIwrl\fP
		1569	to lookup the name `\fIxcolors\fP' in directory file 9,74/4096.6878. In
		1570	the fourth line, \fIwrl\fP sends a reply with the respective transaction id.
		1571	.LP
		1572	Note that the data printed
		1573	depends on the operation type.
		1574	The format is intended to be self
		1575	explanatory if read in conjunction with
		1576	an NFS protocol spec.
		1577	Also note that older versions of tcpdump printed NFS packets in a
		1578	slightly different format: the transaction id (xid) would be printed
		1579	instead of the non-NFS port number of the packet.
		1580	.LP
		1581	If the \-v (verbose) flag is given, additional information is printed.
		1582	For example:
		1583	.RS
		1584	.nf
		1585	.sp .5
		1586	\f(CW
		1587	sushi.1023 > wrl.nfs: NFS request xid 79658
		1588	148 read fh 21,11/12.195 8192 bytes @ 24576
		1589	wrl.nfs > sushi.1023: NFS reply xid 79658
		1590	reply ok 1472 read REG 100664 ids 417/0 sz 29388
		1591	\fP
		1592	.sp .5
		1593	.fi
		1594	.RE
		1595	(\-v also prints the IP header TTL, ID, length, and fragmentation fields,
		1596	which have been omitted from this example.) In the first line,
		1597	\fIsushi\fP asks \fIwrl\fP to read 8192 bytes from file 21,11/12.195,
		1598	at byte offset 24576.
		1599	\fIWrl\fP replies `ok'; the packet shown on the
		1600	second line is the first fragment of the reply, and hence is only 1472
		1601	bytes long (the other bytes will follow in subsequent fragments, but
		1602	these fragments do not have NFS or even UDP headers and so might not be
		1603	printed, depending on the filter expression used).
		1604	Because the \-v flag
		1605	is given, some of the file attributes (which are returned in addition
		1606	to the file data) are printed: the file type (``REG'', for regular file),
		1607	the file mode (in octal), the uid and gid, and the file size.
		1608	.LP
		1609	If the \-v flag is given more than once, even more details are printed.
		1610	.LP
		1611	Note that NFS requests are very large and much of the detail won't be printed
		1612	unless \fIsnaplen\fP is increased.
		1613	Try using `\fB\-s 192\fP' to watch
		1614	NFS traffic.
		1615	.LP
		1616	NFS reply packets do not explicitly identify the RPC operation.
		1617	Instead,
		1618	\fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
		1619	replies using the transaction ID.
		1620	If a reply does not closely follow the
		1621	corresponding request, it might not be parsable.
		1622	.HD
		1623	AFS Requests and Replies
		1624	.LP
		1625	Transarc AFS (Andrew File System) requests and replies are printed
		1626	as:
		1627	.HD
		1628	.RS
		1629	.nf
		1630	.sp .5
		1631	\fIsrc.sport > dst.dport: rx packet-type\fP
		1632	\fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP
		1633	\fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP
		1634	.sp .5
		1635	\f(CW
		1636	elvis.7001 > pike.afsfs:
		1637	rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
		1638	new fid 536876964/1/1 ".newsrc"
		1639	pike.afsfs > elvis.7001: rx data fs reply rename
		1640	\fR
		1641	.sp .5
		1642	.fi
		1643	.RE
		1644	In the first line, host elvis sends a RX packet to pike.
		1645	This was
		1646	a RX data packet to the fs (fileserver) service, and is the start of
		1647	an RPC call.
		1648	The RPC call was a rename, with the old directory file id
		1649	of 536876964/1/1 and an old filename of `.newsrc.new', and a new directory
		1650	file id of 536876964/1/1 and a new filename of `.newsrc'.
		1651	The host pike
		1652	responds with a RPC reply to the rename call (which was successful, because
		1653	it was a data packet and not an abort packet).
		1654	.LP
		1655	In general, all AFS RPCs are decoded at least by RPC call name.
		1656	Most
		1657	AFS RPCs have at least some of the arguments decoded (generally only
		1658	the `interesting' arguments, for some definition of interesting).
		1659	.LP
		1660	The format is intended to be self-describing, but it will probably
		1661	not be useful to people who are not familiar with the workings of
		1662	AFS and RX.
		1663	.LP
		1664	If the -v (verbose) flag is given twice, acknowledgement packets and
		1665	additional header information is printed, such as the RX call ID,
		1666	call number, sequence number, serial number, and the RX packet flags.
		1667	.LP
		1668	If the -v flag is given twice, additional information is printed,
		1669	such as the RX call ID, serial number, and the RX packet flags.
		1670	The MTU negotiation information is also printed from RX ack packets.
		1671	.LP
		1672	If the -v flag is given three times, the security index and service id
		1673	are printed.
		1674	.LP
		1675	Error codes are printed for abort packets, with the exception of Ubik
		1676	beacon packets (because abort packets are used to signify a yes vote
		1677	for the Ubik protocol).
		1678	.LP
		1679	Note that AFS requests are very large and many of the arguments won't
		1680	be printed unless \fIsnaplen\fP is increased.
		1681	Try using `\fB-s 256\fP'
		1682	to watch AFS traffic.
		1683	.LP
		1684	AFS reply packets do not explicitly identify the RPC operation.
		1685	Instead,
		1686	\fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
		1687	replies using the call number and service ID.
		1688	If a reply does not closely
		1689	follow the
		1690	corresponding request, it might not be parsable.
		1691
		1692	.HD
		1693	KIP AppleTalk (DDP in UDP)
		1694	.LP
		1695	AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated
		1696	and dumped as DDP packets (i.e., all the UDP header information is
		1697	discarded).
		1698	The file
		1699	.I /etc/atalk.names
		1700	is used to translate AppleTalk net and node numbers to names.
		1701	Lines in this file have the form
		1702	.RS
		1703	.nf
		1704	.sp .5
		1705	\fInumber name\fP
		1706
		1707	\f(CW1.254 ether
		1708	16.1 icsd-net
		1709	1.254.110 ace\fR
		1710	.sp .5
		1711	.fi
		1712	.RE
		1713	The first two lines give the names of AppleTalk networks.
		1714	The third
		1715	line gives the name of a particular host (a host is distinguished
		1716	from a net by the 3rd octet in the number \-
		1717	a net number \fImust\fP have two octets and a host number \fImust\fP
		1718	have three octets.) The number and name should be separated by
		1719	whitespace (blanks or tabs).
		1720	The
		1721	.I /etc/atalk.names
		1722	file may contain blank lines or comment lines (lines starting with
		1723	a `#').
		1724	.LP
		1725	AppleTalk addresses are printed in the form
		1726	.RS
		1727	.nf
		1728	.sp .5
		1729	\fInet.host.port\fP
		1730
		1731	\f(CW144.1.209.2 > icsd-net.112.220
		1732	office.2 > icsd-net.112.220
		1733	jssmag.149.235 > icsd-net.2\fR
		1734	.sp .5
		1735	.fi
		1736	.RE
		1737	(If the
		1738	.I /etc/atalk.names
		1739	doesn't exist or doesn't contain an entry for some AppleTalk
		1740	host/net number, addresses are printed in numeric form.)
		1741	In the first example, NBP (DDP port 2) on net 144.1 node 209
		1742	is sending to whatever is listening on port 220 of net icsd node 112.
		1743	The second line is the same except the full name of the source node
		1744	is known (`office').
		1745	The third line is a send from port 235 on
		1746	net jssmag node 149 to broadcast on the icsd-net NBP port (note that
		1747	the broadcast address (255) is indicated by a net name with no host
		1748	number \- for this reason it's a good idea to keep node names and
		1749	net names distinct in /etc/atalk.names).
		1750	.LP
		1751	NBP (name binding protocol) and ATP (AppleTalk transaction protocol)
		1752	packets have their contents interpreted.
		1753	Other protocols just dump
		1754	the protocol name (or number if no name is registered for the
		1755	protocol) and packet size.
		1756
		1757	\fBNBP packets\fP are formatted like the following examples:
		1758	.RS
		1759	.nf
		1760	.sp .5
		1761	\s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
		1762	jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
		1763	techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fR\s+2
		1764	.sp .5
		1765	.fi
		1766	.RE
		1767	The first line is a name lookup request for laserwriters sent by net icsd host
		1768	112 and broadcast on net jssmag.
		1769	The nbp id for the lookup is 190.
		1770	The second line shows a reply for this request (note that it has the
		1771	same id) from host jssmag.209 saying that it has a laserwriter
		1772	resource named "RM1140" registered on port 250.
		1773	The third line is
		1774	another reply to the same request saying host techpit has laserwriter
		1775	"techpit" registered on port 186.
		1776
		1777	\fBATP packet\fP formatting is demonstrated by the following example:
		1778	.RS
		1779	.nf
		1780	.sp .5
		1781	\s-2\f(CWjssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001
		1782	helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
		1783	helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
		1784	helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
		1785	helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
		1786	helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
		1787	helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
		1788	helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
		1789	helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
		1790	jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
		1791	helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
		1792	helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
		1793	jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001
		1794	jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fR\s+2
		1795	.sp .5
		1796	.fi
		1797	.RE
		1798	Jssmag.209 initiates transaction id 12266 with host helios by requesting
		1799	up to 8 packets (the `<0-7>').
		1800	The hex number at the end of the line
		1801	is the value of the `userdata' field in the request.
		1802	.LP
		1803	Helios responds with 8 512-byte packets.
		1804	The `:digit' following the
		1805	transaction id gives the packet sequence number in the transaction
		1806	and the number in parens is the amount of data in the packet,
		1807	excluding the atp header.
		1808	The `*' on packet 7 indicates that the
		1809	EOM bit was set.
		1810	.LP
		1811	Jssmag.209 then requests that packets 3 & 5 be retransmitted.
		1812	Helios
		1813	resends them then jssmag.209 releases the transaction.
		1814	Finally,
		1815	jssmag.209 initiates the next request.
		1816	The `*' on the request
		1817	indicates that XO (`exactly once') was \fInot\fP set.
		1818
		1819	.HD
		1820	IP Fragmentation
		1821	.LP
		1822	Fragmented Internet datagrams are printed as
		1823	.RS
		1824	.nf
		1825	.sp .5
		1826	\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
		1827	\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
		1828	.sp .5
		1829	.fi
		1830	.RE
		1831	(The first form indicates there are more fragments.
		1832	The second
		1833	indicates this is the last fragment.)
		1834	.LP
		1835	\fIId\fP is the fragment id.
		1836	\fISize\fP is the fragment
		1837	size (in bytes) excluding the IP header.
		1838	\fIOffset\fP is this
		1839	fragment's offset (in bytes) in the original datagram.
		1840	.LP
		1841	The fragment information is output for each fragment.
		1842	The first
		1843	fragment contains the higher level protocol header and the frag
		1844	info is printed after the protocol info.
		1845	Fragments
		1846	after the first contain no higher level protocol header and the
		1847	frag info is printed after the source and destination addresses.
		1848	For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa
		1849	over a CSNET connection that doesn't appear to handle 576 byte datagrams:
		1850	.RS
		1851	.nf
		1852	.sp .5
		1853	\s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
		1854	arizona > rtsg: (frag 595a:204@328)
		1855	rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
		1856	.sp .5
		1857	.fi
		1858	.RE
		1859	There are a couple of things to note here: First, addresses in the
		1860	2nd line don't include port numbers.
		1861	This is because the TCP
		1862	protocol information is all in the first fragment and we have no idea
		1863	what the port or sequence numbers are when we print the later fragments.
		1864	Second, the tcp sequence information in the first line is printed as if there
		1865	were 308 bytes of user data when, in fact, there are 512 bytes (308 in
		1866	the first frag and 204 in the second).
		1867	If you are looking for holes
		1868	in the sequence space or trying to match up acks
		1869	with packets, this can fool you.
		1870	.LP
		1871	A packet with the IP \fIdon't fragment\fP flag is marked with a
		1872	trailing \fB(DF)\fP.
		1873	.HD
		1874	Timestamps
		1875	.LP
		1876	By default, all output lines are preceded by a timestamp.
		1877	The timestamp
		1878	is the current clock time in the form
		1879	.RS
		1880	.nf
		1881	\fIhh:mm:ss.frac\fP
		1882	.fi
		1883	.RE
		1884	and is as accurate as the kernel's clock.
		1885	The timestamp reflects the time the kernel first saw the packet.
		1886	No attempt
		1887	is made to account for the time lag between when the
		1888	Ethernet interface removed the packet from the wire and when the kernel
		1889	serviced the `new packet' interrupt.
		1890	.SH "SEE ALSO"
		1891	stty(1), pcap(3PCAP), bpf(4), nit(4P), pcap-savefile(@MAN_FILE_FORMATS@),
		1892	pcap-filter(@MAN_MISC_INFO@), pcap-tstamp(@MAN_MISC_INFO@)
		1893	.LP
		1894	.RS
		1895	.I http://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap
		1896	.RE
		1897	.LP
		1898	.SH AUTHORS
		1899	The original authors are:
		1900	.LP
		1901	Van Jacobson,
		1902	Craig Leres and
		1903	Steven McCanne, all of the
		1904	Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
		1905	.LP
		1906	It is currently being maintained by tcpdump.org.
		1907	.LP
		1908	The current version is available via http:
		1909	.LP
		1910	.RS
		1911	.I http://www.tcpdump.org/
		1912	.RE
		1913	.LP
		1914	The original distribution is available via anonymous ftp:
		1915	.LP
		1916	.RS
		1917	.I ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z
		1918	.RE
		1919	.LP
		1920	IPv6/IPsec support is added by WIDE/KAME project.
		1921	This program uses Eric Young's SSLeay library, under specific configurations.
		1922	.SH BUGS
		1923	Please send problems, bugs, questions, desirable enhancements, patches
		1924	etc. to:
		1925	.LP
		1926	.RS
		1927	tcpdump-workers@lists.tcpdump.org
		1928	.RE
		1929	.LP
		1930	NIT doesn't let you watch your own outbound traffic, BPF will.
		1931	We recommend that you use the latter.
		1932	.LP
		1933	On Linux systems with 2.0[.x] kernels:
		1934	.IP
		1935	packets on the loopback device will be seen twice;
		1936	.IP
		1937	packet filtering cannot be done in the kernel, so that all packets must
		1938	be copied from the kernel in order to be filtered in user mode;
		1939	.IP
		1940	all of a packet, not just the part that's within the snapshot length,
		1941	will be copied from the kernel (the 2.0[.x] packet capture mechanism, if
		1942	asked to copy only part of a packet to userland, will not report the
		1943	true length of the packet; this would cause most IP packets to get an
		1944	error from
		1945	.BR tcpdump );
		1946	.IP
		1947	capturing on some PPP devices won't work correctly.
		1948	.LP
		1949	We recommend that you upgrade to a 2.2 or later kernel.
		1950	.LP
		1951	Some attempt should be made to reassemble IP fragments or, at least
		1952	to compute the right length for the higher level protocol.
		1953	.LP
		1954	Name server inverse queries are not dumped correctly: the (empty)
		1955	question section is printed rather than real query in the answer
		1956	section.
		1957	Some believe that inverse queries are themselves a bug and
		1958	prefer to fix the program generating them rather than \fItcpdump\fP.
		1959	.LP
		1960	A packet trace that crosses a daylight savings time change will give
		1961	skewed time stamps (the time change is ignored).
		1962	.LP
		1963	Filter expressions on fields other than those in Token Ring headers will
		1964	not correctly handle source-routed Token Ring packets.
		1965	.LP
		1966	Filter expressions on fields other than those in 802.11 headers will not
		1967	correctly handle 802.11 data packets with both To DS and From DS set.
		1968	.LP
		1969	.BR "ip6 proto"
		1970	should chase header chain, but at this moment it does not.
		1971	.BR "ip6 protochain"
		1972	is supplied for this behavior.
		1973	.LP
		1974	Arithmetic expression against transport layer headers, like \fBtcp[0]\fP,
		1975	does not work against IPv6 packets.
		1976	It only looks at IPv4 packets.