1.\" $OpenBSD: tcpdump.8,v 1.43 2003/10/12 10:59:47 dhartmei Exp $ 2.\" 3.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996 4.\" The Regents of the University of California. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that: (1) source code distributions 8.\" retain the above copyright notice and this paragraph in its entirety, (2) 9.\" distributions including binary code include the above copyright notice and 10.\" this paragraph in its entirety in the documentation or other materials 11.\" provided with the distribution, and (3) all advertising materials mentioning 12.\" features or use of this software display the following acknowledgement: 13.\" ``This product includes software developed by the University of California, 14.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of 15.\" the University nor the names of its contributors may be used to endorse 16.\" or promote products derived from this software without specific prior 17.\" written permission. 18.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED 19.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF 20.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. 21.\" 22.Dd May 25, 1999 23.Dt TCPDUMP 8 24.Os 25.Sh NAME 26.Nm tcpdump 27.Nd dump traffic on a network 28.Sh SYNOPSIS 29.Nm tcpdump 30.Bk -words 31.Op Fl adeflnNoOpqStvxX 32.Op Fl c Ar count 33.Op Fl E Oo Ar espalg: Oc Ar espkey 34.Op Fl F Ar file 35.Op Fl i Ar interface 36.Op Fl r Ar file 37.Op Fl s Ar snaplen 38.Op Fl T Ar type 39.Op Fl w Ar file 40.Op Ar expression 41.Ek 42.Sh DESCRIPTION 43.Nm 44prints out the headers of packets on a network interface that match the boolean 45.Ar expression . 46You must have read access to 47.Pa /dev/bpf* . 48.Pp 49The options are as follows: 50.Bl -tag -width "-c count" 51.It Fl a 52Attempt to convert network and broadcast addresses to names. 53.It Fl c Ar count 54Exit after receiving 55.Ar count 56packets. 57.It Fl d 58Dump the compiled packet-matching code in a human readable form to 59standard output and stop. 60.It Fl dd 61Dump packet-matching code as a C program fragment. 62.It Fl ddd 63Dump packet-matching code as decimal numbers 64preceded with a count. 65.It Fl e 66Print the link-level header on each dump line. 67.It Xo 68.Fl E Oo Ar espalg: Oc Ar espkey 69.Xc 70Try to decrypt RFC 2406 ESP 71.Pq Encapsulating Security Payload 72traffic using the specified hex key 73.Ar espkey . 74Supported algorithms for 75.Ar espalg 76are: 77.Cm aes128 , 78.Cm aes128-hmac96 , 79.Cm blowfish , 80.Cm blowfish-hmac96 , 81.Cm cast , 82.Cm cast-hmac96 , 83.Cm des3 , 84.Cm des3-hmac96 , 85.Cm des 86and 87.Cm des-hmac96 . 88The algorithm defaults to 89.Cm aes128-hmac96 . 90This option should be used for debugging only, since the key will show up in 91.Xr ps 1 92output. 93.It Fl f 94Print 95.Dq foreign 96internet addresses numerically rather than symbolically. 97This option is intended to get around serious brain damage in 98Sun's yp server \(em usually it hangs forever translating non-local 99internet numbers. 100.It Fl F Ar file 101Use 102.Ar file 103as input for the filter expression. 104Any additional expressions given on the command line are ignored. 105.It Fl i Ar interface 106Listen on 107.Ar interface . 108If unspecified, 109.Nm 110searches the system interface list for the lowest numbered, configured 111.Dq up 112interface 113.Pq excluding loopback . 114Ties are broken by choosing the earliest match. 115.It Fl l 116Make stdout line buffered. 117Useful if you want to see the data while capturing it. 118E.g., 119.Pp 120.Dl # tcpdump -l | tee dat 121or 122.Dl # tcpdump -l > dat & tail -f dat 123.It Fl n 124Do not convert addresses 125.Pq host addresses, port numbers, etc. 126to names. 127.It Fl N 128Do not print domain name qualification of host names. 129For example, if you specify this flag then 130.Nm 131will print 132.Dq nic 133instead of 134.Dq nic.ddn.mil . 135.It Fl o 136Print a guess of the possible operating system(s) of hosts that sent 137TCP SYN packets. 138See 139.Xr pf.os 5 140for a description of the passive operating system fingerprints. 141.It Fl O 142Do not run the packet-matching code optimizer. 143This is useful only if you suspect a bug in the optimizer. 144.It Fl p 145Do not put the interface into promiscuous mode. 146The interface might be in promiscuous mode for some other reason; hence, 147.Fl p 148cannot be used as an abbreviation for 149.Dq ether host \&"{local-hw-addr}\&" 150or 151.Dq ether broadcast . 152.It Fl q 153Quick 154.Pq quiet? 155output. 156Print less protocol information so output lines are shorter. 157.It Fl r Ar file 158Read packets from a 159.Ar file 160which was created with the 161.Fl w 162option. 163Standard input is used if 164.Ar file 165is 166.Ql - . 167.It Fl s Ar snaplen 168Analyze at most the first 169.Ar snaplen 170bytes of data from each packet rather than the default of 96. 17196 bytes is adequate for IP, ICMP, TCP, and UDP, 172but may truncate protocol information from name server and NFS packets 173.Pq see below . 174Packets truncated because of a limited 175.Ar snaplen 176are indicated in the output with 177.Dq Op \*(Ba Ns Em proto , 178where 179.Em proto 180is the name of the protocol level at which the truncation has occurred. 181Taking larger snapshots both increases the amount of time it takes 182to process packets and, effectively, decreases the amount of packet buffering. 183This may cause packets to be lost. 184You should limit 185.Ar snaplen 186to the smallest number that will capture the protocol information 187you're interested in. 188.It Fl S 189Print absolute, rather than relative, TCP sequence numbers. 190.It Fl t 191Do not print a timestamp on each dump line. 192.It Fl tt 193Print an unformatted timestamp on each dump line. 194.It Fl ttt 195Print day and month in timestamp. 196.It Fl T Ar type 197Force packets selected by 198.Ar expression 199to be interpreted as the specified 200.Ar type . 201Currently known types are 202.Cm cnfp 203.Pq Cisco NetFlow protocol , 204.Cm rpc 205.Pq Remote Procedure Call , 206.Cm rtp 207.Pq Real-Time Applications protocol , 208.Cm rtcp 209.Pq Real-Time Applications control protocol , 210.Cm sack 211.Pq RFC 2018 TCP Selective Acknowledgements Options , 212.Cm vat 213.Pq Visual Audio Tool , 214and 215.Cm wb 216.Pq distributed White Board . 217.It Fl v 218.Pq Slightly more 219verbose output. 220For example, the time to live 221.Pq TTL 222and type of service 223.Pq ToS 224information in an IP packet are printed. 225.It Fl vv 226Even more verbose output. 227For example, additional fields are printed from NFS reply packets. 228.It Fl w Ar file 229Write the raw packets to 230.Ar file 231rather than parsing and printing them out. 232They can be analyzed later with the 233.Fl r 234option. 235Standard output is used if 236.Ar file 237is 238.Ql - . 239.It Fl x 240Print each packet 241.Pq minus its link-level header 242in hex. 243The smaller of the entire packet or 244.Ar snaplen 245bytes will be printed. 246.It Fl X 247Like 248.Fl x 249but dumps the packet in emacs-hexl like format. 250.El 251.Pp 252.Ar expression 253selects which packets will be dumped. 254If no 255.Ar expression 256is given, all packets on the net will be dumped. 257Otherwise, only packets satisfying 258.Ar expression 259will be dumped. 260.Pp 261The 262.Ar expression 263consists of one or more primitives. 264Primitives usually consist of an 265.Ar id 266.Pq name or number 267preceded by one or more qualifiers. 268There are three different kinds of qualifiers: 269.Bl -tag -width "proto" 270.It Ar type 271Specify which kind of address component the 272.Ar id 273name or number refers to. 274Possible types are 275.Cm host , 276.Cm net 277and 278.Cm port . 279E.g., 280.Dq host foo , 281.Dq net 128.3 , 282.Dq port 20 . 283If there is no type qualifier, 284.Cm host 285is assumed. 286.It Ar dir 287Specify a particular transfer direction to and/or from 288.Ar id . 289Possible directions are 290.Cm src , 291.Cm dst , 292.Cm src or dst , 293and 294.Cm src and dst . 295E.g., 296.Dq src foo , 297.Dq dst net 128.3 , 298.Dq src or dst port ftp-data . 299If there is no 300.Ar dir 301qualifier, 302.Cm src or dst 303is assumed. 304For null link layers (i.e., point-to-point protocols such as SLIP 305.Pq Serial Line Internet Protocol 306or the 307.Xr pflog 4 308header), the 309.Cm inbound 310and 311.Cm outbound 312qualifiers can be used to specify a desired direction. 313.It Ar proto 314Restrict the match to a particular protocol. 315Possible protocols are: 316.Cm arp , 317.Cm decnet , 318.Cm ether , 319.Cm fddi , 320.Cm ip , 321.Cm lat , 322.Cm mopdl , 323.Cm moprc , 324.Cm rarp , 325.Cm tcp , 326and 327.Cm udp . 328E.g., 329.Dq ether src foo , 330.Dq arp net 128.3 , 331.Dq tcp port 21 . 332If there is no protocol qualifier, 333all protocols consistent with the type are assumed. 334E.g., 335.Dq src foo 336means 337.Do 338.Pq ip or arp or rarp 339src foo 340.Dc 341.Pq except the latter is not legal syntax ; 342.Dq net bar 343means 344.Do 345.Pq ip or arp or rarp 346net bar 347.Dc ; 348and 349.Dq port 53 350means 351.Do 352.Pq TCP or UDP 353port 53 354.Dc . 355.Pp 356.Cm fddi 357is actually an alias for 358.Cm ether ; 359the parser treats them identically as meaning 360.Qo 361the data link level used on the specified network interface 362.Qc . 363FDDI 364.Pq Fiber Distributed Data Interface 365headers contain Ethernet-like source and destination addresses, 366and often contain Ethernet-like packet types, 367so you can filter on these FDDI fields just as with the analogous 368Ethernet fields. 369FDDI headers also contain other fields, 370but you cannot name them explicitly in a filter expression. 371.El 372.Pp 373In addition to the above, there are some special primitive 374keywords that don't follow the pattern: 375.Cm gateway , 376.Cm broadcast , 377.Cm less , 378.Cm greater , 379and arithmetic expressions. 380All of these are described below. 381.Pp 382More complex filter expressions are built up by using the words 383.Cm and , 384.Cm or , 385and 386.Cm not 387to combine primitives 388e.g., 389.Do 390host foo and not port ftp and not port ftp-data 391.Dc . 392To save typing, identical qualifier lists can be omitted 393e.g., 394.Dq tcp dst port ftp or ftp-data or domain 395is exactly the same as 396.Do 397tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain 398.Dc . 399.Pp 400Allowable primitives are: 401.Bl -tag -width "ether proto proto" 402.It Cm dst host Ar host 403True if the IP destination field of the packet is 404.Ar host , 405which may be either an address or a name. 406.It Cm src host Ar host 407True if the IP source field of the packet is 408.Ar host . 409.It Cm host Ar host 410True if either the IP source or destination of the packet is 411.Ar host . 412.Pp 413Any of the above 414.Ar host 415expressions can be prepended with the keywords, 416.Cm ip , 417.Cm arp , 418or 419.Cm rarp 420as in: 421.Pp 422.D1 Cm ip host Ar host 423.Pp 424which is equivalent to: 425.Bd -ragged -offset indent 426.Cm ether proto 427.Ar ip 428.Cm and host 429.Ar host 430.Ed 431.Pp 432If 433.Ar host 434is a name with multiple IP addresses, each address will be checked for a match. 435.It Cm ether dst Ar ehost 436True if the Ethernet destination address is 437.Ar ehost . 438.Ar ehost 439may be either a name from 440.Pa /etc/ethers 441or a number (see 442.Xr ethers 3 443for a numeric format). 444.It Cm ether src Ar ehost 445True if the Ethernet source address is 446.Ar ehost . 447.It Cm ether host Ar ehost 448True if either the Ethernet source or destination address is 449.Ar ehost . 450.It Cm gateway Ar host 451True if the packet used 452.Ar host 453as a gateway; i.e., the Ethernet source or destination address was 454.Ar host 455but neither the IP source nor the IP destination was 456.Ar host . 457.Ar host 458must be a name and must be found in both 459.Pa /etc/hosts 460and 461.Pa /etc/ethers . 462An equivalent expression is 463.Bd -ragged -offset indent 464.Cm ether host 465.Ar ehost 466.Cm and not host 467.Ar host 468.Ed 469.Pp 470which can be used with either names or numbers for 471.Ar host Ns / Ns Ar ehost . 472.It Cm dst net Ar net 473True if the IP destination address of the packet has a network number of 474.Ar net . 475.Ar net 476may be either a name from 477.Pa /etc/networks 478or a network number (see 479.Xr networks 5 480for details). 481.It Cm src net Ar net 482True if the IP source address of the packet has a network number of 483.Ar net . 484.It Cm net Ar net 485True if either the IP source or destination address of the packet 486has a network number of 487.Ar net . 488.It Cm dst port Ar port 489True if the packet is IP/TCP or IP/UDP and has a destination port value of 490.Ar port . 491The 492.Ar port 493can be a number or a name used in 494.Pa /etc/services 495(see 496.Xr tcp 4 497and 498.Xr udp 4 ) . 499If a name is used, both the port number and protocol are checked. 500If a number or ambiguous name is used, only the port number is checked; 501e.g., 502.Dq Cm dst port No 513 503will print both TCP/login traffic and UDP/who traffic, and 504.Dq Cm dst port No domain 505will print both TCP/domain and UDP/domain traffic. 506.It Cm src port Ar port 507True if the packet has a source port value of 508.Ar port . 509.It Cm port Ar port 510True if either the source or destination port of the packet is 511.Ar port . 512.Pp 513Any of the above port expressions can be prepended with the keywords 514.Cm tcp 515or 516.Cm udp , 517as in: 518.Pp 519.D1 Cm tcp src port Ar port 520.Pp 521which matches only TCP packets whose source port is 522.Ar port . 523.It Cm less Ar length 524True if the packet has a length less than or equal to 525.Ar length . 526This is equivalent to: 527.Pp 528.D1 Cm len <= Ar length 529.Pp 530.It Cm greater Ar length 531True if the packet has a length greater than or equal to 532.Ar length . 533This is equivalent to: 534.Pp 535.D1 Cm len >= Ar length 536.Pp 537.It Cm ip proto Ar proto 538True if the packet is an IP packet (see 539.Xr ip 4 ) 540of protocol type 541.Ar proto . 542.Ar proto 543can be a number or one of the names 544.Cm icmp , 545.Cm udp , 546.Cm nd , 547or 548.Cm tcp . 549The identifiers 550.Cm tcp , 551.Cm udp , 552and 553.Cm icmp 554are also shell keywords and must be escaped. 555.It Cm ether broadcast 556True if the packet is an Ethernet broadcast packet. 557The 558.Cm ether 559keyword is optional. 560.It Cm ip broadcast 561True if the packet is an IP broadcast packet. 562It checks for both the all-zeroes and all-ones broadcast conventions 563and looks up the local subnet mask. 564.It Cm ether multicast 565True if the packet is an Ethernet multicast packet. 566The 567.Cm ether 568keyword is optional. 569This is shorthand for 570.Do 571.Cm ether Ns [0] & 1 != 0 572.Dc . 573.It Cm ip multicast 574True if the packet is an IP multicast packet. 575.It Cm ether proto Ar proto 576True if the packet is of ether type 577.Ar proto . 578.Ar proto 579can be a number or a name like 580.Cm ip , 581.Cm arp , 582or 583.Cm rarp . 584These identifiers are also shell keywords and must be escaped. 585In the case of FDDI (e.g., 586.Dq Cm fddi protocol arp ) , 587the protocol identification comes from the 802.2 Logical Link Control 588.Pq LLC 589header, which is usually layered on top of the FDDI header. 590.Nm 591assumes, when filtering on the protocol identifier, that all FDDI packets 592include an LLC header, and that the LLC header is in so-called SNAP format. 593.It Cm decnet src Ar host 594True if the 595.Tn DECNET 596source address is 597.Ar host , 598which may be an address of the form 599.Dq 10.123 , 600or a 601.Tn DECNET 602host name. 603.Tn DECNET 604host name support is only available on systems that are configured to run 605.Tn DECNET . 606.It Cm decnet dst Ar host 607True if the 608.Tn DECNET 609destination address is 610.Ar host . 611.It Cm decnet host Ar host 612True if either the 613.Tn DECNET 614source or destination address is 615.Ar host . 616.It Cm ifname Ar interface 617True if the packet was logged as coming from the specified interface 618(applies only to packets logged by 619.Xr pf 4 ) . 620.It Cm on Ar interface 621Synonymous with the 622.Ar ifname 623modifier. 624.It Cm rnr Ar num 625True if the packet was logged as matching the specified PF rule number 626in the main ruleset (applies only to packets logged by 627.Xr pf 4 ) . 628.It Cm rulenum Ar num 629Synonymous with the 630.Ar rnr 631modifier. 632.It Cm reason Ar code 633True if the packet was logged with the specified PF reason code. 634The known codes are: 635.Ar match , 636.Ar bad-offset , 637.Ar fragment , 638.Ar short , 639.Ar normalize , 640and 641.Ar memory 642(applies only to packets logged by 643.Xr pf 4 ) . 644.It Cm rset Ar name 645True if the packet was logged as matching the specified PF ruleset 646name of an anchored ruleset (applies only to packets logged by 647.Xr pf 4 ) . 648.It Cm ruleset Ar name 649Synonymous with the 650.Ar rset 651modifier. 652.It Cm srnr Ar num 653True if the packet was logged as matching the specified PF rule number 654of an anchored ruleset (applies only to packets logged by 655.Xr pf 4 ) . 656.It Cm subrulenum Ar num 657Synonymous with the 658.Ar srnr 659modifier. 660.It Cm action Ar act 661True if PF took the specified action when the packet was logged. 662Known actions are: 663.Ar pass , 664and 665.Ar block 666(applies only to packets logged by 667.Xr pf 4 ) . 668.It Xo Cm ip , 669.Cm arp , 670.Cm rarp , 671.Cm decnet , 672.Cm lat , 673.Cm moprc , 674.Cm mopdl 675.Xc 676Abbreviations for: 677.Pp 678.D1 Cm ether proto Ar p 679.Pp 680where 681.Ar p 682is one of the above protocols. 683.Nm 684does not currently know how to parse 685.Cm lat , 686.Cm moprc , 687or 688.Cm mopdl . 689.It Cm tcp , udp , icmp 690Abbreviations for: 691.Cm ip proto Ar p 692where 693.Ar p 694is one of the above protocols. 695.It Ar expr relop expr 696True if the relation holds, where 697.Ar relop 698is one of 699.Ql > , 700.Ql < , 701.Ql >= , 702.Ql <= , 703.Ql = , 704.Ql != , 705and 706.Ar expr 707is an arithmetic expression composed of integer constants 708.Pq expressed in standard C syntax , 709the normal binary operators 710.Pf ( Ns Ql + , 711.Ql - , 712.Ql * , 713.Ql / , 714.Ql & , 715.Ql | ) , 716a length operator, and special packet data accessors. 717To access data inside the packet, use the following syntax: 718.Sm off 719.Bd -ragged -offset indent 720.Ar proto Op Ar expr : Ar size 721.Ed 722.Sm on 723.Pp 724.Ar proto 725is one of 726.Cm ether , 727.Cm fddi , 728.Cm ip , 729.Cm arp , 730.Cm rarp , 731.Cm tcp , 732.Cm udp , 733or 734.Cm icmp , 735and indicates the protocol layer for the index operation. 736The byte offset, relative to the indicated protocol layer, is given by 737.Ar expr . 738.Ar size 739is optional and indicates the number of bytes in the field of interest; 740it can be either one, two, or four, and defaults to one. 741The length operator, indicated by the keyword 742.Cm len , 743gives the length of the packet. 744.Pp 745For example, 746.Dq Cm ether Ns [0] & 1 != 0 747catches all multicast traffic. 748The expression 749.Dq Cm ip Ns [0] & 0xf != 5 750catches all IP packets with options. 751The expression 752.Dq Cm ip Ns [6:2] & 0x1fff = 0 753catches only unfragmented datagrams and frag zero of fragmented datagrams. 754This check is implicitly applied to the 755.Cm tcp 756and 757.Cm udp 758index operations. 759For instance, 760.Dq Cm tcp Ns [0] 761always means the first byte of the TCP header, 762and never means the first byte of an intervening fragment. 763.El 764.Pp 765Primitives may be combined using a parenthesized group of primitives and 766operators. 767Parentheses are special to the shell and must be escaped. 768Allowable primitives and operators are: 769.Bd -ragged -offset indent 770Negation 771.Po 772.Dq Cm \&! 773or 774.Dq Cm not 775.Pc 776 777Concatenation 778.Po 779.Dq Cm && 780or 781.Dq Cm and 782.Pc 783 784Alternation 785.Po 786.Dq Cm || 787or 788.Dq Cm or 789.Pc 790.Ed 791.Pp 792Negation has highest precedence. 793Alternation and concatenation have equal precedence and associate left to right. 794Explicit 795.Cm and 796tokens, not juxtaposition, 797are now required for concatenation. 798.Pp 799If an identifier is given without a keyword, the most recent keyword is assumed. 800For example, 801.Bd -ragged -offset indent 802.Cm not host 803vs 804.Cm and 805ace 806.Ed 807.Pp 808is short for 809.Bd -ragged -offset indent 810.Cm not host 811vs 812.Cm and host 813ace 814.Ed 815.Pp 816which should not be confused with 817.Bd -ragged -offset indent 818.Cm not 819.Pq Cm host No vs Cm or No ace 820.Ed 821.Pp 822Expression arguments can be passed to 823.Nm 824as either a single argument or as multiple arguments, 825whichever is more convenient. 826Generally, if the expression contains shell metacharacters, 827it is easier to pass it as a single, quoted argument. 828Multiple arguments are concatenated with spaces before being parsed. 829.Sh EXAMPLES 830To print all packets arriving at or departing from sundown: 831.Pp 832.Dl # tcpdump host sundown 833.Pp 834To print traffic between helios and either hot or ace 835(the expression is quoted to prevent the shell from mis-interpreting 836the parentheses): 837.Pp 838.Dl # tcpdump 'host helios and (hot or ace)' 839.Pp 840To print all IP packets between ace and any host except helios: 841.Pp 842.Dl # tcpdump ip host ace and not helios 843.Pp 844To print all traffic between local hosts and hosts at Berkeley: 845.Pp 846.Dl # tcpdump net ucb-ether 847.Pp 848To print all FTP traffic through internet gateway snup: 849.Pp 850.Dl # tcpdump 'gateway snup and (port ftp or ftp-data)' 851.Pp 852To print traffic neither sourced from nor destined for local hosts 853(if you gateway to one other net, this stuff should never make it onto 854your local net): 855.Pp 856.Dl # tcpdump ip and not net localnet 857.Pp 858To print the start and end packets 859.Pq the SYN and FIN packets 860of each TCP connection that involves a non-local host: 861.Bd -literal -offset indent 862# tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet' 863.Ed 864.Pp 865To print IP packets longer than 576 bytes sent through gateway snup: 866.Pp 867.Dl # tcpdump 'gateway snup and ip[2:2] > 576' 868.Pp 869To print IP broadcast or multicast packets that were 870.Em not 871sent via Ethernet broadcast or multicast: 872.Bd -literal -offset indent 873# tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224' 874.Ed 875.Pp 876To print all ICMP packets that are not echo requests/replies 877.Pq i.e., not ping packets : 878.Pp 879.Dl # tcpdump 'icmp[0] != 8 and icmp[0] != 0' 880.Pp 881To print and decrypt all ESP packets with SPI 0x00001234: 882.Pp 883.Dl # tcpdump -E des3-hmac96:ab...def 'ip[20:4] = 0x00001234' 884.Sh OUTPUT FORMAT 885The output of 886.Nm 887is protocol dependent. 888The following gives a brief description and examples of most of the formats. 889.Ss Link Level Headers 890If the 891.Fl e 892option is given, the link level header is printed out. 893On Ethernets, the source and destination addresses, protocol, 894and packet length are printed. 895.Pp 896On the packet filter logging interface 897.Xr pflog 4 , 898logging reason 899.Pq rule match, bad-offset, fragment, short, normalize, memory , 900action taken 901.Pq pass/block , 902direction 903.Pq in/out 904and interface information are printed out for each packet. 905.Pp 906On FDDI networks, the 907.Fl e 908option causes 909.Nm 910to print the frame control field, the source and destination addresses, 911and the packet length. 912The frame control field governs the interpretation of the rest of the packet. 913Normal packets 914.Pq such as those containing IP datagrams 915are 916.Dq async 917packets, with a priority value between 0 and 7; for example, 918.Sy async4 . 919Such packets are assumed to contain an 802.2 Logical Link Control 920.Pq LLC 921packet; the LLC header is printed if it is 922.Em not 923an ISO datagram or a so-called SNAP packet. 924.Pp 925The following description assumes familiarity with the 926SLIP compression algorithm described in RFC 1144. 927.Pp 928On SLIP links, a direction indicator 929.Po 930.Ql I 931for inbound, 932.Ql O 933for outbound 934.Pc , 935packet type, and compression information are printed out. 936The packet type is printed first. 937The three types are 938.Cm ip , 939.Cm utcp , 940and 941.Cm ctcp . 942No further link information is printed for IP packets. 943For TCP packets, the connection identifier is printed following the type. 944If the packet is compressed, its encoded header is printed out. 945The special cases are printed out as 946.Cm *S+ Ns Ar n 947and 948.Cm *SA+ Ns Ar n , 949where 950.Ar n 951is the amount by which the sequence number 952.Pq or sequence number and ack 953has changed. 954If it is not a special case, zero or more changes are printed. 955A change is indicated by 956.Sq U 957.Pq urgent pointer , 958.Sq W 959.Pq window , 960.Sq A 961.Pq ack , 962.Sq S 963.Pq sequence number , 964and 965.Sq I 966.Pq packet ID , 967followed by a delta 968.Pq +n or -n , 969or a new value 970.Pq =n . 971Finally, the amount of data in the packet and compressed header length 972are printed. 973.Pp 974For example, the following line shows an outbound compressed TCP packet, 975with an implicit connection identifier; the ack has changed by 6, 976the sequence number by 49, and the packet ID by 6; 977there are 3 bytes of data and 6 bytes of compressed header: 978.Bd -ragged -offset indent 979O 980.Cm ctcp No * 981.Cm A No +6 982.Cm S No +49 983.Cm I No +6 3 984.Pq 6 985.Ed 986.Ss ARP/RARP Packets 987arp/rarp output shows the type of request and its arguments. 988The format is intended to be self-explanatory. 989Here is a short sample taken from the start of an rlogin 990from host rtsg to host csam: 991.Bd -literal -offset indent 992arp who-has csam tell rtsg 993arp reply csam is-at CSAM 994.Ed 995.Pp 996In this example, Ethernet addresses are in caps and internet addresses 997in lower case. 998The first line says that rtsg sent an arp packet asking for 999the Ethernet address of internet host csam. 1000csam replies with its Ethernet address CSAM. 1001.Pp 1002This would look less redundant if we had done 1003.Nm 1004.Fl n : 1005.Bd -literal -offset indent 1006arp who-has 128.3.254.6 tell 128.3.254.68 1007arp reply 128.3.254.6 is-at 02:07:01:00:01:c4 1008.Ed 1009.Pp 1010If we had done 1011.Nm 1012.Fl e , 1013the fact that the first packet is 1014broadcast and the second is point-to-point would be visible: 1015.Bd -literal -offset indent 1016RTSG Broadcast 0806 64: arp who-has csam tell rtsg 1017CSAM RTSG 0806 64: arp reply csam is-at CSAM 1018.Ed 1019.Pp 1020For the first packet this says the Ethernet source address is RTSG, 1021the destination is the Ethernet broadcast address, 1022the type field contained hex 0806 (type 1023.Dv ETHER_ARP ) 1024and the total length was 64 bytes. 1025.Ss TCP Packets 1026The following description assumes familiarity with the TCP protocol 1027described in RFC 793. 1028If you are not familiar with the protocol, neither this description nor 1029.Nm 1030will be of much use to you. 1031.Pp 1032The general format of a TCP protocol line is: 1033.Bd -ragged -offset indent 1034.Ar src No > Ar dst : 1035.Ar flags src-os data-seqno ack window urgent options 1036.Ed 1037.Pp 1038.Ar src 1039and 1040.Ar dst 1041are the source and destination IP addresses and ports. 1042.Ar flags 1043is some combination of 1044.Sq S 1045.Pq Tn SYN , 1046.Sq F 1047.Pq Tn FIN , 1048.Sq P 1049.Pq Tn PUSH , 1050or 1051.Sq R 1052.Pq Tn RST , 1053.Sq W 1054.Pq Tn congestion Window reduced , 1055.Sq E 1056.Pq Tn ecn ECHO 1057or a single 1058.Ql \&. 1059.Pq no flags . 1060.Ar src-os 1061will list a guess of the source host's operating system if the 1062.Fl o 1063command line flag was passed to 1064.Nm tcpdump . 1065.Ar data-seqno 1066describes the portion of sequence space covered 1067by the data in this packet 1068.Pq see example below . 1069.Ar ack 1070is the sequence number of the next data expected by the other 1071end of this connection. 1072.Ar window 1073is the number of bytes of receive buffer space available 1074at the other end of this connection. 1075.Ar urg 1076indicates there is urgent data in the packet. 1077.Ar options 1078are TCP options enclosed in angle brackets e.g., 1079.Aq mss 1024 . 1080.Pp 1081.Ar src , dst 1082and 1083.Ar flags 1084are always present. 1085The other fields depend on the contents of the packet's TCP protocol header and 1086are output only if appropriate. 1087.Pp 1088Here is the opening portion of an rlogin from host rtsg to host csam. 1089.Bd -unfilled -offset 2n 1090rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024> 1091csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024> 1092rtsg.1023 > csam.login: . ack 1 win 4096 1093rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096 1094csam.login > rtsg.1023: . ack 2 win 4096 1095rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 1096csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077 1097csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1 1098csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1 1099.Ed 1100.Pp 1101The first line says that TCP port 1023 on rtsg sent a packet 1102to port login on host csam. 1103The 1104.Ql S 1105indicates that the SYN flag was set. 1106The packet sequence number was 768512 and it contained no data. 1107The notation is 1108.Sm off 1109.So 1110.Ar first : last 1111.Po Ar nbytes 1112.Pc 1113.Sc 1114.Sm on 1115which means sequence numbers 1116.Ar first 1117up to but not including 1118.Ar last 1119which is 1120.Ar nbytes 1121bytes of user data. 1122There was no piggy-backed ack, the available receive window was 4096 1123bytes and there was a max-segment-size option requesting an mss of 1024 bytes. 1124.Pp 1125Csam replies with a similar packet except it includes a piggy-backed 1126ack for rtsg's SYN. 1127Rtsg then acks csam's SYN. 1128The 1129.Ql \&. 1130means no flags were set. 1131The packet contained no data so there is no data sequence number. 1132The ack sequence number is a 32-bit integer. 1133The first time 1134.Nm 1135sees a TCP connection, it prints the sequence number from the packet. 1136On subsequent packets of the connection, the difference between 1137the current packet's sequence number and this initial sequence number 1138is printed. 1139This means that sequence numbers after the first can be interpreted 1140as relative byte positions in the connection's data stream 1141.Po 1142with the first data byte each direction being 1 1143.Pc . 1144.Fl S 1145will override this 1146feature, causing the original sequence numbers to be output. 1147.Pp 1148On the 6th line, rtsg sends csam 19 bytes of data 1149.Po 1150bytes 2 through 20 1151in the rtsg -> csam side of the connection 1152.Pc . 1153The PUSH flag is set in the packet. 1154On the 7th line, csam says it's received data sent by rtsg up to 1155but not including byte 21. 1156Most of this data is apparently sitting in the socket buffer 1157since csam's receive window has gotten 19 bytes smaller. 1158Csam also sends one byte of data to rtsg in this packet. 1159On the 8th and 9th lines, 1160csam sends two bytes of urgent, pushed data to rtsg. 1161.Ss UDP Packets 1162UDP format is illustrated by this rwho packet: 1163.Pp 1164.D1 actinide.who > broadcast.who: udp 84 1165.Pp 1166This says that port who on host actinide sent a UDP datagram to port 1167who on host broadcast, the Internet broadcast address. 1168The packet contained 84 bytes of user data. 1169.Pp 1170Some UDP services are recognized 1171.Pq from the source or destination port number 1172and the higher level protocol information printed. 1173In particular, Domain Name service requests 1174.Pq RFC 1034/1035 1175and Sun RPC calls 1176.Pq RFC 1050 1177to NFS. 1178.Ss UDP Name Server Requests 1179The following description assumes familiarity with 1180the Domain Service protocol described in RFC 1035. 1181If you are not familiar with the protocol, 1182the following description will appear to be written in Greek. 1183.Pp 1184Name server requests are formatted as 1185.Bd -ragged -offset indent 1186.Ar src 1187> 1188.Ar dst : 1189.Ar id op Ns ?\& 1190.Ar flags qtype qclass name 1191.Pq Ar len 1192.Ed 1193.Pp 1194e.g., 1195.Pp 1196.D1 h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) 1197.Pp 1198Host h2opolo asked the domain server on helios for an address record 1199.Pq Ar qtype Ns =A 1200associated with the name 1201ucbvax.berkeley.edu. 1202The query 1203.Ar id 1204was 3. 1205The 1206.Ql + 1207indicates the recursion desired flag was set. 1208The query length was 37 bytes, not including the UDP and IP protocol headers. 1209The query operation was the normal one 1210.Pq Query 1211so the 1212.Ar op 1213field was omitted. 1214If 1215.Ar op 1216had been anything else, it would have been printed between the 3 and the 1217.Ql + . 1218Similarly, the 1219.Ar qclass 1220was the normal one 1221.Pq Tn C_IN 1222and was omitted. 1223Any other 1224.Ar qclass 1225would have been printed immediately after the A. 1226.Pp 1227A few anomalies are checked and may result in extra fields enclosed in 1228square brackets: if a query contains an answer, name server or 1229authority section, 1230.Ar ancount , 1231.Ar nscount , 1232or 1233.Ar arcount 1234are printed as 1235.Dq Bq Ar n Ns a , 1236.Dq Bq Ar n Ns n , 1237or 1238.Dq Bq Ar n Ns au 1239where 1240.Ar n 1241is the appropriate count. 1242If any of the response bits are set 1243.Po 1244AA, RA or rcode 1245.Pc 1246or any of the 1247.Dq must be zero 1248bits are set in bytes two and three, 1249.Dq Bq b2&3= Ns Ar x 1250is printed, where 1251.Ar x 1252is the hex value of header bytes two and three. 1253.Ss UDP Name Server Responses 1254Name server responses are formatted as 1255.Bd -ragged -offset indent 1256.Ar src No > Ar dst : 1257.Ar id op rcode flags 1258.Ar a 1259/ 1260.Ar n 1261/ 1262.Ar au 1263.Ar type class data 1264.Pq Ar len 1265.Ed 1266.Pp 1267e.g., 1268.Bd -unfilled -offset indent 1269helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) 1270helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97) 1271.Ed 1272.Pp 1273In the first example, helios responds to query 1274.Ar id 12753 from h2opolo 1276with 3 answer records, 3 name server records and 7 authority records. 1277The first answer record is type A 1278.Pq address and its data is internet 1279address 128.32.137.3. 1280The total size of the response was 273 bytes, excluding UDP and IP headers. 1281The 1282.Ar op 1283.Pq Query 1284and 1285.Ar rcode 1286.Pq NoError 1287were omitted, as was the 1288.Ar class 1289.Pq C_IN 1290of the A record. 1291.Pp 1292In the second example, helios responds to query 1293.Ar op 12942 with an 1295.Ar rcode 1296of non-existent domain 1297.Pq NXDomain 1298with no answers, 1299one name server and no authority records. 1300The 1301.Ql * 1302indicates that the authoritative answer bit was set. 1303Since there were no answers, no 1304.Ar type , 1305.Ar class 1306or 1307.Ar data 1308were printed. 1309.Pp 1310Other flag characters that might appear are 1311.Sq - 1312(recursion available, RA, 1313.Em not 1314set) 1315and 1316.Sq \*(Ba 1317.Pq truncated message, TC, set . 1318If the question section doesn't contain exactly one entry, 1319.Dq Bq Ar n Ns q 1320is printed. 1321.Pp 1322Name server requests and responses tend to be large and the default 1323.Ar snaplen 1324of 96 bytes may not capture enough of the packet to print. 1325Use the 1326.Fl s 1327flag to increase the 1328.Ar snaplen 1329if you need to seriously investigate name server traffic. 1330.Dq Fl s No 128 1331has worked well for me. 1332.Ss NFS Requests and Replies 1333Sun NFS 1334.Pq Network File System 1335requests and replies are printed as: 1336.Bd -ragged -offset indent 1337.Ar src Ns . Ns Ar xid 1338> 1339.Ar dst Ns . Ns Ar nfs : 1340.Ns Ar len 1341.Ns Ar op args 1342 1343.Ar src Ns . Ns Ar nfs 1344> 1345.Ar dst Ns . Ns Ar xid : 1346.Ns Ar reply stat len op results 1347.Ed 1348.Bd -unfilled -offset indent 1349sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165 1350wrl.nfs > sushi.6709: reply ok 40 readlink "../var" 1351sushi.201b > wrl.nfs: 1352 144 lookup fh 9,74/4096.6878 "xcolors" 1353wrl.nfs > sushi.201b: 1354 reply ok 128 lookup fh 9,74/4134.3150 1355.Ed 1356.Pp 1357In the first line, host sushi sends a transaction with ID 6709 to wrl. 1358The number following the src host is a transaction ID, 1359.Em not 1360the source port. 1361The request was 112 bytes, excluding the UDP and IP headers. 1362The 1363.Ar op 1364was a readlink 1365.Pq read symbolic link 1366on fh 1367.Pq Dq file handle 136821,24/10.731657119. 1369If one is lucky, as in this case, the file handle can be interpreted 1370as a major,minor device number pair, followed by the inode number and 1371generation number. 1372Wrl replies with a 1373.Ar stat 1374of ok and the contents of the link. 1375.Pp 1376In the third line, sushi asks wrl to look up the name 1377.Dq xcolors 1378in directory file 9,74/4096.6878. 1379The data printed depends on the operation type. 1380The format is intended to be self-explanatory 1381if read in conjunction with an NFS protocol spec. 1382.Pp 1383If the 1384.Fl v 1385.Pq verbose 1386flag is given, additional information is printed. 1387For example: 1388.Bd -unfilled -offset indent 1389sushi.1372a > wrl.nfs: 1390 148 read fh 21,11/12.195 8192 bytes @ 24576 1391wrl.nfs > sushi.1372a: 1392 reply ok 1472 read REG 100664 ids 417/0 sz 29388 1393.Ed 1394.Pp 1395.Fl v 1396also prints the IP header TTL, ID, and fragmentation fields, 1397which have been omitted from this example. 1398In the first line, sushi asks wrl to read 8192 bytes from file 21,11/12.195, 1399at byte offset 24576. 1400Wrl replies with a 1401.Ar stat of 1402ok; 1403the packet shown on the second line is the first fragment of the reply, 1404and hence is only 1472 bytes long. 1405The other bytes will follow in subsequent fragments, 1406but these fragments do not have NFS or even UDP headers and so might not be 1407printed, depending on the filter expression used. 1408Because the 1409.Fl v 1410flag is given, some of the file attributes 1411.Po 1412which are returned in addition to the file data 1413.Pc 1414are printed: the file type 1415.Pq So REG Sc , No for regular file , 1416the file mode 1417.Pq in octal , 1418the UID and GID, and the file size. 1419.Pp 1420If the 1421.Fl v 1422flag is given more than once, even more details are printed. 1423.Pp 1424NFS requests are very large and much of the detail won't be printed unless 1425.Ar snaplen 1426is increased. 1427Try using 1428.Dq Fl s No 192 1429to watch NFS traffic. 1430.Pp 1431NFS reply packets do not explicitly identify the RPC operation. 1432Instead, 1433.Nm 1434keeps track of 1435.Dq recent 1436requests, and matches them to the replies using the 1437.Ar xid 1438.Pq transaction ID . 1439If a reply does not closely follow the corresponding request, 1440it might not be parsable. 1441.Ss KIP AppleTalk (DDP in UDP) 1442AppleTalk DDP packets encapsulated in UDP datagrams 1443are de-encapsulated and dumped as DDP packets 1444.Pq i.e., all the UDP header information is discarded . 1445The file 1446.Pa /etc/atalk.names 1447is used to translate AppleTalk net and node numbers to names. 1448Lines in this file have the form 1449.Bl -column "number" "name" -offset indent 1450.It Sy "number" Ta Ta Sy "name" 1451.It "1.254" Ta Ta "ether" 1452.It "16.1" Ta Ta "icsd-net" 1453.It "1.254.110" Ta Ta "ace" 1454.El 1455.Pp 1456The first two lines give the names of AppleTalk networks. 1457The third line gives the name of a particular host 1458(a host is distinguished from a net by the 3rd octet in the number; 1459a net number 1460.Em must 1461have two octets and a host number 1462.Em must 1463have three octets). 1464The number and name should be separated by whitespace (blanks or tabs). 1465The 1466.Pa /etc/atalk.names 1467file may contain blank lines or comment lines 1468(lines starting with a 1469.Ql # ) . 1470.Pp 1471AppleTalk addresses are printed in the form 1472.Bd -ragged -offset indent 1473.Ar net Ns . Ns Ar host Ns . 1474.Ns Ar port 1475.Ed 1476.Pp 1477e.g., 1478.Bd -unfilled -offset indent 1479144.1.209.2 > icsd-net.112.220 1480office.2 > icsd-net.112.220 1481jssmag.149.235 > icsd-net.2 1482.Ed 1483.Pp 1484If 1485.Pa /etc/atalk.names 1486doesn't exist or doesn't contain an entry for some AppleTalk 1487host/net number, addresses are printed in numeric form. 1488In the first example, NBP 1489.Pq DDP port 2 1490on net 144.1 node 209 1491is sending to whatever is listening on port 220 of net icsd-net node 112. 1492The second line is the same except the full name of the source node is known 1493.Pq Dq office . 1494The third line is a send from port 235 on 1495net jssmag node 149 to broadcast on the icsd-net NBP port. 1496The broadcast address 1497.Pq 255 1498is indicated by a net name with no host number; 1499for this reason it is a good idea to keep node names and net names distinct in 1500.Pa /etc/atalk.names . 1501.Pp 1502NBP 1503.Pq name binding protocol 1504and ATP 1505.Pq AppleTalk transaction protocol 1506packets have their contents interpreted. 1507Other protocols just dump the protocol name 1508.Po 1509or number if no name is registered for the protocol 1510.Pc 1511and packet size. 1512.Pp 1513NBP packets are formatted like the following examples: 1514.Bd -unfilled 1515icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*" 1516jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250 1517techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186 1518.Ed 1519.Pp 1520The first line is a name lookup request for laserwriters sent by 1521net icsdi-net host 1522112 and broadcast on net jssmag. 1523The nbp ID for the lookup is 190. 1524The second line shows a reply for this request 1525.Pq note that it has the same ID 1526from host jssmag.209 saying that it has a laserwriter 1527resource named RM1140 registered on port 250. 1528The third line is another reply to the same request 1529saying host techpit has laserwriter techpit registered on port 186. 1530.Pp 1531ATP packet formatting is demonstrated by the following example: 1532.Bd -unfilled -offset indent 1533jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 1534helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 1535helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 1536helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 1537helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 1538helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 1539helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 1540helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 1541helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 1542jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001 1543helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 1544helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 1545jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001 1546jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002 1547.Ed 1548.Pp 1549Jssmag.209 initiates transaction ID 12266 with host helios by requesting 1550up to 8 packets 1551.Sm off 1552.Pq the Dq Aq 0\-7 . 1553.Sm on 1554The hex number at the end of the line is the value of the 1555.Ar userdata 1556field in the request. 1557.Pp 1558Helios responds with 8 512-byte packets. 1559The 1560.Dq : Ns Ar n 1561following the 1562transaction ID gives the packet sequence number in the transaction 1563and the number in parentheses is the amount of data in the packet, 1564excluding the ATP header. 1565The 1566.Ql * 1567on packet 7 indicates that the EOM bit was set. 1568.Pp 1569Jssmag.209 then requests that packets 3 & 5 be retransmitted. 1570Helios resends them then jssmag.209 releases the transaction. 1571Finally, jssmag.209 initiates the next request. 1572The 1573.Ql * 1574on the request indicates that XO 1575.Pq exactly once 1576was 1577.Em not 1578set. 1579.Ss IP Fragmentation 1580Fragmented Internet datagrams are printed as 1581.Bd -ragged -offset indent 1582.Po 1583.Cm frag Ar id 1584: 1585.Ar size 1586@ 1587.Ar offset 1588.Op + 1589.Pc 1590.Ed 1591.Pp 1592A 1593.Ql + 1594indicates there are more fragments. 1595The last fragment will have no 1596.Ql + . 1597.Pp 1598.Ar id 1599is the fragment ID. 1600.Ar size 1601is the fragment size 1602.Pq in bytes 1603excluding the IP header. 1604.Ar offset 1605is this fragment's offset 1606.Pq in bytes 1607in the original datagram. 1608.Pp 1609The fragment information is output for each fragment. 1610The first fragment contains the higher level protocol header and the fragment 1611info is printed after the protocol info. 1612Fragments after the first contain no higher level protocol header and the 1613fragment info is printed after the source and destination addresses. 1614For example, here is part of an FTP from arizona.edu to lbl-rtsg.arpa 1615over a CSNET connection that doesn't appear to handle 576 byte datagrams: 1616.Bd -unfilled -offset indent 1617arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+) 1618arizona > rtsg: (frag 595a:204@328) 1619rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560 1620.Ed 1621.Pp 1622There are a couple of things to note here: first, addresses in the 16232nd line don't include port numbers. 1624This is because the TCP protocol information is all in the first fragment 1625and we have no idea what the port or sequence numbers are when we print 1626the later fragments. 1627Second, the TCP sequence information in the first line is printed as if there 1628were 308 bytes of user data when, in fact, there are 512 bytes 1629.Po 1630308 in the first frag and 204 in the second 1631.Pc . 1632If you are looking for holes in the sequence space or trying to match up acks 1633with packets, this can fool you. 1634.Pp 1635A packet with the IP 1636.Sy don't fragment 1637flag is marked with a trailing 1638.Dq Pq Tn DF . 1639.Ss Timestamps 1640By default, all output lines are preceded by a timestamp. 1641The timestamp is the current clock time in the form 1642.Sm off 1643.Ar hh : mm : ss . frac 1644.Sm on 1645and is as accurate as the kernel's clock. 1646The timestamp reflects the time the kernel first saw the packet. 1647No attempt is made to account for the time lag between when the 1648Ethernet interface removed the packet from the wire and when the kernel 1649serviced the 1650.Dq new packet 1651interrupt. 1652.Sh SEE ALSO 1653.\" traffic(1C), nit(4P), 1654.Xr ethers 3 , 1655.Xr pcap 3 , 1656.Xr bpf 4 , 1657.Xr ip 4 , 1658.Xr pf 4 , 1659.Xr pflog 4 , 1660.Xr tcp 4 , 1661.Xr udp 4 , 1662.Xr networks 5 , 1663.Xr pf.os 5 1664.Rs 1665.%R RFC 793 1666.%T Transmission Control Protocol 1667.%D September 1981 1668.Re 1669.Rs 1670.%R RFC 1034 1671.%T Domain Names \- Concepts and Facilities 1672.%D November 1987 1673.Re 1674.Rs 1675.%R RFC 1035 1676.%T Domain Names \- Implementation and Specification 1677.%D November 1987 1678.Re 1679.Rs 1680.%R RFC 1050 1681.%T RPC: Remote Procedure Call 1682.%D April 1988 1683.Re 1684.Rs 1685.%R RFC 1144 1686.%T Compressing TCP/IP Headers for Low-Speed Serial Links 1687.%D February 1990 1688.Re 1689.Rs 1690.%R RFC 2018 1691.%T TCP Selective Acknowledgement Options 1692.%D October 1996 1693.Re 1694.Rs 1695.%R RFC 2406 1696.%T IP Encapsulating Security Payload (ESP) 1697.%D November 1998 1698.Re 1699.Sh AUTHORS 1700.An Van Jacobson Aq van@ee.lbl.gov , 1701.An Craig Leres Aq leres@ee.lbl.gov , 1702and 1703.An Steven McCanne Aq mccanne@ee.lbl.gov , 1704all of the Lawrence Berkeley Laboratory, University of California, Berkeley, CA. 1705.Sh BUGS 1706Please send bug reports to 1707.Aq tcpdump@ee.lbl.gov 1708or 1709.Aq libpcap@ee.lbl.gov . 1710.Pp 1711Some attempt should be made to reassemble IP fragments, 1712or at least to compute the right length for the higher level protocol. 1713.Pp 1714Name server inverse queries are not dumped correctly: The 1715.Pq empty 1716question section is printed rather than the real query in the answer section. 1717Some believe that inverse queries are themselves a bug and 1718prefer to fix the program generating them rather than 1719.Nm tcpdump . 1720.Pp 1721Apple Ethertalk DDP packets could be dumped as easily as KIP DDP packets 1722but aren't. 1723Even if we were inclined to do anything to promote the use of Ethertalk 1724(we aren't, LBL doesn't allow Ethertalk on any of its 1725networks so we'd have no way of testing this code). 1726.Pp 1727A packet trace that crosses a daylight saving time change will give 1728skewed time stamps 1729.Pq the time change is ignored . 1730.Pp 1731Filter expressions that manipulate FDDI headers assume that all FDDI packets 1732are encapsulated Ethernet packets. 1733This is true for IP, ARP, and 1734.Tn DECNET 1735Phase IV, 1736but is not true for protocols such as ISO CLNS. 1737Therefore, the filter may inadvertently accept certain packets that 1738do not properly match the filter expression. 1739