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
