 | 1 | initial version |
Can someone please tell me what this means.
It means that some code in Wireshark isn't doing as good a job of setting the Info column as it should.
TCP is a protocol that provides a continuous stream of bytes, without any markers to separate packets. A packet for a protocol running on top of TCP, such as TLS, may begin in the middle of a TCP segment, and may continue into subsequent TCP segments; Wireshark will, in its default configuration, try to reassemble the pieces of those packets and show them in their entirety.
"TCP segment of a reassembled PDU" means that the TCP segment in the frame in question contains part of a higher-level packet, but doesn't contain the last segment of a higher-level packet. The reassembly is done in the last segment for the packet, and the Info column for that frame shouldn't say "TCP segment of a reassembled PDU" - even if the last part of the packet isn't the entire segment, with some other packet beginning after the end of the reassembled packet.
That might be what's happening here - frame 8444 contains the last part of a TLS "Certificate" Handshake packet, but, after that, it contains the first part of a "Server Key Exchange" Handshake packet, the last part of which is in frame 8447.
So none of this represents a protocol problem. It represents a problem in the TCP dissector, where it flags frame 8444 as being a non-final "TCP segment of a reassembled PDU" even though it is the final TCP segment of a reassembled PDU (packet) in addition to being a non-final TCP segment of the next PDU.
So are you seeing an actual networking problem at that time?
(BTW, "that time" is about 00:50 PST, according to my machine. You are probably in a time zone two hours east of the US Pacific time zone, so it would show up as 02:50 in your time zone. Assuming Jaap is in the central European time zone, it would show up as 09:50 on his machine. Time stamps in many capture formats, including Wireshark's native pcap and pcapng formats, are in units of seconds and fractions of a second since January 1, 1970, 00:00:00 UTC, so they're in universal time, not local time, and can display differently in different time zones.)
| | 2 | No.2 Revision |
Can someone please tell me what this means.
It means that some code in Wireshark isn't doing as good a job of setting the Info column as it should.
TCP is a protocol that provides a continuous stream of bytes, without any markers to separate packets. A packet for a protocol running on top of TCP, such as TLS, may begin in the middle of a TCP segment, and may continue into subsequent TCP segments; Wireshark will, in its default configuration, try to reassemble the pieces of those packets and show them in their entirety.
"TCP segment of a reassembled PDU" means that the TCP segment in the frame in question contains part of a higher-level packet, but doesn't contain the last segment of a higher-level packet. The reassembly is done in the last segment for the packet, and the Info column for that frame shouldn't say "TCP segment of a reassembled PDU" - even if the last part of the packet isn't the entire segment, with some other packet beginning after the end of the reassembled packet.
That might be what's happening here - frame 8444 contains the last part of a TLS "Certificate" Handshake packet, but, after that, it contains the first part of a "Server Key Exchange" Handshake packet, the last part of which is in frame 8447.
So none of this represents a protocol problem. It represents a problem in the TCP dissector, where it flags frame 8444 as being a non-final "TCP segment of a reassembled PDU" even though it is the final TCP segment of a reassembled PDU (packet) in addition to being a non-final TCP segment of the next PDU.
I.e., in this case, "TCP segment of a reassembled PDU" is an "error" in Wireshark, not an error in networking. (In some other cases, it's not even an error - if you have a TCP segment that contains the beginning or middle of a packet, but doesn't contain the end of any packet, it should show up as a "TCP segment of a reassembled PDU".
So are you seeing an actual networking problem at that time?
(BTW, "that time" is about 00:50 PST, according to my machine. You are probably in a time zone two hours east of the US Pacific time zone, so it would show up as 02:50 in your time zone. Assuming Jaap is in the central European time zone, it would show up as 09:50 on his machine. Time stamps in many capture formats, including Wireshark's native pcap and pcapng formats, are in units of seconds and fractions of a second since January 1, 1970, 00:00:00 UTC, so they're in universal time, not local time, and can display differently in different time zones.)
