This is our old Q&A Site. Please post any new questions and answers at

So I am reassembling fragments together into complete messages and I started to get a strange bug whenever I test my dissector on large pcap files. My dissector makes its initial pass though all the packets but when it makes its second pass it will randomly process the first packet again in the middle of everything. It runs the first packet through the dissector in the middle of reassembling another message which throws off the reassembly of that message. Is it normal behavior for dissectors to do this?

Thank you, James

asked 12 Jun '17, 10:37

jpetersen's gravatar image

accept rate: 0%

edited 12 Jun '17, 10:38

Hi,excuse me for this command.i have a question about reassembly in a dissector.can you take a look at my question, The function always return zero and dissector dosent Reassemble fragments.what is my problem

(12 Jun '17, 11:52) hhw

@hhw, Please don't attempt to hijack other questions even if they do seem related.

(12 Jun '17, 12:04) grahamb ♦

That's probably a relic of the UI. It may be redrawing your display which probably currently has frame 1 selected.

Note, however, that this isn't a bug--except possibly in your dissector. Your dissector needs to do any reassembly on the first pass (when pinfo->fd->flags.visited in 0).

(It also needs to be prepared to process the saved results of that reassembly in any order--the user may click on packets in any order thus causing redissection of (only) those selected packets.)

permanent link

answered 12 Jun '17, 14:01

JeffMorriss's gravatar image

JeffMorriss ♦
accept rate: 27%


Thank you JeffMorris for your reply, that makes a lot more sense now.

I see that I am not doing reassembly exactly correct, when I tried to put this (pseudocode):

if (pinfo->fd->flags.visited == 0) reassemble();

it wouldn't return the reassembled_tvb but instead it just returned the tvb of the last packet. I believe that I can figure this one out on my own though unless you see that I am misunderstanding this.

However, to your last point, this is an issue I have been frustrated with about my dissector. After the initial pass through when a user is looking through the packets, it will only reassemble if the initial packet is selected first. I have been looking for a way to remedy this (suspecting that my code is not quite right..) Will reassembling it only in the first pass solve this? Or should I look into another option as well?

Thank you again

(12 Jun '17, 15:35) jpetersen

No problem - though now I worry I may have led you astray.

In fact Wireshark's reassembly routines (epan/reassemble.c) do check the visited flag for you--so if you're using them you actually don't need to check the flag yourself.

But, OTOH, if you're using them then they should "just work" even when frames are dissected (in the 2nd pass) out of order.

What reassembly API are you using?

(13 Jun '17, 08:55) JeffMorriss ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 12 Jun '17, 10:37

question was seen: 1,027 times

last updated: 13 Jun '17, 08:55

p​o​w​e​r​e​d by O​S​Q​A