 | 1 | initial version |
could be possible that this is a reason why app works slow ??
Not by itself. "TCP segment of a reassembled PDU" is NOT an error indication; it's merely a simple statement that, at least as Wireshark's dissection code sees it, it appears to be the case that there's a packet, for some protocol running on top of TCP, on that side of the TCP connection that doesn't neatly fit into a single TCP segment, this packet contains one of those TCP segments, and it doesn't, as of when it first saw that packet, have all the data for that packet, so it can't, as of that point, reassemble the packet.
If those two frames have, in the "TCP" part of the detailed dissection pane, a "Reassembled PDU in frame N", for some value of N, then the higher-level packet was successfully reassembled, and frame N will show it. In that case, "TCP segment of a reassembled PDU" does not indicate any problem - the problem lies elsewhere.
Otherwise, the problem might be that not all the TCP segments for that packet are in the capture. That could either be the result of the capture process not capturing all packets received by the machine on which the capture was done, in which case it's a problem with capturing, not a problem with the network, or the result of the packets not seen having been sent by the server but not by the machine on which the capture was done, which could be the result of a network problem.
If that's the case, you might try checking the preferences for the TCP protocol (pop up the Preferences dialog - Edit > Preferences on most operating systems, Wireshark > Preferences on macOS), open up the "Protocols" item, and look for "TCP". If the "Analyze TCP sequence numbers" preference isn't enabled (with a check in its checkbox), enable it and click "OK". If it is enabled, leave it alone.
Then look at the packets in that TCP connection near those two frames and see if, in the packet details, there are any "SEQ/ACK Analysis" items indicating problems, such as, for example,, "Previous segment(s) not captured".
If there are any indications of out-of-order segments, make sure that the TCP preference "Reassemble out-of-order segments" is enabled; if not, enable it and see if that makes it possible for the dissector to reassemble the packet, so that frames 38123 and 38124 are part of that packet.
