This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

“Unreassembled Packet (Exception occurred)” error message

0

While running Wireshark 1.4.4 I found that many of the TLSv1 messages were not being reassembled, but left as [Unreassembled Packet]/Ignored Unknown Record. Having checked the existing documentation on this, I made sure that in the TCP preferences, checksum validation is unchecked, and "allow subdissector to reassemble TCP streams is checked." I also made sure that "Reassemble SSL records spanning multiple TCP segements" and "Reassemble SSL Application Data spanning multiple SSL records" were checked within the SSL preferences. I also upgraded to v1.6.1, in case there was something wrong with my version. Despite all this, this problem persisted - the packets are not reassembled.

In the packets marked "[Unreassembled Packet]", there is an error message, stating:

[Expert Info (Warn/Reassemble): Unreassembled Packet (Exception occurred)] [Message: Unreassembled Packet (Exception occurred)] [Severity level: warn] [Group: Reassemble]

Your help would be appreciated.

Many thanks,

Salem

asked 11 Aug '11, 08:54

Salemicus's gravatar image

Salemicus
1●1●1●1
accept rate: 0%

Hi Salem

I had the same issue as you... Have you checked that "Allow Subdissector to reassemble TCP streams" under TCP protocol settings is checked? (If you hover over the "Reassemble SSL records spanning multiple TCP segments" in the SSL properties it mentions this, that's how I figured it out ;-)

It fixed it for me!

Cheers Ian

(15 Sep '11, 06:58) ipittam

I am having the same problem, was anyone able to find what the issue was?

(03 Jul '12, 06:36) juanJmtz

One Answer:

1

Please make sure the following requirements are met:

  • The packets are not truncated (so no snaplength used at capture time)
  • There are no duplicate packets (when spanning a vlan, make sure you only span RX packets). If there are duplicated, either remove them with "editcap -d" or use "Edit -> ignore packet" on the duplicates)
  • In the IP protocol preferences, enable "Reassemble fragemented IPv4 datagrams"
  • In the TCP protocol preferences, disable "Validate the TCP checksum"
  • In the TCP protocol preferences, enable "allow subdissector to reassemble TCP streams"
  • In the SSL protocol preferences, enable "Reassemble SSL records spanning multiple TCP segements"
  • In the SSL protocol preferences, enable "Reassemble SSL Application Data spanning multiple SSL records"

If things are still not dissected properly, please post your capture file to www.cloudshark.org and paste the link to the file here in a comment.

answered 03 Jul '12, 10:01

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

The packets are truncated: headers + 32 You know for some reason editcap -d is not eliminating the duplicates, even though I am seeing them in the trace, there are too many dups to ignore them 1 by 1. The traffic is being span via a VACL allowing all IP traffic to be sent to the capturing device (I guess this is the same a doing a span on both tx and rx) IP, TCP and SSL settings are set as you recommend.

Thanks for your help.

(03 Jul '12, 11:30) juanJmtz

In your case you have double trouble (and I'm not talking about Stevie Ray Vaughan's band).

Without the full packets, reassembly will not work, so you might see more dissection with reassembly turned off.

Then with your duplicates reassembly would also be problematic. If you can filter one half of the packets with an "eth.addr==xx:xx:xx:xx:xx:xx" filter, you will be able to ignore them all at once :-)

(03 Jul '12, 12:49) SYN-bit ♦♦

For completeness: another possibility in general is that the network has jumbo frames enabled. In this instance you actually will require to set a snaplength of a sensible value (eg: 9000).

(28 Feb '13, 20:04) tychothecat