[jcifs] Max size of an SMB Message.

[Christopher R. Hertel]

I am confused about the maximum size of a CIFS message.  Here's what I do
know:

- The NBT header has a length field that is 17 bits wide (per the RFCs,
  though I think that many implementations use only 16 bits).

- The raw TCP transport header is 24 bits wide.

- Prior to NT LM 0.12, the MaxBufferSize field in the Negotiate Protocol
  Response was an unsigned short, allowing for at most 64K.  According to 
  the SNIA CIFS TR, the MaxBufferSize is an unsigned long as of NT LM 0.12.

The next thing that I note is that the Data portion of an SMB message
(that's the part preceeded by the ByteCount field) has a maximum size of
2^16 - 1 (64K - 1) bytes.  That, of course, is because the ByteCount field
is an unsigned short.  Easy 'nough.  The WordCount field is a single byte,
so it has a maximum value of 255 which is multiplied by 2 (because we're
counting 2-byte words now) and that gives 510.  Add 2 bytes for ByteCount
plus 1 byte for WordCount and 32 bytes for the header...

     32
      1
      2
    510
+ 65535
-------
  66080 is what I get.
  That fits within the smaller NBT session header length:
  (2^17 - 1) == 131071.

Things get a little wierd, though, when I start digging into
CAP_LARGE_READX and CAP_LARGE_WRITEX.  I understand the idea here (I
think).  It should be possible to send and receive very large chunks of
data using these capabilities.  The underlying TCP session will take care
of frag/defragmenting the data...

So here are my questions (finally):

1) Is the length field in the session header used or ignored? That is, if 
   I am sending messages via NBT and I try to send an SMB that is, in
   total, larger than 2^17 - 1 bytes long will the system choke?

2) Is the MaxBufferSize in the NegProt Response a hard-and-fast rule
   (ignoring, of course, the MaxRawSize field and the depricated raw
   read/write SMBs)?

3) In the SNIA doc, in section 4.1.1, in the explanation of the
   Capabilities bits, it says:

    CAP_LARGE_READX   0x4000  The server supports large SMB_COM_READ_ANDX 
                              (up to 64k)
    CAP_LARGE_WRITEX  0x8000  The server supports large SMB_COM_WRITE_ANDX
                              (up to 64k)

   The "up to 64k" doesn't make sense. We can already fit 64k-1 bytes into
   the normal buffer without using LARGE_READX/WRITEX.  What is the
   maximum, however?  My guess is that the max would be MaxBufferSize.

4) In the SNIA doc, section 4.2.4, the MaxCountHigh field is listed as:

    ULONG MaxCountHigh;   /* High 16 bits of MaxCount if CAP_LARGE_READX; 
                           * else MUST BE ZERO */

   That's got to be and unsigned short, not a long, yet even Ethereal 
   (0.9.6)  shows it as a long.  Why are 32-bits being used to store
   16-bits?  What am I missing?

   My claim that this field should be a USHORT is backed up by the
   possible values of the WordCount field, which are given as 10 or 12.  
   If I include the OffsetHigh field, I get a total of 13 words. That's
   one one word too many.

I think that what I have here is a collection of small oddities. Anyone 
willing to shed light on any of it?

Thanks.

Chris -)-----