|
|
This chapter offers suggestions for troubleshooting problems that may arise when installing and using Cisco TCP/IP Suite. This chapter includes:
This section identifies general error messages you might see for various Cisco TCP/IP Suite applications. Each message includes an explanation and recommended actions for resolving the problem.
Error Message Address already in useExplanation Another application is running and using the same port number as the application displaying this message. This usually occurs with a server application listening on a well known port.
Recommended Action Using the Monitor application, show the Connection Table to verify that another application has the port number.
Error Message Broken pipeExplanation An operation was requested on a socket that is no longer connected or considered a socket.
Recommended Action If the remote host has a logging facility, use it to determine why the connection was disconnected. Use any available network analysis tools to determine why the connection was disconnected.
Error Message Connection refusedExplanation The remote host refused this connection request.
Recommended Action Make sure a server application that can accept the connection is running on the target host. Use available tools on the target host to display the connection table. Typical commands are netstat on UNIX hosts, and MULTINET SHOW/CONNECTIONS on VMS hosts using Cisco MultiNet for OpenVMS. Ask the network administrator if there are any access restrictions on the server application.
Error Message Connection reset by peerExplanation An operation was requested on a socket that is no longer connected or considered a socket.
Recommended Action If the remote host has a logging facility, use it to determine why the connection was disconnected. Use any available network analysis tools to determine why the connection was disconnected. Also look for duplicate WINSOCK.DLL files.
Error Message Connection timed outExplanation The application could not establish a connection with the remote host.
Recommended Action Use the Ping application to verify that you have a route to the target host and that the target host is running. However, firewalls often allow Ping to work but not other services such as Telnet or FTP. You may have to contact the network administrator for the remote host for assistance.
Error Message Could not contact DNS ServerExplanation The Ping application cannot communicate with the DNS server.
Recommended Action Verify that the IP address of the DNS server is correct, the DNS server is operational, and the network is operational.
Error Message DNS Server failureExplanation The DNS server failed to respond to the request for name service.
Recommended Action Verify that the DNS server is operational.
Error Message Host not foundExplanation Either the name entered for the target host is not a valid name or it cannot be resolved by DNS.
Recommended Action Verify that you entered the name correctly. Verify that the host name and IP address are accurate in DNS.
Error Message Network is downExplanation The Cisco TCP/IP Suite kernel is not loaded properly or cannot communicate with the network card driver.
Recommended Action Check the ODI, NDIS 2.0, or NDIS 3.0 configuration.
Error Message Network is unreachableExplanation The network portion of the destination IP address is different from the local network. There is no route to the remote network.
Recommended Action Using the Configuration Utility, verify that the default route is correct in the Routing tab. Using network analysis tools on another machine, check the route that the packet takes to the remote network and verify that packets are being forwarded to the default gateway.
If your workstation does not communicate on the network as expected, you can use the Ping application to test Cisco TCP/IP Suite and network communications. Your network administrator may be able to provide additional assistance.
Ping tests network connections by sending ICMP (Internet Control Message Protocol) echo requests to a target host and waiting for replies. When testing a connection, Ping tracks the number of packets sent, the number of replies received, the percentage of packets lost, and the amount of time required for the packets to reach the destination and for replies to be received. This information lets you verify whether your workstation can communicate with other hosts and whether information was lost.
To start Ping, choose Ping from the Cisco Suite 100 group on the Start menu, or double-click the Ping icon in the Cisco Suite 100 program group. As an alternative, you can start Net Tools and click the Ping tab.
If all of the following Ping attempts are successful, Cisco TCP/IP Suite is configured correctly and working as it should. However, firewalls often allow Ping to work but not other services such as Telnet or FTP. If you encounter problems, check your configuration to make sure that you entered all information correctly. You can do this by using the Configuration Utility. If you are not using the Cisco TCP/IP stack, use the configuration utility for your stack. If TCP/IP is configured correctly, and you are having trouble connecting to a remote host, contact the administrator for that host for assistance.
If the Cisco TCP/IP Suite installed correctly and the configuration information is correct but you are still experiencing difficulties, contact your network administrator.
See the online help for more information about how to use Ping.
This section includes the following topics. Check your installation by carrying out the Ping attempts in the order given.
To verify that your workstation can receive and send responses, and that TCP/IP is operating correctly, Ping the special loopback address 127.0.0.1.
If the Ping is not successful:
To verify that your workstation's network interface card and driver are working correctly, Ping your workstation by IP address.
If the Ping is not successful:
To verify that your workstation can communicate with other systems on the local network, Ping another local system by IP address.
If the Ping is not successful:
To verify that your workstation is successfully communicating with the router used to connect your network to other networks, Ping your network router's IP address.
If the Ping is not successful:
To verify that your workstation can communicate with hosts on other networks, Ping a host on a close, but different, network by IP address (for example, on another network connected to your router). If the Ping is successful, you might also try Pinging hosts on increasingly remote networks if you are trying to isolate a specific connectivity problem.
If the Ping is not successful:
To verify that host names are being resolved to IP addresses correctly, Ping your workstation by host name.
If the Ping is not successful:
To verify that your workstation can communicate with other systems on the local network by name, Ping another system on your local network by host name.
If the Ping is not successful:
To verify that your workstation can communicate with hosts on other networks, Ping a host on a close, but different, network by name (for example, on another network connected to your router). If the Ping is successful, you might also try Pinging hosts on increasingly remote networks if you are trying to isolate a specific connectivity problem.
If the Ping is not successful:
The following sections provide troubleshooting advice for the TCP/IP stack. The information in this section only applies to the Cisco TCP/IP stack: if you are using Microsoft's stack, consult the Microsoft documentation for help on troubleshooting the TCP/IP stack.
Use Monitor to troubleshoot TCP/IP stack problems. Monitor displays the contents of various caches maintained by the Cisco TCP/IP stack.
To start Monitor on Windows 95 systems, choose it from the Cisco Suite 100 program group on the Start menu. On Windows 3.x, double-click the Monitor icon in the program group. Monitor is not available on Windows NT.
With Monitor, you can view:
See the online help for Monitor for information about how to use these statistics, on how to print and save statistics, and on other things you can do with Monitor.
The TCP/IP stack displays an error message if it cannot perform as expected or if it encounters other errors as part of its normal operation. These messages either appear in a pop-up window or are reported through another utility, such as Ping.
If you encounter these error messages:
n.n.n.n
Explanation The TCP/IP stack has detected that the IP address specified in the error message has a new hardware address.
Recommended Action Verify that the ARP cache reflects the correct hardware address for the specified IP address, or ignore the message.
Error Message ARP: Host hardware address is broadcastExplanation The TCP/IP stack has detected that the hardware address of the host it is trying to reach is a broadcast address.
Recommended Action Verify that the hardware address for the target host is the correct hardware address.
Error Message Default Gateway ioctl failedExplanation The default route is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that the default route, host IP address, and subnet mask are correct in the Configuration utility.
Error Message Duplicate IP address detectedExplanation The TCP/IP stack has detected one IP address with two hardware addresses.
Recommended Action Identify the host with the incorrect IP address and correct it.
Error Message Error: n Please close all applications, exit Windows, and reboot your systemExplanation The TCP/IP stack has detected an error in the kernel.
Recommended Action Close any open applications, exit Windows, and reboot your workstation. Contact Technical Support.
Error Message Initialization of Cisco TCP/IP Suite Kernel failedExplanation The TCP/IP stack detected a problem with system files or with the stack configuration.
Recommended Action Using the Configuration Utility, delete the enabled interface and add it to the configuration again. Contact Technical Support if the problem persists.
Error Message Initialization of system timer failedExplanation Windows is out of resources.
Recommended Action Reboot your workstation. Contact Technical Support if the problem persists.
Error Message Initialization of VMULTINT.386 failed.Explanation The TCP/IP stack detected a problem with system files or with the stack configuration.
Recommended Action Using the Configuration Utility, delete the enabled interface and add it to the configuration again. Contact Technical Support if the problem persists.
Error Message Interface n: Broadcast address ioctl failedExplanation The broadcast address is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that the broadcast address, host IP address, and subnet mask are correct in the Configuration Utility.
Error Message Interface n: IP Address ioctl failedExplanation Your workstation's IP address is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that your workstation's IP address and subnet mask are correct in the Configuration Utility.
Error Message Interface n: Net Mask ioctl failed.Explanation The subnet mask is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that the subnet mask and the IP address are correct in the Configuration Utility.
Error Message Interface n: wrong Broadcast AddressExplanation The broadcast address is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that the broadcast address and subnet mask are correct in the Configuration Utility.
Error Message Interface n: wrong IP AddressExplanation The IP address is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that the IP address is correct in the Configuration Utility.
Error Message Interface n: wrong Net MaskExplanation The subnet mask is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that the subnet mask and IP address are correct in the Configuration Utility.
Error Message Loading TGVMOD.MOD failedExplanation TGVMOD.MOD is either missing or corrupt, or does not have sufficient DOS memory to load properly.
Recommended Action For Windows 3.x, make sure TGVMOD.MOD is in the DOS path. If you cannot locate TGVMOD.MOD, reinstall the Cisco TCP/IP stack. For both Windows 95 and Windows 3.x, make sure your system has sufficient DOS memory. Close any unused applications to free memory.
Error Message mbuf map fullExplanation The TCP/IP stack does not have enough memory to complete the requested action.
Recommended Action Make sure your system has sufficient memory. Close any unused applications to free memory. Contact Technical Support if the problem persists.
Error Message Memory allocation failed.Explanation The TCP/IP stack does not have sufficient DOS memory to operate properly.
Recommended Action Make sure that your system has sufficient DOS memory. Reboot your workstation. Contact Technical Support if the problem persists.
Error Message No available Callout structuresExplanation The TCP/IP stack does not have enough memory to complete the requested action.
Recommended Action Make sure your system has sufficient memory. Close any unused applications to free memory. Contact Technical Support if the problem persists.
Error Message No interface definedExplanation Your workstation does not have an interface defined for use on the network.
Recommended Action Use the Configuration Utility to add an interface to your workstation's configuration.
Error Message Registering a notification callback failedExplanation Windows is out of resources.
Recommended Action Reboot your workstation. Contact Technical support if the problem persists.
Error Message Route n: route ioctl failedExplanation The route is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that the route, subnet mask, and host IP address are correct in the Configuration Utility.
Error Message Route n: wrong Address QualifierExplanation The destination address of the specified route was incorrectly identified as a host or network.
Recommended Action Specify the correct address qualifier (that is, either host or network) for the specified route in the Configuration Utility.
Error Message Route n: wrong Destination AddressExplanation The destination address of the specified route is incorrect.
Recommended Action Correct the destination address for the specified route in the Configuration Utility.
Error Message Route n: wrong Gateway AddressExplanation The IP address of the gateway is incorrect for the specified route.
Recommended Action Correct the gateway IP address in the Configuration Utility.
Error Message Socket allocation failedExplanation Windows is out of resources.
Recommended Action Reboot your workstation. Contact Technical Support if the problem persists.
Error Message VMULTINT.386: driver initialization failedExplanation The TCP/IP stack detected a problem with system files or with TCP/IP configuration.
Recommended Action Using the Configuration utility, delete the enabled interface and add it to the configuration again.
Error Message Wrong default gatewayExplanation The default gateway is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that the IP address of the default gateway is correct in the Configuration Utility. Contact Technical Support if the problem persists.
Error Message Wrong host nameExplanation Your workstation's host name is either missing from MULTINET.INI or is incorrect.
Recommended Action Verify that your workstation's host name is correct in the Configuration Utility.
If the TCP/IP kernel does not start, the system files probably contain incomplete or incorrect information. The Cisco TCP/IP Suite installation program makes several changes to various system and configuration files. If the installation program does not complete properly, or if these files are later changed manually, the Cisco TCP/IP Suite-specific information in these files may be incorrect.
To correct the condition, reinstall Cisco TCP/IP Suite, or edit the system files and insert the correct information.
If Cisco TCP/IP Suite is not working properly:
The SMC NDIS3 drivers distributed with Windows for Workgroups are not truly NDIS3-compliant. If you are using Windows for Workgroups and NDIS3 network drivers, and have an SMC-brand network interface card, you may experience errors during TCP/IP kernel initialization. To correct the problem, obtain updated NDIS3 drivers from SMC.
If you cannot run WinSock-based applications, or can run them only after running a Cisco TCP/IP Suite application, Windows may not be able to locate the necessary .DLL files for operation. These are the possible causes:
Digital's Pathworks for DOS uses NDIS2 drivers for its network device driver architecture. However, Digital's NDIS2 implementation differs from the NDIS2 standard. Using Cisco TCP/IP Suite with Pathworks for DOS results in VMULTINT.386 failed to load error messages. To correct the condition, the N2GLUE.DOS device driver must be loaded in the Pathworks current template file.
To load the N2GLUE.DOS driver:
Step 1 Remove all references to Cisco TCP/IP Suite's NDIS2 drivers from the CONFIG.SYS file.
Step 2 Locate the template currently being used by Pathworks. This file can be identified by locating the line in STARTNET.BAT that refers to the PWTPL environment variable. For example, this line indicates the current template is C:\DECNET\CFG00001.TPL:
set PWTPL=c:\decnet\CFG00001.TPL
Step 3 Open the template using a text editor, and locate the [Network] section of the file.
Step 4 Insert a load statement for N2GLUE.DOS after the line that loads PROTMAN.DOS, but before the line that loads NETBIND. For example, if you are using an NE2000 network adapter and have installed Cisco TCP/IP Suite into the default directory, your template file might look like the following:
{LOADDRV} {+DEST}PROTMAN.DOS {SW_PROTMAN
{LOADDRV} {+DEST}NE2000.DOS
{LOADDRV} c:\multinet\ndis2\n2glue.dos
{+DEST}NETBIND.COM
Step 5 Save the template file.
Step 6 Reboot your workstation.
Occasionally, you might run into problems that require some ingenuity to diagnose and resolve. Although we cannot anticipate every problem you might run into, this section covers some example problems, and shows you some techniques you might find useful in diagnosing other problems.
You might find that a connection to a network resource such as a printer or workstation is failing even though it had been working fine. For example, you might suddenly find that you can no longer print on your network printer.
This might indicate that another machine on the network has taken over the IP address for the machine that is causing problems.
To check out a bad network connection:
Step 1 If you can, check the machine to ensure that it is turned on and working properly. If the machine is not working properly, fix it and retry your connection.
Step 2 Start Net Tools and use Host Lookup to check the DNS listing for the machine's host name. Make note of the IP address. If there is no entry for the machine, it may no longer be on the network. Contact your network administrator.
Step 3 Ping the machine. If the machine does not respond, then there might be something wrong with the machine. Contact the person responsible for managing the machine.
Step 4 Use Net Tools TraceRoute to determine where the failure occurs.
Step 5 If the machine does respond to Ping, TraceRoute does not help, and you are familiar with the hardware network cards and their hardware addresses (also called media access control (MAC) addresses), start Monitor and look at the ARP table.
Look at the entry for the problem machine. If the hardware address is not within the expected range given the hardware manufacturer for the machine you are expecting at that address, the IP address is probably being used by a different machine.
For example, the expected range of addresses for an HP printer is different than the range for a workstation's ethernet card. Your hardware manufacturer can tell you the hardware addresses that they use.
To restore the connection to the machine, the network administrator must find the machine that has taken over the IP address and change its configuration to use a new, unique IP address.
If you have a network sniffer, or a UNIX or Cisco MultiNet for OpenVMS system that can run a TCP dump in promiscuous mode, you can also check for ARP problems by watching for ARP replies. You should see only one response for an ARP request. If you see two or more responses, they will be from different hardware addresses. Only one system will have the correct hardware address.
Step 6 If you still cannot determine the problem, contact the network administrator, who might be able to examine a TCP dump or call Technical Support for help in isolating the problem.
Occasionally you might find that you cannot connect to a particular system. Often this is due to heavy network activity on the target machine (for example, a popular Web site). If you know the system is popular, you might simply try reconnecting later.
If your problems connecting to the system are regular, or if the system is critical to you, you can follow these steps to determine if there is another problem besides the system being too busy to respond:
Step 1 Start Net Tools and use TraceRoute to trace the route between your machine and the target, unresponsive machine. If the trace makes it to the unavailable system, the system may be too busy at this time to respond to your attempted connection, or may be configured improperly. Try your connection again, and if the problem persists, contact your network administrator or the system administrator of the remote system.
Step 2 If the trace stops before making it to the remote system, the network connection is broken at the last location. If the location is within your company, or is provided as a service for which your company is paying, call the owner of the resource. (Whois in Net Tools can help you locate a contact if you do not know who to call, or call your help desk or network administrator).
Step 3 If the trace does not stop, but at some point circles back on itself, look at the trace information to find the point at which the route is circling back. The machine routing the packets back needs to be fixed.
If you cannot connect outside your local network, you have a routing problem.
Use Monitor to look at the routing table. You should have at least these three destinations:
If you find that, when using an application like Telnet or FTP, your connections to the remote system drop more often than you deem reasonable, there might be a hardware problem on the network.
Here are some things you can do to determine if there is a hardware problem on the network:
Step 1 Start Monitor and look at the protocol statistics. These statistics are accumulated since the last time TCP/IP was started on the machine (typically during boot). Some of these statistics cover "timeout" errors (for example, "dropped due to keepalive timeouts").
In general, the ratio of timeout errors to TCP connections should be no more than 1 to 2 percent. Anything more than 10 percent indicates a problem, and ratios between 2 and 10 indicate a possible problem. (These ratios are rules-of-thumb; it is up to you to determine the ratios that indicate what is a significant problem.)
An excessive number of connections dropped due to timeouts might indicate a faulty bridge on the network.
Step 2 Ping the host that is timing out. To make the Ping useful, you must make it emulate the type of connections that are being dropped by the host.
For example, if users typically Telnet to the host, set up Ping to resemble Telnet. Start Ping and click the Ping button. For data length, use 1000. For number of packets, pick a large number that will keep the Ping going long enough to resemble a normal Telnet session, or the Telnet sessions that are getting dropped. As an alternative, enter 0 to have the Ping continue until you stop it.
If you are emulating FTP connections, use a larger data length (such as 1500 for Ethernet or 4352 for FDDI). Send enough packets so that the Ping resembles the FTP sessions that are being dropped. The reason for sending large packets is to determine if a router is handling large packets incorrectly.
Start Ping and look at the %Loss figure when Ping finishes. A high packet loss might indicate a hardware problem on the network, either in the line itself or in a bridge, router, or other machine. Use Net Tools TraceRoute to help isolate which machines are used in the connection.
If you know which part of a network is failing, you also want to know who is responsible for fixing that part. If the machine's owner has registered with a "white pages" server to which you have access, you can use Net Tools Whois to find out who to notify about the failing machine. You can use Whois to look up contact information on full machine names, domain names, and IP addresses.
White pages contain information about Internet hosts only, not hosts internal to your organization's network.
Serial connections to networks are frequently unreliable. Many factors can break a connection, from poor telephone service to unreliable modems or other hardware. The online help for Dialer contains extensive information on setting up and troubleshooting connections. The following sections cover more general points.
If you are having trouble making a serial connection using a profile:
If you receive the error message WINSOCK error 10017, Dialer cannot open the serial interface. This can indicate any of the following:
If you encounter any problems when using FTP Client or Server, the easiest way to resolve the problems is to review the contents of the FTP message logs.
The message logs list all commands sent and received during your FTP session. If you are using the Client and Server together, you can see the sequence of commands and replies in both message logs. Otherwise, you can see only your end of the transaction.
By examining these logs, you might spot the reason for the problems you encounter.
If the information in the FTP Client message log does not help you, check the following items:
If the information in the FTP Server log does not help you, check the following items:
In order to send and receive your mail, Netscape Mail must be able to connect to the appropriate servers. If you are having problems sending and receiving mail, first check your Netscape Mail Preferences (under Options>Mail and News Preferences) and ensure these settings are correct:
If you cannot open a file on the Web using Netscape Navigator:
Problems can occur when connecting to the NFS server, logging into the NFS server, and working on files on the NFS server.
If you cannot connect to an NFS server, Ping the server by IP address and by name to ensure that it is available on the network and that host names are being resolved. Contact your network administrator for help.
If you can connect to the NFS server, but not log into it:
In Windows 3.x, if you have configured each profile so that NFS automatically maps each connection when Windows starts but the mappings do not appear in the Current Connections list, make sure you check Enable Permanent Connections on Startup on the Global Options tab.
If you are trying to connect to a non-NFS drive, such as a Netware or Microsoft Networking drive, and the NFS logon dialog appears, press the Ctrl key and click the Cancel button on the dialog (you might have to repeat this). NFS tries to pass the connection request to the other network clients.
If you get the message "Windows Networking. The following error occurred while you were trying to connect to: <drive>. Device not connected.," make sure that the LASTDRIVE setting in CONFIG.SYS is set to a drive after the drive you are trying to map.
This section explains how to resolve problems that may arise when accessing, writing, or displaying files on an NFS server. Problems in this areas can usually be resolved by changing the options used for connecting to the drive. In Windows 95, the Wide Area Network, Fast Read, Server Port, and Maximum Packet Size options can only be changed if you first dismount the NFS drive.
These are some problems you might encounter in accessing NFS drives:
If the NFS server appears to run slower when accessing files, your workstation is using a low-end Ethernet adapter, or a copy request appears to stop completely, disable fast read for the connection.
In Windows 95, to disable fast read:
Step 1 Disconnect the drive by right-clicking its icon in My Computer or Windows Explorer and selecting Disconnect.
Step 2 Reconnect the drive by finding its mount point in the NFS Servers and Printers workgroup in the Entire Network entry in Network Neighborhood. Right-click the mount point and select Map Network Drive.
Step 3 When the NFS client asks you to log in, click Options and uncheck Enable Fast Read. You can further improve performance by setting the maximum packet size to 1024 and checking Wide Area Network (especially if you are using serial connections). Click OK and log into the NFS server.
In Windows 3.x, to disable fast read:
Step 1 Double-click the NFS Assistant icon in the Cisco Suite 100 program group.
Step 2 Select the problem connection in the Current Connections list on the Connections tab and click Modify.
Step 3 Uncheck Enable Fast Read. You can further improve performance by setting the maximum packet size to 1024 and checking Wide Area Network (especially if you are using serial connections).
If writing files to the NFS server seems to take a longer time than usual, it may be that the server is overloaded. If the problem is persistent, disable fast write for the connection.
In Windows 95, to disable fast write:
Step 1 Right-click the drive's icon in My Computer or Windows Explorer and select Properties.
Step 2 Choose the NFS Options tab and uncheck Enable Fast Write.
To permanently disable fast write for a drive in Windows 95, you must first disconnect the drive and uncheck Enable Fast Write when you reconnect the drive.
In Windows 3.x, to disable fast read:
Step 1 Double-click the NFS Assistant icon in the Cisco Suite 100 program group.
Step 2 Select the problem connection in the Current Connections list on the Connections tab and click Modify.
Step 3 Uncheck Enable Fast Write.
Some applications do not properly handle or display Stream-LF text files obtained from an NFS server. To make the files display correctly, disable the Convert Text Files to Stream-LF option.
In Windows 95, to prevent files from being converted to Stream-LF:
Step 1 Right-click the drive's icon in My Computer or Windows Explorer and select Properties.
Step 2 Choose the NFS Options tab and uncheck Convert Text Files to Stream-LF.
To permanently prevent conversion for a drive in Windows 95, you must first disconnect the drive and uncheck Convert Text Files to Stream-LF when you reconnect the drive.
In Windows 3.x, to prevent files from being converted to Stream-LF:
Step 1 Double-click the NFS Assistant icon in the Cisco Suite 100 program group.
Step 2 Select the problem connection in the Current Connections list on the Connections tab and click Modify.
Step 3 Uncheck Convert Text Files to Stream-LF.
If your Windows 3.x NFS print requests are not successful, check the information that appears in the Current Connections list in the Connections tab of the Print Assistant. The Windows 3.x Print Assistant displays error messages in the list next to the affected printer. In Windows 95, use the Print Manager to check printer status.
If your print requests are not successful when using an LPR/LPD queue, make sure you are using the right filter. If you specify an incorrect filter, the print server cannot interpret your print request. Your network administrator can give you the information you need.
If you receive the error message The server is not configured to accept print jobs from this PC, this means that LPD is running at the server, but the LPD server has rejected your request to submit a job. In this case, if the remote machine is running Cisco MultiNet for OpenVMS, use the MULTINET CONFIGURE/SERVER command to verify that LPD is accepting requests from your machine. Contact your network administrator for more information.
If NFS and Print Assistant reports no errors and it appears that the job was successfully printed, but no output appears at the printer:
If your Windows 3.x NFS print requests are not successful, check the information that appears in the Current Connections list in the Connections tab of the Print Assistant. The Windows 3.x Print Assistant displays error messages in the list next to the affected printer. In Windows 95, use the Print Manager to check printer status.
If you are using the Cisco MultiNet for OpenVMS print server and the NFS print application did not report any error messages, but the printed output appears improperly formatted, verify the logical name MULTINET_PCNFSD_USE_FIX_512_FILES is defined as TRUE at the print server. Contact your network administrator for more information.
If the NFS print application displays the message Connection to printer timed out: make sure the printer is online a few seconds after submitting a print job:
If the printer only partially prints the job, but Print Assistant does not report any errors, and the job is no longer in the queue, make sure that you enabled Telnet negotiation for the connection.
If the print job is shown in the "Printing" state from the Print Manager utility and no error messages are reported by Print Assistant, but nothing appears at the printer:
If you receive the message Could not connect to printer after a minute or longer delay, the remote server is not reachable from your machine. The long delay indicates that the server is not reachable. A software configuration error would cause the error message to display immediately.
If the NFS print application displays the message Could not create a spool file at the print-server: access denied, verify that your user account at the server has permission to submit jobs to the target queue.
If you cannot log into the remote host using Telnet, make sure you have a valid account on the remote host, and that you are entering the correct user name and password. If you continue to have problems logging in, contact your network administrator.
If you are successful connecting to the host, but your Telnet session produces unexpected characters in the activity window, choose Host>Reset Terminal to reset your session to the default terminal settings.
Incorrect terminal type negotiation can also cause session problems. If Telnet cannot correctly negotiate a correct terminal type, you need to send an identification string to the host. This string is defined in the Identification String field on the VT, TN3270, or TN5250 tabs in the Settings dialog. Ask your network administrator for the exact string required by the host.
These messages describe the main problems you might encounter when using Kerberos:
Error Message Password incorrectExplanation You entered the wrong password.
Recommended Action Your Kerberos password is not necessarily the same as the one you use to log into systems that prompt for a user name and password, even if you can log directly into the Kerberos server. If you still get this message after retrying your Kerberos password, ask your Kerberos administrator to reset your password for you.
Error Message Time is out of boundsExplanation Your workstation's clock is not within five minutes of the Kerberos server's clock or the clock of the host to which you are connecting.
Recommended Action Call your help desk or network administrator to find out the time on the other systems. Update the Windows settings to reflect this time: be sure to specify AM or PM correctly. On Windows 3.x systems, you might also need to use the Configuration Utility to set the correct time zone, if it is in error.
Error Message Can't send requestExplanation There was a problem contacting the Kerberos server.
Recommended Action Verify that you entered the correct name of the server in the Kerberos utility in the Configure Kerberos dialog. Ping the server to verify that it is on the network. Contact your network administrator for more help.
|
|