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.
On Mon, 06 Sep 2004 22:13:40 +0200, Ulf Lamping wrote:
> Eric Wedel wrote:
>
> >Ulf Lamping schriebt:
> >
> >
> >
> >>>Looking forward to the UI stuff whenever you get a chance.
> >>>
> >>>
> >>>
> >>>
> >>Yes, that's the point: "whenever you get a chance". Sorry for the delay,
> >>I just have a lot of things on my Ethereal (and my private) to do list.
> >>
> >>
> >
> >Not that I wish you to slow down, but I've been pondering / waiting for
> >this for well over a year now. A few extra weeks (or whatever) aren't
> >that much more. :-)
> >
> >
> Hmmm, I understand ...
>
> >I'm just grateful that it is likely to get done at some point.
> >
> >
> Well, I've just checked in some more changes for the dcerpc "Decode As"
> thing.
>
> I've almost done the straight GUI related things (no real cleanup code),
> but now I've running into a more serious problem.
>
> I got the "Decode As" dialog running for the first time (showing up the
> DCE-RPC page with the interface names), with a lot of things need to
> think about (still commented out, see gtk/decode_as_dlg.c line 1720 to
> 1726).
>
> But when I implemented the interface to the DCE-RPC things, I'm running
> into deep trouble.
>
> You've added a function to add a new bind mapping to the bind hashtable,
> which looked ok at first sight.
>
> But the problems is buried into timing. When calling "Decode As",
> everything regarding dissection is already done. So it seemed to be the
> right thing to inject the binding into the hashtable and redissect
> everything.
>
> 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 :-(
>
> The right thing might be to inject the "Decode As" bindings (from
> ctx_id, smb_fid, srcport, destport, srcip, ...) before continuing
> dissecting the first packet (again).
>
> But there might be a better way...
>
> Regards, ULFL
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
