1. Introduction to Failed POST Request Analysis
This article marks the beginning of a series focused on Failed POST Request Analysis through the lens of Wireshark. We aim to master network protocols and effectively utilize Wiresharkâs features to resolve various network problems you may encounter in your work and daily life. The data packets we analyze may originate from personal captures or those shared by others, but regardless of the source, we will dissect them to enhance your understanding.
2. Scenario Introduction: Understanding Failed POST Requests
This is a HTTP POSTrequest, but it failed and the application layer reported an error.
There are a total 11of packages, which will be introduced in detail below.
3. Failed POST Request Analysis: Packet Breakdown
3.1, Packages 1-3
This is the well-known three-way handshake. If you are still unclear about the details, you can refer to my article:
But before we continue to analyze the following data packets, I would like to ask you a question: these data packets are HTTPrequests and responses, so the communication is divided clientinto servertwo ends. So which end are these data packets captured from?
Thinking about this issue clearly will help the following analysis.
I provide at least two ways to determine at which end these data packets are captured.
1ătime
Pay attention to this column in the data packet Time. I use
We have selected â â, which means that the reception time difference between the current data packet and the previous data packet is displayed Seconds Since Previous Displayed Packetin units of two adjacent data packets .Time
Carefully observe the three-way handshake, 1-2the time difference of the number packets is 0.000014, and 2-3the time difference of the number packets is 0.30001. This shows that the data packet is servercaptured from the end.
Only in this way can the above-mentioned time difference be explained.
serverThe first handshake packet is received and then sent out. 1-2The time difference between them can be so short because these two data packets are servercaptured on the Internet without being transmitted on the network.
On the contrary, serverfrom sending a data packet to receiving the third handshake, it is transmitted over the network.
This shows that these data packets are indeed serverobtained from the end.
2ăTTL
This method uses the fields IPof the network protocol TTL.
wiki:Time to live(TTL) orhop limitis a mechanism which limits the lifespan or lifetime of data in a computer or network. TTL may be implemented as acounterortimestampattached to or embedded in the data. Once the prescribed event count or timespan has elapsed, data is discarded or revalidated. Incomputer networking, TTL prevents a data packet from circulating indefinitely. Incomputingapplications, TTL is commonly used to improve the performance and manage thecachingof data.
You can simply understand it as follows: when a data packet is transmitted on the network, TTLthe value decreases by one every time it passes through a router.
You will find that the two are completely different. 1The packet TTLhas passed through multiple routers and its value has been reduced. The value 2of the packet TTLis much larger than 1.
But can you say that the number packets are reduced 2because they do not pass through the router ?TTL
I can really determine it pretty accurately. Why?
64 is the standard number for a TTL field in Linux.
LinuxTTLThis is the standard value of the machine 64.
Package 3.2, 4-5
4The packet indicates a request clientto send HTTP post, but it is only a request headers, and the request body is in the subsequent packets.
5The number package means I have received your request headers, please continue to send it
5The number package of the Ack=309=4number seq+tcpLen=4package nextSeqmeans 4the content of the received number package
So far, the process has been relatively smooth. Now, the problems begin
3.3, Package 6
There are too many details here, so letâs analyze them slowly.
The first is the eye-catching â TCP Previous segment not capturedâ, wiresharkwhich gives us this hint. What does it mean?
Thereâs something wrong with this packet, there should have been a data packet before it, but it was received ahead of time.
How do you know?
Look seq=777, according to 4/5the analysis of the number packet, the next one clientshould be sent from seq=309the beginning, but this packet is 777at the beginning.
6Why seq=777? TCP Len=0Should NextSeq=708nât it be 777+0=777?
No, generally speaking, it is nextSeq=Seq+Len. There are only two exceptions, that is, SYNthe packet in the three-way handshake and the packet in the four-way handshake FIN. And this 6packet is one of these two cases â FINa packet.
6The information in the number package Infoactually tells us this.
3.4, Package 7
7The number package said it was innocent. Hey, brother, you should seq=309have sent it from the beginning.
â TCP Dup ACKâTell clientthe terminal that I received your 6number packet, but you may have lost some packets and cannot give them to me.
Repeat confirmation, as the name implies, means that serverthe end has definitely confirmed it once. As shown in the figure:
Package 3.5, 8-9
8Packet: clientThe end finally seq=309sent the data packet, itâs so late.
How belated is it?
It was 7after the number package 16s! It took a long time.
4In fact, there is also a problem with the number packet in terms of timing . 2sThe request is sent only after the three-way handshake.
Seeing this, you should focus on troubleshooting clientthe problem on the end, which is definitely not normal.
The prompt â TCP Retransmissionâ wiresharktells us that this packet is a retransmission, which means it is not sent for the first time.
9Number packet: serverend-to-end confirmation of 8number packets
3.6, 10-11 bags
10Number package: response serverto client POSTrequest
11Number packet: clientThe end returns directly RST, violently disconnecting
3.7 Summary
This is an unusual POSTrequest. clientThe complete request body was not sent. Maybe it was retransmitted nseveral times to bodycomplete the request, but in the end the request still failed.
4. Other points to note
4.1. NextSeq in package 10
NextSeq = 70, but Seq+Len = 1+68, it doesnât match again?
Remember what I said above, three handshakes SYNand four waves FINare equivalent Len=1.
Is the number 10package one of them?
It really is FINa bag.
Then 10why doesnât the number package show the flag information in the column like 6the number package does?InfoFIN
In fact, this is also Wiresharka feature: Infothe column will first display the content of the application layer protocol ( FINthe mark is the information at the control TCPlayer level )
4.2. Why does packet 8 have a retransmission flag?
In other words, Wiresharkon what basis are data packets marked with â TCP Retransmissionâ?
Look directly at the source code
If a packet contains data (or is SYN/FINa packet) and has not been seqoversized, it must be one of a retransmission, fast retransmission, or out of order.
V. Conclusion
This data packet analysis journey ends here. I wonder if you like this form of article. Everyone is welcome to communicate and learn.