Consolidated List of All CIFS Spec Feedback
Andrea Westerinen
andreawest at mindspring.com
Thu Feb 10 20:02:16 GMT 2000
Here is the document in ASCII format <Changes2CIFSinText.txt>. Other
comments and feedback are still welcome.
I would like to establish a bi-weekly conference call to begin work on the
Spec. If you are interested please small "r" (reply to) me. I propose ...
Monday, 9am Pacific
Wednesday, 9am Pacific
Friday, 10am Pacific
Starting next week, 2/14.
Please let me know if you are interested in working on the CIFS Spec, and
what call times would work for you. Also, please propose a few alternate
times if necessary.
Thank you.
Andrea Westerinen
SNIA Technical Director
-------------- next part --------------
Comments on the CIFS Specification
Format:
Ref# - Requested Change
(Blank Line)
Type of Change - Status
1 - Need information on Windows 95 through Windows 2000 - perhaps in an Appendix. For
example,
a) In SMB_COM_SEARCH and SMB_COM_QUERY_ INFORMATION, the Windows 95 client will sometimes
give a null pathname. Is this legal, and if so, what are the intended semantics?
b) Description of a number of messages missing - These are used by Windows 95 under
certain conditions (i.e. the Write SMB is still used by all Microsoft clients to set
the file length)
Additional Information - Open
2 - Need descriptions and permissible values for all fields
Clarification - Open
3 - Several sections do not have lists of error codes. For example, Section 4.3.2, "Delete
Directory", and all the TRANS2_XXX Sections. Also missing ERRHRD/39 (is this "disk full"?)
All error codes should be fully documented (which to use when, and what they mean).
Clarification - Open
4 - Need guidance about using NT status codes. Actually there are some cases where
the relevant status code is reasonably obvious. But there are many cases where it is not.
Here are some important ones:
- STATUS_NO_SUCH_FILE vs. STATUS_OBJECT_NAME_INVALID vs.
STATUS_OBJECT_NAME_NOT_FOUND for a directory lookup failure.
- STATUS_OBJECT_NAME_EXISTS vs. STATUS_OBJECT_NAME_ COLLISION
for an attempt to create a file whose name already exists.
Clarification and Additional Information - Open
5 - Document the mechanisms for getting/setting network share information and
security information (through RPC or mailboxes)
Additional Information - Open
6 - Questions on "transaction2"s:
a) For find_first and find_next, what are "resume keys"?
b) What is the EA size referred to in info-levels? Windows seems to be
setting it to zero. Does EA refer to extended attributes which might have
been defined for a file by a specific implementation and are non-standard?
Clarification - Open
7 - Questions on "string encodings":
a) Is Unicode required? If not, what are the implications of not supporting Unicode?
b) If all files and folders use ASCII, must an implementation support
non-ASCII encodings?
Clarification - Open
8 - Increase/improve the documentation for CIFS using TCP transport (Appendix B)
Additional Information - Open
9 - Define a new dialect that explicitly removes OBSOLETE SMB messages -
In Section 3.15 of the I-D, each dialect introduces new messages w/o getting rid
of old ones, for backward compatibility. Section 4 seems to contradict this. However,
it's normally the case that NT or 2000 will negotiate the top-level dialects
and the top-level CAPABILITIES, and never use the old ones. This leads to weird
problems (such as NT trying to set a 64 bit date in a 32 bit field) by _not_
negotiating certain SMBs or certain CAPABILITIES.
Addition of Negotiation Info and/or New Dialect - Open
10 - Mapping of individual functions to releases (Windows, SAMBA, etc.). Perhaps this
could be done in an Appendix and is similar to #1, above.
Additional Information - Open
11 - Outline the use of SPNEGO / GSS-API in the CAP_EXTENDED_SECURITY blobs
Additional Information - Open
12 - Outline of how NTLMv1 and NTLMv2 work. This should likely be a separate
document, containing annotated examples, showing intermediate calculation stages.
Additional Information, In a New Draft? - Open
Comment: Most of the info available in the book, "DCE/RPC over SMB, Samba and
Windows NT Domain Internals"
13 - Outline of how NTLMSSP works, and how it uses 40-bit, 128-bit, key-exchange
and both sign and seal modes (for BOTH NTLMV1 and NTLMV2). Again, annotated
examples needed showing the intermediate calculation stages and the signed /
sealed traffic, before and after.
Additional Information, In a New Draft? - Open
Comment: Most of the info available in the book, "DCE/RPC over SMB, Samba and
Windows NT Domain Internals"
14 - Outline of how NETLOGON, the new 0x400001ff and the new Windows 2000 0x7fff01ff
(or whatever) modes work - ie, "the NETLOGON secure channel"
Additional Information, In a New Draft? - Open
Comment: Most of the info available in the book, "DCE/RPC over SMB, Samba and
Windows NT Domain Internals"
15 - Specification of how DCE/RPC over SMB works
Additional Information - Open
Comment: Most of the info available in the book, "DCE/RPC over SMB, Samba and
Windows NT Domain Internals"
16 - Specification of each of the services that run over DCE/RPC. Could this be
done as IDL files?
Additional Information - Open
Comment: Most of the info available in the book, "DCE/RPC over SMB, Samba and
Windows NT Domain Internals"
17 - Abstract states: "This document omits discussion of obsolescent requests
not needed by modern clients. They are defined in a companion document." - But there
is no companion document. Also it appears that some flags are reserved for
obsolescent requests as documented in Section 3.2.2 and 3.2.3.
Additional Information, In a New Draft? - Open
18 - When I connect via "net use" from an NT client to sambe, I see two messages,
each with Session-setup-andX/Tree-connect-andX. In the first message, the
session setup username is the name of my workstation, and the tree connect
pathname is \\<samba-host>\IPC$. The Spec mentions that "IPC" is one of the
possibilities for that field in the reply message, but it doesn't say anything
about semantics. Can you describe what sort of SMB traffic an "IPC" service is
likely to see?
Clarification - Open
19 - Question on CREATE_DIRECTORY and TRANS2_CREATE_DIRECTORY: If the following is
sent by an NT client, "mkdir \foo\baz" with Command Extensions enabled, and if foo
does not exist, an NT server returns STATUS_OBJECT_NAME_NOT_ FOUND. The NT client
realizes that its original expectation has not been met and sends two separate
CREATE_DIRECTORY messages, one specifying "foo" and the next specifying "foo\baz".
Is the possibility of creating multiple path components with one message part of the
spec, or just eccentric behavior? If possible, then it should be documented. Also,
different error codes are returned from different implementations - this relates to
#3 above.
Clarification - Open
20 - Have greater granularity in the TOC - 3 levels to allow lookup of an
individual message
Formatting - Open
21 - Need consistency in naming of flags in Section 3.2.2 and 3.2.3 between the
Spec and smbtrace
Consistency of Naming - Open
22 - Regarding Section 3.15, it says: "CIFS Clients and servers may exchange the
following SMB messages if the "PC NETWORK PROGRAM 1.0" dialect is negotiated: ..."
and "If the "LANMAN 1.0" dialect is negotiated ... etc. ... New messages introduced
... are: ..." Should it also say: "If the "NT LM 0.12" dialect is supported, with
the CAP_NT_FIND capability, the following information levels are introduced for the
indicated messages:
TRANS2_FIND_FIRST2 0x101 through 0x104
TRANS2_QUERY_FS_INFORMATION 0x102 through 0x105"
And: "If the "NT LM 0.12" dialect is supported, with the CAP_NT_SMBS capability,
the following information levels are introduced for the indicated messages, in addition
to those listed above for CAP_NT_FIND:
TRANS2_QUERY_PATH_INFORMATION 0x101 through 0x10B
TRANS2_QUERY_FILE_INFORMATION same
TRANS2_SET_PATH_INFORMATION etc.
etc."
Clarification - Open
23 - In Section 3.15, SMB_COM_NT_RENAME is listed, but no such request is listed
in Section 5.1, "SMB Command Codes."
Clarification - Open
24 - It appears that information levels in some SMB requests (such as
TRANS2_ FIND_FIRST2, TRANS2_QUERY_PATH_ INFORMATION, etc.) depend on negotiated
dialect. This should be documented and a listing of these is necessary. Should it
go into Section 3.15 on "negotiated dialect"?
Additional Information - Open
25 - In Section 3.4 (WildCards), it says: "If the negotiated dialect is
'NT LM 0.12' or later, and the client requires MS-DOS wildcard matching semantics ..."
What alternative matching semantics are there? How are MS-DOS semantics different
from others? Should "?" be treated differently from ">", or are they equivalent?
Likewise for "." and """", and for "*" and "<".
Clarification - Open
26 - Time/date fields are FILETIME - Some were listed as LARGE_INTEGER
Correction - Open
27 - Section 3.8, "Access Mask Encoding" needs the flags. Could the WINNT.H header
file just be included/used?
Additional Information - Open
28 - Explain the semantics of CAP_NT_FIND
Additional Information - Open
29 - It is claimed that RAW_MODE is obsolescent. What does this mean when
NT clients still send raw mode messages?
Clarification - Open
30 - STATUS_MORE_PROCESSING_REQUEIRED is misspelled / FILE_PRSISTENT_ACLS is
misspelled and needs an explanation
Correction and Additional Information - Open
31 - Explain SMB_SUPPORT_SEARCH_BITS
Additional Information - Open
32 - Can clients ignore capabilities? If so, should this be documented in
Section 4.1.2? For example, it appears that the Win 95 client pays attention to
the Native File System in the response to Tree Connect And X. In the earlier
response to Negotiate, CAP_NT_FIND was specified, but the Win 95 client
ignored this unless (subsequently) something like "NTFS" or "FAT" was specified
in the response. (Originally, "AFS" was specified.) This also relates
to #1, above.
Additional Information - Open
33 - In Section 4.2.1, the description of CreateDisposition is completely at
variance with the NT client and server implementation. A usable description is
in the documentation of NtCreateFile in the Microsoft DDK. Also, Name is
apparently (in the NT client) not null-terminated. Is this part of the spec?
Consistency and Clarification - Open
34 - In Section 4.2.10, give an example of wildcarding and renaming multiple files.
Request for Example - Open
35 - In Section 4.2.13.4 (TRANS2_QUERY_PATH_INFORMATION) SMB_QUERY_FILE_BASIC_INFO
- From sniffing the NT client and server, it is observed that instead of a
USHORT attributes, the data ended with two longs, of which the first was
apparently extended attributes, and the second was unknown (always zero).
Servers have to conform to the above description, rather than to the CIFS spec,
to work with the NT client.
Consistency - Open
36 - In Section 4.2.13.7 (TRANS2_QUERY_PATH_INFORMATION) SMB_QUERY_FILE_NAME_INFO
- Is the whole file name to be used, or just the last component?
Clarification - Open
37 - In Section 4.2.13.9 (TRANS2_QUERY_PATH_INFORMATION) SMB_QUERY_FILE_ALT_NAME_INFO
- Clarify that this gets the 8.3 name, given the long name.
Clarification - Open
38 - In Section 4.2.13.10 (TRANS2_QUERY_PATH_INFORMATION) SMB_QUERY_FILE_STREAM_INFO
- What is an appropriate response to this, if the server does not support streams?
Clarification - Open
39 - In Section 4.2.16 TRANS2_SET_FILE_INFORMATION - There is no description
for SMB_FILE_BASIC_INFO.
Additional Information - Open
40 - In Section 4.3.3 Check Directory - What if the path turns out to specify
a file (non-directory)? Should ERRDOS/ERRbadpath, STATUS_OBJECT_PATH_INVALID or
some other error code be returned?
Clarification - Open
41 - Questions from Section 4.3.4 TRANS2_FIND_FIRST2:
a) If the search finds no names, should it return an error code? NT server
returns STATUS_NO_SUCH_FILE when responding to the Win 95 client.
b) Resume keys are not used for information levels above (and including) 0x101.
c) There are alignment requirements when responding to an NT client. These
should be documented (why is this alignment necessary?) or fixed. For example,
- The parameter block for the response to SMB_COM_TRANSACTION2 is aligned on a
short boundary.
- The data block for the response to SMB_COM_TRANSACTION2 is aligned on a
longword boundary.
- For the response to TRANS2_FIND_FIRST2, each individual entry is aligned on a
longword boundary.
Additional Information - Open
42 - In Section 4.3.7 NT_TRANSACT_NOTIFY_CHANGE - A flow diagram is
necessary here. What happens if the message is ignored? It seems that an
NT_CANCEL would be sent, to which a reply would be sent with "something useful to say",
or with STATUS_CANCELED. Can the message be rejected e.g. STATUS_NOT_ IMPLEMENTED)?
Additional Information - Open
43 - Questions from Section 5.4 SMB Protocol Dialect Constants:
a) What is the difference between LM1.2X002 and DOS LM1.2X002? A Win95 client
offers the latter, the NT client offers the former. How are they different?
b) The text says, "... the server will perform error mapping to appropriate
DOS errors." What does this mean? Should the error codes in Chapter 6 be used?
Additional Information - Open
44 - Clarify the use and operation of Filter Oplock
Additional Information - Open
45 - Clarify how bulk reads and writes operate and where and how they are implemented
Additional Information - Open
46 - Explain how DFS is set on the Server (The current Spec explains how to
use DFS but not how to set it)
Additional Information - Open
More information about the samba-technical
mailing list