|
Introduction To put it simply, tcpdump is a packet analysis tool that dumps the traffic on a network and intercepts data packets on the network according to the user's definition. Tcpdump can completely intercept the "header" of the data packet transmitted in the network and provide analysis. It supports filtering for network layer, protocol, host, network or port, and provides logical statements such as and, or, not to help you remove useless information. Practical command examples Default startup Normally, starting tcpdump directly will monitor all packets flowing through the first network interface. Monitor packets on a specified network interface If you do not specify a network card, by default tcpdump will only monitor the first network interface, usually eth0. The following examples do not specify a network interface. Monitor packets from a specified host Print all packets entering or leaving sundown. You can also specify an IP address, for example, to capture all packets received and sent by the host at 210.27.48.1 Print the data packets between helios and hot or ace
tcpdump host helios and \( hot or ace \) Intercept the communication between host 210.27.48.1 and host 210.27.48.2 or 210.27.48.3
tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \) Prints IP packets between ace and any other hosts, but not helios.
tcpdump ip host ace and not helios If you want to obtain the IP packets of all hosts except host 210.27.48.2, use the command:
tcpdump ip host 210.27.48.1 and ! 210.27.48.2 Intercept all data sent by host hostname
tcpdump -i eth0 src host hostname
Monitor all packets sent to host hostname
tcpdump -i eth0 dst host hostname
Monitor packets from a specified host and port If you want to obtain the telnet packets received or sent by host 210.27.48.1, use the following command
tcpdump tcp port 23 and host 210.27.48.1
Monitor the local udp port 123. 123 is the service port of ntp Monitor packets on a specified network Print all communication packets between the local host and the host on the Berkeley network (nt: ucb-ether, here it can be understood as the network address of the 'Berkeley network', the most original meaning of this expression can be expressed as: Print all packets with the network address ucb-ether) Print all ftp packets passing through the gateway snup (note that the expression is enclosed in single quotes to prevent the shell from misinterpreting the brackets)
tcpdump 'gateway snup and (port ftp or ftp-data)'
Print all IP packets whose source or destination address is the local host (If the local network is connected to another network through a gateway, the other network cannot be counted as a local network. (nt: This sentence is inaccurate and needs to be supplemented). When localnet is actually used, it should be replaced with the name of the local network.)
tcpdump ip and not net localnet
Monitor packets of the specified protocol Print the start and end packets of a TCP session whose source or destination is not a host on the local network.
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'
Print all packets whose source or destination port is 80, whose network layer protocol is IPv4, and which contain data, rather than SYN, FIN, ACK-only, etc. (The IPv6 version of the expression can be used as an exercise)
tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
(nt: It can be understood that ip[2:2] represents the length of the entire ip data packet, (ip[0]&0xf)<<2) represents the length of the ip data packet header (ip[0]&0xf represents the IHL field in the packet, and the unit of this field is 32 bits. To get the number of bytes, multiply by 4, that is, shift left by 2. (tcp[12]&0xf0)>>4 indicates the length of the TCP header. The unit of this field is also 32 bits. The number of bits converted is ((tcp[12]&0xf0) >> 4) << ２,
That is, ((tcp[12]&0xf0)>>2). ((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0 means: the length of the entire IP packet minus the length of the IP header, minus
The length of the TCP header is not 0, which means that there is indeed data in the IP packet. For the IPv6 version, you only need to consider the difference between the 'Payload Length' in the IPv6 header and the 'Length of the TCP Header', and the expression 'ip[]' needs to be replaced with 'ip6[]'.) Print IP packets with a length of more than 576 bytes and a gateway address of snup
tcpdump 'gateway snup and ip[2:2] > 576'
Print all IP layer broadcast or multicast packets, but not physical Ethernet layer broadcast or multicast datagrams
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
Print ICMP packets other than 'echo request' or 'echo reply' packets (for example, this expression can be used to print all packets not generated by the ping program.
(nt: 'echo request' and 'echo reply' are two types of ICMP packets usually generated by the ping program))
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
tcpdump and wireshark Wireshark (formerly ethereal) is a very simple and easy-to-use packet capture tool under Windows. But it is difficult to find a good graphical packet capture tool under Linux.
Fortunately, there is Tcpdump. We can use the perfect combination of Tcpdump + Wireshark to achieve this: capture packets in Linux and then analyze the packets in Windows.
tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap
(1)tcp: ip icmp arp rarp and tcp, udp, icmp and other options should be placed in the first parameter position to filter the type of datagram
(2)-i eth1: only capture packets passing through interface eth1
(3)-t: Do not display timestamp
(4) -s 0: The default capture length when capturing data packets is 68 bytes. Add -S 0 to capture the complete data packet
(5) -c 100 : capture only 100 packets
(6)dst port ! 22: Do not capture packets with destination port 22
(7)src net 192.168.1.0/24: The source network address of the packet is 192.168.1.0/24
(8)-w ./target.cap: Save as cap file, convenient for analysis with ethereal (wireshark) Capture HTTP packets using tcpdump
tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854
0x4745 is the first two letters "GE" of "GET", and 0x4854 is the first two letters "HT" of "HTTP". tcpdump does not completely decode the intercepted data, and most of the content in the data packet is directly printed out in hexadecimal format. Obviously, this is not conducive to analyzing network failures. The usual solution is to first use tcpdump with the -w parameter to intercept data and save it to a file, and then use other programs (such as Wireshark) to decode and analyze it. Of course, filtering rules should also be defined to avoid the captured data packets filling up the entire hard disk. Output information meaning First of all, let's note that the general output format of tcpdump is: system time source host.port > target host.port data packet parameters The output format of tcpdump is protocol-dependent. The following is a brief description of the most commonly used formats and related examples. Link layer header For FDDI networks, '-e' causes tcpdump to print the 'frame control' field, source and destination addresses, and length of the specified packet. (The frame control field controls the interpretation of the other fields in the packet.) Normal packets (such as those of IP datagrams) are packets with the 'async' flag set, and have a priority value from 0 to 7;
For example, 'async4' means that this packet is an asynchronous data packet with a priority of 4. It is generally believed that these packets contain an LLC packet (Logical Link Control packet); at this time, if this packet is not an ISO datagram or a so-called SNAP packet, its LLC header will be printed (nt: it should refer to the LLC packet header contained in this packet). For Token Ring networks, '-e' causes tcpdump to print out the 'frame control' and 'access control' fields of the specified packet, as well as the source and destination addresses.
plus the length of the packet. Similar to FDDI networks, this packet usually contains LLC packets. Regardless of whether the '-e' option is used. For 'source-routed' type packets on this network (nt:
The source address of the data packet is tracked, the specific meaning is unknown and needs to be supplemented), and the source routing information of the packet will always be printed. For 802.11 networks (WLAN, wireless local area network), '-e' causes tcpdump to print the frame control field of the specified packet.
The packet header contains all addresses and the length of the packet. Similar to FDDI networks, this packet usually contains an LLC packet. (Note: The following description assumes that you are familiar with the SLIP compression algorithm (nt: SLIP stands for Serial Line Internet Protocol.), which can be found in
Relevant clues can be found in RFC-1144.) For SLIP networks (nt:SLIP links, which can be understood as a network, that is, a connection established through a serial line, and a simple connection can also be regarded as a network),
The packet's 'direction indicator' ("I" for in, "O" for out), type, and compression information are printed. The packet type is printed first. Types are ip, utcp and ctcp (nt: unknown, to be added). For ip packets, connection information will not be printed (nt: on SLIP connections, the connection information of ip packets may be useless or undefined.
reconfirm). For TCP packets, the connection identifier is printed followed by the type. If the packet is compressed, the encoded header is printed.
At this time, for a special compressed package, it will be displayed as follows:
*S+n or *SA+n, where n represents the number of packets (sequence number or (sequence number and acknowledgment number)) that are increased or decreased (nt | rt: S, SA is difficult to pronounce and needs to be translated).
For non-special archives, 0 or more 'changes' will be printed. 'Changes' are printed in the following format:
'Flags' +/-/=n Packet data length Compressed header length.
Where 'flag' can take the following values:
U (urgent pointer), W (buffer window), A (acknowledgement), S (sequence number), I (packet ID), and the incremental expression '=n' indicates that a new value is assigned, and +/- indicates increase or decrease. For example, the following shows the printing of an outgoing compressed TCP packet, which contains an implicit connection identifier; the acknowledgment number is incremented by 6,
The sequence number increases by 49, the packet ID increases by 6; the packet data length is 3 bytes (octect), and the compressed header is 6 bytes. (nt: So it seems that this should not be a special compressed data packet). ARP/RARP Packets The output information of tcpdump for Arp/rarp packets will include the request type and the parameters corresponding to the request. The display format is concise and clear. The following is an 'rlogin' from host rtsg to host csam
A sample packet at the beginning of the (remote login) process:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
The first line indicates that rtsg sent an arp packet (nt: sent to the entire network segment, arp packet) to inquire about the Ethernet address of csam
Csam responded with her own Ethernet address (in this case, Ethernet addresses are identified by capitalized names, while internet
The address (i.e. IP address) is identified by all lowercase names). If you use tcpdump -n, you can clearly see the Ethernet and IP addresses instead of name identifiers:
arp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4 If we use tcpdump -e, we can clearly see that the first packet is broadcast to the entire network, while the second packet is point-to-point:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: arp reply csam is-at CSAM
The first data packet shows that the source Ethernet address of the arp packet is RTSG, the destination address is the entire Ethernet segment, and the value of the type field is hexadecimal 0806 (indicating ETHER_ARP (nt: arp packet type identifier)).
The total length of the packet is 64 bytes. TCP Packets (Note: The following assumes that you are familiar with TCP as described in RFC-793. If you are not, the following description and the tcpdump program may not be of much help to you. (nt: Warnings can be ignored,
Just keep watching, and come back to see the parts you are not familiar with.). Usually tcpdump displays tcp packets in the following format:
src > dst: flags data-seqno ack window urgent options src and dst are the source and destination IP addresses and their corresponding ports. flags consists of S(SYN), F(FIN), P(PUSH, R(RST),
W(ECN CWT(nt | rep: unknown, to be supplemented)) or E(ECN-Echo(nt | rep: unknown, to be supplemented)),
A single '.' indicates that there is no flags identifier. The data segment sequence number (Data-seqno) describes a position in the sequence number space corresponding to the data in this packet (nt: the entire data is segmented,
Each segment has a sequence number, and all sequence numbers form a sequence number space (see the following example). Ack describes the next segment that the local end should receive in the same connection and direction.
The sequence number of the data fragment (that the other party should send). Window is the size of the data receiving buffer available on this end (and the data should be organized according to this size when the other party sends data).
Urg (urgent) indicates that there is urgent data in the data packet. options describes some TCP options, which are expressed in angle brackets (such as <mss 1024>). The src, dst and flags fields are always displayed. The other fields may or may not be displayed depending on the information in the TCP protocol header. This is the beginning of an rlogin application login from trsg to csam.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023>csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
The first line indicates that a data packet was sent from TCP port 1023 of the rtsg host to TCP port login of the csam host (nt: the udp protocol port and the tcp protocol port are two separate spaces, although the value range is the same). S indicates that the SYN flag is set. The sequence number of the packet is 768512, and it contains no data. (The format is: 'first:last(nbytes)', which means 'the sequence number of the data in this packet starts from first and ends at last, excluding last. And it contains a total of nbytes of user data'.) There is no piggyback response (nt: from the following text, the second line is the data packet with a piggyback response), the available receive window size is 4096 bytes, and the requesting end (rtsg)
The maximum acceptable data segment size is 1024 bytes (nt: This information is sent to the responding end csam as a request for further negotiation between the two parties). Csam responds to rtsg with a similar SYN packet, except for a piggy-backed ack. rtsg also responded to csam's SYN packet with an ACK packet as a response. '.' means that no flag is set in this packet. Since this response packet does not contain data, there is no data segment sequence number in the packet. Reminder! The sequence number of this ACK packet is just a small integer 1. There is the following explanation: For a session on a tcp connection, tcpdump only prints the sequence number of the initial data packet at both ends of the session, and the subsequent corresponding data packets only print the difference with the initial packet sequence number. That is, the sequence number after the initial sequence number can be regarded as the 'relative byte' position of the data segment currently transmitted on this session in the entire data to be transmitted (nt: the first position of both sides is 1, that is, the starting number of the 'relative byte'). '-S' will override this function,
Causes the original sequence numbers of packets to be printed. The meaning of the sixth line is: rtsg sent 19 bytes of data to csam (bytes are numbered 2 to 20, and the transmission direction is rtsg to csam). The PUSH flag is set in the packet. In line 7,
csam shouts that she has received bytes from rtsg up to, but not including, byte number 21. These bytes are stored in the receive buffer of csam's socket. Accordingly,
The receive buffer window size of csam will be reduced by 19 bytes (nt: can be seen from the change of win attribute value in lines 5 and 7). csam also sends one byte to rtsg in this packet in line 7. In lines 8 and 9, csam continues to send two data packets containing only one byte to rtsg, and this data packet has the PUSH flag. If the captured TCP packet (nt: snapshot here) is too small, so that tcpdump cannot get its header data completely, then tcpdump will try to parse the incomplete header.
The remaining unparsed part is displayed as '[|tcp]'. If the header contains false attribute information (for example, its length attribute is actually longer or shorter than the actual length of the header), tcpdump will display '[bad opt]' for the header. If the length of the header tells us that some options (nt | rt: from the following text, it refers to some options in the header of the TCP packet for the IP packet, which will be translated later) are in this packet,
The length of the real IP packet is not enough to accommodate these options, and tcpdump will display '[bad hdr length]'. Capture TCP packets with special flags (such as SYN-ACK flag, URG-ACK flag, etc.). In the TCP header, there are 8 bits used as control bit area, and its value is:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt: From the expression, we can infer that these 8 bits are combined in an OR manner, which can be turned back later) Now suppose we want to monitor the data packets generated during the entire process of establishing a TCP connection. Recall that TCP uses the three-way handshake protocol to establish a new connection; the data packets corresponding to this three-way handshake connection sequence and with the corresponding TCP control flags are as follows:
1) The connection initiator (nt:Caller) sends a packet with the SYN flag
2) The receiver (nt: Recipient) responds with a packet with SYN and ACK flags
3) After receiving the response from the receiver, the initiator sends a data packet with an ACK flag in response
0 15 31
-----------------------------------------------------------------
| source port | destination port |
-----------------------------------------------------------------
|sequence number |
-----------------------------------------------------------------
| acknowledgment number |
-----------------------------------------------------------------
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
-----------------------------------------------------------------
| TCP checksum | urgent pointer |
-----------------------------------------------------------------
A TCP header, without option data, usually takes up 20 bytes (nt | rt:options is understood as option data and needs to be translated back). The first line contains bytes numbered 0 to 3,
The second line contains bytes numbered 4-7. If the numbering starts from 0, the TCP control flag is located in byte 13 (nt: the left half of the fourth line). 0 7| 15| 23| 31
----------------|---------------|---------------|----------------
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
----------------|---------------|---------------|----------------
| | 13th octet | | |
Let's take a closer look at byte number 13: | |
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
Here are the control flags we are interested in. From right to left the bits are numbered 0 to 7, so PSH is number 3 and URG is number 5.
Remind yourself that we only want packets that have the SYN flag set. Let's look at what happens in byte 13 of a packet header if the SYN bit is set: |C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
In the data of the control segment, only bit 1 (bit number 1) is set. Assuming that byte number 13 is an 8-bit unsigned char type and is sorted by network byte number (nt: for a byte, the network byte order is equivalent to the host byte order), its binary value is as follows:
00000010 And its decimal value is: 0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2 (nt: 1 * 2^6 means 1 times 2 to the sixth power, maybe it is clearer this way, that is, the exponents 7 6 ... 0 in the original expression are moved to the bottom to express it) We are getting closer to our goal, because we already know that if the SYN bit in the packet header is set, then the value of the 13th byte in the header is 2 (nt: in network order, i.e. big-endian mode, the most important byte is at the front (in front, that is, the actual memory address of the byte is relatively small, the most important byte refers to the high bit of the number in the mathematical representation, such as 3 in 356)). The relationship expressed as a formula that tcpdump can understand is:
tcp[13] 2 Therefore, we can use this relationship as a filter condition for tcpdump, the goal is to monitor only packets containing the SYN flag:
tcpdump -i xl0 tcp[13] 2 (nt: xl0 refers to the network interface, such as eth0) This expression says "let byte 13 of the TCP packet have the value 2", which is what we want.
Now, suppose we need to capture packets with the SYN flag, regardless of whether it contains other flags. (nt: as long as it contains SYN, we want it). Let's see what happens when a packet contains
What happens when a SYN-ACK packet (nt: both SYN and ACK flags) arrives:
|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 1 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
Bits 1 and 4 of byte 13 are set, and their binary values are:
00010010 Converted to decimal: 0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18 (nt: 1 * 2^6 means 1 times 2 to the sixth power, maybe it is clearer this way, that is, the exponents 7 6 ... 0 in the original expression are moved to the bottom to express it) Now, we cannot use only 'tcp[13] 18' as the filter expression for tcpdump, because this will result in only packets with the SYN-ACK flag being selected, and all others will be discarded.
Remind yourself that our goal is to only have the SYN flag set on the packet, and ignore any other flags. To achieve our goal, we need to AND the binary value of byte 13 with another number to get the value of the SYN bit. The goal is: as long as SYN is set, so we AND it with the SYN value of byte 13 (nt: 00000010). 00010010 SYN-ACK 00000010 SYN
AND 00000010 (we want SYN) AND 00000010 (we want SYN)
-------- --------
= 00000010 = 00000010
We can see that regardless of whether the packet's ACK or other flags are set, the AND operation above will give us the same value, which is 2 in decimal (00000010 in binary).
So we know that for packets with the SYN flag, the following expression always evaluates to true: ( ( value of octet 13 ) AND ( 2 ) ) ( 2 ) (nt: value of octet 13, i.e. the value of byte 13) Inspiration followed, and we got the following tcpdump filter expression
tcpdump -i xl0 'tcp[13] & 2 2' Note that the single quotes or backslashes (nt: single quotes are used here) cannot be omitted, which prevents the shell from interpreting or replacing &. UDP Packets The display format of UDP data packets can be illustrated by the data packets generated by the specific application rwho:
actinide.who > broadcast.who:udp 84 This means: port who on the actinide host sent a UDP packet to port who on the broadcast host (nt: actinide and broadcast both refer to Internet addresses).
This packet carries 84 bytes of user data. Some UDP services can be identified from the source or destination port of the packet, or from the higher-level protocol information displayed. For example, Domain Name service requests (DNS requests,
in RFC-1034/1035), and Sun RPC calls to NFS (the remote calls initiated by the NFS server (nt: Sun RPC), which are described in RFC-1050). UDP Name Service Request (Note: The following description assumes that you are familiar with the Domain Service protocol described in RFC-103. Otherwise, you may find that the following description is incomprehensible.
Don't pay attention to it, it's just to scare you, just keep watching)) Name service requests have the following format:
src > dst: id op? flags qtype qclass name (len)
(nt: From the following text, the format should be src > dst: id op flags qtype qclass? name (len))
For example, there is an actual display of:
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) The host h2opolo queries the name server running on helios for the address record of ucbvax.berkeley.edu (nt: qtype equals A). The query itself has an id of '3'. Symbol
'+' means the recursive query flag is set (nt: the dns server can query the higher-level dns server for address records that the server does not contain). The query request data sent via the IP packet is 37 bytes long, excluding the header data of the UDP and IP protocols. Because this query operation is the default value (nt | rt: normal one), the op field is omitted.
If the op field is not omitted, it will be displayed between '3' and '+'. Likewise, qclass is the default value, C_IN, and is not displayed either. If it is not omitted, it will be displayed after 'A'. The exception check will show additional fields in square brackets: If a query also includes a response (nt: can be understood as a response to a previous request), and this response contains authoritative or additional records segments,
ancount, nscout, arcount (nt: specific field meaning to be supplemented) will be displayed as '[na]', '[nn]', '[nau]', where n represents the appropriate count. If the following response bits in the packet (such as AA bit, RA bit, rcode bit), or any 'must be 0' bit in byte 2 or 3 is set (nt: set to 1), '[b2&3]=x' will be displayed, where x represents the value after the header byte 2 and byte 3 are ANDed. UDP Name Service Reply For name service reply packets, tcpdump will have the following display format
src > dst: id op rcode flags a/n/au type class data (len)
For example, the specific display is as follows:
helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97) The first line indicates that helios responded to query request No. 3 sent by h2opolo with 3 answer records (nt | rt: answer records), 3 name server records,
and 7 additional records. The first answer record (nt: the first of 3 answer records) is of type A (nt: stands for address) and its data is the internet address 128.32.137.3.
This response UDP packet contains 273 bytes of data (excluding UDP and IP header data). The op field and rcode field are ignored (nt: the actual value of op is Query, rcode, i.e.
The actual value of response code is NoError). The class field is also ignored (nt | rt: its value is C_IN, which is also the default value of A type record) The second line indicates that helios responded to query request No. 2 sent by h2opolo. In the response, the rcode is NXDomain (nt: indicates a non-existent domain), and there is no answer record.
But it contains a name server record, but not an authority server record (nt | ck: From the above, the authority records here are the corresponding additional
records). '*' indicates that the authoritative server answer flag is set (nt: so that additional records indicate authority records).
Since there is no answer record, the type, class, and data fields are ignored. The flag field may contain other characters, such as '-' (nt: indicates recursive query, i.e. RA flag is not set), '|' (nt: indicates truncated message, i.e. TC flag is set). If the 'question' segment of the reply does not contain any entries (nt: the meaning of each entry, need to be supplemented), '[nq]' will be printed. Note that name server requests and replies are large, and the default snaplen of 68 bytes may not be enough to capture the entire packet. If you really need to see the name server load, increase the snaplen value with the -s option to tcpdump. SMB/CIFS decoding tcpdump can now decode the contents of packets for SMB/CIFS/NBT related applications (nt: 'Server Message Block Common', 'Internet File System'
'Short for NETBIOS, a network protocol implemented on top of TCP/IP'. These services usually use UDP ports 137/138 and TCP port 139). The original decoding capabilities for IPX and NetBEUI SMB packets can still be used (nt: NetBEUI is an enhanced version of NETBIOS). By default, tcpdump only decodes the corresponding data packets in the most concise mode. If we want detailed decoding information, we can use its -v startup option. It should be noted that -v will produce very detailed information.
For example, a single SMB packet will generate a screenful or more of information, so this option should only be used when necessary. Information about the SMB packet format, and the meaning of each field can be found at www.cifs.org or the pub/samba/specs/ directory of a samba.org mirror site. SMB patches for linux
(nt | rt: patch) Contributed by Andrew Tridgell ([email protected]). NFS requests and responses tcpdump prints out the following format for Sun NFS (Network File System) request and response UDP packets:
src.xid > dst.nfs:len op args
src.nfs > dst.xid: reply stat len op results The following is a set of specific output data
sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
sushi.201b > wrl.nfs:
144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
reply ok 128 lookup fh 9,74/4134.3150 The first line of output shows that the host sushi sent a 'transaction request' (nt: transaction) to the host wrl. The id of this request is 6709 (note that the host name is followed by the transaction id number, not the source port number). The request data is 112 bytes, which does not include the length of the UDP and IP headers. The operation type is readlink (nt: this operation is a symbolic link read operation).
The operation parameters are fh 21,24/10.73165 (nt: can be interpreted as follows according to the actual operating environment, fd means the file handle is described, 21,24 means the master/slave device number pair of the device corresponding to this handle, 10 means the i-node number corresponding to this handle (nt: each file will correspond to an i-node in the operating system, limited to Unix-like systems),
73165 is a number (nt: can be understood as a random number to identify this request, the specific meaning needs to be supplemented)). In the second line, wrl responds with 'ok' and returns the actual directory of the symbolic link that sushi wants to read in the results field. The third line shows that sushi again requests wrl to search for the 'xcolors' file in the directory described by 'fh 9,74/4096.6878'. It should be noted that the meaning of the data displayed in each line depends on the type of the op field (nt: different ops have different meanings of args). Its format follows the NFS protocol and is concise and clear. If the -v option (verbose printing option) of tcpdump is set, additional information will be displayed. For example:
sushi.1372a > wrl.nfs:
148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
reply ok 1472 read REG 100664 ids 417/0 sz 29388 (The -v option would normally also print the TTL, ID, length, and fragmentation fields of the IP header, but they are omitted in this example.)
In the first line, sushi asks wrl to read 8192 bytes of data from file 21,11/12.195 (nt: format described above), starting at offset 24576 bytes.
Wrl responds to read successfully; since the second line is just the beginning of the response request, it only contains 1472 bytes (the rest of the data will come in the following reply segments, but these packets will no longer have NFS
header, even the UDP header information is empty (nt: source and destination should be present), which will cause these fragments to fail to meet the filtering conditions and thus not be printed). In addition to displaying file data information, the -v option will also display additional file attribute information: file type (file type, ''REG'' means ordinary file), file mode (file access mode, expressed in octal), uid and gid (nt: file owner and group owner), file size (file size). If the -v flag is given multiple times (e.g. -vv), tcpdump will display more detailed information. It must be noted that NFS request packets contain a lot of data. If the tcpdump snaplen (nt: capture length) is too short, detailed information cannot be displayed. You can use
'-s 192' to increase snaplen, which can be used to monitor the network load (nt: traffic) of NFS applications. NFS response packets do not strictly follow the previous corresponding request packets (nt: RPC operation). Therefore, tcpdump will track the most recently received series of request packets and then match them with the corresponding request packets by their exchange sequence numbers (nt: transaction ID). This may cause a problem if the response packet comes too late and is beyond the tracking range of tcpdump's corresponding request packets.
The response packet cannot be parsed. AFS Requests and Responses AFS (nt: Andrew File System, Transarc, unknown, to be supplemented) requests and responses have the following promises src.sport > dst.dport: rx packet-type
src.sport > dst.dport: rx packet-type service call call-name args
src.sport > dst.dport: rx packet-type service reply call-name args elvis.7001 > pike.afsfs:
rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
new fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs reply rename In the first line, the host elvis sends an RX packet to pike.
This is a request packet for file service (nt: RX data packet, send data packet, can be understood as sending a packet to request the other party's service), which is also an RPC
The start of a call (nt: RPC, remote procedure call). This RPC requests pike to perform a rename (nt: rename) operation and specifies the relevant parameters:
The original directory descriptor is 536876964/1/1, the original file name is '.newsrc.new', the new directory descriptor is 536876964/1/1, and the new file name is '.newsrc'.
The host pike responds to the RPC request for the rename operation (the response indicates that the rename operation is successful because the response is a packet containing data content rather than an abnormal packet). Generally speaking, all 'AFS RPC' requests are given a name (nt: decode) when they are displayed. This name is often the operation name of the RPC request.
In addition, some parameters of these RPC requests will be given a name when displayed (nt | rt: decode, decoding, generally speaking, the naming is also very direct, for example,
An interesting parameter will be displayed as 'interesting', which is difficult to pronounce and needs to be translated). This display format is designed to be "easy to understand at a glance", but it may not be very useful for people who are not familiar with how AFS and RX work (nt: just ignore it, it's just to scare you, just read on). If the -v (verbose) flag is given repeatedly (nt: like -vv), tcpdump will print out the confirmation packets (nt: can be understood as packets that are different from the reply packets) and additional header information.
(nt: can be understood as all packets, not just the additional header information of the confirmation packet), for example, RX call ID (the ID of the 'request call' in the request packet),
call number ('call request' number), sequence number (nt: packet sequence number),
serial number (nt | rt: can be understood as another serial signal related to the data in the packet, the specific meaning needs to be supplemented), the identifier of the request packet. (nt: the next paragraph is a repeated description,
Therefore, it is omitted), and the MTU negotiation information in the confirmation packet will also be printed out (nt: the confirmation packet is the confirmation packet relative to the request packet, Maximum Transmission Unit). If the -v option is repeated three times (nt: like -vvv), the 'security index' and 'service id' of the AFS application type packet will be printed. For packets indicating an exception (nt: abort packet, which can be understood as a packet used to notify the receiver that an exception has occurred), tcpdump will print out error codes.
But for Ubik beacon packets (nt: Ubik beacon indication packet, Ubik can be understood as a special communication protocol, beacon packets, beacon data packets, can be understood as some data packets indicating key information in communication), the error number will not be printed, because for the Ubik protocol, abnormal data packets do not indicate errors, but rather indicate a positive response (nt: that is, a yes vote). AFS requests are large in size and have many parameters, so a larger snaplen is required for tcpdump. This can be increased by starting tcpdump with the option '-s 256' to monitor the AFS application communication load. AFS response packets do not indicate which remote call the RPC belongs to. Therefore, tcpdump will track the request packets in the recent period of time and use the call number, service ID
(service index) to match the received response packet. If the response packet is not for the request packet within the recent period of time, tcpdump will not be able to parse the packet. KIP AppleTalk Protocol (nt | rt: DDP in UDP can be understood as, DDP, The AppleTalk Data Delivery Protocol,
It is equivalent to the network layer protocol that supports the KIP AppleTalk protocol stack, and DDP itself is transmitted via UDP.
That is, the network layer implemented on UDP for other networks, KIP AppleTalk is a complete network protocol stack developed by Apple). AppleTalk DDP packets are encapsulated in UDP packets, and their decapsulation (nt: equivalent to decoding) and dumping of corresponding information also follow the DDP packet rules.
(nt:encapsulate, encapsulate, equivalent to encoding, de-encapsulate, decapsulate, equivalent to decoding, dump, dump, usually refers to printing its information). The /etc/atalk.names file contains the mapping of the numerical identifiers of AppleTalk networks and nodes to their names. The file format is usually as follows:
number name 1.254 ether
16.1 icsd-net
1.254.110 ace The first two lines indicate that there are two AppleTalk networks. The third line gives the hosts on a particular network (a host is identified by 3 bytes,
The identifier of a network is usually only two bytes, which is the main difference between the two identifiers) (nt: 1.254.110 can be understood as an ace host on the ether network).
The identifier and its corresponding name must be separated by a space. In addition to the above, /etc/atalk.names also contains blank lines and comment lines (lines starting with '#'). The full AppleTalk network address will be displayed in the following format:
net.host.port The following is a specific display:
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2
(If the /etc/atalk.names file does not exist, or has no entry for the corresponding AppleTalk host/network, the packet's network address will be displayed numerically.) In the first line, node 209 on network 144.1 sends an NBP application packet through port 2 to node 112 listening on port 220 on network icsd-net.
(nt | rt: NBP, name binding protocol, from the data, the NBP server will provide this service on port 2.
'DDP port 2' can be understood as 'DDP corresponding to the transport layer port 2'. DDP itself does not have the concept of ports. This point is not confirmed and needs to be supplemented). The second line is similar to the first line, except that the entire address of the source is identified by 'office'.
The third line indicates that node 149 on the jssmag network sent a data packet to port 2 (NBP port) of all nodes on the icsd-net network via port 235. (Note that
In AppleTalk networks, if an address does not contain a node, it is a broadcast address, so node identifiers and network identifiers are best distinguished in /etc/atalk.names.
nt: Otherwise, a flag x.port cannot determine whether x refers to the port of all hosts on a network or the port of a specific host x). tcpdump can parse NBP (Name Binding Protocol) and ATP (AppleTalk Transport Protocol) packets. For other application layer protocols, only the corresponding protocol name (
If the protocol has not been registered with a common name, only the protocol number and packet size are printed. NBP packets will be displayed in the following format:
icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186
The first line indicates that node 112 in the icsd-net network sent a name query request for 'LaserWriter' through port 220 to port 2 of all nodes in the jssmag network (nt:
Here, name can be understood as the name of a resource, such as a printer). The serial number of this query request is 190. The second line indicates that node 209 in the network jssmag responded to port 220 of the icsd-net.112 node through port 2: I have a 'LaserWriter' resource, whose resource name is 'RM1140', and I provide this resource service on port 250. The sequence number of this response is 190, which corresponds to the sequence number queried previously. The third line is also a response to the first line request: the node techpit responded to port 220 of the icsd-net.112 node through port 2: I have a 'LaserWriter' resource, whose resource name is 'techpit', and it is provided on port 186. The sequence number of this response is 190, which corresponds to the sequence number queried previously. The display format of ATP data packets is as follows jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002
The first line indicates that the node Jssmag.209 sent a request packet with session number 12266 to the node helios, requesting helios
Reply 8 packets (the sequence numbers of these 8 packets are 0-7 (nt: the sequence number is different from the session number, which is the number of a complete transmission,
The former is the number of each data packet in the transmission. The hexadecimal number at the end of the line represents the value of the 'userdata' field in the request packet (nt: from the following text, this does not print out all user data). Helios responds with eight 512-byte packets. The number following the session number (nt: 12266) indicates the sequence number of the packet within the session.
The number in brackets indicates the size of the data in the packet, which does not include the ATP header. In the packet with sequence number 7 (line 8), there is a '*' sign outside.
Indicates that the EOM flag of the data packet is set. (nt: EOM, End Of Media, can be understood as, indicating that the data response of a session is completed). The next line 9 indicates that Jssmag.209 made another request to helios: Please resend the packets with sequence numbers 3 and 5. After receiving this request, Helios resent the two packets. After receiving the two packets again, jssmag.209 actively ended (released) the session. In the last line, jssmag.209 sends a request packet to helios to start the next session. The '*' in the request packet indicates that the XO flag of the packet is not set.
(nt: XO, exactly once, can be understood as in this session, the data packet is processed exactly once at the receiving end, even if the other party repeats the data packet,
The receiver will only process it once, which requires a specially designed packet receiving and processing mechanism). IP packet fragmentation (nt: refers to dividing an IP data packet into multiple IP data packets) Fragmented IP packets (nt: small IP packets generated after a large IP packet is broken) have the following two display formats.
(frag id:size@offset+)
(frag id:size@offset)
(The first format indicates that there are subsequent fragments after this fragment. The second format indicates that this fragment is the last fragment.) id represents the fragmentation number (nt: from the following text, each large IP packet to be fragmented will be assigned a fragmentation number to distinguish whether each small fragment is fragmented from the same data packet).
size indicates the size of this fragment, excluding the fragment header data. offset indicates the offset of the data contained in this fragment in the original entire IP packet (nt: From the following,
An IP packet is fragmented as a whole, including header and data, not just the data). Each fragment will cause tcpdump to generate corresponding output. The first fragment contains the header data of the high-level protocol (nt: from the following, the corresponding TCP header and
The IP header is placed in the first fragment), so tcpdump will display this information for the first fragment, followed by the fragment itself. Some subsequent fragments do not contain the higher-level protocol header information, so only the fragment itself is displayed after the source and destination. Here is an example: This is a packet from arizona.edu to lbl-rtsg.arpa
The ftp application communication fragment via the CSNET network (nt: CSNET connection can be understood as a connection established on the CSNET network):
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560 A few points worth noting:
In the first and second lines of printing, there is no port number after the address.
This is because the TCP protocol information is placed in the first fragment. When the second fragment is displayed, we cannot know the sequence number of the TCP packet corresponding to this fragment. Second, from the first line, we can see that arizona needs to send 308 bytes of user data to rtsg, but the fact is that the corresponding IP packet will generate a total of 512 bytes of data after fragmentation (the first fragment contains 308 bytes of data, and the second fragment contains 204 bytes of data, which is more than 308 bytes). If you are looking for some holes in the sequence number space of the data packets, the number 512 is enough to confuse you for a while (in fact, just focus on 308,
Don’t worry about the total amount of data after fragmentation). If a data packet (nt | rt: refers to an IP data packet) has a non-IP fragmentation flag, it will be displayed with '(DF)' at the end. (nt: means that this IP packet has not been fragmented). Timestamp By default, all tcpdump output lines will include timestamp information.
The display format of timestamp information is as follows
hh:mm:ss.frac (nt: hour:minute:second. (nt:frac unknown, need to be supplemented))
The precision of this timestamp is consistent with the kernel time precision, reflecting the time when the kernel first saw the corresponding data packet (nt: saw, which means the data packet can be operated).
The time it takes for the data packet to be transferred from the physical line to the kernel, as well as the time the kernel spends processing interrupts on this packet, are not taken into account. Command Usage Tcpdump uses the command line method, and its command format is:
tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ] [ -C file_size ] [ -F file ] [ -i interface ] [ -m module ] [ -M secret ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] [ -E spi@ipaddr algo:secret,... ] [ -y datalinktype ] [ -Z user ] [ expression ] A brief introduction to tcpdump options
: : : : : : : : : : : : : : : tcpdump conditional expressions This expression is used to determine which packets will be printed. If no conditional expression is given, all captured packets on the network will be printed, otherwise, only packets that meet the conditional expression will be printed. (nt: all packets, which can be understood as all packets captured by the specified interface). An expression consists of one or more primitives. A primitive is usually composed of one or more qualifiers followed by a name or numeric id. There are three different types of qualifiers: type, dir, and proto.
: : : : : : : : : : : : : : : In addition to the primitives described above, there are other forms of primitives, and they are different from the above expression formats. For example: gateway, broadcast, less, greater and arithmetic expressions (nt: each of which is considered a new type of primitive). These primitives will be explained below. Expression elements can also be connected by the keywords and, or and not to form more complex conditional expressions. For example, `host foo and not port ftp and not port ftp-data' (nt: the filter condition can be understood as the host of the data packet is foo, and the port is not ftp (port 21) and ftp-data (port 20, the correspondence between common ports and names can be found in the /etc/service file in the Linux system)). For convenience, the same modifier can be omitted, such as 'tcp dst port ftp or ftp-data or domain' has the same meaning as the following expression 'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'. (nt: The filtering condition can be understood as, the protocol of the packet is tcp, the destination port is ftp or ftp-data or domain (port 53)). With the help of brackets and corresponding operators, expressions can be combined and used together (because brackets are special characters of the shell, they must be escaped when used in shell scripts or terminals, that is, '(' and ')' need to be expressed as '\(' and '\)' respectively). Valid operators are:
Negation (`!' or `not')
AND operator (`&&' or `and')
Or operation (`||' or `or') The negation operator has the highest precedence. It has the same precedence as the AND and OR operators, and the order of combining the two is from left to right. It should be noted that when expressing the AND operator, The 'and' operator needs to be written explicitly, rather than just placing the preceding and following expressions side by side (nt: the 'and' operator between the two cannot be omitted). If there is no keyword before an identifier, the most recently used keyword during expression parsing (usually the keyword closest to the identifier from left to right) will be used. For example,
not host vs and ace
is a simplification of the following expression:
not host vs and host ace
Instead of not (host vs or ace). (nt: The first two indicate that the required data packet is not from or sent to host vs, but from or sent to ace. The latter indicates that the data packet meets the requirements as long as it is not from or sent to vs or ac) The entire conditional expression can be passed to tcpdump as a single string argument or as multiple arguments separated by spaces, whichever is more convenient. In general, if the expression contains metacharacters (such as '*', '.' in regular expressions, and '(' in shell scripts), it is better to pass it as a single string. In this case, the entire expression should be enclosed in single quotes. When passing multiple arguments, all the arguments are finally concatenated by spaces and parsed as a single string. Appendix: tcpdump expression elements (nt: True in the following description means: the corresponding conditional expression contains only one of the following specific expression elements, then the expression is true, that is, the condition is satisfied) dst host host
True if the destination field of the IPv4/v6 packet is host. Host can be an IP address or a host name.
src host host
True if the source field of the IPv4/v6 packet is host.
host can be an IP address or a host name.
host host
If the source or destination address of the IPv4/v6 packet is host, then the corresponding conditional expression is true. The above host expressions can be preceded by the following keywords: ip, arp, rarp, and ip6. For example:
ip host host
It can also be expressed as:
ether proto \ip and host host (nt: This expression is explained below, where the \ before ip is needed to escape it because ip is already a keyword for tcpdump.)
If host is a host with multiple IP addresses, any one of them will be used for packet matching (nt: the destination address of the data packet sent to the host can be any of these IP addresses, and the source address of the data packet received from the host can also be any of these IP addresses).
ether dst ehost
True if the Ethernet destination address of the packet is ehost. Ehost can be a name in the /etc/ethers file or a numeric address.
ether src ehost
True if the Ethernet source address of the packet is ehost.
ether host ehost
True if the packet's Ethernet source or destination address is ehost.
gateway host
True if the packet's gateway address is host. Note that the gateway address here is an Ethernet address, not an IP address (nt | rt: Ie, for example, can be understood as 'note'. The Ethernet source or destination address, Ethernet source and destination address, can be understood as, referring to the 'gateway address' in the previous sentence). host must be a name, not a number, and must have an entry in the machine's 'host name-IP address' and 'host name-Ethernet address' mappings (the former mapping can be obtained through the /etc/hosts file, DNS or NIS, and the latter mapping can be obtained through the /etc/ethers file. nt: /etc/ethers does not necessarily exist, you can see its data format through man ethers, how to create this file, unknown, need to be supplemented). That is to say, host means ether host ehost, not host host, and ehost must be a name, not a number.
Currently, this option does not work in configuration environments that support IPv6 address formats (nt: configuration, which can be understood as the network configuration of both parties in communication).
dst net net
True if the network field of the packet's destination address (IPv4 or IPv6 format) is net.
net can be a name from the network database file /etc/networks, or a numeric network number.
A numeric IPv4 network number shall be expressed as a dotted quad (e.g., 192.168.1.0), or a dotted triple (e.g., 192.168.1), or a dotted double (e.g., 172.16), or a singleton (e.g., 10);
The network masks for these four cases are: 4-tuple: 255.255.255.255 (this also means that the match on net is the same as the match on host address: all four parts of the address are used), 3-tuple: 255.255.255.0, 2-tuple: 255.255.0.0, 1-tuple: 255.0.0.0.
For IPv6 address format, the network number must be written in full (all 8 parts must be written); the corresponding network mask is:
ff:ff:ff:ff:ff:ff:ff:ff, so the IPv6 network match is a true 'host' match (nt | rt | rc: all 8 parts of the address are used, and the bytes that do not belong to the network are filled with 0, which needs to be supplemented next), but a network mask length parameter is also required to specify how many of the first bytes are the network mask (nt: can be specified by net net/len below)
src net net
True if the network field of the source IPv4 or IPv6 address of the packet is net.
net net
True if the network field of the source or destination address (IPv4 or IPv6 format) of the packet is net.
net net mask netmask
True if the network mask of the source or destination address (IPv4 or IPv6 format) of the packet matches netmask. This option can also be used with src and dst to match the source or destination network address (nt: for example src net net mask 255.255.255.0). This option has no effect on ipv6 network addresses.
net net/len
True if the source or destination IPv4 or IPv6 address has the same number of network bits as len. This option can also be used with src and dst to match the source or destination network address (nt | rt | tt: src net net/24, which means that the source address has a 24-bit network number).
dst port port
True if the packet (of ip/tcp, ip/udp, ip6/tcp or ip6/udp protocols) has a destination port of port. port can be a number or a name (which can be found in /etc/services or described by man tcp and man udp). If a name is used, both the port number and the protocol are checked. If a numeric port number is used, only the port number is checked (e.g., dst port 513 will cause tcpdump to capture packets for the tcp login service and the udp who service, while port domain will cause tcpdump to capture packets for the tcp domain service and the udp domain service) (nt | rt: ambiguous name is used 不理解,需要填).
src port port
If the source port of the packet is port, then the corresponding conditional expression is true.
port port
True if the source or destination port of the packet is port.
dst portrange port1-port2
True if the destination port of the packet (including ip/tcp, ip/udp, ip6/tcp or ip6/udp protocols) is in the range port1 to port2 (inclusive). Tcpdump interprets port1 and port2 the same way it interprets port (noted in the description of the dst port port option).
src portrange port1-port2
If the source port of the packet belongs to the port range from port1 to port2 (including port1 and port2), then the corresponding conditional expression is true.
portrange port1-port2
If the source or destination port of the packet belongs to the port range from port1 to port2 (including port1 and port2), then the corresponding conditional expression is true.
The above options about port can be preceded by the keyword: tcp or udp, for example:
tcp src port port
This will cause tcpdump to only capture TCP packets whose source port is port.
less length
True if the length of the packet is less than or equal to length. This is consistent with the meaning of 'len <= length'.
greater length
True if the length of the packet is greater than or equal to length. This is consistent with the meaning of 'len >= length'.
ip proto protocol
If the packet is an ipv4 packet and its protocol type is protocol, then the corresponding conditional expression is true.
: : : : : : : : : : : : : : :
ip6 proto protocol
If the packet is an ipv6 packet and its protocol type is protocol, then the corresponding conditional expression is true.
Note that this expression will not print out all the protocol header contents in the protocol header chain in the data packet.
ip6 protochain protocol
If the packet is an IPv6 packet and its protocol chain contains a protocol header of type protocol, then the corresponding conditional expression is true. For example, ip6 protochain 6
This will match IPv6 packets that have a TCP header in their protocol header chain. This packet may also contain an authentication header, a routing header, or a hop-by-hop routing options header between the IPv6 header and the TCP header.
The corresponding BPF (Berkeley Packets Filter, which can be understood as a mechanism for packet filtering at the data link layer) code triggered by this is relatively cumbersome.
And the BPF optimization code does not take care of this part, so the packet matching triggered by this option may be slower.
ip protochain protocol
Same meaning as ip6 protochain protocol, but for IPv4 packets.
the broadcast
True if the packet is an Ethernet broadcast packet. The ether keyword is optional.
ip broadcast
True if the packet is an IPv4 broadcast packet. This causes tcpdump to check the broadcast address for some convention of all-0s and all-1s, and to look up the network mask of the network interface on which the packet is being captured.
If the network mask of the network interface where the packet is captured is invalid, or the interface has no corresponding network address and network configured, or if the packet is captured on the 'any' network interface under Linux (this 'any' interface can receive packets from more than one interface in the system (nt: in fact, it can be understood as all available interfaces in the system)), the network mask check will not work properly.
ether multicast
True if the packet is an Ethernet multicast packet. The keyword ether can be omitted. This option has the same meaning as the following conditional expression: `ether[0] & 1 != 0'.
ip multicast
True if the packet is an ipv4 multicast packet.
ip6 multicast
True if the packet is an ipv6 multicast packet.
ether proto protocol
True if the packet belongs to the following Ethernet protocol types.
The protocol field, which can be a number or a name from the following: ip, ip6, arp, rarp, atalk (AppleTalk network protocol),
aarp (nt: AppleTalk Address Resolution Protocol, AppleTalk network address resolution protocol),
decnet (nt: a network protocol stack provided by DEC), sca (nt: unknown, to be supplemented),
lat (Local Area Transport, an Ethernet host interconnection protocol developed by DEC),
mopdl, moprc, iso (nt: unknown, to be supplemented), stp (Spanning tree protocol, which can be used to prevent link loops in the network),
ipx (nt: Internetwork Packet Exchange, a network layer protocol used in Novell networks), or
netbeui (nt: NetBIOS Extended User Interface, which can be understood as network basic input and output system interface extension).
The protocol field can be a number or one of the following protocol names: ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat,
mopdl, moprc, iso, stp, ipx, or netbeui.
It is important to note that identifiers are also keywords and must be escaped using '\'.
SNAP: SubNetwork Access Protocol
In fiber distributed data network interface (the expression element form may be 'fddi protocol arp'), token ring network (the expression element form may be 'tr protocol arp'),
and IEEE 802.11 wireless LAN (which may be expressed as 'wlan protocol arp'), protocol
The identifier comes from the 802.2 logical link control layer header,
This logical link control layer header is included in the FDDI, Token Ring or 802.1 header.
When filtering on the corresponding protocol identifiers on these networks, tcpdump only checks the LLC header for the OUI (0x000000)
The protocol ID field in a SNAP format structure (intended to identify an internal Ethernet), regardless of whether there is a SNAP format structure (nt: SNAP, SubNetwork Access Protocol) with an OUI of 0x000000 in the packet. The following exceptions:
iso tcpdump will check the DSAP field (Destination Service Access Point) in the LLC header and
SSAP domain (source service access point). (nt: iso protocol unknown, need to be supplemented)
stp and netbeui
tcpdump will check the Destination Service Access Point in the LLC header;
atalk
tcpdump will check the LLC header for a 'SNAP format structure' with an OUI of 0x080007, and will check the AppleTalk etype field.
(nt: Whether the AppleTalk etype is in the SNAP format structure is unknown and needs to be supplemented).
Additionally, on Ethernet, for the ether proto protocol option, tcpdump checks the Ethernet type field for the protocol specified by protocol, with the following exceptions:
iso, stp, and netbeui
tcpdump will check the 802.3 physical frame and the LLC header (these two checks are consistent with the corresponding checks in FDDI, TR, and 802.11 networks);
(nt: 802.3, understood as IEEE 802.3, is a collection of IEEE standards. This collection defines the physical layer and the media access control sublayer of the data link layer in wired Ethernet networks. stp has been described above)
atalk
tcpdump will check the AppleTalk etype domain in the physical frame of Ethernet, and will also check the 'SNAP format structure' in the LLC header in the packet
(These two checks are consistent with the corresponding checks in the FDDI, TR, 802.11 network)
aarp tcpdump will check the AppleTalk ARP etype domain, which exists in an Ethernet physical frame or in an LLC (defined by 802.2)
In the 'SNAP format structure', when it is the latter, the OUI identification of the 'SNAP format structure' is 0x000000;
(nt: 802.2, which can be understood as, IEEE802.2, defines a logical link control layer (LLC), which corresponds to the upper part of the data link layer in the OSI network model.
The LLC layer provides a unified interface for users who use the data link layer (usually the user is the network layer). The following is the media access control layer (nt: MAC layer,
Corresponding to the lower part of the data link layer). The implementation and working method of this layer will be different according to different physical transmission media (such as Ethernet, token ring network,
Fiber distributed data interface (nt: can actually be understood as a fiber optic network), wireless LAN (802.11), etc.)
ipx tcpdump will check the IPX etype domain in the physical Ethernet frame, the IPX DSAP domain in the LLC header, and the IPX encapsulated 802.3 frames.
And the IPX etype domain (nt | rt: SNAP frame, which can be understood as the 'SNAP format structure' in the LLC header.
This meaning is a preliminary understanding stage and needs to be supplemented).
decnet src host
If the DECNET source address in the packet is host, the corresponding conditional expression is true.
(nt:decnet, developed by Digital Equipment Corporation, the earliest network protocol used for PDP-11 machine interconnection)
decnet dst host
If the destination address of DECNET in the packet is host, the corresponding conditional expression is true.
(nt: decnet has been explained above)
decnet host host
If the DECNET destination address or DECNET source address in the packet is host, the corresponding conditional expression is true.
(nt: decnet has been explained above)
ifname interface
If the packet has been marked as received from the specified network interface, the corresponding conditional expression is true.
(This option is only applicable to packages marked by pf programs in OpenBSD (nt: pf, packet filter, which can be understood as a firewall program in OpenBSD))
on interface
Consistent with ifname interface.
rnr num
If the packet has been marked as a rule matching PF, the corresponding conditional expression is true.
(This option is only applicable to packages marked by pf programs in OpenBSD (nt: pf, packet filter, which can be understood as a firewall program in OpenBSD))
Rulenum num
Consistent with the meaning of rulenum num.
Reason code
If the packet has been marked as a matching result code containing PF, the corresponding conditional expression is true. Valid result codes are: match, bad-offset,
fragment, short, normalize, and memory.
(This option is only applicable to packages marked by pf programs in OpenBSD (nt: pf, packet filter, which can be understood as a firewall program in OpenBSD))
rset name
If the packet has been marked as matching the specified rule set, the corresponding conditional expression is true.
(This option is only applicable to packages marked by pf programs in OpenBSD (nt: pf, packet filter, which can be understood as a firewall program in OpenBSD))
ruleset name
Consistent with the meaning of rset name.
srnr num
If the packet has been marked as matching a specific rule in the specified rule set (nt: specified PF rule number, specific rule number, i.e. specific rule),
The corresponding conditional expression is true. (This option is only applicable to packages marked by pf programs in OpenBSD (nt: pf, packet filter, can be understood as
Firewall program in OpenBSD))
subbrulenum num
Consistent with the meaning of srnr.
action act
If PF will perform the action specified by act when the packet is recorded, the corresponding conditional expression is true. Valid actions include: pass, block.
(This option is only applicable to packages marked by pf programs in OpenBSD (nt: pf, packet filter, which can be understood as a firewall program in OpenBSD))
ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
Consistent with the following expression meta meaning:
ether proto p
p is one of the above protocols.
lat, moprc, mopdl
Consistent with the following expression meta meaning:
ether proto p
p is one of the above protocols. It must be noted that tcpdump cannot analyze these protocols at present.
vlan [vlan_id]
If the packet is an IEEE802.1Q VLAN packet, the corresponding conditional expression is true.
(nt: IEEE802.1Q VLAN, that is, IEEE802.1Q virtual network protocol, this protocol is used for interconnection between different networks).
If [vlan_id] is specified, only the data contains the specified virtual network id (vlan_id), and the corresponding conditional expression is true.
It should be noted that for VLAN packets, the first vlan keyword encountered in the expression will change the starting position of the data in the packet corresponding to the next keyword in the expression (i.e., the decoding offset). When filtering packets in the VLAN network system, the vlan [vlan_id] expression can be used multiple times. The keyword vlan will be added every time it appears.
4-byte filtering offset (nt: filtering offset, which can be understood as the above decoded offset).
For example:
vlan 100 && vlan 200
Indicates: Filter packets on the VLAN200 network encapsulated in VLAN100, for example:
vlan && vlan 300 && ip
Indicates: Filter IPv4 packets encapsulated in VLAN300 network, and VLAN300 network is encapsulated by a more outer VLAN
mpls [label_num]
If the packet is an MPLS packet, the corresponding conditional expression is true.
(nt: MPLS, Multi-Protocol Label Switch, multi-protocol label switching, a technology that uses tags to guide data transmission on an open communication network).
If [label_num] is specified, only the data contains the specified label id (label_num), and the corresponding conditional expression is true.
It should be noted that for IP packets containing MPLS information (i.e. MPLS packets), the first MPLS keyword encountered in the expression will change the starting position of the data in the packet corresponding to the next keyword in the expression (i.e. decoding offset). When filtering packets in the MPLS network system, the mpls [label_num] expression can be used multiple times. The keyword mpls will be added every time it appears.
4-byte filtering offset (nt: filtering offset, which can be understood as the above decoded offset).
For example:
mpls 100000 && mpls 1024
Indicates: Filter packets with outer layer labels of 100000 and layer labels of 1024, for example:
mpls && mpls 1024 && host 192.9.200.1
Indicates: Filter data packets sent to or from 192.9.200.1, the inner layer tag of the data packet is 1024 and has an outer layer tag.
pppoed
If the packet is a PPP-over-Ethernet server, search for the packet (nt: Discovery packet,
If its ethernet type is 0x8863), the corresponding conditional expression is true.
(nt: PPP-over-Ethernet, a point-to-point Ethernet bearer protocol, its point-to-point connection establishment is divided into Discovery stage (address discovery) and
In the PPPoE session establishment stage, the discovery packet is the packet sent from the first stage. ethernet type
It is a field in an Ethernet frame that indicates the protocol applied to the frame data field)
pppoes
If the packet is a PPP-over-Ethernet session packet (nt: ethernet type is 0x8864, PPP-over-Ethernet has been described above, you can search for the keyword 'PP-over-Ethernet' to find its description), then the corresponding conditional expression is true.
It should be noted that for PPP-over-Ethernet session packets, the first pppoes keyword encountered in the expression will change the start position of the data in the packet corresponding to the next keyword in the expression (i.e., the decoding offset).
For example:
pppoes && ip
Representation: Filter ipv4 packets embedded in PPPoE packets
tcp, udp, icmp
Consistent with the following expression meta meaning:
ip proto p or ip6 proto p
where p is one of the above protocols (the meaning is: if the packet is ipv4 or ipv6 packet and its protocol type is tcp, udp, or icmp, the corresponding conditional expression is true)
iso proto protocol
If the protocol type of the data packet is the protocol protocol in the iso-osi protocol stack, the corresponding conditional expression is true. (nt: [Initial Solution] The specific protocol of each layer in the iso-osi network model is different from the protocol used by the corresponding layer of tcp/ip. The specific protocols in each layer of iso-osi need to be supplemented in addition)
protocol can be a number, or one of the following names:
clnp, esis, or isis.
(nt: clnp, Connectionless Network Protocol, this is the network layer protocol in the OSI network model, esis, isis is unknown, and needs to be supplemented)
clnp, esis, isis
It is the abbreviation of the following expression
iso proto p
where p is one of the above protocols
l1, l2, iih, lsp, snp, csnp, psnp
It is an abbreviation for the IS-IS PDU type.
(nt: IS-IS PDU, Intermediate system to intermediate system Protocol Data Unit, the protocol data unit from intermediate system to intermediate system. The OSI (Open Systems Interconnection) network consists of a terminal system and an intermediate system.
The terminal system refers to the router, while the terminal system refers to the user equipment. The local group formed by the router is called the "area" and multiple areas form a "domain".
IS-IS provides routing within the domain or region. l1, l2, iih, lsp, snp, csnp, psnp represents the type of PDU, and the specific meaning needs to be added)
vp n
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system,
If the packet is an ATM packet and its virtual path is identified as n, the corresponding conditional expression is true.
(nt: ATM, Asychronous Transfer Mode, can actually be understood as a proposed by ITU-T (Telecom Standardization Department of the International Telecommunications Union) and
A series of protocols with the same functions as IP layer in TCP/IP, and the specific protocol level needs to be supplemented)
vci n
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system,
If the packet is an ATM packet and its virtual channel identification is n, the corresponding conditional expression is true.
(nt: ATM, described above)
lane
If the packet is an ATM LANE packet, the corresponding conditional expression is true. Note that if it is a LANE packet that simulates Ethernet or
LANE logical unit control package, the first lane keyword in the expression will change the test of subsequent conditions in the expression. If the lane keyword is not specified, the conditional test will be performed according to the ATM packet containing the LLC (logical link layer) in the data packet.
llc
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system,
If the packet is an ATM packet and contains LLC, the corresponding conditional expression is true
oamf4s
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is a Segment OAM F4 cell (VPI=0 and VCI=3), the corresponding conditional expression is true.
(nt: OAM, Operation Administration and Maintenance, operation management and maintenance, can be understood as: the classification method of ATM cells generated by network management in ATM network.
The transmission unit in the ATM network is a cell, and the data to be transmitted will eventually be divided into cells of fixed length (53 bytes).
(First understanding: A physical line can be multiplexed to form a virtual path. A virtual path is multiplexed to form a virtual channel).
The addressing method of both parties in the communication is: virtual path number (VPI)/virtual channel number (VCI)).
OAM F4 flow cells can be divided into segment class and end-to-end class. The difference is unknown and needs to be supplemented.)
oamf4e
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is an end-to-end OAM F4 cell (VPI=0 and VCI=4), the corresponding conditional expression is true.
(nt: OAM and end-to-end OAM F4 have been described above, you can search for 'oamf4s' to locate)
oamf4
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is an end-to-end or segment OAM F4 cell (VPI=0 and VCI=3 or VCI=4), the corresponding conditional expression is true.
(nt: OAM and end-to-end OAM F4 have been described above, you can search for 'oamf4s' to locate)
oam
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is an end-to-end or segment OAM F4 cell (VPI=0 and VCI=3 or VCI=4), the corresponding conditional expression is true.
(nt: This option is repeated with oamf4, need to be confirmed)
metac
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is from a 'meta signaling line' (nt: VPI=0 and VCI=1, 'meta signaling line', meta signaling circuit, the specific meaning is unknown, and it needs to be added),
The corresponding conditional expression is true.
bcc
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is from the 'broadcast signaling line' (nt: VPI=0 and VCI=2, 'broadcast signaling line', broadcast signaling circuit, the specific meaning is unknown, and it needs to be added),
The corresponding conditional expression is true.
sc
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is from a 'signaling line' (nt: VPI=0 and VCI=5, 'signaling line', signaling circuit, the specific meaning is unknown, and it needs to be added),
The corresponding conditional expression is true.
ilmic
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is from the 'ILMI line' (nt: VPI=0 and VCI=16, 'ILMI', Interim Local Management Interface, it can be understood as an interface for network management based on SNMP (Simple Network Management Protocol)) the corresponding conditional expression is true.
connectmsg
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is from a 'signaling line' and is the following messages specified in the Q.2931 protocol: Setup, Calling Proceeding, Connect,
Connect Ack, Release, or Release Done. The corresponding conditional expression is true.
(nt: Q.2931 Signaling protocol for ITU (International Telecommunications Union). It stipulates the relevant steps for establishing, maintaining and canceling network connections at the user interface layer of a broadband integrated service digital network.) metaconnect
If the packet is an ATM packet, the corresponding conditional expression is true. For SunATM devices on the Solaris operating system, if the packet is an ATM packet and is from a 'meta-signaling line' and is the following messages specified in the Q.2931 protocol: Setup, Calling Proceeding, Connect,
Connect Ack, Release, or Release Done. The corresponding conditional expression is true. expr relop expr
If the operands (expr) on both sides of relop satisfy the relationship specified by relop, the corresponding conditional expression is true.
relop can be one of the following relational operators: >, <, <=, =, !=.
expr is an arithmetic expression. In this expression, integer constants (representation is consistent with standard C), binary operators (+, -, *, /, &, |,
<<, >>), length operator, and reference operator to data in a specific packet. Note that all comparison operations have default operands that are unsigned,
For example, 0x80000000 and 0xffffffffff are both greater than 0 (nt: For signed comparisons, according to the complement rule, 0xffffffff
Will be less than 0). If you want to reference data in a data packet, you can use the following expression:
proto [expr : size]
The value of proto can be one of the following values: ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp,
tcp, udp, icmp, ip6 or radio. This indicates the protocol layer corresponding to the reference operation. (ether, fddi, wlan,
tr, ppp, slip and link correspond to the data link layer, radio corresponds to the accompanying data link layer in 802.11 (wlan, wireless LAN) packets.
"radio" header (nt: which describes baud rate, data encryption and other information)).
It should be noted that upper-level protocols such as tcp, udp can only be applied to networks that use IPv4 or IPv6 protocols in the network layer (this restriction will be modified in future versions of tcpdump). For the data required for a specified protocol, its offset byte in the packet data is specified by expr.
In the above expression, size is optional, used to indicate the length of the data segment we are concerned about (nt: usually this data is a field of the data packet), and its length can be 1, 2, or 4 bytes. If size is not given, the default is 1 byte. The keyword of the length operator is len,
This code is the entire length of the packet.
For example, 'ether[0] & 1 != 0' will cause tcpdump to grab all multicast packets. (nt: the lowest bit of ether[0] byte is 1 to indicate that the destination address of the packet is the multicast address). 'ip[0] & 0xf != 5' will grab all options with crawl
IPv4 packet. 'ip[6:2] & 0x1fff = 0' corresponds to crawling unbreaked IPv4 packets or broken IPv4 packets with fragment number 0. This data check method is also suitable for references to tcp and udp data.
That is, tcp[0] corresponds to the first byte in the TCP header, rather than the byte in the middle.
Some offsets and domain values can be expressed in addition to numbers or names. The following are the names of some available domains (domains in protocol headers): icmptype (refers to the type domain in ICMP protocol headers), icmpcode (refers to the ICMP protocol header code domain), and tcpflags (refers to the flags domain of TCP protocol headers)
The following are the available values for the type domain in the ICMP protocol header:
icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert,
icmp-routersolicit, icmp-timx-ceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply,
icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply.
The following are the available values for the flags domain in the TCP protocol header: tcp-fin, tcp-sync, tcp-rst, tcp-push,
tcp-ack, tcp-urg. This is the article about the detailed explanation of the tcpdump command analysis and use of Linux. For more related contents of Linux tcpdump commands, please search for previous articles of 123WORDPRESS.COM or continue to browse the related articles below. I hope you will support 123WORDPRESS.COM in the future! You may also be interested in:- Linux uses the sar command to view network card traffic
- Detailed discussion on how to use sar in Linux
- Detailed explanation of Linux commands sort, uniq, tr tools
- Detailed explanation of the use of stat function and stat command in Linux
- Linux cut command explained
- Detailed explanation of the usage of grep commands for common Linux commands
- A complete collection of common command operations for Linux (recommended collection)
- Linux sar command usage and code example analysis
| 
