[jcifs] Re: Sanity check.

[Simo Sorce]

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.

Simo.


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