11.5 The Flow of Conversation

SMB conversations start after the session has been established via the transport layer. As a rule, the client always speaks first. Clients send requests , servers respond, and that's the way SMB is supposed to work. This is a hard-and-fast rule which means, of course, that there is an exception. Fortunately, we can (and will) put off talking about that exception until we talk about Opportunistic Locks (OpLocks).

The NEGOTIATE PROTOCOL REQUEST/RESPONSE is always the first SMB exchange in the conversation. The client and server need to know what language to speak before they can say anything else. This is also a hard-and-fast rule, but there are no exceptions (which is an exception to the rule that all hard-and-fast rules have exceptions).

Once the dialect has been selected, the next formality is to establish an SMB session using the SMB SESSION SETUP REQUEST message. We keep running into terminology twists , and here we have yet another. The SMB SESSION SETUP exchange sets up an SMB session within the NBT or naked TCP session.

Huh?

Well, yes, that's confusing. The problem is that we are talking about two different kinds of sessions here.

• There is the network session built at layer 5 of the OSI model, on top of the transport layer.

• There is the user logon session.

Ah, there's a clue! The SESSION SETUP is used to perform authentication and establish a user session with the server. ^[6] A quick look at the SESSION SETUP ANDX REQUEST block in the packet above shows that the Exists utility did in fact send a username the name " GUEST ", passed via the AccountName field to the server.

^[6] We are dealing with a vague definition here. According to the SNIA doc, the SESSION SETUP is meant to "set up" the session created by the NEGOTIATE PROTOCOL , which also makes some sort of sense. Thing is, there may be multiple SESSION SETUP exchanges following the NEGOTIATE PROTOCOL , meaning multiple SMB user sessions per NBT or naked TCP transport session. The waters are muddy.

Once the user session is established, the client may try to connect to a share using a TREE CONNECT SMB. It is a hard-and-fast rule that TREE CONNECT SMBs must follow the SESSION SETUP . There is an exception to this as well, which we will cover when we get to share-mode vs. user-mode authentication.

Figure 11.4 shows the right way to start an SMB conversation. Combining the SESSION SETUP ANDX and TREE CONNECT ANDX SMBs into a single AndX message is optional (jCIFS' Exists does, but Samba's smbclient doesn't). Once the conversation has been initiated using the above sequence, the client is free to improvise.

Figure 11.4. A simple SMB conversation

The client makes requests (some of which may be batched in AndX messages) and the server responds. The jCIFS Exists utility sends a NEGOTIATE PROTOCOL REQUEST followed by batched SESSION SETUP plus TREE CONNECT AndX requests. The TREE DISCONNECT exchange at the end is optional. When the client closes the session at the transport layer, all resources are released.