Hi, this is your lucky day.
There is already means for this in dcerpc, regardless of whether you use
dissect_ndr... or not.
di=pinfo->private_data
foo=di->call_data->private_data
foo is initialized to NULL whenever a new DCERPC request is seen.
You can allocate data and assign it to di->call_data->private_data anywhere
in a dcerpc subdissector.
The value will be persistant between scanning the packet list and between
each request/call pair.
If you allocate a block of memory to store in di->call_data->private_data
YOU are responsible to deallocate that memory
whenever a new capture is opened etc or ethereal will leak.
This can be used to pass data between subdissector levels or between
request/response.
----- Original Message -----
From: "Tim Potter" <tpot@xxxxxxxxx>
To: "Richard Sharpe" <rsharpe@xxxxxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Sent: Saturday, March 16, 2002 8:22 AM
Subject: Re: [Ethereal-dev] Returning strings for later use in other places
in the DCERPC dissectors ...
> On Sat, Mar 16, 2002 at 07:15:24AM +1030, Richard Sharpe wrote:
>
> > In looking at prettying up some aspects of the DCERPC dissector I would
> > like to be able to take some parts if the objects dissected and place
them
> > in the INFO field.
> >
> > However, since each dissector returns how many bytes it consumed, this
is
> > not currently possible.
>
> Yes that would be very handy. Only the spoolss dissector (which doesn't
> use the dissect_ndr functions yet) can pass data upstream for inclusion
> in the info field.
>
> I haven't thought of a good solution other than returning a GList of
> items parsed.
>
> > I guess that we could return this info in another param passed to each
of
> > these functions, but it sure would be nice if we had a protocol tree as
an
> > attribute-value tree that we could search for info :-)
>
> Like a GHashTable or something?
>
>
> Tim.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev