Ethereal-dev: Re: [Ethereal-dev] RTP Analysis: Need help with redissect_packetsimplementation
From: "Lars Ruoff"
To: "Ethereal-Dev"
Sent: Friday, November 21, 2003 8:22 PM
Subject: [Ethereal-dev] RTP Analysis: Need help with
redissect_packetsimplementation details
> RTP Analysis: need help with redissect_packets implementation details
>
> Hi list,
Hi, sorry that you guys lost in the semifinals, the others had a really
boring style of play. I really thought you guys and the kiwis would
be in the final.
> I still dont understand very well how packets are dissected.
> In my modifications to RTP Analysis, i got rid of the filter expression.
> But in order to redissect the packets, i still call redissect_packets,
which
> in turn calls
> rescan_packets(... , TRUE, TRUE)
> Would there be a significant performance increase if we rather called
> rescan_packets(... , FALSE, FALSE) ??
> Also, I notice that the protocol tree is still being built when there are
> color filters defined.
> (Regardless of the redissect parameter)
If your tap wants the _packet() function to be called, the pacekts must be
completely dissected again.
>
> that's because of a condition in file.c:add_packet_to_packet_list :
> if ((cf->dfcode != NULL && refilter) || filter_list != NULL
> || num_tap_filters != 0)
> create_proto_tree = TRUE;
>
> where filter_list!=NULL if color filters are defined.
> But tap-dissection doesnt have to care about color filters, does it?
> It seems to me that we should add another execution path in the case we
have
> only a tap running that wants to collect some information about the
packets
> it sees.
No, but we MUST redissect the packets if there are color filters defined.
We also MUST redissect the packets if there are tap listeners registered.
Taps and ColorFilters do not interact but they have in common that both of
them need a full packet redissection.
