test

TotalNET Advanced Server 5.2 Reference Manual

Chapter 7 Troubleshooting

This chapter explains how to correct problems with the TAS system. It includes instructions for collecting diagnostic information for customer support engineers using trace and csr.tn, as well as a compilation of common error messages that users might see and instructions for resolving them. This chapter includes the following sections:

General Troubleshooting

You can resolve many problems that occur in the TAS system if you start from the simplest possible causes for an error and work towards the more complex. Such a systematic approach helps you develop a theory, test it, and isolate and correct the problem.

The list of questions below provides a starting point for resolving problems this way. They address the following categories:

Initial Connection

Does the user have a valid UNIX account?

To make sure that the server recognizes the user name, attempt to open a telnet session from the client, with that user name.

If you cannot complete a process from a PC, can you complete it from UNIX?

If you can perform the process from UNIX, you may have incorrect attach point configuration or client connection--but keep in mind that you cannot replicate all actions performed from a PC, on UNIX. Open a telnet session and try the process from UNIX. For example, if you have printing problems, telnet to the server and use the lpr command to send a file to the printer. If the action works under UNIX, check the client and server configurations.

Did you correctly configure the transport protocol?

Check this using another program. For example, to check the TCP/IP configuration, use ping from UNIX.

LM-NT-OS/2 Connections

Do the client and server reside on different subnets but connect via NetBIOS-over-NetBEUI?

If they do, the client cannot connect to the server because this protocol setup only works within the subnet. You must have NetBIOS-over-TCP/IP to connect a client and server on different subnets. NetBIOS-over-NetBEUI does not route.

Does the client attempt to access a service using NetBIOS-over-TCP/IP on the other side of the router?

In order for a client to find a NetBIOS name on the other side of a router, it must have the ability to map an IP address to that NetBIOS name. You can accomplish this by using static tables, Windows Internet Naming Service (WINS), or Enterprise Name Server (ENS) to configure the client to resolve the service name to its associated IP address.

Does the client use the same SMB dialect as the server?

Some older client software does not use the extended SMB protocol in the same way as the server. To force the client to revert to the core protocol, use this command:

tnservice -M -r NB -s servicename -a smb-protocol-level=on

NetWare Connections

Do IPX network numbers correspond to interface frame types?

For the server network interface, make sure that you have configured the correct frame type and associated it with the correct hexadecimal NetWare network number. To find out the correct rame type/network number combination, look at Novell server configurations or run ipxprobe after shutting down IPXd. If your network does not contain a Novell server, you can use any hexadecimal number unique for the frame type.

TotalNET IPX supports full routing, which means that you can configure it to use more than one network interface, and it supports multiple frame types on each interface. TAS treats a single physical network as a collection of distinct logical networks using distinct interface frame types and performs routing among the logical networks just as it does their physical networks, so each frame type on the system must associate with a different net number.

You can configure each interface for a number of frame types with corresponding network numbers. For instance, interface_1 might have frametype_x with netnumber_x and frametype_y with netnumber_y, and interface_2 might have frametype_x with netnumber_x and and frametype_z with netnumber_z. You must use a unique net number for the internal frame type in the NetWare realm. Never delete the internal frame type.

To check frame types and network numbers from the UNIX command line, use the command tniface -R -n tnipx.

Can you see the server with "slist"?

To view all of the NetWare servers currently active on the network, access Network Neighborhood or, in DOS, use the slist command. If the NetWare server you need does not appear on the slist list, advertisements from the server do not reach your client. You may have a disabled server or a problem with Service Advertisement Protocol (SAP) advertisements. To see if you enabled your server, click Status at a Glance.

If you suspect a problem with SAP advertisements, contact a Syntax Technical Support engineer at support@syntax.com for further assistance. Before contacting Syntax, see "Contacting Sun Technical Support".

Does the server process the client utilities?

Different versions of login programs used by NetWare vary greatly. For example, if you wish to use Novell 3.12 utilities to connect to a NetWare realm service, you must turn on client encryption for that service, since the 3.12 utilities only send encrypted passwords. You do not need to turn on password encryption for clients of versions later than 3.12, however, because they can send clear-text passwords.

Syntax provides login utilities for the NetWare realm in $TNHOME/NW/sys/login. They provide similar functionality to programs used by NetWare. To turn on client encryption, use the "tnservice" command.

AppleTalk Connections

Does each file have three parts?

UNIX stores Macintosh files in three forks: the data fork, the resource fork, and the finder information fork. The data fork contains the actual data contained in the file, the resource fork indicates the application to launch when you open the file, and the finder information fork maintains data about the file's creator, type, location on the desktop, and icon.

TAS stores these parts in separate directories. When you create a file from a Macintosh client, TAS writes the data fork writes to the current directory, the resource fork to the subdirectory .tnatr:reso-fork, and the finder information to the file .tnatr:intf. If TAS cannot locate all of these pieces, the file may not launch correctly. In versions of TAS previous to 5.x, TAS writes the data fork to the current directory, the resource fork to the .resource directory and the finder information to the .finderinfo directory.

Does the finder information map file exist and contain the correct information?

The finder maintains information about files, such as the file's creator, type, location on the desktop, and icon. When the server cannot locate finder information, it attempts to generate reasonable default values for this information based on data in the map file. These values may not contain the correct information.

An AppleTalk map associates file suffixes with Macintosh applications. The client operating system uses these associations to determine which application it should invoke when it accesses a file.

To check mapping configuration, use the "tnsuffix""tnsuffix command.

Do the Macintosh and PC versions of the program share the same data format?

Occasionally, these platforms cannot share files of the same program.

Realm-Specific Error and Activity Logs

TAS generates a number of logs that you can use to monitor and manage the TAS system. Within each realm, a log generates during startup, and error messages sent within the realm append to the log as they occur.

You can enable an activity log that records information about all connections to file services; do so by enabling the log activity attribute when you configure a file service. This attribute applies per service. The report generated by csr.tn includes the activity log.

Error Logs

Realm error logs reside in each realm's folder. The NetWare realm's log resides in $TNHOME/NW/log, the LM-NT-OS/2 realm's log resides in $TNHOME/NB/log, and the AppleTalk realm's log resides in $TNHOME/AT/log. These logs provide startup information for the realm and error messages generated during startup in a common log format. If a client cannot connect to a service in a particular realm, you can check the log for that realm for TAS startup errors.

Activity Logs

To maintain a log of connection activity for a realm, you must enable the activity attribute on each relevant file service. This attribute applies per service. The activity log file activity.tn then registers the following statistics whenever service terminates in the realm:

To enable activity logs from the UNIX command line, open a telnet session to the server and use the following command:

./tnservice -M -r NB -s service -a activity=on

Error Messages and Solutions

This section provides solutions to error conditions accompanied by error messages. The table below details the exit codes that appear as tn-utilities error messages. The rest of this section lists causes and solutions for other common error messages.

0 

Success 

1 

Usage 

2 

Incompatibility 

3 

Invalid command line 

4 

General memory allocation 

5 

Disabled system 

6 

Invalid realm, system, or service 

7 

Application Interface error 

8 

System call failure 

9 

C library failure 

10 

Invalid characters in volume, for specified realm 

11 

Invalid characters in service, for specified realm 

12 

Service name too long for specified realm 

13 

Denied permission; superuser access only 

Access denied

The user does not have privileges to either read a file, write a file, execute a program, or search a directory.

Cannot access a directory

The NetWare client cannot access a UNIX directory. Verify that the directory has the execute permission bit set and resides below the virtual root of the volume.

Cannot access network drive

The Windows interface on the network has one of these problems:

Cannot create socket on server

The system socket call failed on TAS startup for one of the following reasons:

Cannot log in to server as supervisor

The server uses the UNIX operating system to authenticate users, so the user account must exist on the UNIX host before you can log in. A Novell server's system administrator defaults to supervisor; the UNIX equivalent defaults to root. Typically, you must log in as root to administer the UNIX operating system.

Incorrect password

The server has not validated the user's name or password. Make sure the name and password fulfill the following requirements:

Incorrect response from network

The name discovery phase succeeded, but the system rejected the connection request, for one of the following reasons:

Invalid connections in "tninfo" report

The output of tninfo shows a connection that does not exist. The tninfo report normally shows only one connection per Ethernet address. Occasionally, a duplicate may list when the server has not yet recognized a connection termination. An ungraceful disconnection by the client, as when the client turns off the PC or reboots without logging out, usually causes this.

To detect dead connections, enable the keepalive function for the LM-NT-OS/2 and NetWare realms. This tells the server to send keepalive packets, similar to Novell watchdog packets, to determine whether clients remain attached. After sending the first keepalive packet, the server sends another packet every minute for 10 minutes. If it receives no response during this time, the server assumes that the connection died and updates the connection database accordingly. The client no longer lists in the tninfo report.

To enable keepalives, use the following command, where n represents the number of minutes for the server to wait after a connection establishes before sending the first keepalive packet:

tnservice -M -r NW -s nwhera:file -a keepalive=n:

Invalid drive was specified

A problem exists with the drive letter in a client command. This can occur when a client attempts to redirect a local drive, such as a diskette drive or a hard drive partition.

Network device type incorrect

The user has attempted to redirect either a drive to a print device or a printer port to a directory.

Network path not found

The client did not receive a response from a server when it broadcast a request for a NetBIOS name, for one of the following reasons:

A.B.C.D

Determine the address with this table:

If A is: 

the network number is: 

< 128 

A 

128 - 191 

A.B 

> 191 

A.B.C 

If A is: 

the network mask is: 

< 128 

255.0.0.0 

128 - 191 

255.255.0.0 

> 191 

255.255.255.0 

No servers listed by "slist"

In a PC's net.cfg file, you can list several frame types to use over the network card. The network uses only the first entry when transmitting packets. If a server host does not have the configuration to use the same type of frame as the client, the client cannot see that server; the server does not list from the slist utility or on the Windows NetWare interface.

Remote computer not listening

This problem may occur with an inactive NBdaemon process. Use the "tnstat" command to verify that you started TAS. If you have not, use the "tnstart" command.

Routing information database corrupted on large internetwork

NetWare servers broadcast routing information every 60 seconds using the Routing Information Protocol (RIP), and they broadcast service information every thirty seconds using the Service Advertising Protocol (SAP). On a very large internetwork or wide-area network, the RIP or SAP database can grow so large that the time necessary to download it exceeds the interval between downloads, especially if you have a low-speed WAN link. This can cause the apparent disappearance of volumes, printers, or servers or extreme delays in packet re-routing, if a node fails.

Novell will replace RIP and SAP with NetWare Link State Protocol (NLSP). NLSP associates multiple network interfaces with a single network number, distributing traffic across multiple network segments. If a node fails, NLSP can quickly establish an alternate path. NLSP builds a map of the network incrementally and sends updates only as needed. NetWare 3.11, 3.12, 4.11, and 4.12 servers support NLSP. They can still work with existing SAP/RIP servers.

Server not found

The name-discovery phase succeeded, but the system cannot find the requested resource on the server, for one of the following reasons:

Too many redirections

The user has attempted to exceed the number of connections allowed by the client computer's network operating system, NetBIOS, or TCP/IP. Update nb_sessions, tcp_sockets, or udp_sockets entries in the net.cfg file to allow more redirections. If you do not want to allow more redirections, cancel a redirection, then try again.

Unknown board ID

The age of the network card driver exceeds the age of the physical network board. Replace the board interface software with a newer version.

Error Conditions and Solutions

This section provides solutions to several error conditions not necessarily accompanied by error messages.

Application on UNIX server inaccessible

The user cannot execute a program residing on a TAS host, for one of the following reasons:

Compilation problems in DOS window

Compiling programs on a network drive in a Windows DOS prompt window can cause data corruption or dropped connections. For Windows for Workgroups and Windows 3.1, add the following line in the section labeled [386Enh] in the PC's Windows system.ini file:

InDOSPolling=True

Connection failure

Some network boards have more than one cable connection, and some have transceivers on their boards. Make sure the physical hardware jumpers can use the same connection as the software settings.

Dead sessions not dropped

When a user turns off or reboots a client PC, the network connection breaks. If this happens during a data transfer, TAS notices immediately and terminates the appropriate process. If it happens when no traffic passes between client and server, TAS notices only after a few minutes. This timeout period, dependent on the host system, typically lasts about five minutes. After the timeout period elapses, TAS terminates the appropriate process.

TAS, by default, relies on the host's underlying transport layer keepalives to keep track of dead sessions. If other applications, such as telnet, do not drop dead connections, the transport vendor may not have keepalives implemented. You may have configured TAS to use NetBIOS keepalives instead by changing the keepalive attribute with the "tnservice" command.

Disconnected clients still appear connected

When a PC client terminates a session--that is, disconnects a redirected drive--the associated process attempts to close the session in an orderly fashion. This includes removing the file name.number from the directory $TNHOME/TAS/tn/tndb. The name variable represents the machine name of the client PC, and number represents the UNIX ID number of the associated process.

If the client cannot remove this file, it exits without error, but when you check connection status or issue a tnwho or tninfo command, the client appears connected. Verify that totalnet owns the program srm, which does the actual removing of entries from the circuits directory, that srm has a mode of 4511, that totalnet owns the circuits directory, and that the circuits directory has a mode of 755.

DOS commands yield unexpected results

Certain DOS commands may behave unexpectedly, for the following reasons:

File locking errors

Files do not properly lock or unlock because the client PC rebooted and file locks did not clear. Run tnck to clear the locks.

Free disk space indicated incorrectly

Client disk space calculation limitations have become too great. DOS has problems with any disk device, whether redirected or local, that reports cluster sizes of 64 kilobytes or larger. Large UNIX systems or machines with, for example, several CD-ROM drives mounted, may represent drives totaling more than four gigabytes. DOS cannot handle numbers of this magnitude.

NetBIOS does not start

When NetBIOS does not start, make sure that the NetBIOS processes completely shut down. Use the ps command to find out whether the NBname or NBdaemon process runs even after you use shut down TAS services. This problem occurs only when a process aborts abnormally. Use the UNIX kill command to terminate the offending process, then use the "tnstart" command.

Performance of network slow

Copying files to or from redirected drives, printing jobs over the network, or executing remote commands yields unduly slow responses, for one of the following reasons:

"Ping" does not work

This happens for one of the following reasons:

Printing problems

These happen for one of the following reasons:

Contacting Sun Technical Support

Contact your local Sun Technical Support Center. Sun Technical Support Centers are listed at: http://www.sun.com/services/contacting/solution.html. Please have the following information ready: