                         My experiences with SMB
                           Preliminary Report
			       26-July-1996
                              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.

Since the last posting of this document, I believe that I have managed to 
find a way to crash Windows NT 4.0 Beta2, I have definitely found a way to 
crash the VSERVER VDX in Windows 95, and have discovered all sorts of problem
areas with old SMB implementations like PATHWORKS for ULTRIX V1.3a. I have also
been offered access to VisionFS from SCO, which I will also test.

The next areas I am going to look at are:

  a. Checking to see that servers really ignore fields like TID when you do
     a tree connect.

  b. Checking the behaviour of servers if you close a file handle that has 
     never been opened.

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. It also allows vendors to 
     be aware of the faults in their implementations and to fix them. Just 
     imagine the sort of damage that malicious people could do armed with the
     knowledge that Windows 95's VSERVER has a bug and some Visual Basic or 
     Visual C++ code.

  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. 

I have also noticed that Digital's PATHWORKS for OSF V5.0f ECO4 resets the 
connection if you do not use a called name that is the server's name in upper
case.

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 negotiates the NT LANMAN 1.0 protocol if given a choice.

Samba will respond with a Max Buffer Size (MBS) of 65535 in the response to
the negprot SMB, and if you send a tcon SMB, it also responds with an MBS of 
65535.

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, 
however, when doing a Tcon_And_X SMB, Samba seems to require the 
\\server\service syntax.

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
connection) if such an account exists and the correct password is presented
in the tcon SMB.

If you send disconnect tree SMBs to Samba for all TIDs from 0 to 0xFFFF, when
you have not set up any tree connections, Samba sends back an incorrect 
response of no error for TIDs 0 through 1969. For TIDs 1970 through 65535, 
the server process handling your connection crashed. Andrew Tridgell has 
provided a patch that fixes this problem. I have checked, and Samba now 
correctly sends back ERRSRV - ERRinvnid for all 65536 TIDs.

3.2 Windows NT 3.51 sp3

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 respond with a Max Buffer Size (MBS) of 4356 in the 
response to the negprot SMB, but when you send a tcon SMB, it responds with 
an MBS of 65535. There is an inconsistency here, since if you use a tcon_and_x
SMB, then you are stuck with an MBS of 4356.

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.

If you send disconnect tree SMBs to Windows NT 3.51 for all TIDs from 0 to 
0xFFFF, when you have not set up any tree connections, Windows NT 3.51 
correctly responds with ERRSRV - ERRinvnid on all of them.

ERRSRV - 2239 seems to mean Account Disabled.

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.

If you send disconnect tree SMBs to Windows NT 4.0 Beta 2 for all TIDs from 0 
to 0xFFFF, when you have not set up any tree connections, Windows NT 4.0 Beta 2
responds correctly with ERRSRV - ERRinvnid for all of them, but if you send a 
tree disconnect on TID 65535 to Windows NT 4.0 Beta 2 after having sent a 
LogonAndX SMB (which in my case failed) it seems to crash reliably.

3.4 Windows 95 (SP1 I think)

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).

Windows 95 will accept a service name from A: to Z: without any problems. This
is inconsistent with Windows NT which will only accept a service name of A:.
Seems like different development teams were used on Windows NT and Windows 95
and they didn't talk to each other on these matters.

If you send disconnect tree SMBs to Windows 95 for all TIDs from 0 to 0xFFFF,
when you have not set up any tree connections, Windows 95 responds correctly 
with ERRSRV - ERRinvnid up to and including TID 0x0238. After that, you get 
the following message from Windows 95:

                               Windows

  A fatal exception 0E has occurred at 0028:C104B7B7 in VXD VSERVER(01)
  + 00001973. The current application will terminate.

  * Press any key etc ...

If we press any key, then things continue, but eventually VSERVER hangs and 
will not respond to any network connection requests. I have tested this on two
separate machines, one installed by me, one installed by someone else, so I am
fairly confident that the bug exists.

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.

PATHWORKS for ULTRIX V1.3a will accept anything from A: to Z: as a service 
name in a tree connect, but it will not allow a sequence of:

  TreeConnect
  TreeDisconnect
  TreeConnect

The server process serving your requests crashes upon receiving the second 
tree connect. It is interesting to not that the Windows 95 client software 
disconnects the TCP connection when you disconnect the last network drive 
using that service. Since Windows 95 does not send a fresh TreeConnect when if
you map a drive to the same file service, it does not stumble over this 
problem.

If you send disconnect tree SMBs to PATHWORKS for ULTRIX 1.3a for all TIDs
from 0 to 0xFFFF when you have not set up any tree connections, PATHWORKS for 
ULTRIX V1.3a sends back ERRSRV - ERRinvnid for TIDs 0 through 482. For TIDS 
483 through 65535, the server process on ULTRIX serving the connection appears
to crash.

PATHWORKS for DEC OSF/1 AXP Version 5.0f ECO4

This product is also called PATHWORKS V5.0 for Digital UNIX (LAN Manager).

PATHWORKS for DEC OSF/1 AXP negotiates the LANMAN2.1 protocol when given a 
choice. It will not negotiate the NT LM 0.12 protocol, even when given the 
choice.

PATHWORKS for DEC OSF/1 AXP responds with a Max Buffer Size (MBS) of 4356 in
the response to the negprot SMB, and it responds with an MBS of 4356 when you 
send it a TreeConnect SMB.

PATHWORKS for DEC OSF/1 AXP will accept multiple attempts to negotiate a 
protocol and always returns the maximum it is happy with.

PATHWORKS for DEC OSF/1 AXP will not accept a large number of protocols in a 
negprot SMB. In fact, it will not accept any more than 11 protocols in the
negprot SMB. It responds with an ERRSRV - ERRerror (Non-specific error code.)
when given more than 11 protocols. It does not drop the connection or hang the 
connection when given a very large negprot SMB (32876 is the largest tried).

PATHWORKS for DEC OSF/1 AXP will accept C: as a service name as well as A: on
a tree connect. In fact, it will accept A: through Z: as the service name.

If you negotiate a protocol of PC NETWORK PROGRAM 1.0, PATHWORKS for DEC 
OSF/1 AXP will log you in as <calling-name> (from the RFCNB connection) as 
long as such an account exists and the correct password is present in the
tcon SMB. It also seems that if you send PATHWORKS for DEC OSF/1 AXP the 
following list of dialects:

     PC NETWORK PROGRAM 1.0
     LANMAN2.1NT LM 0.12
     NT LANMAN 1.0

that is, with out a 0x00 between LANMAN2.1 and NT LM 0.12, PATHWORKS for DEC 
OSF/1 AXP still seems to accept LANMAN2.1NT LM 0.12.

If you send disconnect tree SMBs to PATHWORKS for DEC OSF/1 AXP for all TIDs 
from 0 to 0xFFFF, when you have not set up any tree connections, PATHWORKS for 
DEC OSF/1 AXP sends back an incorrect response or no error for TIDs 0 through
65535 (0xFFFF). 
