Ok. Glad to hear this doesn't fall into the category of "You forgot to turn on option XYZ".
I'll see what I can figure out.
Thanks,
Devin
Quoting Guy Harris <guy@xxxxxxxxxx>:
> On Tue, Dec 03, 2002 at 10:47:35PM -0500, dheitmueller wrote:
> > Is there any way to get Ethereal to interpret the "file data" field as
> > DCE/RPC?
>
> Yes.
>
> Fix the bug that's causing it not to realize that the write is to a pipe
> over which DCE RPC stuff is being done. :-)
>
> See the "is this part of DCERPC over SMB reassembly?" code in
> "dissect_write_andx_request()"; it appears that the hash table lookup in
> the "si->ct->dcerpc_fid_to_frame" table isn't finding anything.
>
> I *suspect* the problem is that it's expecting the first part of a DCE
> RPC-over-SMB call to be in an Transaction SMB; however, in this case we
> have:
>
> frame 3 - Transaction SMB request from .80 to .71, containing
> the Bind
>
> frame 4 - Transaction SMB reply from .71 to .80, containing the
> Bind_ack
>
> frame 5 - Write andX request from .80 to .71, presumably
> containing an AUTH3 or something such as that, *NOT* a
> continuation of the Bind or the Bind_ack
>
> Frame 6 - Write andX from .71 to .80, replying to that write
>
> Frame 7 - Transaction SMB request from .80 to .71, containing a
> GetDomainPasswordInfo request
>
> Frame 8 - Transaction SMB reply from .71 to .80, containing a
> GetDomainPasswordInfo reply
>
> and so on, so the write isn't a continuation of a Transaction operation.
> Perhaps once we identify a FID as referring to a pipe over which DCE RPC
> stuff is being done, we need to treat *everything* written to that pipe
> as pipe stuff.
>
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
732-652-5211
