On 11/01/2013 11:53 AM, Didier wrote:
Hi
To make it worse if I go back and forth to the same packet it will be
dissected one more time.
With complex protocols like DRS (directory replication for Active
directory)
it's really a problem as the UI freeze for a while.
Is the protocol really so complex that dissecting a single packet of
it takes a user-visible amount of time? That seems suspect to me.
So what I did is that I'm dissecting the deferred RPC pointers only if tree
!= NULL the dissection of pointers takes a while because there is ~ 1700 top
level pointers and each of them have a lot inner pointers, DRS is a very
complicated protocol.
Fair enough, that's quite a bit of data to process. The packets must
be enormous.
The reassembled packet payload is 300K but it's compressed, after
decompression it's 2MB of data.
Did you profile the code or can you share a capture?
Problem could be elsewhere, like in dfilter_macro_build_ftv_cache (a usual
culprit)...
Yes I did, I'm writing another email about this expect news soon
om the second pass, but we would have to calculate in advance which
It's not in dfilter_macro... it's in the dcerpc dissector at the heart
of it because of the # of objects.
packets are visible, which may or may not be easy.
Pardon my wireshark ignorance but it really look like the 2nd and the 3rd
pass are recreating the thing from scratch.
Every time we do a dissection it is more-or-less "from scratch". The
This kind of massive DRS is spread on ~300 1500 bytes TCP packets.
That's not a big packet :)
Well by DRS standard it is, and more than the size it's the number of
objects that is important because of the complex structure of this kind
of object.
But then yes agreed that it's not huge packets.
Matthieu.
--
Matthieu Patou
Samba Team
http://samba.org