[cifs-protocol] Status: SRX091209600095 [MS-SMB] error returns

Christopher R. Hertel crh at ubiqx.mn.org
Wed Jan 27 11:50:16 MST 2010


Just to be more clear...

[MS-CIFS] specifically covers the NT LM 0.12 dialect as implemented in
Windows NT.

* Windows NT *never* clears that bit.  Therefore, the first change
  (changing the "MUST" to "SHOULD" is absolutely incorrect.  It MUST
  be "MUST", since NT does not vary its behavior.

* The WBN, aside from being somewhat unclear, introduces several
  references to OS/2 LANMAN behavior.  That's okay on the surface,
  but it's an unnecessary reference to the behavior of older dialects.
  We try, as much as possible, to direct readers to the actual
  IBM, Intel, Microsoft, and Open Group documentation for all questions
  regarding LANMAN, XENIX, and Core Protocol behavior.  We *do not*
  want to try and cover the older dialects in this document.  (It'd
  bloat the doc like crazy and just muddy the waters more than they
  already are.)

* [MS-CIFS] already provides wire-format definitions for the STATUS_OS2_
  error codes.  The internal definitions are never seen on the wire, so
  we provide the wire-format 32-bit definitions (which are identical to
  the wire format CLASS/CODE values that would be indicated if that bit
  were turned off).

[MS-SMB] covers changes and extensions to the protocol starting with Windows
2000.  So...

* In [MS-SMB], we will add a WBN and additional notes explaining that
  Windows 2000 and above *do* clear that bit when sending any of the
  following:
  + STATUS_INVALID_SMB
  + STATUS_SMB_*
  + STATUS_OS2_*

* The above set of error codes can be interpreted either as CLASS/CODE
  paisr or as 32-bit codes.  There are no collisions or other problems
  if you interpret them either way.

There is no perfect solution to this problem, since it's really a problem
with the NT implementation itself.  The whole thing appears to be some sort
of interoperability work-around kludge that was never fixed quite right.  My
goal, when coming up with the current text, was to make sure that [MS-CIFS]
was at least consistent in its presentation.

Chris -)-----

Bill Wesse wrote:
> Good morning Chris. I am advised we have some changes planned for [MS-CIFS] concerning error codes. I have attached a pdf showing the tentative changed text, which addresses the SMB_FLAGS2_NT_STATUS bit, along with a Windows Behavior note.
> 
> Please let me know your considerations concerning this.
> 
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:	billwe at microsoft.com
> Tel: 	+1(980) 776-8200
> Cell: 	+1(704) 661-5438
> Fax: 	+1(704) 665-9606
> 
> 
> -----Original Message-----
> From: Bill Wesse 
> Sent: Thursday, January 14, 2010 2:45 PM
> To: 'Christopher R. Hertel'
> Cc: tim.prouty at isilon.com; Jeremy Allison; pfif at tridgell.net; cifs-protocol at samba.org; Gary Shang; José Rivera
> Subject: RE: STATUS_OS2_INVALID_LEVEL
> 
> Thanks for the clarification about the SMB_FLAGS2_NT_STATUS bit flipping (I inadvertently generalized that to your comments concerning 32-bit wire-identical to DOS&OS/2 style Class/Code pairs).
> 
> As you have already seen (or will no doubt shortly see), the internal conversation about whose lap the work will land in is expanding.
> 
> Concerning the supplemental content (if that becomes necessary), a KB sounds reasonable - we do have some KBs that fall into that brain space (for example, the following, which I think may need an update):
> 
> INFO: Mapping NT Status Error Codes to Win32 Error Codes
> http://support.microsoft.com/kb/113996
> 
> On that same topic, I am sure there are better formats that could made available on a possible Blog entry (http://blogs.msdn.com/OpenSpecification); zipped attachments there could include .csv (or tab-delimited) files running this down (and don't we all love those when we have source identifiers / enum's / data to declare...). Nothing like a good old-fashioned regex party!
> 
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> Email:	billwe at microsoft.com
> Tel: 	+1(980) 776-8200
> Cell: 	+1(704) 661-5438
> Fax: 	+1(704) 665-9606
> 
> -----Original Message-----
> From: Christopher R. Hertel [mailto:crh at ubiqx.mn.org] 
> Sent: Thursday, January 14, 2010 2:16 PM
> To: Bill Wesse
> Cc: tim.prouty at isilon.com; Jeremy Allison; pfif at tridgell.net; cifs-protocol at samba.org; Gary Shang; José Rivera
> Subject: Re: STATUS_OS2_INVALID_LEVEL
> 
> Bill Wesse wrote:
>> Thanks for the heads up Christopher - you are totally correct in saying
>> my comments on the complexity of NT platform SMB error returns were
>> meant to be 'polite understatements' (especially that pesky flipped
>> response SMB_FLAGS2_NT_STATUS bit, not to mention the 'occasionally
>> optional' WordCount and ByteCount absence from transact2 responses).
> 
> The thing about the flipped bit:  The SMB_FLAGS2_NT_STATUS bit is *NOT*
> cleared by Windows NT when sending one of the suspect error codes.  NT, that
> is, is saying that it's a 32-bit code.  We've documented these codes as such
> in [MS-CIFS].  It makes it MUCH easier to document the entire problem.
> 
> Basically, though, what we're dealing with is a 20-year-old kludge with no
> clear fix.  It simply needs to be explained so that implementers can work
> with it.
> 
>> I will shortly forward your email to concerned internal parties...
> 
> I'm available internally as v-chhert.
> Yeah... I'm a double agent!  :)
> Say hello to Will and Darryl for me.
> 
>> I have no doubt a complete rundown of all the exceptions to the rule
>> would be quite valuable to our respective organizations and customers
> 
> It's difficult to get the documentation right but it can be explained and
> doing so would probably help you guys out.
> 
>> - figuring what to do in response to a 'surprise' error value classifies
>> as yet another 'polite understatement'.
> 
> :)
> 
>> I won't rule out the possibility of (my team) providing supplemental
>> content concerning this, in case the documents aren't the optimal place
>> for the info - I hate to state the obvious, but a complete WB
>> description of the above for all NT/SMB (or just transact2) would be
>> pretty big.
> 
> Perhaps a KB article that we can reference from a WB?
> 
>> There I go again. Another understatement.
> 
> :)
> 
> 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
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: [MS-CIFS]_Changes.pdf
Type: application/pdf
Size: 241053 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100127/c636f258/attachment-0001.pdf>


More information about the cifs-protocol mailing list