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" <[EMAIL PROTECTED]> To: "Richard Sharpe" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://www.ethereal.com/mailman/listinfo/ethereal-dev
