Introduction

This document describes the initial plan for CIFS interoperability testing at Connectathon . Participants are encouraged to suggest changes at the kick-off meeting on Monday.

Connectathon represents a rare opportunity to test cross-vendor interoperability, so we should focus our test efforts on testing configurations that are not easily found outside of Connectathon.  In particular, this implies that we should not spend much time testing each vendors' server against the  common MS clients, because we can all do that back at our own facilities. We should try to examine interactions between vendor systems, i.e. between a member server and a domain controller when a client authenticates with the member server, etc.

Our test results at Connectathon will be recorded in an on-line grid with a cell for each combination of vendor, protocol area, and role (server or client).  After we have finalized the list of protocol features for the test grid, every participant will setup their part of the grid to reflect which protcol areas they will test, and what roles they can play in those areas (server, client, or both).  Once that is done, each vendor should run interoperability tests with each other vendor to fill in the results grid.

Server-To-Server Tests

Most Connectathon participants testing CIFS are bringing a "CIFS file server".  The proposed list of functional tests below is focused on server-to-server interactions.  Note that every "CIFS file server" acts as both a "server" and a "client" in various parts of its interactions with other servers.
 

List of tests: (proposed)

CIFS file service	This is the primary function of all CIFS servers.  All server vendors should check the "server" box for this protocol area. Note that many server implementations also provide a file service client, i.e. smbclient.  Vendors with such a client should also check the "client" box.  The test procedure for this protocol should be: Logon with the server as "cthon01" (a normal, non-admin account) Create a folder (named for the client vendor?) Copy a file into the folder Copy the file back to the client Delete the folder and file created
Domain Logon	This is the interaction between a "member server" and a domain controller when a client tries to connect with the member server. If the server supports LmCompatibilityLevel, set it to zero. All server vendors should check the "client" box for this area. Vendors that have domain controller functionality should also check the "server" box.  The test procedure is: Make your server a member of the domain name served by the domain controller you are testing with. Logon in the domain on an NT4 workstation Use the NT4 w/s to view a share on your server
Domain Logon  (NTLM)	(same as above, with LmCompatibilityLevel=4)
Domain Logon (NTLMv2)	(same as above, with LmCompatibilityLevel=5)
NetBIOS/TCP (WINS)	Both server and client are using WINS (no DNS). Open a connection to a server on another subnet. (Viewing the list of shares is sufficient.)
NetBIOS/TCP (DNS)	Both server and client are using DNS (no WINS). Open a connection to a server on another subnet. (Viewing the list of shares is sufficient.)
Browser service	With PDC on an isolated subnet and only one client in its domain, verify that the client shows up in the browse list on the PDC. (The client should act as the local master browser.)
Active Directory?	(suggestions anyone?)

Note that all of the above tests can be performed without any special test program technology.  Manual control and observation at a client will be sufficient for determining pass/fail results.  Of course, failure diagnosis will require "netmon" or similar network trace tools.

Other Tests

There are also tests that have been contributed to previous Connectathon events and CIFS conferences, but none of them appear to exercise cross-vendor interoperability (aside from MS client to your server, or your server to itself).  If there are additional tests that could be used to exercise interoperability between CIFS systems, please advise the CIFS coordinator.