Remote Node (PPPRNS and ARAS) Connections

This section contains remote node (PPPRNS) and AppleTalk* Remote Access Server (ARAS) connection troubleshooting information that is divided into four categories:

• Troubleshooting Tools
• Configuration Tips
• Troubleshooting Checkpoints
• Common Problems

If a problem that is general in nature occurs, the procedure described in Troubleshooting Checkpoints will help you isolate and resolve the problem. If a problem with a specific symptom occurs, refer to Common Problems.

Troubleshooting Tools

The following troubleshooting tools can be used to troubleshoot remote node connections:

• PPPTRACE. Refer to Using the PPPTRACE Utility in the PPP documentation in the Connectivity Services section of the NetWare 5.1 online documentation.
• AIO Port Trace. Refer to Activating Remote Access Port Traces.
• PING. Refer to Determining Whether a Remote TCP/IP Node Is Reachable in the TCP/IP documentation in the Connectivity Services section of the NetWare 5.1 online documentation.
• IPXPING. Refer to Using the IPXPING Utility on the Server and Using the IPXPING Utility on the Workstation in the IPX documentation in the Connectivity Services section of the NetWare 5.1 online documentation.

Configuration Tips

We recommend the following guidelines for configuring remote access dial-in connections:

• By default, only Novell proprietary NWCAP authentication is enabled for Windows 95* and Windows NT* connections. Load NIASCFG to enable PAPRemote configuration and CHAP for PPPRNS (parameter path: Select Configure NIAS > Remote Access > Configure Services > PPPRNS > Configure Security).
• Assign remote client passwords to users who will be dialing in from Windows 95 or Windows NT dialers.
• For Windows 95 or Windows NT dial-in users who want to use PAP and CHAP authentication, they must use Remote Client passwords, not their NetWare^® passwords. PAP and CHAP passwords are case-sensitive. For more information on Remote Client passwords, refer to Setting Remote Client Passwords.
• Novell's Remote Access Dialer for Windows 3.x as well as older Novell Dialers) use NWCAP authentication. This enables remote users to use their NetWare passwords when dialing in.
• Windows 95 dialers can also use NWCAP authentication by using the latest Novell Client^TM.
• Windows NT users establishing dialback connections should verify that Enable PPP LCP Extensions is enabled in Dial-Up Networking.
• Dialback failures are often caused by configuration errors. If you cannot find any errors in the configuration, use Audit Trail and PPPTRACE.
• The Novell dialback feature requires the NWCAP authentication method.
• For the dialback feature to work with the Windows 95 dialer, the server must be configured for Allow User to Request Dialback to Any Number or Force Dialback to a Caller Specified-Number.
• Dialback fails when the server is configured to Force Dialback to a Specific Number if the caller still provides a dialback number, even if the caller puts in the same number as the number specified on the server.

Troubleshooting Checkpoints

To isolate and resolve problems with remote node (PPPRNS) connections, complete the following tasks:

• Verify that PPPRNS is configured to support all the Authentication Protocols (NWCAP, PAP, or CHAP) that dial-in clients will use.
• Verify that users who will be using PAP or CHAP have remote client passwords defined.
• Verify that the PPPRNS Internetwork Packet Exchange^TM (IPX^TM) network number is a unique IPX network number among all IPX servers on the network.
• Verify the following on Home Servers configured for users or containers.
  • They are reachable by all remote access servers that users (or users in containers) will be attempting to access. Load NIASCFG to verify (parameter path: Select Configure NIAS > Remote Access > Configure Services > PPPRNS > Set IPX Parameters > select any user > Home Server). Press Ins to display a list of servers visible to the remote access server.
  • They are running IPXRTR.NLM.

• If the remote access server is configured to use third-party security, make sure of the following:
  • The third-party security software is installed and configured properly.
  • PPP clients (dialers) are configured to open a terminal window (after the modem connection is made) in order to execute the third-party security processing.
  • Users are aware of the third-party security steps that are necessary and have the appropriate hardware or software to successfully pass the third-party security authentication.
  • The PPP dialers must use the same name that was used in the third-party security authentication to perform any subsequent PPP authentication. That is, the NetWare username that the third-party software associates with this connection is the same name that PPP authentication must use.
  • Verify in NIASCFG that the modem and cabling is configured correctly to send and receive AT commands and responses to the modem (parameter path: Select View Status for NIAS > Remote Access > Display Port Status > select a port > Terminal Mode).
  • Verify in NIASCFG that all dial-in ports are in the Waiting State (parameter path: Select View Status for NIAS > Remote Access > Display Port Status).
  • Check the port usage security restrictions to make sure that PPPRNS and the user are allowed to use the port in question.

If the users are unable to access any network resources, use the following checkpoints to help isolate the problem:

• In the CONFIG.SYS file, verify the following:Files = 75 (minimum)Buffers = 40 (minimum)
• Install the Novell Client for Windows 95 or the Novell Client for Windows NT on the workstation before you install Dial-Up Networking or Remote Access Server (RAS).
• In the NIASCFG utility on the server, verify the following:
  • Specified Home Server is running IPXRTR.NLM.
  • PPPRNS IPX network address is unique.
  • Specify IPX Address for users is set to No.

• Set the data rate to 19,200 when you use AIOCOMX.
• On the file server, perform the following:
  • Apply the current driver for the communications adapter.
  • Try connecting the modem to a COM port to bypass the communications adapter.
  • Set Reply to Get Nearest Server = ON.
  • Apply all current OS, CLIB, and Sequenced Packet Exchange^TM (SPX^TM) patches.
  • Set Maximum Packet Receive Buffers = 2000.
  • Set Minimum Packet Receive Buffers = 500.
  • Apply all current Novell Directory Services^TM (NDS^TM) patches for NetWare.
  • Decrease the DCE-to-DTE data rate to 57,600. Use the modem script editing tool, WMDMMGR.EXE, in SYS:SYSTEM\UTILS to change this value. This modem script editor is also available from the WWW location http://support.novell.com. For more information, refer to Using the WMDMMGR Utility in the Modems documentation in the Connectivity Services section of the NetWare 5.1 online documentation.

If ARAS users are able to make a connection but cannot log in to a server, complete the following steps:

1. Open the Control Panel folder and double-click the MacIPX icon.

2. Select the AppleTalk icon.

3. Select an IPX gateway.

4. Exit MacIPX and close the folder.

   If you cannot find an IPX gateway, make sure the software is loaded on your remote access server.

Common Problems

This section discusses various symptoms of common problems related to PPPRNS connections and AppleTalk Remote Access Server (ARAS) connections and the potential solutions.

PPPRNS client does not receive configured IP domain information.

Ensure that DHCPD.NLM is loaded on the server running the remote access software. DHCPD.NLM must be loaded in order to pass the domain information to the client.

Also, load NIASCFG and select Configure NIAS > Remote Access to verify that the PPPRNS IP parameters for the user's container includes domain information, such as domain name and address.

NOTE:  Windows 95 uses a proprietary protocol that does not request (or receive) Domain Name System (DNS) information provided by the DHCP services on a Novell Internet Access Server 4.1 server. This prevents Windows 95 Dial-Up Networking from receiving IP DNS information from the Novell Internet Access Server 4.1 server.

Users report a timeout error while waiting for a modem response.

This condition might be caused by heavy traffic or delays in response. Access the Port Settings dialog box for the desired PhoneBook entry. Increase the Seconds to Wait After Dialing setting. By default, this value is set to 60 seconds.

This condition might also be caused by a faulty RS-232 cable or the cable not being secured at both the serial port and modem connections.

Remote PPP users cannot establish a NetWare Core Protocol^TM (NCP^TM) connection. After entering F:, users are returned to the C: prompt. If users attempt to log in from the C:\NWCLIENT or C:\NOVELL\CLIENT32 directory, an NCP connection error message appears.

Cause 1--- Users are configured for a Home Server that is not visible from the server running the remote access software.

NOTE:  You must first unload NWCCON.

From NIASCFG, select Configure NIAS > Remote Access > Services > PPPRNS > Set IPX Parameters. Select the desired username and press Enter. Select Home Server and press Enter. In the Home Server field, either specify a home server that the current server can route to or leave the field blank. Make sure that the Home Server is running IPXRTR.NLM.

Cause 2--- The Maximum Packet Receive Buffers value is too low.

Make sure the remote access server has been configured with a sufficient value for Packet Receive Buffers. Typical values are 500 minimum and 1000 to 2000 maximum depending on LAN/WAN traffic.

During an attempt to establish a PPPRNS connection, an error occurs indicating DCD carrier detect is off.

This condition could be due to a modem script problem or defective modem. If your modem uses the standard Hayes command set, use one of the Hayes Compatible modem scripts or try a different modem. You can also try a null-modem connection.

This condition could also be due to the server expecting third-party security on the PPP client but the client is not properly configured to go through the authentication process before sending PPP frames. Configure the client to open a terminal window after modem connection is established to execute the authentication process.

PPPRNS Windows 95 client reports that authentication failed.

Ensure that the client is specifying the complete NDS username and the correct remote client password. PAP and CHAP remote client passwords are case-sensitive. Ensure that CHAP is enabled in PPP security on the client. Ensure that PAP and CHAP security options are enabled on the server.

When the Windows dialer is executed, the following message is displayed: Dialer tried to open a communication port, but none was available.

Ensure that the port is enabled and not in use by another application. Also, ensure that the correct port is specified in the configuration.

Calling card bong tone not supported by modem.

If your modem is not waiting for the correct bong tone from the ISP before sending calling card details, refer to the modem documentation to determine the character that the modem supports. Usually, the ampersand (&) is used by the modem to instruct it to wait for the bong. If your modem does not support the use of the ampersand, edit the dialing string to use a different character, such as dollar sign ($). If your modem does not support a different character, use commas to specify a time interval. Start with two commas.

Dialback fails.

Dialback failures are most often caused by configuration errors. If you cannot find any errors in the configuration, use Audit Trail and PPPTRACE.

The following are additional configuration guidelines:

• Windows NT users should verify that the Enable PPP LCP Extensions is enabled in Dial-Up Networking.
• When the Novell dialer is used, the dailback feature is effective only if the NWCAP authentication method is used.
• When the Windows 95 dialer is used, the dialback feature will work if the server is configured for Allow User to Request Dialback to Any Number or Force Dialback to a Caller-Specific Number. In the latter case, the caller must provide a dialback number.
• When the server is configured for Force Dialback to a Caller-Specific Number, dialback fails if the caller provides a dialback number, even if the number is identical to the one entered on the client.

ARA 1.0 clients can log in, but PPP clients cannot.

When both the ARAS and PPPRNS services are in use, a workstation dialing in using a modem with V.42bis compression will try to connect using ARAS (as seen at the server console). The reason is that ARA 1.0 packets have the same headers as V.42bis packets. ARA 2.0 packets do not present this problem.

Use the following checkpoints to resolve the problem:

• Change Support Apple Remote Access Client Version to 2.0 only. Only ARA 2.0 clients can connect, but this allows PPP clients to use the same ports as ARA clients.
• Assign separate ports for ARAS and PPPRNS.
• Disable V.42bis on the modems.

ARA clients are unable to establish a connection to Novell Internet Access Server 4.1 remote access, but PPP clients can.

Most ARA dial-in problems are related to modem scripts. Use the latest ARA-specific modem script for your modem from the modem manufacturer. The Novell Labs^TM group does not create modem scripts for ARA.