Ask Your Question

Certficate [TCP segment of a ressembled PDU] -- WHY/WHAT causes it?

asked 2018-11-10 19:28:53 +0000

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

Can someone please tell me what this means. Again I am not quite sure here. Did some short reading but little over my head. The more info I bring to the developers the faster they may fix it.

In the capture the unit is working just fine with SSL ON until 2:50 AM. At that time I see all of the Certficate [TCP segment of a ressembled PDU] error. At 11:23 I turn off SSL the unit starts posting data to the servers.

IOT device eth.addr == 20:F8:5E:E1:7B:CF ip.addr ==

Here is a capture


edit retag flag offensive close merge delete


Where did you get these timestamps from, what timezone are they in?

Jaap gravatar imageJaap ( 2018-11-11 11:41:19 +0000 )edit

I am not sure what you mean. The timestamps in the capture look correct to me.

Serch4 gravatar imageSerch4 ( 2018-11-12 02:43:15 +0000 )edit

I've move your answer to a comment, since this is a Question and Answer site, not a forum.

Jaap gravatar imageJaap ( 2018-11-12 07:44:33 +0000 )edit

Some more detailed questions then: - What timezone are these timestamps in? - What events in the capture file make you say that these timestamps are significant in the capture?

Jaap gravatar imageJaap ( 2018-11-12 07:47:05 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2018-11-12 22:37:35 +0000

Guy Harris gravatar image

updated 2018-11-12 22:40:20 +0000

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.)

edit flag offensive delete link more


Thank you for the detailed response. We have figured out what has happened. The Devops team released a new load balancer and it decided to use a different cipher suite. When the device connects with SSL, it presents the load balancer with a list of cipher suites to choose from, but for whatever reason it was selecting a different one.

Serch4 gravatar imageSerch4 ( 2018-11-19 14:56:45 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2018-11-10 19:28:53 +0000

Seen: 3,196 times

Last updated: Nov 12 '18