ronnie sahlberg wrote:
A simple workable solution might be to just stop having ethereal
clear/flush this table when the redissection is done.
I.e. removing the "flush table" thing in the xxx_init() routine.
It will increase the likelyhood of incorrect dissection for the case
where you load a new capture and a different DCERPC interface is
signalled ontop of the exact same
socket-pair (and SMB FID for ncacn_pipe transport).
I dont think it is very likely for this to happen though.
But trying to redissect the packets, this is leading to remove both the
complete binding and conversation tables (which must be done), so even
keeping the conv pointer won't help much here, as the complete
conversations are rebuild :-(
Well, there are some problems here.
At first, your approach will become an ongoing memory leak, if the
tables were not g_hash_table_destroy()'ed.
Another problem is that there are *two* tables destroyed when
redissecting packets, see below.
The conversation table (containing 2*ip + 2*port + x -> conv) is
destroyed when redissecting. I don't want to change this, as it might
interfere with other dissections and I also think it is reasonable to
destroy it.
This results in having to keep the values leading to a conversation
(2*ip + 2*port) in the "Decode As" thing, instead of keeping only a
pointer to the conversation which I'm doing now. This must be done, as
simply keeping the pointer to the conversation is pretty useless after
throwing away the whole conversation table.
The binding table (containing ctx_id + smb_fid + conv -> uuid
conversions) is destroyed when redissecting, which is ok as the
conversation table (the basis) is "already" gone.
After some sleep, I think I have to keep the conversation basis (2*ip +
2*port) somewhere in the "decode as", and reinject it every time the
dcerpc is doing a dcerpc_init_protocol(), where the dcerpc_binds
hashtable is reinitialized.
There is still one drawback in this approach: you cannot replace a
"correct" binding with the decode as, as a new binding always replaces
the entry in the bindings hashtable :-( But this is not scope I'm in, as
I only want to attach a specific interface to an *unknown* binding. And
I could think of solutions to this, like keeping a flag in the bindings
if the entry is a "decode as" entry or not and always "forcing" that one.
Regards, ULFL
