How to use tcpdump to capture packets

Some examples of packet capture analysis have been found for a long time, which can be repeated continuously. After analyzing the packet capture, I think the basic skills are too inadequate. there are too many things involved and too many things to understand. The purpose of posting this post is to hope that we have the honor to share your labor and sweat with you. we suggest you give more examples. thank you. Example 1: arp fault

Some examples of packet capture analysis have been found for a long time, which can be repeated continuously. After analyzing the packet capture, I think the basic skills are too inadequate. there are too many things involved and too many things to understand. The purpose of this post is to share your labor and sweat with us.
I suggest you give more examples. thank you.

Example 1: arp fault

Failure: A solaris operating system in the LAN server A-SERVER network connection is not normal, from any host can not ping the server.

Troubleshooting: first, check the system. the system itself works normally. there are no special processes running, cpu and memory usage are normal, no firewall is mounted, and the network cable is normal.
In this caseTcpdumpFirst, we will execute the ping command from the B-CLIENT host and send the icmp packet to the A-SERVER, as shown below:
[Root @ redhat log] # ping A-SERVER
PING A-SERVER from B-CLIENT: 56 (84) bytes of data.
At this point, tcpdump is started in the A-SERVER to capture packets from the host B-CLIENT.
A-SERVER # tcpdump host B-CLIENT
Tcpdump: listening on hme0
16:32:32. 611251 arp who-has A-SERVER tell B-CLIENT
16:32:33. 611425 arp who-has A-SERVER tell B-CLIENT
16:32:34. 611623 arp who-has A-SERVER tell B-CLIENT
We can see that not receive the expected ICMP packet, instead captured the arp broadcast packet sent by the B-CLIENT, because the host B-CLIENT can not use arp to get the server A-SERVER

The address, so repeatedly ask the MAC address of the A-SERVER, from this point of view, the possibility of high-level problems is not big, it is likely that some problems in the link layer, first look up the host A-SERVER

Arp table:
A-SERVER # arp-
Net to Media Table
Device IP Address Mask Flags Phys Addr
-------------------------------------------------------------
Hme0 netgate 255.255.255.255 00: 90: 6d: f2: 24: 00
Hme0 A-SERVER 2017100000000255 S 00: 03: ba: 08: b2: 83
Hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01: 00: 5e: 00: 00: 00
Please pay attention to the Flags position of the A-SERVER and we see only the S sign. We know that in the arp implementation of solaris, the flags of arp must set the P flag to respond to ARP.

Requests.
Manually add p-bit
A-SERVER # arp-s A-SERVER 00: 03: ba: 08: b2: 83 pub
Now let's call arp-.
A-SERVER # arp-
Net to Media Table
Device IP Address Mask Flags Phys Addr
-------------------------------------------------------------
Hme0 netgate 255.255.255.255 00: 90: 6d: f2: 24: 00
Hme0 A-SERVER rj0000255 SP 00: 03: ba: 08: b2: 83
Hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01: 00: 5e: 00: 00: 00
We can see that the host already has the PS mark, and then test the system's network connection to restore normal, the problem is solved!

Example 2: netflow software problems

Fault description: the cisconetflow software is installed on the newly installed network management workstation to analyze the traffic of the routing device. the router is configured as required, and the software is installed on the local work.

Normally, no error message is reported, but starting netflow collector does not receive the traffic information sent from any vro, resulting in the software failure. Troubleshooting: check routes and software repeatedly

Configuration is correct. When using the step-by-step analysis method, first identify the faulty device, whether the router does not send traffic information or the local system receives the error?
I suddenly thought that on the vro, we defined the client to receive data from udp port 9998. we can monitor this port to see if the vro actually sent udp data,

If the system can receive data packets from the route, the routing problem may be small, and vice versa.
Use tcpdump on the network management workstation:
Nms # tcpdump port 9995
Tcpdump: listening on hme0
18:15:34. 373435 routea> nms.9995: udp 1464
18:15:34. 373829 routea.50111> nms.9995: udp 1464
18:15:34. 374100 routea.50111> nms.9995: udp 1464
Now we can see that the data packets are indeed sent from the vro. The problem is that the possibility of the vro is basically ruled out, and the system is re-checked. as a result, the network management workstation is installed with fire prevention.

Wall, udp port 9998 is blocked. adjust the firewall configuration on the workstation, and the netflow operation resumes normal, troubleshooting!
Example 3: email server troubleshooting

Fault description: the local area network is equipped with a new mail server with qmail in the background. The basic functions such as sending and receiving emails on the mail server are normal, but a common strange phenomenon is found during use.

: It takes a long time to start sending tasks after connecting to the mail server when sending emails on pc machines.

Troubleshooting: the network connection is normal. The performance of the email server and the following pc is normal. what is the problem? For accurate positioning, we

The client sends an email and uses tcpdump on the server to capture and analyze the client data packets, as shown below:
Server # tcpdump host client
Tcpdump: listening on hme0
19:04:30. 040578 client.1065> server. smtp: s00007965815: 1087965815 (0) win 64240

0, nop, nop, timestamp [| tcp]> (DF)
19:04:30. 040613 server. smtp> client.1065: S99285900: 99285900 (0) ack 1087965816 win 10136 < p><>

0, nop, [| tcp]> (DF)
19:04:30. 040960 client.1065> server. smtp:. ack 1 win 64240 (DF)
The three handshakes are successfully completed, so far normal. let's look down.
19:04:30. 048862 server.33152> client.113: S99370916: 99370916 (0) win 8760 (DF)
19:04:33. 411006 server.33152> client.113: S99370916: 99370916 (0) win 8760 (DF)
19:04:40. 161052 server.33152> client.113: S99370916: 99370916 (0) win 8760 (DF)
19:04:56. 061130 server.33152> client.113: R99370917: 99370917 (0) win 8760 (DF)
19:04:56. 070108 server. smtp> client.1065: P 109 (10 ack 1 win10136 (DF)

There is a problem here. we can see that the server tries to connect to the 113identd port of the client and requires authentication. However, the server does not receive a response from the client, and the server tries 3 again.

After 26 seconds, the authentication request was abandoned, and the packet with the reset flag was actively sent, and the data following the push was started.

The long wait time for sending emails.
After finding the problem, you can take the right medicine. by modifying the qmail configuration on the server end, it will no longer perform port 113 authentication, and capture packets again.

Port 113 is used for authentication, but data is pushed directly after three handshakes. The problem is solved!

Conclusion: the above example demonstrates the role of the package analysis software in troubleshooting. through these examples, we can easily find that using the package analysis software

The administrator can quickly and accurately locate network faults and analyze network problems.