Ethereal-dev: Re: FW: [Ethereal-dev] Any chance to get something like "decode as" for DCE-RPC
On Tue, 07 Sep 2004 10:23:03 +0200, Ulf Lamping wrote:
> At first, your approach will become an ongoing memory leak, if the
> tables were not g_hash_table_destroy()'ed.
There are several other state mechanisms already in ethereal that will
slowly leak memory anyway.
Ethereal is not a "capture forever until end of time" tool anyway.
>
> Another problem is that there are *two* tables destroyed when
> redissecting packets, see below.
Ah, yes. Good point.
>
> 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.
No, that one is probably best left the way it is, too much depend on
that state structure so emantic changes to it might have unexpected
sideeffects.
>
> 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.
ip and port can be found from pinfo, so the dcerpc conversation
manager can keep these and match these one explicitely in its own conv
handling without relying on the tcp/udp/whatever conversation id being
the same from rescan to rescan.
it should be reasonably painless to detangle the dcerpc conversation
tracking from the normal conversation tracking. replace a
conversdation identifier in the structs with the protocol/ip/port
pairs from the pinfo struct itself.
>
> 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.
change this one to ctx_id +smb_fid + pinfo->ip/port -> uuid
then it doesnt matter if the real conversation table is destroyed and rebuilt.
>
> 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.
maybe, but removing the conv dependensy above would not make it neccesary.
>
> 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 :-(
This should not be too much of a problem, this only means that IF
ethereal has seen a Bind/BindAck that that one will override whatever
setting someone has done with DecodeAs.
I think that is fair enough. The problem we want to solve are those
packets where there are no Bind/BindAcks at all in the capture.
