Thanks for your quick response.
Yes, enabling those flags does help some. Why aren't those on by
default?
I am still having problems decoding one particular trace which uses the
SAMR function LookupRIDs(). In particular, if "Reassemble DCERPC over
SMB" is disabled, it gets interpreted as a LookupRIDs request. However
if I enabled "Reassemble DCERPC over SMB", the dissector only reports it
as a DCERPC request. Isn't this the exact opposite of what one would
expect.
It could just be that I'm hitting some sort of exception, because I am
attempting to lookup about 2200 RIDs in one request. The server throws
a DCERPC fault (which is expected), but I would believe the request is
still properly formatted.
I have a trace, if anyone is interested.
-Devin
On Fri, 2002-11-08 at 14:01, Ronnie Sahlberg wrote:
> I think ethereal can decode DCERPC carried ontop of SMBreadX just fine.
>
> Make sure you have DCERPC reassembly enabled :
> DCERPC/Desegment all DCEoverTCP (also includes SMB transport)
> SMB/Reassemble SMB Transaction Payload
> SMB/Reassemble DCERPC over SMB
>
> You probably also want to enable NBSS/Reassemble NBSS over TCP
> and TCP/Allow subdissector to desegment TCP streams
>
>
> ----- Original Message -----
> From: "Devin Heitmueller"
> Subject: [Ethereal-dev] Support SMBreadX in SAMR calls
>
>
> > Hello,
> >
> > I've been doing some work with SAMR calls using Ethereal, and I am
> > seeing that Ethereal is incapable of dissecting the trace if the PDU is
> > large enough to require the use of SMBreadX and SMBwriteX.
> >
> > Has anyone investigated being able to handle output represented in a
> > SMBreadX request? Has anyone determined that this is not practical or
> > technically feasible?
> >
> > Thanks,
>
>
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc