NTCreateAndX Response with wrong WordCount.

[Christopher R. Hertel]

On Sun, Aug 01, 2004 at 04:51:01PM -0400, Michael B Allen wrote:
> Christopher R. Hertel said:
> > I am actually seeing 32 bytes in these particular captures.  I keep
> > counting it up to be sure.
> 
> I think you're right. I don't have the captures I was looking at in front
> of me but I recall it was 2 rows of data in the hexdump window in Ethereal
> which would be 32 bytes. I don't know how I counted 16. It was late.
> 
> > The first few of these extra bytes, in all
> > captures I've got, really do look like garbage left over in a buffer (eg.
> > the tail end of the filename from the request).
> 
> Agreed. Maybe it starts with some reserved fields? The second half does
> not look like garbage though.

Even if the second half (or latter 2/3rds or whatever it turns out to be) 
is actual data, there is an underlying problem in the formatting of this 
message.

Consider the NTCreateAndX Response packet I'm looking at right now, for
instance...

The WordCount is 42, but the total number of bytes following the WordCount 
field is 102 (51 words).

Okay, so... Assume that the correct WordCount should be 34 (that's 68
bytes).  In this particular capture (and all I've seen) the result is that 
the ByteCount field (leading the Data block) is zero as I'd expect.  
Unfortunately, that leaves me with 32 bytes of data that's just tacked on 
to the end of the packet.  It's not included in either the WordCount or 
the ByteCount which is very, very wrong (but now outside of the realm of 
possibilities for CIFS).

Okay, so let's see what happens if that 42 value is actually really truly
correct...  The first thing I notice is that the ByteCount then becomes
0xA7A0, which I don't have to translate to know it can't be a ByteCount
value.

So, whatever these extra bytes may be (and I'm really interested in the 
possibilities) W2K and WXP are clearly messing up something.  I'm just 
amazed that the clients parse these things.

...the only other thing that has occurred to me is that Ethereal's parsing
of the 34 word parameter block may be wrong somehow.  I've given it a 
reasonable look-through, however, and nothing pops out at me as being 
"wrong".

This is fun.  :)

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org