More Samba steps

We’ve been discussing Samba, the open source freeware implementation of the Server Message Block protocol, and last week we established a NetBIOS session between a client and a Samba server. Now we have to get the two ends of the connection to agree on what variant of SMB they are going to use.

The result of negotiating which protocol variant to use always is determined by whichever end uses the earliest dialect – that will be the protocol variant spoken.

The client sends the SMB command for this negotiation, SMBnegprot, to the server along with a list of all the variants the clients can speak. The server replies with an index value that indicates which entry in the client’s list of variants the server wants to use. The server also can reply that none of the dialects are acceptable, in which case the connection fails.

Now that the server and clients have agreed on what variant of the protocol to use, the client must set the session parameters using the SMBsesssetupX command. These parameters include the work group that the client wants to join (this name was found by browsing the NetBIOS names from the name server before the NetBIOS session between the client and server was established); the account name and password (if required); the maximum amount of data that can be transferred in a single response; and the number of pending requests that can be queued.

When the server authorizes the connection it returns a reply that includes a tree identifier (TID). The TID can be thought of as a handle (or pointer) that the server allocates to identify the client’s connection to a share.

In that same reply is the ServiceType field, which is A for a disk or file, LPT1 for a spooler such as a print queue, COMM for a directly connected device such as a modem or printer; or IPC for a named pipe.

Digression: Although you already know, a named pipe is a mechanism for passing data from one process to another using a named message buffer, and it runs on top of NetBIOS. Named pipes shouldn’t be confused with regular pipes (denoted by | as in the DOS command dir | more), which redirect the standard output (stdout) from one process to the standard input (stdin) of another. The biggest difference between regular and named pipes is that the latter can connect processes running either locally to each other or on different machines.

Windows equivalents

Under MS-DOS, defining shares and deleting them, connecting to shares and checking the status of SMB connections is done using the Net command. Under Windows, all the functionality of the Net command essentially is embedded in Windows Explorer.

So, for example, clicking on Network Neighborhood is equivalent to running the command “NET VIEW /DOMAIN,” which lists all the visible domains (work groups). If you then click on a work-group name it is equivalent to executing “NET VIEW DOMAIN:” to display all the constituent computers. If you then click on a computer name to show all available shares it is the same as “NET VIEW.”

Finally, clicking on a share name in Explorer is like executing “NET USE : >”. Note that many of the options available under the Net command will fail if you are running it in a command shell under Windows.

There are a few differences between using a Samba server and a Windows server. First, as we noted last week, if Samba is your primary Windows Internet Name Service server it can’t synchronize with Windows secondary WINS servers and it can’t be a secondary WINS server. Second, Samba doesn’t support Windows NT domain trust relationships.

Third, Samba can act as a primary domain controller for clients running all versions of Windows but not as a backup domain controller. Samba doesn’t yet support Microsoft’s Active Directory services – that is planned for the next version – but it can function in a mixed-mode environment that runs Windows Active Directory and Windows NT domains simultaneously.

The current version of Samba is 2.2, and you can download source and binaries for a number of operating systems, including AIX, DigitalUnix, Irix, Linux (Debian, Mandrake, Red Hat, SuSE, TurboLinux), SCO-Caldera, Novell, Solaris and VMS. Go to http://www.samba.org and select the site closest to you – the download link will be on the left side of the home page.

Next week we’ll get Samba running. Upload thoughts to gearhead@gibbs.com