On Sun, Mar 17, 2002 at 10:47:36AM -0500, Todd Sabin wrote:
> I've seen this kind of stuff, too. For me, it's usually win2k doing
> the bind/bind-ack part of its DCERPC session with SMBread/write and
> then switching to SMBtrans for the actual calls. However, your patch
> doesn't fix things for my captures. (It doesn't break anything,
> either.) My traces have this pattern with SMBWriteAndX and
> SMBReadAndX (with no following command), instead of just SMBWrite and
> SMBRead.
Ronnie's changes affected the SMBReadAndX code, rather than the SMBRead
code, so it should work with ReadAndX (but not with Read).
He didn't change the WriteAndX code, though, just the Write code.
> There's also a byte of padding sometimes.
Yes - I checked in a fix for that. (The padding works the same for
DCERPC-over-SMB as it does for ordinary file data, from what I can see.)
> I was looking at how to extend your patch to the other calls, and it
> seemed like it might make more sense to push your changes down into
> dissect_file_data().
That might work. I put in a "dissect_file_data_dcerpc()" routine; that
could, *if* we can make the code common, get swallowed by
"dissect_file_data()" (which would have to have "si->sip", the FID, and
other arguments passed to it).
For SMBWrite, the code dissected it as DCERPC only if the offset is 0.
I don't know what the right thing to do there is; I *assume* similar
things should be done for other write operations. Does that get used in
reassembly?
There's no check of the offset for SMBReadAndX, perhaps because it's
used for reassembly as well.