Tim Potter <tpot@xxxxxxxxxxx> writes:
> Todd Sabin writes:
>
> > Guy Harris <guy@xxxxxxxxxx> writes:
> > > Using the file/pipe number would probably work as a short-term solution,
> > > as long as you don't run DCE RPC over both port 138 and port 139 SMB
> > > (or, if you do, they get different file/pipe numbers).
>
> [...]
>
> > Anyway, I'm going to try the TCP port plus file id for now. Would
> > love to hear from SMB gurus if that sounds like a reasonable approx.
>
> I had most of a patch to do this. You need to take the uid from
> the sesssetupX packet, the tid from the tconX, and the fid from
> the ntcreateX packet. This information, plus the existing
> guint32 conversation id gives you a unique tuple that you can
> match to a pipe name.
>
Cool. Do you still have the patch lying around somewhere? Can you
send me what you've got so far?
> I ended up getting annoyed at not having a DCE/RPC idl compiler
> that could generate a custom back end (i.e an ethereal dissector)
> so ethereal could become a better netmon.
>
Well, don't give up yet. I don't have a full IDL compiler finished,
but I don't think making ethereal better than netmon fairly soon
requires that. I don't think a similar beast exists for netmon,
outside of MS, for example. Do you know of one?
I find just having the names of the functions being called is a
tremendous help. I've written netmon parsers to do that for samr,
winreg, and a few others. Dissecting all the parameters would be
ideal, of course, but even the parsers supplied with netmon often get
those wrong.
Once these SMB issues are ironed out, I'll work up very basic
dissectors for lsarpc, samr, winreg, wkssvc, etc.
I also want to replace packet-mapi with something that actually works,
but that's separate from the SMB stuff.
Todd