5

Pic related:alt text

Why those segments are marked as separate packets (all Ack, Seq=509)? Why did a packet get split?

kagali-san
  • 1,724
  • 1
    Your picture is unreadable. Since you're not actually trying to show a picture but text, extract the information as text and post that. (If your packet capture tool doesn't have an option to save the trace in a text file or copy it to the clipboard, ditch it.) – Gilles 'SO- stop being evil' Oct 30 '10 at 00:32
  • Here is a link to the full-size image... http://i.imgur.com/glr69.png – rascher Nov 06 '10 at 19:19
  • 2
    @Gilles: I think it's Wireshark (previously Ethereal). – Hello71 Nov 07 '10 at 19:26
  • You can also use this display filter to hide the reassembled noise in the Wireshark display: !tcp.reassembled_in –  Nov 07 '12 at 14:50

3 Answers3

8

I can't see the picture, but a lower level protocol (Say, Ethernet) can break a higher level protocol (say, TCP packet) into fragments based on the size of its MTU (Maximum Transmission Unit).

kmarsh
  • 4,960
  • 1
    You're right about TCP packets being split into parts based on the MTU. The statement, "but a lower level protocol (Say, Ethernet) can break a higher level protocol", is completely off. All of the protocols below TCP in the packets only exist to identify the host and enable routing through the internet. That's all they do, nothing more. – Evan Plaice Nov 11 '10 at 00:39
  • 5
    Wow. Just wow. Ethernet consists of nothing but ARP and RARP. Wow. – kmarsh Nov 11 '10 at 23:08
4

Wikipedia defines Protocol data unit as follows :

In telecommunications, the term protocol data unit (PDU) has the following meanings:

  1. Information that is delivered as a unit among peer entities of a network and that may contain control information, address information, or data.
  2. In a layered system, a unit of data which is specified in a protocol of a given layer and which consists of protocol-control information and possibly user data of that layer. For example: Bridge PDU or iSCSI PDU1

PDUs are relevant in relation to each of the first 4 layers of the OSI model (Layer 5 and above are referred to as data).

So, in effect a PDU is simply a unit of data, defined in its own context.

From Understanding WireShark :

Sometimes the packet will not arrive in one piece. Instead, the packet arrives as several Protocol Data Units (PDU). WireShark will try to reassemble these units back into a single packet. Such a packet is called a reassembled PDU.

When working with a reassembled PDU, the display will not be as nice as a regular packet. The headers of the response are in the bottom pane of Figure 2.11.

This means that these are segments of the TCP/IP message, and that normally only the last segment has meaningful and complete information about the TCP/IP message.

From Wireshark TCP segment of a reassembled PDU :

You can disable the reassembly of TCP segments by unchecking the "Allow subdissector to desegment TCP streams" in the TCP protocol preferences. That way, all parts of the application PDU will be displayed on their own.

This is a way to ensure that all segments will contain all the information required to meaningfully display the TCP/IP segment, and not only the last packet.

harrymc
  • 480,290
3

I presume you are referring to visible frames in the range 56-78.
Lets tackle things in this order,

  1. About: "TCP segment of a reassembled PDU"
    This implies that wireshark (ethereal?) reassembled TCP Segments together for your view.
    So, you can ignore this string, it means no harm.
    I have elaborated what these frames are in point 4 below.
  2. About: Different frames with the same 'seq' number.
    Frames 58, 60,62,64,etc show the same sequence number.
    However, note that these are not a single packet "marked as separate packets" -- no splitting.
    These packets had only the 'ACK' flag set and you will see that the ACK number is incrementing.
    These are ACKs sent to the HTTP server from your machine as different TCP segments reached it.
  3. The 'ACK' sequence starts at 1 in frame 52 and ends with 9646 in the FIN frame 78.
    During this time, all frames from your browser towards the HTTP server are repeating the last sequence number sent (which is 609) -- this is normal TCP protocol behavior.
    The browser is not sending any further data after its first HTTP request (frame 52).
    The HTTP server acknowledged this in frame 54.
  4. I expect frame 54 is the (wireshark) re-assembled server response which was formed with the frames marked "TCP segment of a reassembled PDU".
    So, all those succeeding frames marked that way are from the HTTP server to the client
    (that detail is not visible in your picture since you scrubbed the Source and Destination columns).

If you re-check your original capture file, you should find frames 54 to 67 that have TCP Source port 80 (for HTTP) will add up to the 9646 byte response data from the HTTP server.

What you see here is a 9KB reply from the HTTP server reaching your browser as several MTU limited TCP segments, each of which was acknowledged by the TCP stack of your OS.

This is the high-level sequence of communication.

  1. Your browser started connection to the HTTP server with a 3-way TCP handshake.
  2. It sent a single HTTP Request to the server on this connection
  3. The server replied to this with a 9 KB response which was spread over several TCP/IP packets as (TCP Segments)
  4. The TCP/IP stack on your browser machine acknowledged each TCP packet as it was received from the server
  5. Finally, it closed the connection starting with a FIN packet.
    I expect there were a couple of more FIN and ACK packets after frame 78 (or a single RST packet).

You can read up some more on Wireshark TCP Reassembly handling at the Wireshark Wiki.

nik
  • 56,306