Chris - thank you very much for the feedback. I will add that to the TDI right away (the pending changes being work in progress, of course).
Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 -----Original Message----- From: Christopher R. Hertel [mailto:c...@ubiqx.mn.org] Sent: Wednesday, January 27, 2010 1:50 PM To: Bill Wesse Cc: tim.pro...@isilon.com; Jeremy Allison; p...@tridgell.net; cifs-proto...@samba.org; Gary Shang; José Rivera; David Kruse Subject: Re: Status: SRX091209600095 [MS-SMB] error returns 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: bil...@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.pro...@isilon.com; Jeremy Allison; p...@tridgell.net; > cifs-proto...@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: bil...@microsoft.com > Tel: +1(980) 776-8200 > Cell: +1(704) 661-5438 > Fax: +1(704) 665-9606 > > -----Original Message----- > From: Christopher R. Hertel [mailto:c...@ubiqx.mn.org] > Sent: Thursday, January 14, 2010 2:16 PM > To: Bill Wesse > Cc: tim.pro...@isilon.com; Jeremy Allison; p...@tridgell.net; > cifs-proto...@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/ -)----- c...@ubiqx.mn.org >> OnLineBook -- http://ubiqx.org/cifs/ -)----- c...@ubiqx.org >> >> _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
