On 04/15/2014 02:18 PM, Evan Huus wrote:
On Tue, Apr 15, 2014 at 1:57 PM, David Ameiss <netshark@xxxxxxxxxxxxx> wrote:
I could be wrong, but I could swear that, until recently, conversations
essentially had capture lifetime. So that, from one pass of the capture to
the next, the conversations (and any proto data stored in them) remained.
That is correct. The conversation data (typically from
find_or_create_conversation) will persist across passes of the
capture. Additional data stored with that conversation via
conversation_add_proto_data will be persisted (or at least, a pointer
to it will be; the data itself should be allocated with
wmem_file_scope in order to persist correctly).
That does not seem to be the case now. Between one pass of the capture
(pinfo->fd->flags.visited == 0) and the next (pinfo->fd->flags.visited ==
1), the conversation data seems to have been nuked.
Note: this is the git development tree.
Has this changed? Or did I completely misunderstand the scope of
conversations, and have just been lucky until recently?
Something funny's going on. Either a bug in libwireshark, or you're
accidentally misusing and API, or something. Can you turn this into a
small reproducible case?
Evan
It was apparently me. I setup some synthetic conversations (based on
advertisements) with frame 0 - and that caused subsequent passes to not
find the conversation created in the first pass. Interestingly, turning
on the conversation debug code, on subsequent passes it couldn't find
the conversation I had added (using frame 0) - but when adding the
conversation, it *did* note that a chain already existed.
Using the actual frame, everything seems to work correctly.
--
David Ameiss
netshark@xxxxxxxxxxxxx
