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