Title: TCPDUMP Chinese manual (3 ). Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
On the SLIP link, tcpdump displays outbound indications ('I' indicates inbound, ''o' indicates outbound), packet type, and compression information. the message type is displayed first. there are three types of ip addresses: utcp and ctcp. no more link information is displayed for ip packets. for TCP packets, the connection id is displayed after the type. if the packet is compressed, the encoding header is displayed. in special cases, it is displayed in the form of * S + n and * SA + n. here, n is the sum of changes in the sequence number (or sequence number and its confirmation. if this is not a special case, 0 or multiple changes are displayed. changes are specified by U (urgent pointer), W (window), A (ack), S (sequence number), and I (packet ID, followed by a variation (+ n or-n), or another value (= n ). the total data in the message and the length of the compressed header are displayed.
For example, the following line shows an outgoing compressed TCP packet with an implicit connection identifier. the variation of ack is 6, the sequence number is 49, and the message ID is 6; there are three bytes of data and six bytes of compressed header:
O ctcp * A + 6 S + 49 I + 6 3 (6)
ARP/RARP packets
The output of Arp/rarp packets shows the request type and its parameters. the output format tends to be self-explanatory. here is a simple example from the 'rlogin' start section of the host rtsg to the host csam:
The first line indicates that rtsg sends an arp packet to ask about the Ethernet address of the internet host csam. csam uses its Ethernet address as a response (in this example, the Ethernet address is in upper case, and the internet address is in lower case ).
If tcpdump-n is used, it seems clear:
The first packet indicates that the Ethernet source address is RTSG, and the destination address is the Ethernet broadcast address. the type field is hexadecimal 0806 (type ETHER_ARP), and the packet length is 64 bytes.
TCP packets
(Note: The following description assumes that you are familiar with the TCP protocol described in the RFC-793, if you do not understand this protocol, either this article or tcpdump is of little use to you)
Src and dst are source object IP addresses and ports. flags are S (SYN), F (FIN), P (PUSH), R (RST), or separate '. '(unsigned), or their combination. data-seqno indicates the position of the Data in this document in the stream sequence number (see the following example ). ack is the sequence number of the byte received by the source machine on this connection ). window is the size of the buffer byte received by the source machine on this connection. urg indicates that the packet is 'urgent 'data. options is an optional tcp header, which is enclosed by angle brackets (for example ,).
Src, dst, and flags must exist. Other domains output only necessary parts based on the tcp header content of the packet.
Below is the starting part from the host rtsg rlogin to the host csam.
The first line is to send a packet from tcp port 1023 of rtsg to the login port of csam. the S flag indicates that the SYN flag is set. the stream number of the message is 768512, with no data. (This is written as 'first: last (nbytes) ', which means 'user data with nbytes bytes from stream number first to last, not including last '.) there is no piggy-backed ack. the valid receiving window is 4096 bytes and there is a max-segment-size option, set mss to 1024 bytes for the request.
Csam responds in a similar way, but adds a token for rtsg SYN. then Rtsg confirms the SYN of csam. '. 'means no flag is set. this packet does not contain data, so there is no data stream number. note that the sequence number of this validation stream is a small integer (1 ). when tcpdump finds a tcp session for the first time, it displays the stream number carried by the packet. in the subsequently received message, it shows the difference between the current message and the stream sequence number of the original message. this means that starting from the first packet, the subsequent stream sequence numbers can be interpreted as the relative displacement as relative byte positions in the conversation's data stream (with the first data byte each direction being '1 '). the '-s' option can change this feature to directly display the original stream sequence number.
In row 6, rtsg transmits 19 bytes of data to csam (2 to 20 bytes ). the PUSH flag is set in the message. the seventh line of csam indicates that it has received rtsg data. The Byte number is 21, but it does not include 21st bytes. apparently, most of the data is in the buffer zone of the socket, because the receiving window of csam receives less than 19 bytes of data. at the same time, csam sends a byte of data to rtsg. lines 8 and 9 show that csam sent two bytes of emergency data to rtsg.
If the capture area is too small, so that tcpdump cannot capture the complete TCP header, tcpdump will try to translate the captured part, and then display ''[| tcp]'', it indicates that the remaining part cannot be translated. if the header contains a forged option (one with a length that's either too small or beyond the end of the header ), tcpdump displays ''[bad opt]'' and does not translate other options (because it cannot determine where to start ). if the header length indicates that there are options, but the IP datagram length is not enough, it is impossible to really save the options, tcpdump will display ''[bad hdr length]''.
UDP packets
The UDP format is shown in the following figure:
Actinide. who> broadcast. who: udp 84
That is to say, a udp datagram is sent from the who port of the host actinide to broadcast, and the who port of the Internet broadcast address. the packet contains 84 bytes of user data.
Some UDP services can identify (from the source destination port number) and display higher-level protocol information. in particular, domain name service requests (RFC-1034/1035) and nfs rpc calls (RFC-1050 ).
Name Server Requests)
(Note: The following description assumes that you are familiar with the domain name service agreement described in the RFC-1035. if you are not familiar with this agreement, the following content is like the book .)
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
