3

I am capturing/trying to understand a http response capture in wireshark.

enter image description here

On packet capture row 78,79, i am seeing the HTTP headers (no 78) and body (no 79) in the capture's payload.

On packet capture row 80, i am seeing the entire HTTP capture of 78 and 79.

But what does that means ?
Row 78 and 79 is the transmission of the HTTP payload. and Row 80 is again the HTTP payload

We transmit x2 times ??? Or Row 80 is something that wireshark has made up from capture of 78 and 79 ?

===

Add-on, another example, frame 37896 is assembled from 37894 and 37895. It has no payload and 0 bytes.

So is this frame 37896 actually being transmitted at all ? or it is just assembled by wireshark for clarify purpose ?

enter image description here

Regards,

Noob

Improve this question
1
  • As I understand it, row 78 is the first segment of the HTTP PDU, 79 is the second and 80 would be the third, but Wireshark reassembles all three pieces and that is what you see in row 80.
    – user27899
    Apr 7, 2018 at 7:04

3 Answers 3

Reset to default
4

It looks like this is Wireshark reassembling a HTTP PDU that was split between multiple TCP segments. The PDU was split between segments 78, 79 and 80. Wireshark reassembled the PDU as frame 80.

I have carried out a similar capture in Wireshark.

enter image description here

The HTTP PDU is split between three TCP segments: frames 22743, 22744 and 22746. Wireshark shows the first two segments as-is, but for the third segment, the HTTP PDU is reassembled as frame 22746. The Ethernet/IP/TCP headers for frame 22746 are that of the original frame, but the TCP payload (the HTTP PDU) is the reconstructed PDU from all three segments.

If you look at the detail for segments 22743:

enter image description here

It shows that the PDU was reassembled as part of frame 22746. The detail for frame 22744 also shows the same:

enter image description here

And now looking at the detail for frame 22746:

enter image description here

It shows that frame 22746 was reassembled from the contents of frame 22743, 22744 and the original frame 22746. It also shows the length of each of these segments and the total length of the reconstructed segment. The Ethernet/IP/TCP headers are that of frame 22746, but the TCP payload is the full reconstructed HTTP PDU

Improve this answer
6
  • For educational purposes, can you please also dump the IP Header to show the Identifier field?
    – mere3ortal
    Apr 7, 2018 at 13:54
  • Sorry, I've deleted the capture now, but looking at another one the ID is sequential and increasing per frame as expected, so 3 separate ID values, one for each frame
    – user27899
    Apr 7, 2018 at 14:00
  • 1
    It would be nice to add that this behavior is controlled through the two options Edit/Preferences/Protocols/HTTP/Reassemble HTTP...
    – JeanPierre
    Apr 7, 2018 at 16:20
  • @KarlBillington i have edited my post with an additional screenshot, just wondering if the assembled frame itself is made up by wireshark or actually it is a real frame being transmited over.
    – Noob
    Apr 7, 2018 at 18:20
  • @Noob It looks like the last segment is a TCP FIN, the server closed the connection, so there was no payload data in that segment. The headers in the last frame are real, just the payload is made of reassembled data from the payload of previous segments and any payload data in that segment, although in this case there was none. Look at the IP header for each of the frames, you should see that the server is giving each IP packet a different Identification value - this shows that they are different IP packets that the server is sending,also the TCP sequence number is increasing in each segment
    – user27899
    Apr 7, 2018 at 18:49
2

Rows 78-80 seem to be the frames of a single, fragmented packet (note the dots). Judging from the size, there's a problem with the MTU, just a few hundred bytes is unusual.

The HTTP payload comes wrapped in a TCP segment which in turn comes wrapped in an IP packet which in turn can come fragmented in several frames. You only display the highest layer of each frame, so the first fragments display as just TCP and with the last fragment is displayed as HTTP.

which frame is actually the payload?

All are. The payload is distributed to the fragments.

Improve this answer
3
  • 1
    Surely if it was an IP fragment the TCP sequence number could not increase between fragments as shown in the image? An IP fragment would only contain the TCP header in the first fragment. The remaining fragments would contain only TCP payload information. This looks to be segmentation of an application layer PDU inside TCP. Each row is a separate TCP segment with its own TCP sequence number
    – user27899
    Apr 7, 2018 at 8:38
  • An IP packet to be fragmented is split anywhere - the first fragment contains the TCP header along with some of the TCP payload. I can't explain the details while seeing only the summary lines.
    – Zac67 ♦
    Apr 7, 2018 at 9:45
  • @Zac67 79 has a completely intact TCP header which is different from the TCP header in 78. 77 has no payload, just an Ack. 78 has Len = 195, Seq =1. 79 has Seq = 196. All this shows that there is no IP fragmentation. The TCP session looks completely legit to me. Now whether this is a legitimate HTTP session, or whether the server is broken, that only some HTTP expert can say.
    – mere3ortal
    Apr 7, 2018 at 12:02
0

We know packets 77, 78, and 79 are part of the same socket because we see their port numbers. We can't say that for 76 and 80. I see this happen all the time when you don't filter on the client port you only filter in the two IPs. Also the Ack in 77 is only 19, which would be a very small get request, and 500 bytes would be a very large 304 Response. And if it were some sort of re-assembly (which it isn't) there would be no reason to increment the delta time. This is bad filtering.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.