I just checked in a fix that makes ethereal decode the packet as DCERPC.
The problem in ethereal is that it needs to know the type of TID in order to
know
if the content to read/write is normal file i/o or dcerpc.
If the TreeConnect call is not seen ethereal did not know what type of TID
it is and
assumed it is just a normal share and not an IPC share.
Ethereal only considers read/write calls to contain dcerpc if the TID is
known to be IPC.
The change checked in assumes that if a TransactionSMB is seen that contains
PIPE/DCERPC
then the TID is of IPC type and thus future read/writes on that TID will all
be treated as DCERPC.
> > 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:
>
> I need to look at the source but I think ethereal can dissect SMBWriteAndX
> as DCERPC even if it is not
> part of something that starts with a Transaction.
> However, I think i remember something like it will ONLY consider the data
in
> Read/Write as part
> of DCERPC PDUs if and only if the TID was mounted with a TreeConnect for
> type IPC.
>
> If the TreeConnect can not be seen in the capture, ethereal fails to
decode
> it as DCERPC.
>
>
> Perhaps the heuristics used to consider the data in Read/Write as DCERPC
to
> loosen this
> requirement and set up something similar when it sees DCERPC in
Transaction
> calls
> the same way as if it has seen the previous TreeConnect call.
>
>
> I can look into it but not until the weekend.
> If someone else wants to fix this ethereal bug, please go ahead.
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
