Wireshark-users: Re: [Wireshark-users] "TCP Segment of a reassembled PDU" from aNetApp filer
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 18 Mar 2008 19:28:06 -0700

On Mar 18, 2008, at 7:08 PM, lemons_terry@xxxxxxx wrote:

Thanks very much for this explanation, Guy.  I turned off TCP
reassembly, and Wireshark then reported the following for every other
packet from the NetApp: "Unreassembled Packet: NDMP".  So should I be
assuming that NetApp, as an efficiency, stuffs multiple PDUs into the
TCP segment,

NDMP packets could be bigger than the maximum TCP segment size on the network you're on (e.g., 1460 bytes on Ethernet with TCP-over-IPv4), in which case *any* NDMP implementation would have to split the NDMP packet across two or more TCP segments, even if there *aren't* multiple NDMP packets per TCP segment.

As for packing multiple NDMP PDUs into a TCP segment, if, for example, the receiving machine has its receive window on the connection shut at the time NDMP hands a PDU to TCP on the sending machine, the sending machine couldn't immediately send the PDU that had been handed to TCP, so its TCP will just buffer up the data for that PDU - and if another PDU is handed to TCP for that connection before the receiving opens its window, by the time the window opens up, there will be more than one PDU buffered up, and TCP will send whatever it chooses to send, which might include parts of more than one PDU.

The display you're reporting seems to imply that the NDMP packets take two TCP segments.

and the Wireshark NDMP dissector hasn't been trained to
decipher this?

No, you shouldn't, because the Wireshark dissector was changed ages ago (back when Wireshark was called Ethereal...) to handle that.

However, there might be a TCP reassembly bug, or there might be some other reason, such as packets not captured, preventing reassembly.

If you can, send us a capture with at least two of the "Unreassembled Packet: NDMP" packets, and at least two of the packets before them, so we can see which of those is the case.