[Eric Wedel <ewedel@xxxxxxxxxxx>]

That was indeed the first place I looked, prior to diving into the code.

While it is certainly nice to be able to override the interpretation of a
packet manually, there is something to be said for "automatic guessing" as
well.  Question then is what sort of guidance to give the guessing
machinery.

Whether it is opnum-based inference as in my earlier post, or something
along the lines of Tim's suggestion where various subdissectors are allowed
a go at the packet, both a "master switch" option to disable the heuristic
and some more detailed guidelines would be helpful.  In the opnum-based
approach, this would probably be a user-assignable opnum -> UUID map.  In
the dissector probe case, perhaps an order of precedence in trying the
various dissectors on a packet?

*sigh*, this is all sounding rather complex.  UIs in general are not my
strong suit, and I have exactly zero experience with GTK.

On the DecodeAs... side of things, seems almost like a sub-dialog would be
needed to select UUID iff the RPC transport was selected.  Or perhaps a
"session" tab, if one could construe a specific RPC interface as
session-level?

Preferences?  And anybody know how GTK UIs are developed in the ethereal
environment?
I'm hoping there is some "dialog editor" sort of thingie.

regards, Eric

> -----Original Message-----
> From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx]
> Sent: Thursday, October 09, 2003 1:03 AM
> To: Tim Potter; Eric Wedel
> Cc: ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] Missing UUID inference
> 
> 
> I think the optimal would be if a DCERPC packet was selected
> then Tools/DecodeAs one could select any of the protocols that
> were registered atop DCERPC for that conversation/contextid
> 
> 
> ----- Original Message ----- 
> From: "Tim Potter"
> Sent: Thursday, October 09, 2003 2:16 PM
> Subject: Re: [Ethereal-dev] Missing UUID inference
> 
> 
> > On Wed, Oct 08, 2003 at 07:19:07PM -0700, Eric Wedel wrote:
> >
> > > We just had a field case where the customer seemed unable 
> to obtain full
> > > traces.  Instead, they kept giving us traces where the 
> DCERPC bind had
> > > happened sometime earlier, so ethereal didn't know how to 
> interpret
> > > subsequent traffic.
> > >
> > > Looked through 0.9.15, and couldn't see any option to 
> force the UUID.
> So I
> > > knocked together a little hack to guess the UUID when a 
> request is seen
> > > whose conversation doesn't have a known binding.  Patch 
> is attached for
> your
> > > amusement.
> >
> > It would be nice to be able to select from a list of known 
> uuids I think.
> >
> > > discussion, not sure if this idea has been considered 
> before.  I can
> tell
> > > you that when you need it, this is *very* helpful.  :-)
> >
> > Yep.  Especially from customer traces where they haven't 
> started capturing
> > early enough or for long running dcerpc processes where it wouldn't
> > be practical.
> >
> > It should actually be possible to make the subdissectors 
> heuristic as
> there
> > should only be one (or maybe one or two) that dissects a 
> given packet
> > properly.  That would be neat.
> >
> >
> > Tim.


*********************************************************************
This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to sysadmin@xxxxxxxxxxx
*********************************************************************