Comment # 20
on bug 8089
from Evan Huus
(In reply to comment #19)
> I attempted to run the existing config_frame_fast code for each
> "configuration" message before, but found that the conversation structure
> was always over-writing the previously-saved config message with the current
> one. So all I ever ended up with was a A5D3 message (as that's typically
> the last config message encountered). I guess it's down to my lack of
> understanding of how to utilize the conversation functionality to save
> multiple config packets and be able to iterate through them later.
Oh, I think I understand the confusion now.
Conversations allow you to associate a single pointer (to an arbitrary data
structure) with a collection of packets travelling over the same connection (as
identified by address+port combination).
Although conversations by definition include multiple packets, the conversation
library does not automatically provide a pointer per
packet-in-the-conversation, as many conversations don't need to track this
amount of data (the current TCP window size, for example, is a single data
point regardless of the number of packets processed).
If you want a structure per packet in your conversation, you need the
conversation to point to a wrapper object that contains a list.
Off the top of my head, the 'standard' pattern should look something like:
/* if it's a packet we haven't seen yet */
if (!pinfo->fd->flags.visited) {
/* find an existing conversation or create a new one as necessary */
conversation = find_or_create_conversation();
/* get the data for this conversation */
data = ""
/* if this conversation doesn't have any data yet, this is the first packet
* in the conversation, so create a new structure for it and add it to
* the conversation data */
if (data == NULL) {
data = ""
conversation_add_proto_data();
}
/* now that data is guaranteed to exist, do whatever logic is necessary
* to add the current frame to it's stored information (appending it to a
* list or what have you) */
update_data_for_new_packet();
}
You almost never want to conversation_add_proto_data more than once for a given
conversation.
> I am thinking that moving over to the new memory management system is beyond
> my capabilities, at least without plenty of pre-existing examples to refer
> to. Can I put it out there that you could modify the existing selfm code to
> use the new library? I'd be happy to verify that all the functionality
> works as before, and you get a showcase for the new library! :) Mind you,
> I understand if you're tied up with other things and can't take that on.
Hopefully my explanation of how conversations work will clear things up. If not
then I'll take a crack at it at some point, but it may be a while.
Cheers,
Evan
You are receiving this mail because:
- You are watching all bug changes.