12.2 The FLAGS and FLAGS2 Fields Tell All Most (but not all) of the bits in the older FLAGS field are of interest only to older servers. They represent features that have been superseded by newer features in newer servers. It would be nice if all of the old stuff would just go away so that we wouldn't have to worry about it. It does seem, in fact, as though this is slowly happening. (Maybe it would be better if the old stuff stayed and the new stuff had never happened . Hmmm...) In any case, this next table presents the FLAGS bits in order of descending significance the opposite of the order used in the SNIA doc. English speaking people tend to read from left to right and from top to bottom, so it seems logical (as this book is, more or less, written in English) [3] to transpose the left-to-right order into a top-to-bottom table. [3] The English language is Copyright 1597 by William Shakespeare & Co., used by permission. All rights deserved. | SMB_HEADER.FLAGS | | Bit | Name / Bitmask / Values | Description | | 7 | SMB_FLAGS_SERVER_TO_REDIR 0x80 : request 1 : reply | What an awful name! On DOS, OS/2, and Windows systems, the client is built into the operating system and is called a "redirector," which is where the " SERVER_TO_REDIR " part of the name comes from. Basically, though, this is simply the reply flag. | | 6 | SMB_FLAGS_REQUEST_BATCH_OPLOCK 0x40 : Exclusive 1 : Batch | Obsolete. If bit 5 is set, then bit 6 is the "batch OpLock" (aka OPBATCH ) bit. Bit 6 should be clear if bit 5 is clear. In a request from the client, this bit is used to indicate whether the client wants an exclusive OpLock ( ) or a batch OpLock ( 1 ). In a response, this bit indicates that the server has granted the batch OpLock. OpLocks ( opportunistic locks) will be covered later. This bit is only used in the deprecated SMB_COM_OPEN , SMB_COM_CREATE , and SMB_COM_CREATE_NEW SMBs. It should be zero in all other SMBs. The SMB_COM_OPEN_ANDX SMB has a separate set of flags that handle OpLock requests , as does the SMB_COM_NT_CREATE_ANDX SMB. | | 5 | SMB_FLAGS_REQUEST_OPLOCK 0x20 : no OpLock 1 : OpLock | Obsolete. This is the "OpLock" bit. If this bit is set in a request, it indicates that the client wants to obtain an OpLock. If set in the reply, it indicates that the server has granted the OpLock. OpLocks (opportunistic locks) will be covered later. This bit is only used in the deprecated SMB_COM_OPEN , SMB_COM_CREATE , and SMB_COM_CREATE_NEW SMBs. It should be zero in all other SMBs. The SMB_COM_OPEN_ANDX SMB has a separate set of flags that handle OpLock requests, as does the SMB_COM_NT_CREATE_ANDX SMB. (Sigh.) | | 4 | SMB_FLAGS_CANONICAL_PATHNAMES 0x10 : Host format 1 : Canonical | Obsolete. This was supposed to be used to indicate whether or not pathnames in SMB messages were mapped to their "canonical" form. Thing is, it doesn't do much good to write a client or server that doesn't map names to the canonical form (which is basically DOS, OS/2, or Windows compatible). This bit should always be set ( 1 ). | | 3 | SMB_FLAGS_CASELESS_PATHNAMES 0x08 : case-sensitive 1 : caseless | When this bit is clear ( ), pathnames should be treated as case-sensitive. When the bit is set, pathnames are considered caseless. All good in theory. The trouble is that some systems assume caseless pathnames no matter what the state of this bit. Best practice on the client side is to leave this bit set ( 1 ) and always assume caseless pathnames. | | 2 | 0x04 | <Reserved> (must be zero). ...well, sort of. This bit is clearly listed as "Reserved (must be zero)" in both the SNIA and the X/Open docs, yet the latter contains some odd references to optionally using this bit in conjunction with OpLocks. It's probably a typo. Best bet is to clear it ( ) and leave it alone. | | 1 | SMB_FLAGS_CLIENT_BUF_AVAIL 0x02 : Not posted 1 : Buffer posted | Obsolete. This was probably useful with other transports, such as NetBEUI. If the client sets this bit, it is telling the server that it has already posted a buffer to receive the server's response. The expired Leach/Naik Internet Draft says that this allows a "send without acknowledgment" from the server. This bit should be clear ( ) for use with NBT and naked TCP transports. | | | SMB_FLAGS_SUPPORT_LOCKREAD 0x01 : Not supported 1 : Supported | Obsolete. If this bit is set in the SMB NEGOTIATE PROTOCOL RESPONSE , then the server supports the deprecated SMB_COM_LOCK_AND_READ and SMB_COM_WRITE_AND_UNLOCK SMBs. Unless you are implementing outdated dialects, this bit should be clear ( ). | The NEGOTIATE PROTOCOL REQUEST that we dissected back in Section 11.3 on page 186 shows only the SMB_FLAGS_CANONICAL_PATHNAMES and SMB_FLAGS_CASELESS_PATHNAMES bits set, which is probably the best thing for new implementations to do. Testing with other clients may reveal other workable combinations. Now let's take a look at the newer flags in the FLAGS2 field. | SMB_HEADER.FLAGS2 | | Bit | Name / Bitmask / Values | Description | | 15 | SMB_FLAGS2_UNICODE_STRINGS 0x8000 : ASCII 1 : Unicode | If set ( 1 ), this bit indicates that string fields within the SMB message are encoded using a two-byte, little endian Unicode format. The SNIA doc says that the format is UTF-16LE but some folks on the Samba Team say it's really UCS-2LE. The latter is probably correct, but it may not matter as both formats are probably the same for the Basic Multilingual Plane. Doesn't Unicode sound like fun? [4] If clear ( ), all strings are in 8-bit ASCII format (by which we actually mean 8-bit OEM character set format). | | 14 | SMB_FLAGS2_32BIT_STATUS 0x4000 : DOS error code 1 : NT_STATUS code | Indicates whether the STATUS field is in DOS or NT_STATUS format. This may also be used to help the server guess which format the client prefers before it has actually been negotiated. | | 13 | SMB_FLAGS2_READ_IF_EXECUTE 0x2000 : Execute != Read 1 : Execute confers Read | A quirky little bit this. If set ( 1 ), it indicates that execute permission on a file also grants read permission. It is only useful in read operations. | | 12 | SMB_FLAGS2_DFS_PATHNAME 0x1000 : Normal pathname 1 : DFS pathname | This is used with the D istributed F ile S ystem (DFS), which we haven't covered yet. If this bit is set ( 1 ), it indicates that the client knows about DFS, and that the server should resolve any UNC names in the SMB message by looking in the DFS namespace. If this bit is clear ( ), the server should not check the DFS namespace. | | 11 | SMB_FLAGS2_EXTENDED_SECURITY 0x0800 : Normal security 1 : Extended security | If set ( 1 ), this bit indicates that the sending node understands Extended Security. We'll touch on this again when we discuss authentication. | | 10 | 0x0400 | <Reserved> (must be zero) | | 9 | 0x0200 | <Reserved> (must be zero) | | 8 | 0x0100 | <Reserved> (must be zero) | | 7 | 0x0080 | <Reserved> (must be zero) | | 6 | SMB_FLAGS2_IS_LONG_NAME 0x0040 : 8.3 format 1 : Long names | If set ( 1 ), then any pathnames that the SMB contains are long pathnames, else the pathnames are in 8.3 format. Any new CIFS implementation really should support long names. | | 5 | 0x0020 | <Reserved> (must be zero) | | 4 | 0x0010 | <Reserved> (must be zero) | | 3 | 0x0008 | <Reserved> (must be zero) | | 2 | SMB_FLAGS2_SECURITY_SIGNATURE 0x0004 : No signature 1 : Message Authentication Code | If set, the SMB contains a M essage A uthentication C ode (MAC). The MAC is used to authenticate each packet in a session, to prevent various attacks. | | 1 | SMB_FLAGS2_EAS 0x0002 : No EAs 1 : Extended Attributes | Indicates that the client understands Extended Attributes. Note that the SNIA doc talks about "Extended Attributes" and about "Extended File Attributes." These are two completely different concepts. Extended Attributes are a feature of OS/2. They are mentioned in Section 1.1.6 (page 2) of the SNIA doc and explained in better detail on page 87. Extended File Attributes are described in Section 3.13 (page 30) of the SNIA doc. The SMB_FLAGS2_EAS bit deals with Extended Attribute support. | | | SMB_FLAGS2_KNOWS_LONG_NAMES 0x0001 : Client wants 8.3 1 : Long pathnames okay | Set by the client to let the server know that long names are acceptable in the response. | [4] One of the reasons that the jCIFS project was started is that Java has built-in Unicode support, which solves a lot of problems. That, plus the native threading model and a few other features, made an SMB implementation in Java very tempting. Support for Unicode in a CIFS implementation is not really optional any more except, perhaps, in the simplest of client systems. Unfortunately, Unicode is way beyond the scope of this book. See the References section for some web links to get you started with Unicode. Some of the flags are used to modify the interpretation of the SMB message, while others are used to negotiate features. Some do both. It may take some experimentation to find the safest way to handle these bits. Implementations are not consistent, so new code must be fine- tuned . You may need to refer back to these tables as we dig further into the details. Note that the constant names listed above may not match those in the SNIA doc, or those in other docs or available source code. There doesn't seem to be a lot of agreement on the names.  |
