[jcifs] Re: Sanity check.

Simo Sorce simo.sorce at xsec.it
Tue Sep 10 17:39:28 EST 2002

It come me to mind that recentely we changed the code to check the
packet is really an smb packet by checking the header field for the SMB.
string, so I suppose samba will not support RAW calls anymore too.


On Tue, 2002-09-10 at 06:49, Christopher R. Hertel wrote:
> Just a quick sanity check, if any of you have the time.  In my book I'm
> trying to describe the MaxBufferSize and MaxRawSize fields in the NegProt
> response.  I neither want or need to go into great depth, but I do need to
> be as close to correct in my descriptions as SMB allows.  If anyone has
> any constructive criticism on the notes below please send it along.
> Looking forward to your replies.
> Chris -)-----
> MaxBufferSize
>     MaxBufferSize is the size (in bytes) of the largest message that the
>     server can receive.  Keep in mind that the transport layer will
>     fragment and defragment packets as necessary. It is, therefore,
>     possible to send very large SMBs and let the lower layers worry about
>     ensuring safe, fast, reliable delivery.
>     How big can an SMB message be?
>     In the NT LM 0.12 dialect, the MaxBufferSize field is an unsigned
>     longword. As described much earlier on, however, the Length field in
>     the NBT SESSION MESSAGE is 17-bits wide and the naked transport header
>     has a 24-bit Length field. So the session headers place slightly more
>     reasonable limits on the maximum size of a single SMB message.
> MaxRawSize
>     This is the maximum size of a raw data buffer.
>     The X/Open doc describes the READ RAW and WRITE RAW SMBs, which were
>     introduced with the Extended 1.0 version of SMB (the MICROSOFT
>     NETWORKS 3.0 and LANMAN1.0 dialects). These were a speed hack. For a
>     large read or write operation, the first message would be a proper
>     SMB, but subsequent messages would be sent in "raw" mode, with no SMB
>     or session header. The raw blocks could be as large as MaxRawSize
>     bytes in length. Once again, the transport layer was expected to take
>     care of fragmentation/defragmentation and the re-sending of any lost
>     packets.
>     Raw mode is not used much any more. Among other things, it conflicts
>     with message signing because there the raw messages have no header in
>     which to put the MAC signature. Thus, the field is considered obsolete.
> -- 
> 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
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/jcifs/attachments/20020910/f0ec29ae/attachment.bin

More information about the jcifs mailing list