Ethereal-dev: Re: [Ethereal-dev] RE: Missing UUID inference

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

From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
Date: Sat, 25 Oct 2003 12:52:09 +1000
Please study how the DecodeAs dialog works.

The best solution is likely to be to extend the DecodeAs dialog so one can
map a specific DCERPC interface
onto a specific conversation/contextid.

I dont think it should be implemented as a DCERPC specific dialog since
ethereal already has a dialog for this puprose
albeit this dialog does not currently handle DCERPC


This would be very useful so please take a stab at implementing it.

----- Original Message ----- 
From: "Eric Wedel"
Sent: Saturday, October 25, 2003 12:40 PM
Subject: [Ethereal-dev] RE: Missing UUID inference


> Hi..
>
> Have spent some quality time trying to come up with a UI for setting the
> opnum / UUID inference associations suggested for the below patch.
>
> Actually, two approaches were suggested:  1) call each DCE/RPC
subdissector
> looking to see which can handle the protocol (no prefs UI needed,
> presumably), or 2) set up a prefs UI which can be used to set the opnums
> which imply a given UUID.  The idea in either case being to get away from
> the present hard-coded knowledge of just a few (probably
> application-specific) opnum/UUID inferences.
>
> Regarding option (1), it seems the DCE/RPC subdissectors are not presently
> structured to provide a go/no-go sort of response.  They merely return an
> offset indicating how much of the packet they "consumed."  Consumed in
> quotes since at least some of the NDR parsing seems to advance the offset
> regardless of whether the data is valid.  So it doesn't even seem
practical
> to use the offset output to decide whether a dissector likes a packet.
>
> For option (2), I tried the simple approach of adding an integer
preference
> to the main DCP/RPC preferences pane for each UUID, to allow selection of
> opnum per UUID mapping.  This produced a totally unworkable preferences
> dialog, since the dialog apparently has no provision for introducing a
> scrollable child pane when the full set of preferences items for a module
> exceeds a "reasonable" dialog window size (whatever that might be :-).
> There are a lot more DCE/RPC subdissectors than I had thought.
>
> At this point, it seems like the best approach would be a custom dialog
> linked from a button on the DCE/RPC preferences pane.  The present generic
> preferences machinery used by the dissectors doesn't seem to support this.
>
> I'd be willing to take a stab at it, but it is not clear to me what giving
> the DCE/RPC dissector knowledge of a GTK dialog callback (as needed by the
> button setup, presumably) would do to tethereal.
>
> Comments / suggestions very welcome at this point.
>
> thanks, Eric