----- Original Message -----
From: "Tim Potter"
Sent: Monday, January 14, 2002 9:07 AM
Subject: Re: [Ethereal-dev] dissect_ndr_pointer() experimental unfinished
implementation, comments wanted
> Hi Ronnie. I might steal some of your ideas for the dcerpc over smb
> code. (-: In particular the idea of passing a pointer type in is
> probably better than my long-winded prs_struct_and_referents() function.
Thanks, though it would be even nicer if when dissect_nds_pointer() is
working
that one could be used instead, also for the NT services running over
DCERPCoverSMB.
>
> The problem I found that was slightly difficult to deal with is that
> you need to pass back return data from each of the parse functions if
> you want to have nice dissection of things. So parsing a list of
> embedded pointers should return a list of return data.
What data would be nessecary to pass back from the dissector?
I can think of two cases of the top of my head,
1, putting stuff into COL_INFO which could be done just as well
from the dissector for the structure itself, or
2, putting stuff on the item under which the tree for the structure is
expanded.
This could potentially also be done from the dissector itself by using the
tree parameter and figuring out
which item the tree is attached to and then proto_item_append_string() or
whatever. ?
Perhaps one can use a global variable if one really needs to pass data back
through dissect_ndr_pointer()
ugly yes but it would not require the function pointer prototype for
dissect_ndr_pointer() to be modified.
Since i havent implemented any dissectors yet for dcerpc i do not understand
yet which requirements there are
for subdissector to pass data between them.
Ofcourse, for handwritten structure dissectors, where one knows there will
NOT be any non-first
I did choose the current function pointer prototype because that would have
the dissector for structures be identical to
dissectors for requests or responses. Making all dissectors, be it for
requests/responses structures or arrays (or anything else)
have the same function prototype would make it much easier to automate
generate dissectors from the idl file.
(i think so, i have not got far enough to see if this is a valid claim or
not)
One other thought, i also think the following would make life easier for an
automatic tool:
i propose the following naming convention for use with all dissectors for
dcerpc:
dissect_ndr_<structure_name>
<structure_name> would then be the name for this structure as used in the
samba sources.
(or the naming used by freedce, project which also might benefit from full
support in ethereal
for these services)
Of course, special common structure dissectors could be handcoded and placed
in packet-dcerpc-ndr.c
I think here primarily of dissect_ndr_UNI_STR2() (or whatever it is called
(no samba sources available right here)).
The primary goal i have is to produce a crude idl compiler to genereate a
standard ethereal dissector once , then to hand massage
the generated dissectors to add stuff like prettifying COL_INFO, tree
expansions etc etc.
It is in this light you must see my desire to have a generic function
prototype to all dissectors for any type of datatype in dcerpc.