On Fri, Dec 07, 2001 at 10:06:36PM -0500, Todd Sabin wrote:
> > There are quite a lot of bugs in netmon if you use it for any length of
> > time. I'm also including the fact that it's really hard to decode the
> > output as a bug and the fact that most pipes are deliberately not
> > decoded (samr, spoolss for example).
>
> Those are more like missing features to me. :) Besides, you can write
> you own netmon plugins, too. E.g., http://www.webspan.net/~tas/netmon
Right - another Samba team member has a plugin from Microsoft that is
supposed to dissect WINS replication.
> Of course, ethereal is better that netmon+those at this point.
No arguments there.
> I wrote a traditional lex/yacc parser based on the specs at
> http://www.opengroup.org/onlinepubs/9629399/toc.htm. I can parse most
> of the stuff in the spec, but generating stubs or code is a ways off.
> What kind of code are you spitting out? ethereal dissector? rpc stubs?
This is the kind of stuff it is spitting out:
static int LsarOpenPolicy_q(tvbuff_t * tvb, int offset,
packet_info * pinfo, proto_tree * tree,
char *drep)
{
ptr_server = prs_ptr(tvb, offset, pinfo, tree, "server");
if (ptr_server) {
prs_wchar_t(tvb, offset, pinfo, tree, flags, "server");
}
ptr_attribs = prs_ptr(tvb, offset, pinfo, tree, "attribs");
if (ptr_attribs) {
prs_OBJECT_ATTRIBUTES(tvb, offset, pinfo, tree, flags,
"attribs");
}
prs_uint32(tvb, offset, pinfo, tree, "access");
return 0;
}
I still need to convert it to the "offset = dissect_blah(...)" pattern
(again - the first try lost in a hd crash )-:) as well as write a
whole bunch of helper funtions for parsing scalar types as per
packet-dcerpc.c
About packet-dcerpc.c, I'm not sure it's necessary to give every
element it's own hf field and associated searching and filtering
capability. In fact I'm tempted to put no filtering at all in the
NT dcerpc dissection code initially and then go back and add fields
as necessary.
> Honestly, I think you'd do better to refer to the NDR specs inside
> http://www.opengroup.org/onlinepubs/9629399/toc.htm. Last time I
> looked, the samba parse code had lots of "unknown_N" stuff in it which
> is explained by the rules of NDR. If you've never looked at the stuff
> on the wire, the NDR explanation might be somewhat bewildering. OTOH,
> if you have looked at the stuff on the wire, but not the NDR docs,
> you'll find lots of light bulbs going on as you read it and compare
> with traces.
I've been using both resources for this task and discovering what
a lot of the unknown stuff is. People have known more about NDR for
quite a while but no-one has gone back and refactored the rpc parsing
code to reflect this. )-: There are all sorts of unecessary calls
to prs_align, and the handling of arrays is very messy.
Tim.
