                         My experiences with SMB
                           Preliminary Report
                              Richard Sharpe
		      (currently at Digital Equipment)
                        (sharpe@nmesis.enet.dec.com)

1 Introduction

This document sets out some of my experiences with SMB implementations.
It mainly details some of the quirks that I have seen in server
implementations. I list some of the interesting errors I have seen as well
as what various servers respond with.

Why are these matters important?

  1. Interoperability. It will help all parties involved in implementing SMB
     servers and clients if more is known about the behaviour of various 
     implementations out there.

  2. Safety. Knowing what sort of stupid things clients or servers might do
     will allow all implementations to get better.

  3. Developing SMB. As the protocol becomes standardized and evolves it will
     help to see areas that have been abuse, are hard to use, etc.

At the moment, this looks at two areas: RFCNB, the implementation of
RFC1001 and RFC1002 over TCP/IP, that is NetBIOS over TCP/IP (also
known as NBT); and SMB. However, I hope to extend this to looking at name 
serving requests and problems as well as other problems with various SMBs.

2. RFCNB Experiences

In testing out my implementation of RFCNB (NBT) I have noticed that
Microsoft implementations demand that the Called Name be the uppercase
version of the Server Name. They will not accept anything else, whereas
all others that I have tried (Samba, PATHWORKS for OpenVMS 4.x,
PATHWORKS for ULTRIX 1.3a) all accept anything in the Called and Calling
name fields of an RFCNB Session Connect message. 

3. SMB Experiences

Here I have tried various things with various implementations to see
what would work and what would not. I also tried several crazy things to
see how robust the various servers were.

I have split each server implementation out for discussion.

3.1 SAMBA 1.9.15p8

Samba seems the most robust implementation that I have access to in
terms of the testing that I have done. It negotiates the NT LANMAN 1.0 
protocol if given a choice.

Samba will accept multiple attempts to negotiate a protocol and always
returns the maximum it is happy with.

Samba will accept a very large number of protocols in the negotiate
request. The largest SMB negprot packet I have tried so far is 32904
bytes consisting of 1000 protocols, all but the last 8 being rubbish.
The last 8 were the 8 that Samba knows about.

Samba is happy accepting service names in lower case when doing a tree
connect, and does not insist that they be of the form \\server\service.

Samba will accept C: as a service name as well as A:. In fact, testing I
have done establishes that it will accept from A: to Z: in the serice name in 
a tree connect.

If I negotiate a protocol of PC NETWORK PROGRAM 1.0, Samba will allow me
to do a tree connect to a service with out a password as long as it is a
public share. It will also log you in as <calling-name> from the RFCNB (NBT)
connection if such an account exists and a password is presented in the Tree 
Connect request.

Samba did appear to have a bug where if you disconnected a tree that was not
connected, the server process serving you crashed (this was in 1.9.15p8, I 
think this has been fixed now).

3.2 Windows NT 3.51

Windows NT 3.51 negotiates the NT LM 0.12 protocol, even if given the choice 
of NT LANMAN 1.0 (where does this protocol come from?).

Windows NT 3.51 will not accept multiple attempts to negotiate the protocol, 
and returns an error class of 2 (ERRSRV) and an erro code of 1 (Non specific 
error code) on any subsequent attempt to negotiate the protocol. This is 
interesting because while the CIFS draft and the document smbpub.doc (in the file smbpub.zip) at ftp://ftp.microsoft.com/developr/drg/SMB-info/ states that 
this is the expected reaction (in the section on error codes) it is not 
defined as the required behaviour. Moreover, Windows 95 behaves differently.

Windows NT 3.51 does not like a service of C: in a Tree Connect, and wants the
service to be A: for a disk service. If you try to connect on any other,
service, Windows NT returns ERRDOS, with an error code of 66. This error 
code is undocumented, even in the draft CIFS document, but the SMS Network 
Monitor decodes this as ERRbaddevtype (actually BAD_DEV_TYPE).

Windows NT 3.51 will not accept a large number of protocols in a negprot SMB. 
It seems to have a 16kB internal buffer for this SMB request. Windows 
NT 3.51 hangs the TCP connection if I try a negprot SMB with 32904 bytes 
consisting of 1000 protocols, all but the last 8 being rubbish. The last 8
were the 8 that Samba knows about. You have to kill the connection, because
Windows NT does not seem to time this out. The reason I conclude it has a
buffer of 16kB is that when I use the Network Monitor, Windows NT 4.0B2 drops
the window from 16384 to 0 on the TCP connection, and after that the window
never re-opens.

3.3 Windows NT 4.0 Beta2

Windows NT 4.0 Beta2 negotiates the NT LM 0.12 protocol, even if given
the choice of NT LANMAN 1.0 (where does this protocol come from?).

Windows NT 4.0B2 will not accept a large number of protocols in a negprot SMB. 
It seems to have a 16kB internal buffer for this SMB request. Windows 
NT 4.0B2 hangs the TCP connection if I try a negprot SMB with 32904 bytes 
consisting of 1000 protocols, all but the last 8 being rubbish. The last 8
were the 8 that Samba knows about. You have to kill the connection, because
Windows NT does not seem to time this out. The reason I conclude it has a
buffer of 16kB is that when I use the Network Monitor, Windows NT 4.0B2 drops
the window from 16384 to 0 on the TCP connection, and after that the window
never re-opens.

3.4 Windows 95

Windows 95 negotiates the NT LM 0.12 protocol. 

Windows 95, unlike Windows NT 3.51 or 4.0B2 is happy to accept multiple 
negprot requests, and always accepts the NT LM 0.12 protocol.

Windows 95 will not accept a large number of protocols in a negprot SMB. 
However, unlike Windows NT 3.51 and Windows NT 4.0B2, it accepts the whole 
packet without hanging the connection and then drops the connection (resets 
it).

3.5 PATHWORKS for OpenVMS 4.x

PATHWORKS for OpenVMS 4.x negotiates the MICROSOFT NETWORKS 1.03 protocol.

PATHWORKS for OpenVMS 4.x is happy to accept multiple negotiate requests. It
accepts the same protocol on each request.

PATHWORKS for OpenVMS 4.x will not accept a large number of protocols in 
a negprot SMB. However, while it does not hang the TCP connection, unlike 
Windows 95, it resets the connection before the whole SMB has been sent from 
the client machine.

3.6 PATHWORKS for ULTRIX 1.3a

PATHWORKS for ULTRIX 1.3a negotiates the PC NETWORK PROGRAM 1.0 protocol.

PATHWORKS for ULTRIX 1.3a is happy to accept multiple negotiate requests. It
accepts the same protocol on each request.

PATHWORKS for ULTRIX 1.3a will not accept a large number of protocols in 
a negprot SMB. However, unlike Windows NT 3.51 and 4.0B2, it accepts the 
whole negprot SMB from the client, then resets the connection. In this 
respect, it seems to be like Windows 95.