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.
