Re: Sanity check.
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/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED] -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: Sanity check.
On Tue, Sep 10, 2002 at 09:39:28AM +0200, Simo Sorce wrote: 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. Nope - not true. Raw calls are handled inside the reply_readbraw/reply_writebraw functions - the initial header is all that is needed checked. Raw still works ok. Jeremy.
Re: [jcifs] Re: Sanity check.
On Tue, Sep 10, 2002 at 08:08:38AM +, [EMAIL PROTECTED] wrote: On Tue, Sep 10, 2002 at 09:39:28AM +0200, Simo Sorce wrote: 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. Nope - not true. Raw calls are handled inside the reply_readbraw/reply_writebraw functions - the initial header is all that is needed checked. Raw still works ok. The \xFFSMB string would be in bytes 4..7. The first four bytes (0..3) are the message length, which should always be -le the negotiated buffer size. My memory of the discussion at the CIFS conference was that the initial check simply validates the length to insure that the packet is sane. Checking for the \xFFSMB string would happen after the length check. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Sanity check.
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/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
