16.1 That TREE CONNECT Thingy

16.1 That TREE CONNECT Thingy

We have talked a lot about the TREE CONNECT ANDX REQUEST SMB. There was even an example way back in Section 11.4 on page 188. The example looked like this:

 SMB_PARAMETERS   {   WordCount       = 4   AndXCommand     = SMB_COM_NONE (0xFF)   AndXOffset      = 0   Flags           = 0x0000   PasswordLength  = 1   } SMB_DATA   {   ByteCount       = 22   Password        = ""   Path            = "\SMEDLEY\HOME"   Service         = "?????"  (yes, really)   } 

Notice that the TREE CONNECT includes a Password field, but that in this example the Password field is almost empty (it contains a nul byte). If the server negotiates Share Level security, then the password that would otherwise be in the SESSION_SETUP_ANDX.CaseInsensitive-Password field will show up in the TREE_CONNECT_ANDX.Password field instead. The password may be plaintext, or it may be one of the response values we calculated earlier.

The TREE_CONNECT_ANDX.Path field is also worth mentioning. It contains the UNC pathname of the share to which the client is trying to connect. In this example, the client is attempting to access the HOME share on node SMEDLEY . Note that the Path will be in Unicode if negotiated.

Finally there is that weird quintuple question mark string in the TREE_CONNECT_ANDX.Service field. There are, as it turns out, five possible values for that field:

String	Meaning
A:	A filesystem share
LPT1:	A shared printer
IPC	An interprocess communications named pipe
COMM	A serial or other communications device
?????	Wildcard

It's annoying for the client to need to know the kind of share to which it is connecting, which is probably why the wildcard option is available. The server will return the service type in the Service field of the Response. Note that the Service strings are always in 8-bit ASCII characters never Unicode.

The response (for LANMAN2.1 and above) looks like this:

 SMB_PARAMETERS   {   WordCount        = 3   AndXCommand      = <Next ANDX command>   AndXOffset       = <Next ANDX block offset>   OptionalSupport  = <A bitfield>   } SMB_DATA   {   ByteCount        = <variable>   Service          = <"A:"  "LPT1:"  "IPC"  "COMM">   NativeFileSystem = <""  "FAT"  "NTFS">   } 

The example above shows the empty string, " FAT ", or " NTFS " as the valid values for the NativeFileSystem field. Other values are possible. (Samba, for instance, has a configuration option that allows you to put in anything you like.) The empty string is used for the hidden IPC$ share.

There are two bits defined in the OptionalSupport bitfield:

Bit	Meaning
SMB_SUPPORT_SEARCH_BITS 0x0001	The meaning of this bit is explained in the LANMAN2.1 documentation. Basically, it indicates that the server knows how to perform directory searches that filter out some entries based on specific file attributesfor example, the DOS archive bit, the directory attribute, etc. This is old stuff and all current implementations should support it.
SMB_SHARE_IS_IN_DFS 0x0002	This bit, if set, indicates that the UNC name is in the D istributed F ile S ystem (DFS) namespace. DFS is yet to be covered.

There is a note in the SNIA doc that states that some servers will leave out the OptionalSupport field even if the LANMAN2.1 or later dialect is negotiated. It does not say whether SMB_SUPPORT_SEARCH_BITS should be assumed in such cases.