Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: FW: [Ethereal-dev] Any chance to get something like "decode as" for DCE-RPC

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Mon, 06 Sep 2004 22:13:40 +0200
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