IUP "Sciences et Technologies de l'Information et de la Communication" 1992-93 Deuxième année

Testing LAN Manager for UNIX at ICL

Manager: Chris Menmuir Keywords: LAN, UNIX, network, share ...

Author: Delphine Caron

0

1

Table of Contents

1. INTRODUCTION

2. WHAT IS ICL ?

3. DETAILS ON THE WORK CARRIED OUT 3.1. Training time 3.2.

Learning exercises

3.3.

Problem analysis 3.3.1. Testing 3.3.2. Programming

3.4.

Detailed presentation of the tasks carried out 3.4.1. Installations 3.4.2. Testing 3.4.3. Programming

4. COMPUTER CONFIGURATION & TECHNICAL ENVIRONMENT

5. DESCRIPTION OF THE SOFTWARE AND OTHER TOOLS USED

6. CONCLUSION

2

Appendix A: DOCUMENT REFERENCE Appendix B: EXAMPLE OF REPORT WRITTEN WHILE TESTING WITH THE CLIENT SIMULATOR Appendix C: EXAMPLE OF BUG RECORD IN RABID Appendix D: NETBIOS PING PROJECT DEFINITION

3

1. Introduction

WORK PLACE ICL Lovelace Road Bracknell Berkshire RG12 8SN U.K. ...also known as BRA01.

PERIOD OF TRAINING From June 14th, 1993 to September 30th, 1993

WORK SUBJECTS 9 TESTING (5 weeks) I was part of the team which tested LAN Manager for UNIX v 2.1a & 2.2. I then tested the capacity of connection of several Unix servers using AT&T's Client Simulator (StarGROUP Software System Test Products). 9 PROGRAMMING (11 weeks) I developed a "ping"-like utility for NetBIOS (over UNIX).

4

Y

TECHNICAL ENVIRONMENT I tested and programmed on UNIX servers, also using a PC under DOS environment for a few tests and for daily works.

USE OF MY WORK 9 After testing had been completed by the LM/X team, the software has been customised. 9 Testing the capacity of connection of a Unix server enables, among other things, to know how many LAN Manager client sessions it will be able to support at a time. 9 It is envisaged that the UNIX components of the "ping" utility will be included as part of the DRS/NX NetBIOS packages in future versions. It is envisaged that "NetBIOS ping" will be used to check whether or not NetBIOS connections between computers can be successfully established after configuration before applications such as LAN Manager, which use NetBIOS, are tried, or in situations where LAN Manager cannot establish a connection.

5

2. What is ICL ?

ICL is one of the world's leading computer manufacturing and information technology companies. Operating in over 70 countries worldwide, with around 25,000 employees, ICL generated revenues of almost £2,5 bn in 1992. ICL supplies applications software, information technology services and computing hardware, through its companies located worldwide. ICL (UK) Ltd covers the UK and Ireland; ICL Europe covers the EC and EFTA countries and ICL International covers Eastern Europe, Asia and Africa. ICL's North American operations are managed principally through ICL Inc., and joint venture with Fujitsu under the management control of ICL. ICL was formed in 1968 by the merger of the leading British indigenous computer suppliers and its corporate centre is still in London. In 1984, ICL was acquired by STC PLC, which then became the second largest UK-based industrial electronics group. In November 1990, Fujitsu Limited of Japan invested in ICL by taking an 80 per cent shareholding. STC (now owned by Northern Telecom of Canada) retained a 20 per cent shareholding. In October 1991, ICL merged with Nokia Data. As part of the terms of this agreement, Nokia Group acquired options to take 5 per cent of the shares, when ICL is re-floated on the London International Stock Exchange. ICL is a leading European computer systems and services company and an autonomous member of the world's second largest information Technology group. Its home market is Europe but ICL conducts business in over 70 countries worldwide. Within this business stream, ICL provides a wide range of services including support and maintenance of hardware and software, consultancy, facilities management, training and disaster recovery. ICL is already the largest provider of IT services in the UK and Finland. ICL supplies business and technical services for any IT project e.g. project management, systems integration, communications, applications development, training and implementation. Operational services such as hardware maintenance (for most types of equipment), facilities management and disaster recovery, are also provided by ICL. ICL has worked for companies like BP, ICI, Marks and Spencer, the Bankers Automated Clearing Service (BACS - the largest clearing service in Europe), Deutsche Bundespost, SNCF, and Telefonica.

6

ICL is also a major investor in European IT research and development. ICL takes an active role in the IT research programmes run under the auspices of the European Comission, e.g. ESPRIT, RACE etc., and ICL is also a partner in JESSI, a EUREKA programme. In addition, ICL has one-third share in the European Computer Industry Research Centre (ECRC) in Munich, and advanced institute investigating "fifth generation" computing techniques. ICL's principal product development activities are undertaken in Europe notably in the United Kingdom and Scandinavia (Finland, Sweden and Denmark). Additionally, in the USA, retail systems development is carried out at Santa Clara and San Diego, California; UNIX development at Irvine, California; and development of ICL's OFFICEPOWER office automation system at Reston, Virginia. ICL is a member of the European Foundation for Quality Management (EFQM), and is now used by other companies as a "benchmark" for Total Quality Management (TQM) in Europe. External recognition in 1992 included a Michelin Quality Circle Excellence Award for the second year running, a third UK National Training Award for our quality and customer care training, and a supplier of the year award from Sun Microsystems Inc. to its factory in Kidsgrove.

7

3. Details on the work carried out

3.1. TRAINING TIME The first two weeks were spent becoming familiar with the computer systems used, and the LM/X product itself. To become familiar with LM/X, I read all the manuals written on this subject (see Appendix A) to get the main purpose and actions of this software, and to be able to manipulate it. For the first month of my placement at ICL, I could be aided by another industrial trainee, who had been testing the product for the last 6 months, and so was quite knowledgeable in the matter.

3.2. LEARNING EXERCISES 9 The learning exercises for LAN Manager just consisted in reading the manuals and then trying to run commands by myself. 9 As AT&T's Client Simulator is a quite simple product, I just needed to read a booklet of user's information, then to start sessions to see how it worked. It took half a day to get used to it. 9 Creating the "NetBIOS ping" utility, I had to learn everything about the XTI library (C library). I programmed an initiator and a responder step by step, testing my programs just after I had added a new XTI function. This usually enabled me to encounter one bug at a time, and to be able to understand it and correct it. This can be considered as a learning stage in "NetBIOS ping" programming.

8

3.3. PROBLEM ANALYSIS 3.3.1. TESTING There are 2 different types of tests: • those you do for the first time from the Product Test Schedule document • those you do to check whether or not a bug still exists in the new version of a software I was given the opportunity to do tests of these two types. ♦ Testing from the "Product Test Schedule" document You just refer to the section you are testing in the "Product Test Schedule" document, read what has to be tested, then use your brain to find out how to test it. For example, testing the client netrun service, you read in the "Product Test Schedule": 8.7. Client netrun service The netrun service enables a client to run a program or command on a server. Run a few commands, e.g. date, who,... etc. Run a few programs, e.g. bc (binary calculator),... etc.

♦ Bug management Each time a tester finds a bug (inconsistency with the design) in a software, he has to make a record of it in a database called RABID (Remote Access Bug Information Database). This type of record gives all sorts of information on a bug, including who found the bug for the first time, doing what, the severity of the bug, which kind of machine and which version of the software the raiser was working on, and other details permitting to identify it correctly so that it can then be fixed. You can find an example of RABID record in Appendix C. Each time a new version of a software is about to release, you have to check whether or not the bugs previously found in it still exist. Following is the development of the main stages of bug management: •

send a request to the RABID database to get the full details on the current bugs

•

follow the same steps as the bug raiser and see what happens

•

if a bug still exists (the same as described or a slightly different one), then you specify what you did and what exactly happened, and you add this information to the bug record in RABID.

9

If the bug still exists but you know the problem won't be solved before the software customised version releases, then you have to raise a SKE (Software Known Error). If the bug does not appear any more, then you can fix it, and close its record file in RABID. A fixed bug can be re-opened in case of need. Raising a SKE is made by making a record in a huge database called PARIS, where it will be stored on a CD-ROM. The PARIS database enables customers and engineers to refer to a bug they have encountered while running a software, and gives them another way to do what they wanted. Moreover, engineers can read a technical description and explanation of the bug. ♦ Testing with AT&T's Client Simulator The purpose of these tests was to establish how many client sessions a specific server could support. This is why you worked concurrently on 3 or 4 servers, starting the maximum number of sessions on 2 or 3 of them, and checking how the last one handled those sessions. To start sessions from a server, you have to define the following parameters: Server name: [test. server]: Server shared directory: [SYSTEST]: Local test directory: [/tmp]: # of VCs to start: [32]: File size (# of Kb) for transfer: [10]: Number of seconds sleep between transfers: [0]: Max. number of runs: I= infinite; F=fixed number [I]: Three forms of Client Simulator runs can be executed: r = READ (File Xfer server to client) w = WRITE (File Xfer client to server) v = VERIFY (File Xfer client to server & back) Enter which type of test: r, w, or v: [w]:

I wrote the results of those tests in a report as shown in Appendix B.

10

3.3.2. PROGRAMMING As I had not to use any of my skills for testing, I asked to do something else. That is why I have been told to work on a "ping"-like utility for DRS/NX NetBIOS. This project had already been started by a French IT. I was expected to test his program, then to go on with it, programming a DOS interface. However, the existing program was so complex that it was absolutely impossible for a beginner as I was to test it. Thus, in agreement with my manager, I re-started the "ping" project, trying to make something simpler and which would correspond better to ICL's need. ♦ Purpose of the "ping" utility This project entails producing a "ping"-like utility which works over any form NetBIOS', i.e. NetBEUI, OSI or TCP NetBIOS' using both connection-mode and connectionless transports. The component parts consist of UNIX initiator and responder. It is envisaged that the UNIX components will be included as part of the DRS/NX NetBIOS packages, in future versions. It is envisaged that "NetBIOS ping" will be used to check whether or not NetBIOS connections between computers can be successfully established after configuration before applications such as LAN Manager, which use NetBIOS, are tried, or in situations where LAN Manager cannot establish a connection. (extract of the Project Definition document)

The program suite ( an initiator and a responder) had to be written using standard UNIX 'C' and the XTI library. Let's now define the basical concepts of programming with the XTI. ♦ Transport endpoints A transport endpoint specifies a communication path between a transport user and a specific transport provider, which is identified by a local file descriptor (fd). When a user opens a transport provider identifier, a local file descriptor fd is returned which identifies the transport endpoint. A transport provider is defined to be the transport protocol that provides the services of the transport layer (e.g. TCP with COTS, OSI with CLTS, NetBEUI with COTS, etc.). All requests to the transport provider must pass through a transport endpoint. The file descriptor fd is returned by the function t_open() and is used as an argument to the subsequent functions to identify the transport endpoint. A transport endpoint (fd and local address) can support only one established transport connection at a time. To be active, a transport endpoint must have a transport address associated with it by the t_bind() function. A transport connection is characterised by the association of two active endpoints, made by using the functions of establishment of transport connection (t_listen(), t_connect(), t_accept()). The fd is a communication path to a transport provider. The t_open() function will work only if the opened character string is a pathname (e.g., for OSI with COTS the pathname is the "/dev/nb/osi/cots" string).

11

♦ Transport providers The transport layer may comprise one or more transport providers at the same time. Usually the transport providers for NetBIOS will be: • • • • • • • • •

TCP – lana0 - COTS TCP - lana0 - CLTS … TCP - lana7 - COTS TCP - lana7 - CLTS OSI - COTS OSI - CLTS NetBEUI - COTS NetBEUI - CLTS

The identifier parameter of the transport provider passed to the t_open() function determines the required transport provider. For the above transport providers, the identifier parameters are: • • • • • • • • •

"/dev/lana0" "/dev/lana0dg" … "/dev/lana7" "/dev/lana7dg" "/dev/nb/osi/cots" "/dev/nb/osi/clts" "/dev/netbeui" "/dev/netbeuid"

An application which wants to manage multiple transport providers must call t_open() for each provider. For example, a server application which is waiting for incoming connect indications from several transport providers must open a transport endpoint for each provider and listen for connect indications on each of the associated file descriptors.

12

♦ Overview of connection-oriented mode

The connection-mode transport service consists of four phases of communication: • Initialisation / De-initialisation • Connection Establishment • Data Transfer • Connection Release

In order to establish a transport connection, a user application must: 1. Supply a transport provider identifier for the appropriate type of transport provider ( using t_open() ); this establishes a transport endpoint through which the user may communicate with the provider. 2. Associate (bind) an address with this endpoint ( using t_bind() ). 3. Use the appropriate connection functions ( using t_connect(), or t_listen() and t_accept() ) to establish a transport connection. The set of functions depends on whether the user is an initiator or responder. 4. Once the connection is established, normal, and if authorised, expedited data can be exchanged. 5. The transport connection can be released at any time by using the disconnect functions. Then the user can either de-initialise the transport endpoint by closing the file descriptor returned by t_open() (thereby freeing the resource for future use), or specify a new local address (after the old one has been unbound) or reuse the same address and establish a new transport connection. •

Initialisation / De-initialisation phase

The functions that support initialisation/de-initialisation tasks are listed below. t_open()

This function creates a transport endpoint and returns protocol-specific information associated with that endpoint. It also returns a file descriptor that serves as the local identifier of the endpoint.

t_bind()

This function associates a protocol address (NetBIOS address) with a given transport endpoint, thereby activating the endpoint. It also directs the transport provider to begin accepting connect indications if desired.

t –unbind() This function disables a transport endpoint such that no further request destined for the given endpoint will be accepted by the transport provider. t_close()

This function informs the transport provider that the user is finished with the transport endpoint, and frees any local resources associated with that endpoint.

13

•

Overview of Connection Establishment

This phase enables two transport users to establish a transport connection between them. In the connection establishment scenario, one user (called the initiator) is considered active and initiates the conversation, while the second user (called the responder) is passive and waits for a transport user to request a connection. The functions that support these operations of connection establishment are: t_connect()

This function requests a connection to the transport user at a specified destination and waits for the remote user's response. This function may be executed in either synchronous or asynchronous mode. In synchronous mode, the function waits for the remote user's response before returning control to the local user. In asynchronous mode, the function initiates connection establishment but returns control to the local user before a response arrives.

t_listen()

This function enables the passive transport user to receive connect indications from other transport users.

t_accept()

This function is issued by the passive user to accept a particular connect request after an indication has been received.

•

Overview of Data Transfer

Once a transport connection has been established between two users, data may be transferred back and forth over the connection in a full duplex way. Two functions have been defined to support data transfer in connection mode as follows: t_snd()

This function enables transport users to send data over a transport connection.

t_rcv()

This function enables transport users to receive data on a transport connection.

•

Overview of Connection Release

An abortive release may be invoked from either the connection establishment phase or the data transfer phase. When in the connection establishment phase, a transport user may use the abortive release to reject a connect request. In the data transfer phase, either user may abort a connection at any time. The functions that support connection release are: t_snddis()

This function can be issued by either transport user to initiate the abortive release of a transport connection. It may also be used to reject a connect request during the connection establishment phase.

14

t_rcvdis()

This function identifies the reason for the abortive release of a connection, where the connection is released by the transport provider or another transport user.

t_sndrel()

This function can be called by either transport user to initiate an orderly release. The connection remains intact until both users call this function and t_rcvrel().

t_rcvrel()

This function is called when a user is notified of an orderly release request, as a means of informing the transport provider that the user is aware of the remote user's actions.

15

♦ Overview of connectionless mode The connectionless mode consists of two phases of communication: • Initialisation/ De-initialisation • Data Transfer

In order to permit the transfer of connectionless data, a user application must: 1. supply a transport endpoint for the appropriate type of provider ( using t_open() ); this establishes a transport endpoint through which the user may communicate with the provider; 2. associate (bind) an address with this transport endpoint ( using t_bind() ); 3. the user may send and /or receive connectionless data, as required, using the functions t_sndudata() and t_rcvudata(). Once the data transfer phase is finished, the application may either directly close the file descriptor returned by t_open() (using t_close() ), thereby freeing the resource for future use, or start a new exchange of data after disassociating the old address and binding a new one. •

Initialisation / De-initialisation Phase

The functions that support the initialisation/de-initialisation tasks are the same functions used in the connection-mode service. •

Overview of Data Transfer

Once a transport endpoint has been activated, a user is free to send and receive data units through that endpoint in connectionless mode as follows: t_sndudata()

This function enables transport users to send a self-contained data unit to the user at the specified protocol address.

t_rcvudata()

This function enables transport users to receive data units from other users.

♦ Progressive stages of NetBIOS session The following figure shows the progressive states of a NetBIOS session.

16

Program A

NetBIOS

Open a transport endpoint

Program B Open a transport endpoint

t_open ---------------> transport_id

sequence number

Session ID

Session begins t_snd ---------------> t_rcv --------------- >

EARTH total: 210 sessions - OK

/dev/lana0 100 sessions - OK 100 sessions: could not start more than 99 sessions 56 sessions - OK

/dev/lana0dg. 100 sessions - all NotCONN 56 sessions - all NotCONN 100 sessions - sessions 61 to 100 NotCONN

/dev/nb/osi/clts 100 sessions - hung up after having started the 1st session 56 sessions - hung up after having started 48 sessions 100 sessions - sessions 1 to 16: stanby; sessions 17 to 100: NotCONN

35

Appendix C - Example of bug record in RABID ------------------------------------------------------------------------------------------------------------------------Bug 44152 Mar 19 1993 15:40:13 sw product lmxclient release null version v2.2.0 (b) Severity: (b) critical User Contact: james darling icl - bra01 Phone 7263 x2253 Originator: jcd (James Darling) Machine: msdos Customer Reference: jcd_19/03/93_15:40:12 Assigned to jsh (stuart harrison x2551) Keywords: Bug Abstract: "revoke tree" on WNetAdmin v2.2 (version b) does not work. Bug Attachments: Bug Description: this bug is repeatable When trying to "revoke tree" with net admin 2.2 (the newer version), the screen shows everything working OK, but the root directory (.) of the share appears to remain permitted. This can only be seen from an older version of net admin, as version b looks at the directory entries, and assumes that all other files have these permissions unless explicitly set. On leaving the file permissions screen, net admin returns "computer name invalid", and then proceeds to misbehave as before. When then trying to "revoke tree" with an older version of net admin, "list the permissions for this resource" is returned. However, the. entry can be un-permitted individually. interim response by jsh on Mon Apr 5 09:39:36 1993 The tester indicates that this used to work in the 2.1a version. interim response by jsh on Wed Apr 14 09:32:56 1993 Response from AT&T: #44152 -We can't make it happen, but are not sure we're doing what you did to make it happen. This is the second one that I asked for clarification. Please, again, give me the exact steps you took. Thanks

Jul 1 12:34 1993

lmxclient Page 15

interim response by jcd on Thu Apr 22 18:51:07 1993 44152 - select server, view/shared resources, select share. choose "permissions". Make up some permissions for the root (.) entry, and do "permit tree". Also you could individually change perms. for a couple of files. Do "revoke tree" and then "save" or "done" and you should get "computer name invalid" message. Net admin may well hang up when trying to leave it. On going back into the "permissions" screen, either after restarting Net Admin, or from another client, you can see that none of the permissions have changed. Revoking all on the root (.) entry of the share, and then doing "revoke tree" usually works, but occasionally permissions on subdirectories remain unchanged. -

36

Appendix D - NetBIOS PING Project Definition Draft Issue 1 Project Title: NetBIOS PING Date: April 8th, 1993 Author: Stuart Harrison

0

TERMINOLOGY

Initiator a process which initiates a call from to another process (responder). The responder process may be on another computer or the same computer as the initiator. Responder a process on one computer which replies to a call made from an initiator. The responder may be on another or the same computer as the initiator. TBD to be defined. 1

INTRODUCTION

This project entails producing a "ping"-like utility which works over any form NetBIOS', i.e. NetBEUI, OSI or TCP NetBIOS' using both connection-mode and connectionless transports. The component parts consist of a UNIX initiator and responder and a DOS initiator and responder. The project can be implemented in phases with the UNIX initiator and responder being implemented first, followed by the DOS initiator. It is envisaged that the UNIX components will be included as part of the DRS/NX NetBIOS packages, in future versions. The final disposition of the DOS components is to be defined. It is envisaged that "NetBIOS ping" will be used to check whether or not NetBIOS connections between computers can be successfully established after configuration before applications such as LAN Manager, which use NetBIOS, are tried, or in situations where LAN Manager cannot establish a connection.

2 2.1

OUTLINE DESIGN UNIX responder

For connection-mode, Ian suggests that this uses the Network Listener service to listen for incoming connections and fork a copy of the UNIX ping responder when one is received. The Network Listener service should be configured to listen on all of the NetBIOS interfaces present on a given computer, i.e. which of NetBEUI, TCP NetBIOS or OSI NetBIOS the given computer is running. The "ping" listener should listen on the NetBIOS name:

37

computername \0xfe i.e. the computername padded up to 15 bytes with spaces with the 16th byte set to 0xfe. The forked "ping" responder will read the data from whoever sent it, then write the data back again. The connectionless "ping" listener will use the XTI-to-NetBIOS interface to interface with NetBEUI, TCP NetBIOS and OSI NetBIOS. It will open connectionless endpoint(s) on one, two or all three NetBIOS' as directed from the command line and bind to a "well-known" unique NetBIOS name, e.g: computername \0xfd i.e. the computername padded up to 15 bytes with spaces with the 16th byte set to 0xfd. The connectionless responder will then poll the file descriptors which it has opened waiting for input; when input is received the responder will return the datagram received back to the sender. The connectionless responder will be startable and stoppable from the UNIX command line or it could be started from a startup script in /etc/rc2.d, for example. For connection-mode and connectionless responders, there will be an option to write a message to a log file of the form: "Message received from NetBIOS name on transport devicename" "Message received was :dump of message in hex and ascii"

2.2

UNIX initiator

This will be run from the command line with a command of the form nbping computername netbios-type tranport-type timeout where netbios-type will be one of tcp, osi, netbeui transport-type will be one of cots for connection-oriented transport clts for connectionless transport and timeout will be the time to wait for a reply (6 seconds is suggested as the default) netbios-type, transport-type and timeout could be optional arguments. When not specified, nbping could try all netbios-types in turn and report success/failure on each.

38

On cots, success is denoted by a successful connection, sending of data, receiving the same data back again and successful close. Any discrepancy or error response will be reported to stderr. On clts, success is denoted by sending of a datagram and receiving the datagram back again. Again any discrepancy will be reported to stderr. Since connectionless datagrams are not guaranteed to be delivered, then the Initiator should send the datagram again if it has not received a reply to its first send after the timeout has expired; the total number of repeats before the Initiator assumes a connectionless failure could be a configurable option. 2.3

DOS initiator

My knowledge of the DOS interface to NetBIOS is too hazy to attempt even a partial definition; however I am informed that the NBC (NetBIOS Control Block) interface is the same for all of the NetBIOS'. The functions are essentially the same as for the UNIX initiator and the command which the user specifies at the DOS prompt should be as close to the UNIX command as possible in format and argument order so that the user doesn't need to know too many variants of the command to use it simply. With advent of MS-DOS OSLAN version 4, which is Windows virtual device driver, there will be a need for a Windows version of "nbping" (i.e. a Windows program). This will be implemented at a later stage, i.e. will not form part of the initial implementation. 2.4

DOS responder

See 2.3 above. 3

PROJECT DEFINITION

This stage involves the writing of a design document for the project; this document will conform to NPC standards wherever possible but it is acknowledged that because of time constraints that flexibility will be required here. The design document will show at least the following: 1. the design of the major components, i.e. what programs will reside where, how they will work and communicate with other programs in the suite. 2. a plan for implementation in stages such that if the designer doesn't get all of the project finished, a working set of programs will be the result even if they don't contain all the target functionality. The first stage should be prototyping. Each stage will build on what has gone before. 3. a definition of each stage, i.e. what it contains. 4. the tools to be used. 5. what someone in the future will need to know to support, maintain and possibly enhance this program suite 6. the standards to be met or exceeded If time permits, there will be a design review before much of the implementation is done.

39

4

IMPLEMENTATION

As previously mentioned, the project will be implemented in stages; I suggest that the first stage should be a prototyping exercise to become familiar with the interfaces to be used and to get some simple UNIX programs to talk to each other over NetBIOS. The next stage could be to define exactly what is to be implemented in the design document. Where a stage involves writing and testing some of the components, testing should be completed in accordance with the definition in the design document before the next stage is started. Minor inconsistencies with the design ("bugs") will not prevent the succeeding stage from being started. It is anticipated that the program suite will be written in 'C' using Microsoft 'C' (6.0 or later) for the PC components and "standard" UNIX 'C' and libraries for the UNIX components.

40