MS RAS and X.25 - Evaluation, Implementation, and Troubleshooting for All RAS Versions

Last updated: March 1997

Contributed by Gert C. Gustedt, Technical Content Developer and former Support Engineer specializing in RAS
Microsoft® Enterprise Systems Support

AT A GLANCE

Introduction

In many organizations, computers run different versions of Remote Access Service (RAS). This makes the job harder for the planner and support engineer because it requires knowing all about all the versions, and this material is scattered through the manuals, the help and Readme files, the Microsoft (MS) Knowledge Base, the Pad.inf and Switch.inf files, and the Script.doc file (Windows 95 and Windows NT 4.0). This article is designed to be a Remote Access Service X.25 reference that addresses common network questions related to all versions of RAS current at the time of writing (March 1997). To help its target audience (CIO, MIS, or help desk employees) it incorporates the most useful information and provides other helpful material that cannot be found even in the usual sources. Even though this paper focuses on X.25 issues, many sections relating to writing and troubleshooting Pad.inf scripts also apply to Switch.inf scripts in RAS 1.x, Windows for Workgroups 3.11 and Windows NT 3.x because the script language is the same. (For more information on writing Switch.inf scripts see the MS Knowledge Base or the RAS online help.)

For convenience and to assist with planning, a copy of the Windows NT 4.0, Networking Supplement, Chapter 9, titled X.25 PAD Support is included.

Appendix E lists manuals (including on-line sources, when possible) for the different RAS versions. Microsoft recommends that you refer to the manuals that pertain to your RAS versions in addition to this article.

Not covered in-depth is the new script language for Windows 95 and Windows NT 4.0. Windows 95 has not been tested with X.25 dial-up, though it may work, and Windows NT 3.x and 4.0 do not support the use of the new script language inside the Pad.inf file. (However, Windows NT 4.0 supports the new script language in regular RAS script files for PPP and Slip dial-up which is not the topic of this article.) The new script language is more intuitive, very similar to BASIC and C, and is well described in Script.doc, which you can find in Appendix F. Three example script files are included with Windows NT 4.0: Pppmenu.scp, Slip.scp, Slipmenu.scp. These three files and Script.doc are in the Windows NT 4.0 %SystemRoot%\System32\RAS directory.

Troubleshooting RAS 1.0 and 1.1 for Microsoft OS/2 version 1.3 is mainly covered in Appendix G because most OS/2 implementations have been upgraded to Windows NT. For more information on RAS for Microsoft OS/2 (v. 1.3) versions 1.0 and 1.1 see the Microsoft Knowledge Base.

List of Microsoft Remote Access Versions

Microsoft Remote Access for MS-DOS, versions 1.0, 1.1, and 1.1a

Microsoft Remote Access for OS/2 (v. 1.3), versions 1.0 and 1.1

Microsoft Windows for Workgroups version 3.11 (RAS is built-in)

Microsoft Windows 95 (RAS is built-in under the name “Dial-Up Networking”)

Microsoft Windows NT operating system version 3.1 (RAS is built-in)

Microsoft Windows NT Advanced Server version 3.1 (RAS is built-in)

Microsoft Windows NT Workstation versions 3.5, 3.51, and 4.0 (RAS is built-in; Windows NT 4.0: “Dial-Up Networking”)

Microsoft Windows NT Server versions 3.5, 3.51, and 4.0 (RAS is built-in; Windows NT 4.0: “Dial-Up Networking”)

General X.25 Information

The following section contains general information about X.25 networks.

Overview of X.25 Networks

An X.25 network transmits data between two computers with a packet-switching protocol. This protocol relies on an elaborate worldwide network of packet-forwarding nodes (DCEs) that can deliver an X.25 packet to its designated address.

X.25 also requires additional hardware such as an X.25 Smart Card or a PAD. For additional information on hardware requirements, see “What Third-Party Products Are Required to Set Up a RAS Connection over X.25” below and the Windows NT Server 3.5 and 3.51 Remote Access Service manual, Chapter 6, or the Windows NT Server 4.0 Networking Supplement manual, Chapter 9.

How RAS Supports X.25 Networks

Connecting to a server through an X.25 network is similar to connecting through a phone line. The only difference is that the phone book entry must specify an X.25 PAD type and an X.121 address for the RAS server.

RAS does not know what medium it is running over. It does not know about the X.25 protocol, just as it does not know about how phone lines and modem

equipment work on the lower levels. The RAS server uses the Eicon Technology WAN Services Eicon drivers and an internal Eicon X.25 adapter to convert the X.25 protocol to the serial (RS232) protocol signals (and vice versa), or it can send and receive serial signals to and from an external X.25 PAD (packet assembler/disassembler), in which case, no Eicon software and hardware is necessary because the X.25 PAD does the protocol conversion.

Some RAS client versions can also be configured with the Eicon driver and adapter or the external PAD, but usually the clients use a modem to call the X.25 network provider dial-up PAD, which is also a modem. After the RAS client modem and the X.25 provider dial-up PAD connect, the X.25 provider usually requires callers to identify themselves for billing purposes. To support caller identification, most RAS clients can run a customized command script, and some can also go into an interactive post-connect Terminal mode, to allow the client to send the user name and password.

Note

The external PAD configuration mentioned above is not supported in Windows for Workgroups 3.11, Windows 95, and Windows NT Workstation and Server versions 3.5, 3.51, and 4.0, because they have not been tested. However, there are no known reasons why this external configuration should not work.

Note

You need to purchase an Eicon X.25 adapter card and the specific Eicon WAN Services for your operating system. Since Windows NT version 4.0 the “Eicon WAN Adapters” card driver ships with Windows NT.

Reasons to Use RAS with an X.25 Network

In addition to transmitting data more reliably than regular phone lines, X.25 connections supply bandwidths of up to 56 kilobytes (K) (64K in Europe).

How Many X.25 Connections Are Supported by RAS Servers

A Windows NT 3.1, 3.5, 3.51, or 4.0 RAS server with Eicon Technologies software and Smart Card installed can host up to 256 RAS client connections over one X.25 line simultaneously. This compares favorably to the expense and space needs of having to purchase and maintain 256 modems and phone lines for the RAS server for regular telephone line connections not using X.25.

RAS 1.1 for OS/2 (OS/2 version 1.3), version 2.1 or later only supports 13 simultaneous RAS client connections over one X.25 line.

X.25 Versus ISDN

Note

In areas where ISDN is available, Microsoft recommends considering the use of ISDN rather than X.25. ISDN is much faster (128kb or more depending on the type of adapter and provider network) without compromising reliability, however, it is likely to be more expensive.

For additional information on ISDN and RAS, see the Windows NT 3.5 Server “Remote Access Service” manual, page 8, or the Windows NT 3.5 RAS online Help.

Planning an X.25 RAS Client to Server Dial-Up or Direct Connection

X.25 Related Limitations of Certain RAS Versions

RAS 1.0

Microsoft RAS version 1.0 does not have the capability to invoke RAS

Terminal or use scripts in .INF files. It does not support X.25. Upgrades to RAS 1.1 and RAS 1.1a are free.

RAS 1.1 and 1.1a

RAS 1.1 is the first RAS version to support X.25 with a Pad.inf file, however, the syntax in Pad.inf scripts is different from the syntax used in later RAS versions. For more information, see your RAS version 1.1x Pad.inf file, RAS manual, and release notes.

RAS 1.1x also does not support a RAS Terminal screen (nor the capability to run scripts from a Switch.inf file for use with intermediary security devices). The latter two features were introduced with RAS for Windows For Workgroups 3.11.

Windows 95

Windows 95 was not tested with X.25 RAS Dial-Up Networking and therefore is not supported as a RAS X.25 client, however, it may work. If you want to try RAS X.25 on Windows 95 keep in mind that it does not support the script language used in the Pad.inf and Switch.inf files and that the Pad.inf and Switch.inf files do not exist and cannot be invoked in Windows 95.

To get support for scripting in non-X.25 environments (for example for Slip or PPP Internet access) in Windows 95, obtain Windows 95 Service Pack 1 (SP1). In the Admin directory of SP1 you can find the scripting tool Script.exe. The Admin directory also contains the Script.doc file that describes the commands and syntax of that new and improved script language which is, however, incompatible with the Pad.inf and Switch.inf script language.

Windows 95 supports an after-dialing Terminal window for connections to non-X.25 providers. We have received unconfirmed reports from customers attempting to use Windows 95 with X.25 dial-up that there are problems of receiving incomplete text from the provider PAD in the Terminal window.

Note

Windows NT 4.0 supports the script language used in Pad.inf and Switch.inf as well as the new Windows 95 script language. RAS for Windows for Workgroups 3.11 and Windows NT 3.1, 3.5, 3.51, and 4.0 support RAS Terminal screens for X.25 dial-up. Eicon Technologies supports Windows 95 as a non-RAS X.25 client with the OSI PCGATEWAY software which does not allow connections to a Windows NT RAS server.

Which RAS Clients Support X.25 Dial-Up

RAS 1.1x for LAN Manager 2.1 or later (MS-DOS-based or Windows-based)

RAS 1.1 for LAN Manager for OS/2 (v. 1.3), version 2.1 and later

RAS for Windows for Workgroups 3.11

RAS for Windows NT Workstation and Server 3.1, 3.5, 3.51, and 4.0

Note

The Dial-up Networking client (DUN) for Windows 95 has not been tested as an X.25 dial-up client and is therefore not supported in that function, but may work.

Which RAS Clients Support X.25 Smart Cards (Client and Server function)

The following RAS versions can assume the RAS client or RAS server roll:

RAS 1.1 for LAN Manager for OS/2 (OS/2 v. 1.3), version 2.1 and later

RAS for Windows NT Workstation and Server 3.1, 3.5, 3.51, and 4.0

To make Windows NT work with an X.25 SmartCard, install the driver and the X.25 SmartCard from Eicon Technologies in your computer. Windows NT 4.0 ships with the Eicon X.25 driver. The driver is called “Eicon WAN Adapters.” You do not need to purchase additional software if you have purchased an adapter that is supported by this driver. See “What Third-Party Products Are Required to Set Up a RAS Connection over X.25” below.

Which RAS Versions Can Become RAS Servers Using an X.25 Smart Card

The RAS versions that can become RAS servers are identical to the ones listed above under “ RAS Clients Accessing X.25 Through an X.25 Smart Card.”

RAS and External X.25 PADs - Supported Only in Windows NT 3.1

RAS for Windows NT 3.1 was the only RAS version tested with an external X.25 PAD (see RAS manual page 34, 37 Figure 6.3). Other versions of RAS may work with an external X.25 PAD, but are not supported in that configuration.

For Which X.25 Providers Exist RAS Dial-Up Scripts in the Pad.inf File

These scripts allow an automatic connection of your RAS client with the RAS server over X.25 dial-up:

RAS 1.1, Windows for Workgroups 3.11, and Windows NT 3.1 include the following scripts:

Sprintnet (9600 bps and 2400 bps)

InfoNet (9600 bps and 2400 bps)

The following scripts are included with Windows NT 3.5, 3.51, and 4.0, but should work with Windows NT 3.1, too.

Sprintnet (9600 bps and 2400 bps)

InfoNet (9600 bps and 2400 bps)

Compuserve

SITA Group Network

Alascom/Tymnet/MCI

Telematics

Note

These scripts are not required to connect. You can also connect manually by using a RAS Terminal window and typing the required parameters, user name and password. For X.25 providers that are not listed here, you can write your own script or connect manually. To write your own script, see the section titled “Writing a Pad.inf script to automate Remote RAS Logons.”

In case there were updates to Pad.inf after this document is published, check the Pad.inf file that is installed with RAS automatically to find out for which X.25 carriers your current RAS version includes scripts. The section title (enclosed in square brackets [ ]) for each script usually indicates the name of the X.25 carrier for which the script was designed, except the section titled Eicon X.PAD which is the X.25 Eicon card script for Windows NT servers and clients that have an Eicon card installed.

For Which X.25 Cards Exist RAS Scripts in the Pad.inf File

Only X.25 cards by Eicon Technologies are supported for RAS over X.25. See the following paragraph for more information on Eicon products. There maybe X.25 cards and drivers available by other companies, however, they have not been tested by Microsoft. Please contact that vendor for support.

What Third-Party Products Are Required to Set Up a RAS Connection over X.25

Microsoft only supports Eicon Technologies hardware and software with RAS over X.25. You only need Eicon products for your RAS X.25 server and RAS X.25 direct-connection clients. RAS Dial-Up clients do not need any additional software or adapters.

Software

To get X.25 support on your Windows NT 3.1, 3.5, or 3.51 server you need to purchase the corresponding version WAN Services for Windows NT from Eicon Technologies. However, in Windows NT 4.0 you do not need to purchase Wan Services For Windows NT (it does not exist). Windows NT 4.0 already ships with the Eicon driver for Eicon X.25 adapters. You can install the adapter driver by running Control Panel and choosing Network. The adapter driver name is Eicon WAN Adapter.

Driver Versions and Adapter Support

For Windows NT 3.51 obtain Eicon Wan Services version 3, release 4a (V3R4A). This version works only on Windows NT 3.51, not on Windows NT 4.0. It supports the following Eicon X.25 adapters:

PC, HSI, DPNA, MPNA, C21, and S51

There is a newer version of Wan Services for Windows NT 3.51 known as version 3, release 4c (V3R4C). This version works only on Windows NT 3.51 but has additional adapter support as follows:

S52, S50, C20

The Windows NT 4.0 Eicon Wan Adapter driver supports the following adapters:

C21, S51, PC, HSI, DPNA, and MPNA.

For a complete up-to-date list contact Eicon Technologies.

Note

At the time of this writing (December 1996) Eicon Technologies stated it was close to releasing a new X.25 Windows NT Server product called Connection For Windows NT 4.0. This software has support for new and faster X.25 adapters and is said to support software compression and other new features. To find out more about this new product contact Eicon Technologies. Contact information is provided below.

Per Eicon Technologies, Connection For Windows NT 4.0 supports the following adapters:

All cards the Eicon Wan Adapter in Windows NT 4.0 supports.

New: C20, S50, S52, and S94.

Note

The S-series of adapters, that is the adapters with an “S” in the model name, are generally faster (S stands for Server) than those with a “C” in the model name (“C” stands for Client) which are designed to be for X.25 clients which do not require as much speed.

You can contact Eicon Technologies at:

USA: (214) 239-3270

Canada: (514) 745-5500

Internet: http://www.eicon.com

E-mail: sales@eicon.com

On CompuServe, type: go eicon

Implementing an X.25 RAS Client-to-Server Dial-Up or Direct Connection

Creating Reliable Links When Connecting Through Dial-up PADs

The following is recommended on all workstations that are going to access a dial-up PAD to connect through X.25 to a RAS server using an Eicon card.

Establish all modem connections using a reliable link (either V.42, LAPM, or MNP4) and enable hardware handshaking between your local modem and the workstation. Enable these settings by editing the Remote Access entry's modem settings. Select the check box for modem error correction and the check box for hardware flow control.

Using this feature ensures that there is end-to-end flow control and no data will be lost between the dial-up PAD and the client workstation. You may encounter problems unless these modem settings are made.

Configuring RAS Clients to Use RAS Terminal After Dialing

If RAS does not have an X.25 logon script for your particular X.25 provider (see above “For Which X.25 Providers Exist RAS Dial-Up Scripts in the Pad.inf File”), you need to write a script or configure RAS to pop up the interactive RAS Terminal screen after dialing to display logon prompts from X.25 providers and allow you to type your logon credentials and other parameters. For more information on writing your own X.25 script see “Creating Scripts for the RAS Pad.inf File” below.

RAS 1.x Clients do not have support for a RAS Terminal screen.

To configure a Windows NT RAS 3.1, 3.5, or 3.51 entry to use RAS Terminal after dialing:

1.In Remote Access, select an entry.

2.Click Edit.

3.If the Security button is not available, click the Advanced button.

4.Click Security. (In Windows NT 3.1 and Windows for Workgroups 3.11 this button is labeled Switch).

5.In the After Dialing field, select Terminal. (In Windows NT 3.1 and Windows for Workgroups 3.11 this is labeled Post-Connect).

6.Click the OK button until you return to the main Remote Access screen.

To configure a Windows NT RAS 4.0 entry to use Terminal after dialing:

1.On the Windows NT 4.0 desktop, double-click My Computer and then Dial-Up Networking.

2.In Dial-Up Networking, select a Phonebook entry and then click More and click Edit entry and modem properties.

3.In the Script tab under After Dialing (Login), click on Pop Up A Terminal Window.

To configure a Windows 95 Dial-Up entry to use Terminal after dialing:

1.On your Desktop double-click My Computer.

2.Double-click Dial-Up Networking

3.Double-click Make New Connection and click Configure.

4.Click the Options tab and click the Bring Up Terminal Window After Dialing check box.

Configuring a Windows NT 3.x or Windows for Workgroups 3.11 RAS Dial-Up Client to Run a Pad.inf X.25 Script

You can configure a RAS entry to run a Pad.inf script after dialing. For example, to automate the task of logging onto a remote host, create the script in the Pad.inf file and then configure the RAS entry to use the created script after dialing. The following steps allow you to connect to an X.25 provider through Windows for Workgroups RAS dial-up. These instructions assume that a dial-up script exists for your X.25 provider:

1.In Remote Access, do one of the following:

If you need to add a new RAS Phonebook entry, click Add from the toolbar.

– Or –

If you want to edit an existing RAS Phonebook entry, click Edit from the toolbar.

2.In the Phone Book Entry dialog box, if the Advanced button is displayed, select Advanced, otherwise go to step 3.

1. In the Port field, select the COM port your modem is connected to.

Note

Do not select the “Any X.25 port” option in the Port drop down list unless you are connecting through an Eicon X.25 card instead of a modem.

4.At the bottom of the Advanced Phone Book Entry dialog box, select X.25.

5.Fill in the fields in the X.25 dialog box:

PAD Type: Enter the name of the X.25 provider (for example, SprintNet, InfoNet, or another provider that you added to Pad.inf file manually with a text editor).

X.121 Address: Provide the RAS server X.121 address

User Data: Enter any additional connection information required by the X.25 host computer. In Windows for Workgroups RAS Setup or X.25, the User Data field is usually left blank unless additional connection information is required such as a user name to identify the caller to the X.25 provider for billing purposes.

Facilities: Facility parameters for the X.25 provider. For example, some X.25 providers support the /R parameter to specify reverse charging. Consult the X.25 documentation or provider for more information. Some providers require the user to provide a password which you can enter here if the script you are using specifies the reserved word “<facilities>“ to send the password to the remote X.25 device.

Note

When using a Pad.inf script the “PAD Type” and “X.121 Address” are mandatory settings. The “User Data” and “Facilities” fields are only used with certain scripts where additional information is required by the X.25 provider.

For more information, see the RAS Online Help under “Setting X.25 Parameters.”

Activating an X.25 Script in Switch.inf instead of Pad.inf in Windows for Workgroups 3.11 RAS

In Windows for Workgroups 3.11 RAS, if you have a problem of Pad.inf script files not executing completely, you can try running your X.25 script from Switch.inf after replacing all references to the special Pad.inf macros X25address, Userdata, and Facilities (if applicable) with the actual values because Switch.inf does not support these macros.

You can configure a RAS entry to run a Switch.inf script before dialing, after dialing, or both. For example, to automate the task of logging onto a dial-up PAD, create the script in the Switch.inf file and then configure the RAS entry to use the created script after dialing.

To activate a Switch.inf script in Windows for Workgroups version 3.11

1.Run Remote Access and select an entry.

2.Click the Edit button.

3.If the Security button is not available, click the Advanced button.

4.Click the Security button. (In Windows NT 3.1 and Windows for Workgroups 3.11 the button is labeled Switch).

5.In the After Dialing box, select the name of the script. The section header in the Switch.inf file is what appears as the name of the script. (In Windows NT 3.1 and Windows for Workgroups 3.11 this box is labeled Post-Connect).

6.Click the OK button until you return to the main Remote Access Screen. When you dial this entry, the selected script runs after RAS dials and connects to the remote host.

Configuring a Windows NT 3.x RAS X.25 Direct-Connection Client to Run a Pad.inf Script

On a direct connect (via an Eicon card) X.25 RAS client you can configure a RAS entry to run a Pad.inf script to call the X.25 RAS server. In most cases you should select the script titled Eicon X.PAD which is for Eicon cards on SprintNet network. If you have an Eicon card, but a different X.25 provider select the Eicon X.PAD script to try it out. If it does not work, see the section titled “Writing a script for Direct X.25 Connections” below.

The following steps allow you to connect to an X.25 provider through a Windows NT direct X.25 connection. These instructions assume that a script exists for your X.25 provider:

1.In Remote Access, do one of the following:

If you need to add a new RAS Phonebook entry, click Add from the toolbar.

– Or –

If you want to edit an existing RAS Phonebook entry, click Edit on the toolbar.

2.In the Phone Book Entry dialog box, if the Advanced button is displayed, select Advanced, otherwise go to step 3.

3.In the Port field, select an X.25 port which usually appears as a COM port with a high number such as COM3 or COM10 or select “Any X.25 port.”

4.At the bottom of the Advanced Phone Book Entry dialog box, select X.25.

5.Fill in the fields in the X.25 dialog box:

PAD Type: Enter the name of the X.25 provider (for example, SprintNet, InfoNet, or another provider that you added to Pad.inf file manually with a text editor).

X.121 Address: Provide the RAS server X.121 address

User Data: Enter any additional connection information required by the X.25 host computer. In Windows for Workgroups RAS Setup for X.25, the User Data field is usually left blank unless additional connection information is required such as a username to identify the caller to the X.25 provider for billing purposes.

Facilities: Facility parameters for the X.25 provider. For example, some X.25 providers support the /R parameter to specify reverse charging. Consult the X.25 documentation or provider for more information. Some providers require the user to provide a password which you can enter here if the script you are using specifies the reserved word “<facilities>“ to send the password to the remote X.25 device.

Note

When using a Pad.inf script the “PAD Type” and “X.121 Address” are mandatory settings. The “User Data” and “Facilities” fields are only used with certain scripts where additional information is required by the X.25 provider.

For more information, see the RAS Online Help under “Setting X.25 Parameters.”

Configuring a Windows NT 4.0 X.25 Client to Run a Pad.inf X.25 Script

These instructions apply to RAS Direct-Connection or Dial-Up X.25 clients:

1.In Dial-Up Networking, select a phonebook entry and then click More and click Edit entry and modem properties.

2.On the Basic tab under Dial Using, select the X.25 card if you have a direct X.25 connection, or, select the COM port your modem is on, if you are using a dial-up X.25 connection. If you need to configure the entry, click on Configure.

3.The X.25 tab, select your X.25 provider dial-up provider (or Eicon X.PAD for direct connections) and type the X.25 address of the remote server.

In most cases of direct-connect RAS X.25 client configurations you should select the script titled Eicon X.PAD which is for Eicon cards on SprintNet network. If you have an Eicon card, but a different X.25 provider select the Eicon X.PAD script to try it out. If it does not work, see the section titled “Writing a script for Direct X.25 Connections” below.

4.Type additional information in the User Data and Facilities boxes if the Userdata and Facilities variables are used in the script you selected.

Configuring a RAS Server for an X.25 Network

To install RAS, run Control Panel and click Network. In Windows NT 3.x click Add Software. In Windows NT 4.0 click the Services tab and click Add. Then add the Remote Access service.

To configure your RAS server for an X.25 RAS network, follow the installation instruction for the X.25 adapter and software. As a rule of thumb use the defaults, for example, leave the X.25 COM port (e.g.: COM10) at the default unless you are absolutely sure another COM port number has to be used.

Also for X.25 Buffering: On each communication port in the Eicon PAD configuration, it is recommended that the packet length supported be left at the default of 128. This will give optimum performance on the server.

Otherwise, connection problems may occur.

Windows NT 4.0 RAS Server

To configure RAS on Windows NT 4.0 for the X.25 adapter:

1.Install the Eicon adapter in your computer according to your computer manufacturer and Eicon adapter installation instructions.

Install the Eicon driver by running Control Panel, clicking Network, then Adapters, and then Add and adding the Eicon Wan Adaters driver.

Configure the driver according to your Eicon WAN Services for Windows NT System Guide or in online Help “Help For WAN Services Configuration” on how to configure the total number of virtual circuits.

The sum of the two-way virtual circuits (TVC) and incoming virtual circuits (IVC) in the X.25 configuration screen must equal the number of incoming X.25 clients the server will support at one time. You may have to find out how many TVCs and IVCs your X.25 line has by contacting your X.25 vendor.

2.Define the number of communication ports to be available for RAS in the XPAD configuration program.

Click the Network option in Control Panel.

Click the Services tab.

If didn't chose to install the Eicon X.PAD services during the Eicon card installation in step1, click the Add button and install the “Eicon X.PAD Driver” and follow the instructions for rebooting.

Restart Windows NT and Control Panel Network and click the Services tab.

Click the Eicon X.PAD Driver in the Network Services list box and click Properties.

Configure the total number of COM ports by selecting the COM ports from the Available Ports list and then clicking Add.

It is recommended that the number of communication ports should be equal to the number of virtual circuits (TVC+IVC) configured.

Click Configure Ports and make sure that the Local Profile and Remote Profile name is RAS. Make changes to the fields in this screen only if you know they are necessary. The default values work with most X.25 networks and RAS.

3.Configure the number of communication ports (Eicon XPAD's) in RAS using the Network option in Control Panel.

Run Control Panel and click Network again.

Click the Services tab, then click Remote Access Service.

Click Properties, click Add, and then click Install X.25 Pad.

Add an X.25 port to RAS by specifying a port name. Take the default or first available port first to avoid connection problems due to unexpected configurations.

Specify an X.25 PAD and click OK.

If you do not see the PAD name you want in the Click X.25 PAD Name box, you can edit the PAD names in Pad.inf. For more information, see the section on X.25 PAD Support in the Windows NT Server Networking Supplement, below in appendix A.

Make sure the selected ports are configured for dial-in.

Windows NT 3.x RAS Server

When configuring a RAS Server to use X.25 over an EiconCard, several steps must be followed to define the number of clients that can connect to the server.

1.Define the total number of virtual circuits that the EiconCard will be configured for.

Click the Network option in Control Panel.

In the Network Settings dialog box, select the EiconCard driver in the Installed Adapter Cards box.

Click the Configure button.

Follow the instructions in your Eicon WAN Services for Windows NT System Guide on how to configure the total number of virtual circuits.

The sum of the two-way virtual circuits (TVC) and incoming virtual circuits (IVC) in the X.25 configuration screen must equal the number of incoming X.25 clients the server will support at one time. You may have to find out how many TVCs and IVCs your X.25 line has by contacting your X.25 vendor.

2.Define the number of communication ports to be available for RAS in the XPAD configuration program.

Click the Network option in Control Panel.

In the Network Settings dialog box, select the Eicon X.PAD Driver in the Installed Network Software box.

Click the Configure button.

Configure the total number of COM ports by selecting the COM ports from the Available Ports list and then choosing the Add button.

It is recommended that the number of communication ports should be equal to the number of virtual circuits (TVC+IVC) configured.

3.Configure the number of communication ports (Eicon XPAD's) in RAS using the Network option in Control Panel. Make sure the selected ports are configured for dial-in.

Configuring the X.25 RAS Server Eicon card to Configure the Client Dial-Up PAD

The client dial-up PAD, through which a remote computer connects to the X.25 network, might have previously been set to X.3-parameter values that are incompatible with the Remote Access Service. Therefore, it is important to configure the X.25 smart card on the Remote Access server so that it changes the client PAD’s X.3 settings to the values described in “X.3 RAS Specifications and Potential Problems” Table 9.3 as soon as a connection is established through X.29 commands. To configure an X.25 smart card to make these changes, see the configuration manual for your specific card.

Note

If the X.25 smart card on the server end does not support commands for the X.29 language, the client PAD script must set the X.3 parameters locally. If you have problems, contact the support site for your X.25 smart card vendor.

Server Bandwidth and the Total Number of Clients

To obtain maximum performance in the RAS clients and to ensure reliable connections, ensure that the aggregate throughput of all clients does not exceed the bandwidth of the RAS server.

For example, four clients running at 2400 bits per second (bps) can be connected to a server with a 9600 bps X.25 line. However, attaching a fifth client at 2400 bps will exceed the server's bandwidth. This will cause all clients to operate at speeds below 2400 bps. If a virtual circuit, communication port, and RAS port are defined for five ports, then five clients can connect using X.25. However, connecting five clients at one time is not recommended since the throughput of each client will be very low and will cause time-outs in the network protocols running over RAS.

Configuring Null Modem Connections on X.25 Networks

When using a null-modem connection on X.25 networks, the server X.25 port must be set to DCE and the client should be set to DTE. If the port on both computers is set to DTE, you cannot connect.

The X.25 null modem should be configured for DCE and internal clocking before an X.25 null-modem client can connect. To configure the X.25 null modem, in Control Panel click Network. In the Network Settings dialog box, click the X.25 card driver in the list of adapters, then click Configure. Select the null modem port, click X.25 and change the node type to DCE. Select X.25 and set the clocking to Internal. Save the configuration and restart the system.

The X.28 Packet Assembler/Disassembler (PAD) and X.3 and X.29 Standards

On an X.25 network, a X.28 Packet Assembler/Disassembler (PAD) converts serial signals from the RAS client modem to and from X.25 packet-switched signals for communication with the X.25 host, for example, a RAS server with Eicon WAN services installed. A PAD is similar to a modem in that it has a command mode and a data transfer mode. In command mode the user can issue X.3 commands to the PAD. In data transfer mode the PAD forwards data between the client and the server which can be any equipment that complies with the X.25 standards like Unix TTY hardware and a Unix host or a RAS client and a RAS server with Eicon WAN Services installed. The host must comply with the X.29 standard , which allows the host to configure the dial-up PAD's X.3 parameters remotely. Therefore, the PAD X.3 parameters can be set by the client or by the server. The client or the server can invoke predefined purpose-specific Profiles that configure all X.3 parameters at once. When writing a new RAS Pad.inf script, it can sometimes save code to invoke a Profile first and then set only a couple parameters with the Set command rather than having to use the Set command to set all X.3 parameters individually.

These X.3 parameters configure the dial-up PAD so that it produces a data stream of required characteristics similar to serial communication where Parity, Data Bits, and Stop Bits are configured. For RAS to work over X.25 the X.3 parameters must be set according to the RAS specifications mentioned below under “X.3 RAS Specifications and Potential Problems.” The X.3 parameters can be set by the RAS client or the WAN services on the X.25 RAS server (the host) depending on the X.25 provider network functionality. The X.29 standard allows the host to modify the dial-up PAD X.3 parameters over the X.25 network, however, in most RAS Pad.inf scripts, the RAS client sets the X.3 parameters. The RAS client can set the X.3 parameters either in a Terminal window or usually inside a script (see Pad.inf).

Some X.25 network providers use additional proprietary parameters that are extensions to the standard X.3 set of 22 parameters. For more information on X.3 extionsions, see “X.3 RAS Specifications and Potential Problems” below.

Therefore, for RAS X.25 set up and troubleshooting it is important to verify that all X.3 parameters are set correctly. If problems occur they can be caused by setting the X.3 parameters correctly, but failing to configure the X.29 parameters which can override the X.3 parameters or vice versa.

Important X.28 Commands

The RAS client can issue the following commands to the PAD when the PAD is in command mode:

Set <X.3 parameter A>:<value> [,<X.3 parameter B>:<value>,<X.3 parameter C>:<value>,…]

Sets the PAD X.3 configuration to define the form of the data stream. Multiple parameter/value pairs can be listed on the same line if each pair is separated by a comma.

Par?

Displays the current settings of all X.3 parameters. This is an important command for verifying X.3 parameter settings during RAS X.25 setup and troubleshooting.

PROF (identifier)

Invokes a predefined set of values for all or a number of X.3 parameters to prepare the data stream for different types of connections eliminating the need to set X.3 parameters individually.

PRF?

Displays the current profile settings. This is an important command for verifying X.3 parameters during setup troubleshooting. This command may not work on all X.25 networks.

RESET

Resets all X.3 parameters back to their default settings. Default settings vary according to vendor equipment used on the particular X.25 network.

Contact your X.25 network provider for other commands, that the RAS client needs to issue before calling the RAS server. For example, on SprintNet the @ sign configures the PAD to use 8 data bits, the letter D requests 9600 bits per second (bps) communication.

Important X.28 Service Signals

The following are X.28 service signals that a RAS client or Windows Terminal client receives when making a call to the X.121 address of the RAS server X.25 host. One of these signals should appear in the Terminal window or the Device.log file if logging is turned on:

Note

Some vendors have non-standard service signals like “connected” or similar.

X.3 RAS Specifications and Potential Problems

The following table shows the RAS X.3 specifications. This table was taken from the Windows NT 4.0 Networking Supplement Chapter 9, titled “X.25 PAD Support.” For a detailed description of the standard 22 X.3 parameters, see “Appendix B: General X.3 Parameter Description.” Give these specifications to your X.25 provider and the information in the following two paragraphs as well.

The values set for the X.3 parameters in the following table apply to the X.25 network equipment of most providers, however, there are exceptions. The values in the table are derived from a SprintNet X.25 network. If your X.25 provider has different X.25 equipment the X.3 values may actually specify different unit sizes or may mean “off” when the same value on SprintNet means “on”. Therefore, to achieve the same effect as on a SprintNet network you may have to specify values that differ from the values in the table below.

For example, if you set parameter 4: to 4:1 to set the Idle Timer to an interval of 50 miliseconds on a Sprintnet x.25 network, the same setting of 4:1 may mean an interval of only 20 miliseconds on your x.25 carrier network (e.g. on a SITA Group Network 4:1 means 40 miliseconds as of July 1994). Therefore, parameter 4: should be set to 4:2 in this example (or should be tried at 4:1 or 4:2 for the SITA Group Network).

As the example demonstrates, it is essential to know how the values for the X.3 parameters on your x.25 carrier network map to those of a SprintNet X.25 network or you may experience connection problems. See your X.25 providers documentation for more specific information on your X.25 network if you have problems.

A note on syntax. The parameter number is always separated from the parameter value by a colon. for example, to set parameter 1 to a value of 126 you type:

1:126

To set parameters 1 and 2 to the value 0 (zero) from within the RAS Terminal Window separate the two parameter/value pairs with a space. For example

and press the enter key.

X.25 Configuration Values

Caution:

Failure to set these values as shown prevents the Remote Access Service from functioning properly. For information on setting these values, see the instructions with your X.25 smart card.

Some X.25 network providers use additional proprietary parameters that are extensions to the standard X.3 set of 22 parameters. Northern Telecom Equipment may support the following X.3 parameter extensions. Not all extended X.3 parameter information was available or confirmed at the time of publishing this paper, therefore, please do not rely on the information in the following table. Instead, please consult your X.25 provider whether extended X.3 parameters are used on the X.25 network. The information in this table is provided as an example only and will be updated as information becomes available.

Example Extended Parameter Table

The SITA Group Network is an X.25 provider that supports these additional parameters and maybe more. Therefore, if your provider equipment uses extended X.3 parameters, it is important for RAS X.25 setup and troubleshooting to verify that all X.3 parameters are set correctly including these extended parameters. If problems occur they can be caused by setting the standard X.3 parameters correctly, but failing to configure the extended X.3 parameters which can override the X.3 parameters or vice versa. For example, the following parameters can cancel each other based on the example table of extended parameters above:

Consult your X.25 provider for a complete list of parameters that can cancel each other's effect, if applicable.

Writing a Script for Direct X.25 RAS Client Connections with Non-Eicon X.25 Cards

If you plan on using a non-Eicon X.25 card, verify first that the drivers are available to work with the version of your RAS server.

If you have a non-Eicon X.25 card in a RAS client, but the Eicon X.PAD script does not work, modify the script according to your X.25 card vendor and your X.25 providers requirements to initialize the PAD and make the X.121 address call to the RAS server. To do that, first make a copy of the Eicon X.PAD script and copy it to the end of Pad.inf. Rename the script title so that it is unique in Pad.inf and then start modifying the copied script.

For more information on modifying Pad.inf scripts, read the section below titled “Writing a Pad.inf Script to Automate Remote RAS Logons.”

Automating Remote RAS Logons Using Pad.inf Scripts

Use an Existing Script or Write a New Script

Instead of using the interactive RAS Terminal screen, you can automate the logon process to X.25 providers by using an existing script in the Pad.inf file if you are using an X.25 provider for which a script is provided. See the section above “For Which X.25 Providers Exist RAS Dial-Up Scripts in the Pad.inf File”. Keep in mind that these scripts are provided only for your convenience and are not guaranteed by Microsoft to work because X.25 providers may change or upgrade their equipment at any time which may cause the requirements for scripts to change, in effect making the scripts obsolete. If this is the case in your situation or if your X.25 provider is not listed at all you can create a modified or new script in the Pad.inf file yourself.

Pad.inf was specifically designed for X.25 scripts, but most of the information pertaining to Pad.inf scripting also applies to Switch.inf scripting. However, Pad.inf supports a few more features and has a few more requirements. If you have problems using Pad.inf under Windows for Workgroups please see “Potential Pad.inf Problem in Windows for Workgroups” below in the Troubleshooting section.

Creating Scripts for the Ras Pad.inf File

Note

In Windows NT version 4.0, you must use the script language described in this section if you are planning to use Pad.inf for X.25 dial-up. The new and improved script language described in Script.doc in Appendix F (also in the Windows NT 4.0 %SystemRoot%\System32\RAS directory) does not work in Pad.inf. RAS X.25 dial-up has not been tested with the new script language using a regular *.scp file. If you are planning to run your script on a previous version of RAS as well, you must use the Pad.inf script language described in the following paragraphs:

The Pad.inf file is like a set of small batch files or scripts, all contained in one file separated by script titles called section headers. A Pad.inf script can contain six elements: a section header, comments, commands, responses, response keywords, and reserved macro keywords.

In addition to dividing the Pad.inf file into individual scripts, section headers start the scripts. Comment lines are used to document the script. Any other line in a script is either a command or a response. A command is issued from the local RAS client. A response is received from the remote device or computer.

To write an automatic script for your RAS client you must know the required commands and corresponding responses for the intermediary device. The commands and responses must be in the exact order that the device expects to encounter them. Branching statements, such as GOTO or IF command, are not supported by the Pad.inf and Switch.inf script language. The required sequence of commands and responses from the PAD device should be in the device documentation. If you are connecting to a commercial service, the required sequence of commands and responses should also be available from the service support staff.

The Pad.inf file contains scripts for different X.25 providers or different PADs that the RAS user calls. The scripts are activated by configuring Remote Access Phonebook entries as described under “Configuring a Windows NT 3.x or WFWG 3.11 RAS Client for a Pad.inf X.25 Script” and “Configuring a Windows NT 4.0 RAS Client for a Pad.inf X.25 Script.”

For additional information on writing a Pad.inf script, see the instructions in the Windows NT 3.5 RAS manual, pages 65-67

SECTION HEADERS

A section header marks the beginning of a script, is enclosed in square brackets, and cannot exceed 31 characters. For example:

Each script requires one section header. The section header appears in the RAS Phonebook field allowing you to select RAS Terminal or any other Pad.inf script. For more information, see the “Activating Pad.inf Scripts” section below.

COMMENTS

Comment lines are preceded by semicolons (;) in the left most margin (column one), are optional, and can be placed anywhere in the file. For example:

COMMANDS

A command comes from the local computer. A response comes from the remote device or computer. The COMMAND= statement, which can be used in three different ways, is used to send commands to the intermediary device.

Note

Use upper case for all Pad.inf commands.

DEVICETYPE=pad

DEVICETYPE=pad tells RAS that it is not communicating with a modem which is the default if DEVICETYPE= is completely omitted. Use the string as the first line of your script only if your are writing a new script for communication with an X.25 adapter.

DEFAULTOFF=

DEFAULTOFF= by itself specifies that no default off commands are going to be send to the PAD. This command allows you to specify a custom macro, but is usually only used in the Modem.inf file. See the Modem.inf file for examples.

MAXCARRIERBPS=<bits per second>
MAXCONNECTBPS=<bits per second>

The MAXCARRIERBPS=<bits per second> and MAXCONNECTBPS=<bits per second> should be specified for every X.25 script. These parameters specify a bits-per-second (bps) rate, however, these rates are not dictating the actual maximum carrier or connect rate. Instead, they indicate to the RAS server to wait for a response from the client as long as it would wait for a response over a connection of that bps rate. For example, the client-server carrier speed may occur at 9600 bps, but both parameters may be set as follows to allow the server to wait longer before timing out:

MAXCARRIERBPS=1200
MAXCONNECTBPS=1200

The following setting allows the server to time out faster:

MAXCARRIERBPS=9600
MAXCONNECTBPS=9600

COMMAND=

COMMAND= by itself causes an approximate two second delay, depending on CPU speed and the presence of caching software (for example, SMARTDRV.EXE). If the intermediary device cannot process all of the characters on a COMMAND=<CustomString><cr> line (because they are sent at once), use multiple COMMAND= statements.

COMMAND=<CUSTOM STRING>

COMMAND=<custom string> sends the custom string and causes a slight delay of several hundred milliseconds (depending on CPU speed and installed caching software). The delay gives the intermediary device time to process the custom string and prepare for the next command.

COMMAND=<CUSTOM STRING> <cr>

COMMAND=<custom string><cr> sends the custom string immediately.

Consult the remote device documentation to determine which strings are required.

RESPONSES

Each command line is followed by one or more response lines. Consult the remote device documentation to determine which response strings and dialogs are expected by the remote device. RAS compares responses received with what you put on the response lines. If it matches, RAS uses the response related keyword and macro.

RESPONSE KEYWORDS

The keyword in a response line specifies what your RAS client does with the responses it receives from the remote computer.

The response strings your RAS client receives from the remote device or online service can be used with one of the following keywords in response lines:

OK= remote_device_response <macro>

The OK keyword indicates that RAS can execute the next script line if the condition on the right side of the equal sign is met.

LOOP= remote_device_response <macro>

The LOOP keyword indicates to RAS to wait for a response that matches the condition to the right of the equal sign and if that condition is met to wait for the same response again. If a response does not meet the condition on the right side of the equal sign RAS executes the next line.

CONNECT= remote_device_response <macro>

This keyword is used near the end of the script to indicate the end of the script.

ERROR_NO_CARRIER= remote_device_response <macro>

This keyword is used to test for the presence of a carrier. Intermediary devices report their presence in different ways.

ERROR_DIAGNOSTICS= remote_device_response <macro>

This keyword can be used in conjunction with the <Diagnostics> macro to allow RAS to display a message box containing a problem cause and diagnostic information.

These response related keywords are usually clustered, but do not have to be. CONNECT= is usually the last line, unless it is followed by an ERROR_line. For example:

CONNECT=<match>“ CONNECT”
ERROR_NO_CARRIER=<match>“NO CARRIER”
ERROR_DIAGNOSTICS=<cr><lf><Diagnostics>
ERROR_DIAGNOSTICS=<lf><cr><lf><Diagnostics>

NoResponse

The RAS client always expects a response from the remote device. The client waits until a response is received unless a NoResponse statement follows the COMMAND= line. If there is no statement for a response following a COMMAND= line, the COMMAND= line still executes, but the script does not execute any further.

RESERVED MACRO KEYWORDS

The macros in the following list are reserved words, which you cannot define in Pad.inf to create a new entry. Reserved words are case insensitive.

Stepping Through an Example Script

This topic describes each part of a relatively long X.25 script for a fictitious X.25 provider. Not every script has to contain as many commands as this one, but for training purposes this type of script is most helpful. Please see the Pad.inf file for the following examples of short scripts: Compuserve or Alascom/Tymnet/MCI.

Every script must start with a script header followed by DEFAULTOFF=, MAXCARRIERBPS=<baudrate>, and MAXCONNECTBPS=<baudrate> to properly inform the RAS client software of transmission speeds and corresponding expected delays, for example:

[Fictitious X.25 Provider]

Next issue a command to the remote computer, followed by one or more response lines. This initial command might be simply to wait for the remote computer to initialize and send its logon banner. The initial command depends on your X.25 carrier equipment. In some cases it is necessary to wait two seconds after making the telephone connection to the X.25 PAD modem so the PAD can initialize and get ready to receive commands from your RAS client. So a COMMAND= to cause a two second delay should be used first in such a case, otherwise not. Note, the COMMAND= is preceded by a line with a semicolon indicating to RAS it is a comment line. Use comments to allow easy debugging in the future. Near the end of this walk-through the comment lines are used instead of regular text:

If there is no response expected, RAS needs to be informed about that or it waits forever for a response. So the next line should be:

On a computer with a Pentium processor you may need to add another COMMAND= followed by NoResponse to achieve an approximate two second delay since the COMMAND= delay is controlled by CPU speed or slowness not actual time.

Next the X.25 provider requires you to select 8 data-bit communication and send an “@” sign to the PAD upon which the PAD is not expected to respond. To delay RAS from moving on to the next command too fast the carriage return (<cr>) is left out:

Next a “D” should be sent to configure the PAD for 9600 baud. However, through testing it was found that the @ command needs about 3 seconds to be processed by the PAD before it is ready to receive the next command; so to give the PAD some more time (about 2 more seconds) in addition to leaving out the <cr> in the previous command, use the following two lines:

; Delay RAS 2 more seconds to give the PAD time to process previous command

Next send the D without a carriage return to cause RAS to delay moving on to the next command; the response can be ignored:

Next the caller's user id and password need to be entered.

Next the caller's password needs to be provided to the X.25 provider. For that the Facilities variable is used which allows the user to enter the password in the RAS user interface:

The response should contain the word “active” if the user ID and password were recognized:

If the user ID and password are not recognized, the error information provided in the response from the PAD should be displayed by RAS with the help of the <Diagnostics> macro. Since the X.25 equipment error response has two versions (preceded by a different number of carriage returns and line feeds), two error lines are added to make sure both error response versions are received by the RAS client and displayed on the screen:

Next profile 6 is invoked to set all 22 (or more) X.3 parameters to values that are close to the X.3 RAS specifications. The few parameters that are known to differ from the X.3 RAS specifications will be set later:

The profile set the X.3 Echo facility to Off (2:0) which prevents responses from the PAD being send to the RAS client. It is important to see the responses from the PAD so problems can be identified, therefore parameter 2 is set to On again:

If you are in the process of debugging X.3 parameter settings use the following two lines to request the PAD to send all X.3 parameter settings information to the RAS client so you can capture it in the Device.log or Modemlog.txt files.

; Finally turn echo Off again to comply with X.3 RAS specifications

Creating One Script for Multiple Situations

RAS for Windows NT 4.0 supports a new script language that supports subroutines, IF, WHILE, and GOTO command, etc. which allows for complex scripts, however, this script language does not work in the Pad.inf file. It is designed to work with PPP and SLIP dial-up connections in *.scp files invoked in RAS under the Script tab (not the X.25 tab) and has not been tested with X.25 dial-up. Windows 95 supports the same script language, but has not yet been tested with X.25 and therefore is not supported in that environment; however, it may work.

A company with employees working at different locations may need to provide employees with the ability to log on to an X.25 service from various locations requiring different scripts. Not all employees may have the same RAS versions and the RAS script language on pre-Windows NT 4.0 RAS does not provide any IF, or GOTO statements or support for subroutines. Therefore, you cannot test for logical responses or errors received from a PAD and then branch off to a different execution path. However, the script language does allow you to catch errors and display them on the screen using:

To provide a variety of RAS clients with a Pad.inf or Switch.inf script you need to write several scripts in the Pad.inf file to manage all local logon dialog variations. For example:

If you have a Windows for Workgroups 3.11 RAS client or Microsoft RAS 1.1a client, set an environment variable to a value representing the local X.25 carrier. Then run a batch file that copies the correct script to the file name Pad.inf or switch.inf (depending on the value of the environment variable) and then start Windows.

If you have a Windows NT RAS client, create an icon that runs a similar batch file that tests the environment variable and then runs RAS. All scripts can be provided on one disk and all the user has to do is copy the files to a directory on their hard drive and set the environment variable. This can be automated as well to minimize user interaction.

Troubleshooting a X.25 RAS Client-to-Server Dial-Up or Direct-Connection

The following sections contain formation about X.25 RAS connections.

Frequent Problem Areas

The following are often especially difficult problem areas when implementing a RAS X.25 network:

On the Client side:

Writing a new logon script for communication with the dial-up PAD.

Setting the x.3 paramenters on the x.25 providers network.

On the Server side:

The server side usually does not experience difficult problems unless the Eicon software is erroneously changed from the default settings.

Troubleshooting Connection Problems During Implementation

To ensure proper operation of the dial-up X.25 RAS client and server, do the following:

1.Verify your RAS client can establish a simple RAS link with the RAS server over a regular public switched telephone network (PSTN) using a supported modem.

This verifies the RAS software on client and server is properly working and the serial port, cable, and modem on the client side are properly configured.

Note

If problems persist over PSTN and you have an internal modem in the client or the serer, test with an external modem. This configuration is usually easier to troubleshoot because the modem can be easily reset by switching it on and off while an internal modem can only be reset completely if the computer is turned off and on again. External modem configurations are also less prone to interrupt and i/o address conflicts.

To isolate the problem to the client or the server it is often useful to have two RAS clients with different versions of RAS to test with. If the problem occurs with one client and not the other, you know that the server is configured correctly and the client that failed has the problem.

If problems persist PSTN connections, use the MS RAS troubleshooters and the MS Knowledge Base available on the MS support web site http://www.microsoft.com or query your TechNet CD.

If simple PSTN connections work and the problems over a X.25 connection persist, the problem lies with the X.25 network or the RAS server X.25 configuration. Read item number 2.

2.Make sure the Eicon software and hardware is installed on the RAS server without changing any default settings, for example, do not change the COM port numbers Eicon software is configured to use. For example, Eicon WAN Services version 3, release 1 on Windows NT Server 3.51 uses COM10 as the default COM port. If problems persist, read item 3.

3.Verify that you can type messages back and forth over x.25 using the Windows Terminal (not the RAS after-dialing Terminal window!) application on the client and server side.

4.If this works but RAS connections do not, the server Eicon software is probably configured correctly and the problem lies with the X.3 parameter settings not matching the RAS specifications. Read item 4.

5.Verify that your X.25 provider has configured the X.25 network according to the RAS X.3 specifications above or if it is your responsibility to set the X.3 parameters for each call, verify that you are setting them correctly. To resolve this problem,

If you are using a script:

Turn on logging on your RAS client (See “Enabling Logging and Creating a Device.log file” below).

Insert the command COMMAND=PAR? into your X.25 dial-up script after your X.25 vendor user account name and password and after your attempt to set the X.3 parameters so you can later verify the result of your attempt.

Call the RAS server to run the script with the PAR? command.

Verify that the Device.log or Modemlog.txt file captured the X.3 parameter settings.

Compare the X.3 parameters in the Device.log file to the Microsoft X.3 RAS Specifications above and note any mismatches. Be sure to read “X.3 RAS Specifications and Potential Problems” above.

If any parameter values are set incorrectly, correct your script in Pad.inf to set them to the correct value. If you are already setting them to the correct value in your script, the problem may be a timing issue where the RAS client is sending the script command too fast for the PAD to process. Adjust your script by inserting more COMMAND= statements to delay RAS and give the PAD more time to process the previous command (See “Stepping Through an Example Script” above).

There is also a possibility of you trying to set a parameter that is not changable by users. For example, many X.25 providers have a fixed terminal speed (X.3 parameter 11) and any attempt to change that setting causes an error. Check with your X.25 provider if there are any other X.3 parameters that are “frozen.”

If you are using RAS Terminal:

After you type your X.25 vendor user account name and password and after typing the X.3 parameter settings, type the PAR? command. Write down the resulting PAD response with all the X.3 parameter settings and compare it to the RAS X.3 specifications.

If any parameter values are set incorrectly, you may not have specified them when you gave the Set command. Be sure to set them to the correct value the next time.

There is also a possibility of you trying to set a parameter that is not changable by users. For example, many X.25 providers have a fixed terminal speed (X.3 parameter 11) and any attempt to change that setting causes an error. Check with your X.25 provider if there are any other X.3 parameters that are “frozen.”

Understanding RAS X.25 Configurations

In all troubleshooting, the cause needs to be identified through tests that isolate the problem to the component that is not working properly. To be able to isolate a problem quickly an understanding of the following is helpful and sometimes necessary:

Hardware and software components and their functionality.

Required sequence of events and expected feedback from the software.

Troubleshooting tools available.

A. Hardware and Software Components of X.25 Configurations

Verify that all the following hardware and software components are installed and configured correctly:

RAS Client

Software

RAS software

X.25 Logon Script (unless RAS Terminal is used)

Latest X.25 card driver (if X.25 SmartCard is used and supported in this client)

Hardware

Modem

X.25 SmartCard (if used)

Phone line

X.25 Provider

Software

X.3 settings

X.29 settings

Hardware

X.28 Packet Assembler/Disassemblers (PADs)

RAS Server

Software

RAS software

X.25 card driver(if X.25 SmartCard is installed)

Wan Services if applicable

Hardware

X.25 SmartCard (unless external PAD is used)

Cables

B. The Sequence of Events During RAS X.25 Connections

This section has two subsections because the events during RAS X.25 dial-up connections differ from the events during direct RAS X.25 connections (where both the RAS client and the RAS server have an X.25 card installed). Read the section that applies to your configuration.

X.25 Dial-Up Connections

For a successful dial-up RAS connection to a remote network over X.25 to a RAS X.25 server, the RAS client needs to make five successfull connections, that is, the RAS client has to use command mode five times and each time following the command mode switch into a data transfer mode that becomes the command mode for the next connection level. After the fifth connection the user can issue network commands to the remote network or run applications from the remote network:

Connection I—Connect to the dial-up PAD of the X.25 provider.

Connection II—Authenticate with the X.25 provider software.

Connection III—Connect over X.25 to RAS server X.25 adapter.

Connection IV—Authenticate with the RAS server service.

Connection V—Log on to the remote Windows NT domain.

These five connection phases can be broken down into the following actions:

X.25 Dial-Up Connection I

1.The RAS client dials the number for the X.25 service providers dial-up PAD.

2.The dial-up PAD and the client modem establish a connection. (The RAS server is not involved yet, that is, the RAS server is not aware of the RAS client call to the X.25 dial-up PAD.)

X.25 Dial-Up Connections II and III

The RAS client supplies miscellaneous information, including but not limited to:

For X.25 Dial-Up Connection II

PAD configuration parameters to set databits, echo, etc.

User name to identify the user for billing purposes to the X.25 provider.

Password to maintain security on the X.25 customer account.

For X.25 Dial-Up Connection III

X.3 parameters to configure the X.25 network according to RAS specifications.

The RAS server X.121 address to call the RAS server host PAD configured with Eicon WAN services. The host PAD accepts the X.25 connection and the client and host PADs go into data transfer mode.

This information is supplied by the RAS client through two methods depending on your configuration:

The RAS client displays a RAS Terminal window (available in Windows For Workgroups 3.11, Windows 95, Windows NT 3.1, 3.5, 3.51, and 4.0) and the user types the information.

The RAS client executes a logon script that provides the information with the correct timing which is critical.

X.25 Dial-Up Connection IV

The RAS client and the RAS server begin the RAS client authentication conversation. If the RAS client is authenticated as an authorized RAS client, the RAS connection is established and the RAS client and server go into data transfer mode.

X.25 Dial-Up Connection V

The RAS client logs on to the remote domain for network access. RAS 1.1 clients need to log on with the Net Logon command. RAS for Windows for Workgroups 3.11 clients can log on using Log On/Off icon in the Network group in Program Manager. Windows NT RAS clients are logged on automatically with the credentials they provided during system startup, or if those credentials differ from the remote domain credentials are prompted for their credentials for the remote domain when accessing resources that require proper permission.

X.25 Direct Connections

For a RAS client to connect to a remote Windows NT network over a direct X.25 to X.25 RAS connection between RAS client with a X.25 card installed and RAS server (also using an X.25 card), the RAS client needs to make three successful connections:

Connection I—Connect over X.25 to the RAS server Eicon WAN services.

Connection II—Authenticate with the RAS server service.

Connection III—Log on to the remote Windows NT domain.

X.25 Direct Connection I

The RAS client issues X.3 PAD configuration parameters to set data bits, echo, etc. and calls the RAS server X.121 address using a script in Pad.inf. The RAS server host PAD configured with Eicon WAN services responds and accepts the X.25 connection. The client and host PADs go into data transfer mode.

X.25 Direct Connection II

The RAS client and the RAS server begin the RAS client authentication conversation. If the RAS client is authenticated as an authorized RAS client, the RAS connection is established and goes into data transfer mode.

X.25 Direct Connection III

The RAS client logs on to the remote domain for network access. RAS 1.1 clients for OS/2 need to log on with the Net Logon command. Windows NT RAS clients are logged on automatically with the credentials they provided during system startup, or if those credentials differ from the remote domain credentials are prompted for their credentials for the remote domain when accessing resources that require proper permission

Troubleshooting Scripts using Device.log and RAS Terminal

Before writing scripts to automate the process of logging onto a PAD, use the RAS Terminal feature to familiarize yourself with the logon sequence of events. For more information on activating the RAS Terminal feature, see the section “Implementing an X.25 RAS Client-to-Server Dial-Up or Direct Connection” above.

To find errors that prevent your scripts from working, log all information passed between RAS, the modem, and/or the PAD (including errors reported by any other intermediary device in your configuration) by turning on RAS logging (see “ENABLING LOGGING AND CREATING A Device.log FILE” in this section below).

After you enable logging, the Device.log file is created (when you start RAS) in the Windows NT %systemroot%\SYSTEM32\RAS subdirectory or the Windows for Workgroups \WINDOWS directory.

If an error is encountered during script execution, execution halts. Determine the problem by studying any RAS error messages that appear on the screen and by studying the Device.log file contents. Make necessary corrections to the script and then restart RAS. If you are running Windows for Workgroups RAS 3.11 and the script execution halts even though you verified all lines to be error free, read the paragraph titled “Potential Pad.inf Problem in Windows for Workgroups” in the implementation section below.

The Device.log file appends any communication as long as RAS is not restarted. If you restart RAS, the Device.log file is erased and re-created. Therefore, if you make changes to Pad.inf during your script development which always require you to restart RAS, and you need to save the current traces contained in the Device.log file, rename the Device.log file before starting RAS again.

Enabling Logging and Creating a Device.log or Modemlog.txt File

To enable logging and create a Device.log file under Windows NT 3.x or 4.0:

Warning

Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

1.Hang up any connections, and exit from Remote Access.

2.Run Registry Editor (REGEDT32.EXE).

3.From the HKEY_LOCAL_MACHINE subtree, go to the following key:

SYSTEM\CurrentControlSet\Services\RasMan\Parameters

4.Change the value of the Logging parameter to 1:

Logging begins when you restart Remote Access or start the Remote Access Server service (if your computer is receiving calls). You do not need to shutdown and restart Windows NT.

To enable logging and create a Device.log file under Windows for Workgroups:

1.Using a text editor such as Windows Notepad, edit the System.Ini file.

2.In the [Remote Access] section, add the following line:

3.Save the file.

In Windows 95 the Device.log text file is named Modemlog.txt instead and is created in the Windows directory when you restart Windows and RAS.

To enable logging and create a Modemlog.txt file under Windows 95:

1.On your Desktop double-click My Computer.

2.Double-click Dial-Up Networking

3.Double-click Make New Connection and click Configure.

4.Click the Connection tab and click on Advanced.

5.Click the Record A Log File check box.

Troubleshooting RAS X.25 Client Pad.inf Script Timing Problems

Many script problems occur because of timing problems in the command-response dialog between the RAS client and the dial-up PAD. Often the RAS client sends commands too soon to the dial-up PAD because the PAD is still processing the first command while the second command already arrives from the RAS client. In those cases the second command is lost by the time the PAD becomes available. If the PAD has a buffer to store the command, the timing becomes less of an issue, but most PADs do not have buffers for storing remote commands.

To diagnose timing problems and measure timing intervals precisely, you may use a serial analyzer such as a Hewlett Packard HP 4957A, but a serial analyzer is not required. Serial analyzers can be expensive relative to using the trial and error method of troubleshooting a script which takes longer, but usually is successful, too.

To prevent the RAS X.25 client from sending commands too soon, use the COMMAND = without the carriage return macro (<cr>), or the COMMAND = <PAD_X.28_or_other_command> without <cr>, and the LOOP = commands. The tricky part is that the amount of time delayed with these commands varies by the speed of your processor and the presence of caching software in your RAS client. Therefore, on a 386-based computer the COMMAND= and the COMMAND= <PAD_X.28_or_other_command> cause a longer delay than on a 486-based or Pentium-based computer.

For example, if your Device.log or Modemlog.txt file shows that a certain command in your script is not received by the PAD, insert a “COMMAND=“ line before that command to gain about a 2 second delay.

For more information, see the text and the examples in the Switch.inf and Pad.inf files in the Windows NT <SystemRoot>\System32\RAS directory.

After the X.25 provider has given you the commands you need to send from your script or RAS Terminal screen to log on to the dial-up PAD, start out by issuing the commands manually in a RAS Terminal window. Once you verified that this works you can start building a script either from scratch or by copying one of the existing scripts to the end of the Pad.inf file and renaming and modifying that script to suite your X.25 provider equipment.

Potential Pad.inf Problem in Windows for Workgroups

RAS for Windows for Workgroups 3.11 reportedly may under certain circumstances not execute Pad.inf scripts completely even though no error was encountered in the script. If that problem occurs you can try copying your Pad.inf script to the Switch.inf file and replace the special Pad.inf macros X25address, Userdata, and Facilities (if applicable) with the actual values because Switch.inf does not support these macros in Windows for Workgroups. See the section “Activating an X.25 Script in Switch.inf in Windows for Workgroups 3.11 RAS.”

Note

If you are using Windows for Workgroups make sure that you have the RAS program files with a file date of April 1994 or later installed. The update to these RAS files is free. Call Microsoft Technical Support to obtain these files. These files make RAS memory usage more efficient and eliminate error 640 and other symptoms. For more information see the Microsoft Knowledge Base on www.microsoft.com or your TechNet CD.

Troubleshooting the X.25 Provider X.3 Parameters

See the information provided above under “X.3 RAS Specifications and Potential Problems.”

Troubleshooting the RAS X.25 Server During Setup

Problem: After calling the RAS server X.121 address the following server PAD response appears on the X.25 provider monitoring equipment:

(the X.25 provider helpdesk person sees this on the screen) and the RAS Client Device.log file captures:

Solution: This is a sign of the RAS server Eicon card not being properly initialized. Make sure that the Eicon software is not changed from the default configuration. Verify the COM port used by the Eicon software, for example, COM10, is not changed to another COM port, for example, COM4.

Eicon Software Trace Utility

Eicon Technologies provides the EiconCard Loadable Module Management Utility (ECMODULE) which allows the tracing of all activity on the Eicon card. These traces may have to be interpreted with the help of an Eicon support engineer.

Troubleshooting Transmission Reliability Problems

The following are X.25 troubleshooting tips from the Windows NT 4.0 Help File:

Problem: After connecting through a dial-up PAD, the server consistently fails to authenticate the client.

Solution: If the remote access server is running and clients cannot connect to it directly through an X.25 smart card or an external PAD, the dial-up PAD may have the wrong X. 3 parameters or serial settings. Ask your administrator for the correct settings, listed in the Chapter 9 “X. 25 PAD Support” in the Networking Supplement of Windows NT Server 4.0.

Problem: A connection has been established, but network drives are disconnecting, and you are dropping sessions or getting network errors.

Solution: Congestion on the Remote Access server's leased line may be the cause. The administrator should make sure that the speed of the leased line can support all the COM ports at all speeds clients use to dial in.

For example, four clients connecting at 9600 bps (through dial-up PADS) require a 38,400-bps (four times 9600) leased line on the server end. If the leased line does not have adequate bandwidth, it can cause timeouts and degrade performance for connected clients. This example assumes the Remote Access Service is using all the bandwidth. If it is sharing the bandwidth, fewer connections can be made.

Problem: While transferring files, you frequently get the error messages “Network drive disconnected” or “Network drive no longer exists.”

Solution: On X. 25 smart cards, change the Negotiate network parameters option in the X. 25 settings to Yes. This problem arises when X.25 parameters, such as the size of the send and receive window, are set differently for the server, the network, and the client X.25 software.

By enabling the Negotiate network parameters option on the client's (if using the direct X. 25 connection) and the server's X.25 software, you let the server, the network, and the client use commonly negotiated X.25 network parameters.

Topic 4 is not included here. This topic is better explained with this article.

Problem: A modem connected to a dial-up PAD connects a lower speed than it should.

Solution: Replace the modem with a compatible one from the list in the Setup program.

The following section is from the Windows NT 3.51 and 4.0 RasRead.txt file:

Troubleshooting Remote Disconnections

When a client connection is cleared, the system event log of the RAS server running X.25 can be examined for an error message. The event log can record why the remote client or the remote network disconnected.

If the remote client (through a dial-up PAD or local PAD) disconnects, the following warning message will appear in the system event log:

Remote DTE cleared the X.25 call on XPADxxx, X.25 Return Codes: Cause yy (hex) Diagnostic yy (hex)

The “XPADxxx” is the port name defined in the XPAD configuration. “yy” is a hex string. For DTE clearing the cause will always be 00. The Diagnostic code can be 00--indicating that the remote client requested a disconnect--or another non-zero value. When the diagnostic code is non-zero it indicates a clearing due to the remote client's dial-up PAD service. Contact the remote client's X.25 service provider to determine the problem.

If the X.25 network disconnects, the following warning message will appear in the system event log:

Network cleared the X.25 call on XPADxxx, X.25 Return Codes: Cause yy (hex) Diagnostic yy (hex)

The “XPADxxx” is the port name defined in the XPAD configuration. “yy” is a hex string. For a network clearing the cause value will always be a non-zero value. The diagnostic code in the cause can be any value. Consult your local X.25 service provider with the cause and diagnostic value to determine the exact reason for the network disconnect.

Appendix A: Windows NT 4.0 Networking Supplement Manual RAS X.25 Chapter

chapter 9 - X.25 PAD support

An X.25 network uses a packet-switching protocol to transmit data. This protocol relies on an elaborate worldwide network of packet-forwarding nodes (Data Communications Equipment [DCEs]) that participate in delivering an X.25 packet to its designated address.

Dial-up Asynchronous Packet Assemblers/Disassemblers (PADs) constitute a practical choice for Remote Access clients because they don’t require an X.25 line to be plugged into the back of the computer. Their only requirement is the telephone number of the PAD service for the carrier.

Note

This Chapter is specific to X.25 PADs. X.25 cards can also be supported through WAN miniport drivers.

The Remote Access Service lets you access the X.25 network in two general ways:

The next section tells how to access the X.25 network in both ways for specific configurations.

X.25 Configurations

The Remote Access Service for X.25 networks offers two configurations for the client and one for the server:

Table 9.1 X.25 Configurations

Pad.inf Format

Similar in format to Modem.inf (which contains script information used to talk to the modem), Pad.inf contains conversations between the client software and the PAD. For details, see Appendix C, “Understanding Modem.inf.” Pad.inf is located in the \systemroot\SYSTEM32\RAS folder.

The macros in the following list are reserved words, which you cannot define in Pad.inf to create a new entry. Reserved words are case insensitive.

x25address

diagnostics

userdata

facilities

Caution

Using reserved words as macro names in Pad.inf could result in unpredictable behavior of the Remote Access software.

Sample Pad.inf

The following sample Pad.inf file will help you create a section within Pad.inf for your X.25 network. This example shows an entry for Sprintnet:

After this sample conversation for SPRINTNET is completed (with the correct responses), the X.25 connection is established. If errors are detected during the PAD conversation, no connection is made.

Note

The Remote Access Service currently works with PADs set to 8 data bits, 1 stop bit, and no parity. Consult the documentation for the PAD to see how to install these settings.

In Pad.inf, you can use the COMMAND_ series of commands (COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN) or the generic COMMAND. But do not mix the two families of commands. For more information on the COMMAND_ series, see Appendix C, “Understanding Modem.inf.”

Troubleshooting

For troubleshooting information, see the Remote Access online Help.

Accessing X.25 Through Dial-Up PADs

Operating between the client and the Remote Access server, an asynchronous PAD converts serially-transmitted data into X.25 packets. When the PAD receives a packet from an X.25 network, it puts the packet out on a serial line, making communication possible between the client and the X.25 network.

Remote Access clients can connect with Remote Access servers through dial-up PAD services supplied by X.25 carriers, such as Sprintnet and Infonet. After the client’s modem (modem A in Figure 9.1) connects to the PAD’s modem (modem B), the client software must converse with the dial-up PAD. When their conversation is successfully completed, a connection is established between client and server. The conversation (command/response scripts) for the PADs supported by an X.25 carrier is stored in the Pad.inf file. Remote Access software supplies one example. To customize your PAD, see “Pad.inf Format,” in this chapter.

For example, Pad.inf contains two Sprintnet entries: Sprintnet Standard and Sprintnet Alternate. Generally, if you are calling through 9600 bits-per-second (bps) or faster dial-up PADs, try Sprintnet Standard. If you are calling through 2400 bps or slower dial-up PADs, try Sprintnet Alternate.

If one Sprintnet entry fails to connect reliably, try the other one. Sprintnet dial-up PADs should work with both.

Note

For dial-up PADs, you must use the COMMAND= format, not the COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN format.

Figure 1.1 shows how a client connects to the Remote Access server through a dial-up PAD and the X.25 network.

Figure 1.1 Connecting to the Server Through a Dial-Up PAD

Note

For best results when using a dial-up PAD, use a modem that matches the one used by the PAD carrier (or at least matches the V. protocol supported by the carrier’s modem).

The following table compares connecting through dial-up PADs and connecting directly to the X.25 network:

Table 1.2 Comparison of Dial-Up PADs to Connecting Directly

PAD and Serial Configuration

To configure your PAD correctly, set the X.3 parameters according to the information shown in Table 9.3 later in this chapter.

The configuration of the dial-up PAD should be as follows:

8 data bits

1 stop bit

No parity serial communication

For dial-up PADs, make sure your vendor supports this configuration. The PADs might already be set to the correct configuration for connecting directly through an internal X.25 smart card. If they are, do not change the configuration.

Connecting to the X.25 Network Directly

RAS also supports connecting directly from the remote computer to the X.25 network through a smart card, which acts like a modem. An X.25 smart card is a hardware card with a PAD embedded in it. To the personal computer, a smart card looks like several communication ports attached to PADs. To access the X.25 network through a direct connection, you must have

a direct line connection to an X.25 network (clients only)

a smart card

Note

The server side always requires an X.25 smart card, but the client side requires one only when connecting to the X.25 network directly.

Note

For connecting to the network directly, you must use the COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN format.

Figure 1.2 shows how the server and a Windows NT client (both equipped with smart cards) connect to the X.25 network directly.

Figure 1.2 Connecting to X.25 Directly

Callback

The Remote Access server does not support callback on X.25 networks.

Setting Up the Remote Access Server for an X.25 Network

After installing Windows NT Server and adding the Remote Access Service, follow these steps:

To set up the Remote Access server for an X.25 network

1.Install the X.25 smart card (according to the manufacturer’s instructions).

A communications driver for the X.25 smart card that emulates communication ports is supplied by the hardware manufacturer or by a third party.

2.Make sure your X.25 smart card is configured with the X.3-parameter values shown in Table 9.3.

3.From the list of devices on the Remote Access Setup dialog box, select an entry corresponding to the X.25 smart card.

4.In setting up the Remote Access server, make sure that the ports selected are configured for dial-in.

Note

Make sure that the speed of the leased line can support all the serial communication (COM) ports at all speeds at which clients will dial in. For example, 4 clients connecting at 9600 bps (through dial-up PADs) will require a 38,400-bps (4 times 9600) leased line on the server end. If the leased line does not have adequate bandwidth, it can cause time-outs and can cause the performance for connected clients to degrade.

Table 1.3 X.25 Configuration Values

Caution

Failure to set these values as shown prevents the Remote Access Service from functioning properly. For information on setting these values, see the instructions with your X.25 smart card.

Setting Up Remote Access Clients

This section tells how to set up Remote Access clients for connecting to the X.25 network through PAD services and for connecting to the X.25 network directly.

Connecting Through Dial-Up PADs

Following these steps to connect a client to an X.25 network:

1.Dial from the client’s modem to a PAD (modem-to-modem).

2.Establish a connection over the X.25 network between the PAD and the server-side X.25 smart card.

After you’ve established a connection, communicate as you would through any asynchronous connection. For a complete description of connecting through dial-up PADs, see “Accessing X.25 Through Dial-Up PADs,” earlier in this chapter.

Configuring Client PADs

The client PAD, through which a remote computer connects to the X.25 network, might have previously been set to X.3-parameter values that are incompatible with the Remote Access Service. Therefore, it is important to configure the X.25 smart card on the Remote Access server so that it changes the client PAD’s X.3 settings to the values in Table 9.3 as soon as a connection is established through X.29 commands. To configure an X.25 smart card to make these changes, see the configuration manual for your specific card.

Note

If the X.25 smart card on the server end does not support commands for the X.29 language, the client PAD script must set the X.3 parameters locally. If you have problems, contact the support site for your X.25 smart card vendor.

Connecting Directly

To set up the client for connecting directly to the X.25 network, follow the procedures used in setting up the Remote Access server. See “Setting Up the Remote Access Server for an X.25 Network,” earlier in this chapter. Make sure the communication ports are selected as dial-out.

Configuring Remote Access Software for X.25

Connecting to a server through an X.25 network is similar to connecting through a phone line. The only difference is that the phone book entry must specify an X.25 PAD type and an X.121 address.

To add a phone book entry with X.25 or to add X.25 to an existing entry

See RAS online Help. This online Help also provides troubleshooting information.

Appendix B: General X.3 Parameter Description

This is a general listing of X.3 Packet Assembler/Disassembler (PAD) parameters. There are 22 standard PAD parameters since 1984. Parameters 16, 17, 18, and 19 describe editing functions that are not used with RAS.

For more information on how to set these parameters with RAS, see the paragraph titled “X.3 RAS Specifications and Potential Problems” above.

Parameter 1: PAD recall

Description: This enables an escape from the PAD on-line state (data transfer mode) to the PAD command state on receipt of a specific character. When the PAD receives this character, the PAD prompt is displayed on your terminal monitor.

Parameter 2: Echo

Description: This parameter is set to “0” (zero) for echo and “1” fornon-echo. One of the most frequently used parameters, this is handy for applications used for suppression of text when you are typing in your name and password. When this parameter is set, all characters received from the terminal are echoed, excluding those specified by parameters 5,12,20,22. Setting parameters 12 or 22 to non-zero values suppresses character echo (XON and OFF) even if parameter 2 is set to echo on.

Parameter 3: Data Forwarding Signal (characters)

Description: This value is bit-mapped. The PAD does not usually transmit one character at a time; it prefers large blocks of data, such as lines of text. A normal character used for this parameter is [carriage return = 2]. A PAD manufacturer's manual should have a table showing the options for this parameter.

Parameter 4: Idle Time Delay

Description: With the Data Forwarding, this parameter provides the capability to forward data to a host based on idle time. If there is data in the buffer and there has been no additional characters received in the IDLE TIME, the buffer is sent to the host. The time units are in 0.05 seconds and the values range from 1 - 255. The implementation of the time unit sizes can vary from vendor to vendor.

Parameter 5: Flow Control - PAD to Terminal

Description: This parameter tells the PAD to transmit the XON/OFF characters to the DTE, depending on the buffer state.

Parameter 6: PAD Result Code Control

Description: This controls how the PAD result codes are transmitted to the terminal. The parameter can stop the PAD from sending service codes back to the terminal in response to events as the X.25 calls for clear or reset.

Parameter 7: Action on Receipt of Break from Character Terminal

Description: This parameter is bit-mapped. The break action here is a sequence (from the host that the PAD is connected to) for indicating that attention is required. This can be used in the interruption of a long transmission that the host may think is hung in a loop or stuck in constant transmit mode.

Parameter 8: Discard Output

Description: Set this parameter so that you can abort a running process on the remote system by pressing a [break] key. If set to zero [0], normal data delivery is used.

Parameter 9: Padding after Carriage Return

Description: Specifies the number of {NUL} characters to transmit after a carriage return.

Parameter 10: Line Folding

Description: This allows for the formatting of data into regular line lengths when delivered to the character terminal. If a line length is specified, a [carriage return / line feed] must be transmitted.

Parameter 11: Terminal Speed

Description: This is a READ ONLY value. The parameter shows the current DTE speed. It is automatically set by the PAD using the last AT command.

Parameter 12: Flow Control of the PAD by Local Terminal

Description: This is basically the opposite of parameter 5: it allows the character terminal to control the flow control.

Parameter 13: Line Feed Insertion after Carriage Return

Description: This specifies whether the PAD inserts a line feed character after carriage returns. This applies only in the PAD on-line state.

Parameter 14: Padding after Line Feed

Description: This is the same as parameter 9 except that the padding {NUL} characters instead of a carriage return are inserted after a line feed.

Parameter 15: Editing

Description: This specifies whether editing is used in the PAD on-line state.

Parameter 16: Character Delete

Note

Parameters 16, 17, 18, and 19 help describe the available editing functions. If editing is enabled, parameter 4 (Idle Time Delay) is ignored.

Description: This defines the delete character to delete the last character in the editing buffer. ASCII 8 is the backspace character.

Parameter 17: Line (buffer) Delete

Description: This defines the line delete character. ASCII 24 is <Ctrl-X>.

Parameter 18: Line Display

Description: This defines the line display. If you enter the character specified and editing is enabled, the editing buffer is displayed. ASCII 18 is <Ctrl-R>.

Parameter 19: Editing PAD Result Codes

Description: This defines the effect of editing buffered characters with the character delete and line delete functions.

Parameter 20: Echo Mask

Description: Bit-Masked Parameter. If parameter 2 is set to 1, this parameter lets you select the characters that are echoed.

Parameter 21: Parity Treatment

Description: This controls the parity and character format used by the terminal. Best left in the “OFF” condition.

Parameter 22: Page Wait

Description: This allows for pagination of data sent to the terminal. If the terminal display can display 20 lines and this parameter is set to 20, the PAD sends 20 lines of data then stops transmission.

Appendix C: Using Pad.inf with Non-X.25 RAS Connections

In Windows for Workgroups 3.11 and Windows NT 3.1 and 3.50 Pad.inf has the advantage over Switch.inf that it supports three macros (variables): X.121 Address, User Data, and Facilities that are getting their values from the X.25 user interface. This makes Pad.inf more user-friendly and secure because the password does not need to be entered permanently in the Pad.inf script like it would have to in the Switch.inf file.

For example, calling a RAS server with an intermediary security device switched in-line where the security device requires a user ID and password in addition to the Windows NT RAS credentials becomes more secure and user-friendly by using the Pad.inf file rather than Switch.inf. In those cases where the password for the intermediary security device is changing every few seconds or minutes, the use of the variables in Pad.inf file is virtually the only feasible solution because quickly editing the Switch.inf file to enter the password, saving the changes and then starting RAS and making the call may take so much time that the password has changed again in the meantime.

However, in Windows NT 3.51 and 4.0, Switch.inf supports two variables: Username and Password which are conveniently obtained through the familiar Windows NT logon dialog box. The Username and Password variables are not available in Windows for Workgroups 3.11, Windows NT 3.1 and 3.5 RAS. For more information, see your RAS manual and online help for X.25 topics.

Note

Pad.inf was designed for X.25 connectivity. Although using Pad.inf with non-X.25 networks may work, it has not been tested by, and is not supported by Microsoft.

Appendix D: List of Electronic and Hardcopy RAS documentation in the Different RAS Versions

The following list shows all RAS versions to-date - regardless of X.25 support - and whether they ship with a hard copy of the manual or only a softcopy manual or only online help. All RAS versions ship with online help, however, the early RAS versions do not contain nearly as much information in the online help as the later versions.

The following RAS version ship with a hard copy of the manual:

Remote Access for MS-DOS, versions 1.0, 1.1, 1.1a

Remote Access for OS/2, version 1.0, 1.1

Windows NT operating system version 3.1

Windows NT Advanced Server version 3.1

Windows NT Workstation versions 3.5, and 3.51

Windows NT Server versions 3.5, and 3.51

The following RAS versions only have online help:

RAS for Windows for Workgroups only has online help documentation.

RAS for Windows 95

The following RAS versions ship online help and with a printable, electronic version of the manual on the compact disc. A hard copy of the manual can be purchased for a small fee:

Microsoft Windows NT Workstation version 4.0

Microsoft Windows NT Server version 4.0

Note

The RAS server and RAS client online help may contain information on different topics.

Appendix E: Other RAS sources

The Windows NT 3.51 Resource Kit Update 2 manual has a comprehensive RAS Reference that discusses all RAS versions up to Windows NT 3.51 and Windows 95.

The RAS Troubleshooter on the Microsoft web at: http://www.microsoft.com

Microsoft TechNet (Knowledge Base and White Papers)

The Microsoft Knowledge Base on the web and on Microsoft TechNet: http://www.microsoft.com/technet

For More Information

For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/ntserver or the Windows NT Server Forum on MSN™ The Microsoft Network (GO WORD: MSNTS).

Appendix F: The New Script Language for Windows 95 and Windows NT 4.0

This script language is not supported for use in the Windows NT Pad.inf file! Use it with RAS for PPP and SLIP dial-up networking, for example, to access the Internet via an Internet access provider. Using the script language in a *.scp script file for X.25 dial-up has not been tested by Microsoft and is therefore not supported, however, it may work. Also Windows 95 has not been tested with X.25 dial-up and this script language, however, it may work, too.

Dial-Up Scripting Command Language / For Dial-Up Networking Scripting Support

1.0 Overview

Many Internet service providers and online services require you to manually enter information, such as your user name and password, to establish a connection. With Scripting support for Dial-Up Networking, you can write a script to automate this process.

A script is a text file that contains a series of commands, parameters, and expressions required by your Internet service provider or online service to establish the connection and use the service. You can use any text editor, such as Microsoft Notepad, to create a script file. Once you've created your script file, you can then assign it to a specific Dial-Up Networking connection by running the Dial-Up Scripting Tool.

2.0 Basic Structure of a Script

A command is the basic instruction that a script file contains. Some commands require parameters that further define what the command should do. An expression is a combination of operators and arguments that create a result. Expressions can be used as values in any command. Examples of expressions include arithmetic, relational comparisons, and string concatenations.

The basic form of a script for Dial-Up Networking follows:

A script must have a main procedure, specified by the proc keyword, and a matching endproc keyword, indicating the end of the procedure.

You must declare variables before you add commands. The first command in the main procedure is executed, and then any subsequent commands are executed in the order they appear in the script. The script ends when the end of the main procedure is reached.

3.0 Variables

Scripts may contain variables. Variable names must begin with a letter or an underscore ('_'), and may contain any sequence of upper- or lower-case letters, digits, and underscores. You cannot use a reserved word as a variable name. For more information, see the list of reserved words at the end of this document.

You must declare variables before you use them. When you declare a variable, you must also define its type. A variable of a certain type may only contain values of that same type. The following three types of variables are supported:

Variables are assigned values using the following assignment statement:

variable = expression

The variable gets the evaluated expression.

Examples:

3.1 System Variables

System variables are set by scripting commands or are determined by the information your enter when you set up a Dial-Up Networking connection. System variables are read-only, which means they cannot be changed within the script. The system variables are:

These variables may be used wherever an expression of a similar type is used. For example,

is a valid command because $USERID is a variable of type string.

4.0 String Literals

Scripting for Dial-Up Networking supports escape sequences and caret translations, as described below.

If char is a value between '@' and '_', the character sequence is translated into a single-byte value between 0 and 31. For example, ^M is converted to a carriage return.

If char is a value between a and z, the character sequence is translated into a single-byte value between 1 and 26.

If char is any other value, the character sequence is not specially treated.

Examples:

5.0 Expressions

An expression is a combination of operators and arguments that evaluates to a result. Expressions can be used as values in any command.

An expression can combine any variable, or integer, string, or boolean values with any of the unary and binary operators in the following tables. All unary operators take the highest precedence. The precedence of binary operators is indicated by their position in the table.

The unary operators are:

The binary operators are listed in the following table in their order of precedence. Operators with higher precedence are listed first:

Examples:

6.0 Comments

All text on a line following a semicolon is ignored.

Examples:

7.0 Keywords

Keywords specify the structure of the script. Unlike commands, they do not perform an action. The keywords are listed below.

proc name

Indicates the beginning of a procedure. All scripts must have a main procedure (proc main). Script execution starts at the main procedure and terminates at the end of the main procedure.

endproc

Indicates the end of a procedure. When the script is executed to the endproc statement for the main procedure, Dial-Up Networking will start PPP or SLIP.

integer name [ = value ]

Declares a variable of type integer. You can use any numerical expression or variable to initialize the variable.

string name [ = value ]

Declares a variable of type string. You can use any string literal or variable to initialize the variable.

boolean name [ = value ]

Declares a variable of type boolean. You can use any boolean expression or variable to initialize the variable.

8.0 Commands

All commands are reserved words, which means you cannot declare variables that have the same names as the commands. The commands are listed below:

delay nSeconds

Pauses for the number of seconds specified by nSeconds before executing the next command in the script.

Examples:

getip value

Waits for an IP address to be received from the remote computer. If your Internet service provider returns several IP addresses in a string, use the value parameter to specify which IP address the script should use.

Examples:

goto label

Jumps to the location in the script specified by label and continues executing the commands following it.

Example:

halt

Stops the script. This command does not remove the terminal dialog window. You must click Continue to establish the connection. You cannot restart the script.

if condition then

commands

endif

Executes the series of commands if condition is TRUE.

Example:

label :

Specifies the place in the script to jump to. A label must be a unique name and follow the naming conventions of variables.

set port databits 5 | 6 | 7 | 8

Changes the number of bits in the bytes that are transmitted and received during the session. The number of bits can be between 5 and 8. If you do not include this command, Dial-Up Networking will use the properties settings specified for the connection.

Example:

set port parity none | odd | even | mark | space

Changes the parity scheme for the port during the session. If you do not include this command, Dial-Up Networking will use the properties settings specified for the connection.

Example:

set port stopbits 1 | 2

Changes the number of stop bits for the port during the session. This number can be either 1 or 2. If you do not include this command, Dial-Up Networking uses the properties settings specified for the connection.

Example:

set screen keyboard on | off

Enables or disables keyboard input in the scripting terminal window.

Example:

set ipaddr string

Specifies the IP address of the workstation for the session. String must be in the form of an IP address.

Examples:

transmit string [ , raw ]

Sends the characters specified by string to the remote computer.

The remote computer will recognize escape sequences and caret translations, unless you include the raw parameter with the command. The raw parameter is useful when transmitting $USERID and $PASSWORD system variables when the user name or password contains character sequences that, without the raw parameter, would be interpreted as caret or escape sequences.

Examples:

waitfor string [ , matchcase ] [ then label

{ , string [ , matchcase ] then label } ]

[ until time ]

Waits until your computer receives one or more of the specified strings from the remote computer. The string parameter is case-insensitive, unless you include the matchcase parameter.

If a matching string is received and the then label parameter is used, this command will jump to the place in the script file designated by label.

The optional until time parameter defines the maximum number of seconds that your computer will wait to receive the string before it execute the next command. Without this parameter, your computer will wait forever.

If your computer receives one of the specified strings, the system variable $SUCCESS is set to TRUE. Otherwise, it is set to FALSE if the number of seconds specified by time elapses before the string is received.

Examples:

while condition do

commands

endwhile

Executes the series of commands until condition is FALSE.

Example:

...

9.0 Reserved Words

The following words are reserved and may not be used as variable names.

Appendix G: Troubleshooting RAS 1.0 and 1.1 on a MS OS/2 1.3 Server Running MS LAN Manager

The following are two Microsoft Knowledge Base troubleshooting articles that focus on RAS 1.0 and 1.1 installed on computers running Microsoft OS/2 1.3 and LAN Manager 2.1 or later.

Part 1 (of 2)--Troubleshooting RAS on an OS/2 1.x Server [lanman]

ID: Q98518 CREATED: 06-MAY-1993 MODIFIED: 26-JAN-1995

2.10 2.10a 2.20

MS-DOS PUBLIC | kbnetwork

The information in this article applies to:

Microsoft LAN Manager versions 2.1, 2.1a, and 2.2
Microsoft Remote Access Service versions 1.0 and 1.1

SUMMARY

This is part 1 of a two-part article meant to supplement (not replace) information provided in the “Remote Access Administrator's Guide,”Chapter 4, “System Requirements.” It will help you troubleshoot problems by verifying that basic requirements are met.

To ensure proper operation of RAS 1.0 or 1.1 on an OS/2 1.21 or 1.3 server (OS/2 2.0 is currently not supported), verify that the following elements are present — preferably BEFORE you run the RAS Setup program:

1.Serial Ports/Device Drivers

One or more serial ports.

One or more OS/2 serial port device drivers.

Part 1 (the rest of this article) provides information on item 1: serial drivers and boards for ISA, EISA, MCA, Hewlett-Packard (HP) and 3Com computers, Digiboards, AST 4 port boards, and X.25 configurations. Part 2 of this article provides information on items 2-6 below:

2. Modems

One or more modems.

All supported modems are listed in the RAS 1.1 MODEMS.INF file.

Unsupported modems may also work.

3.Serial Cable

External modems require properly wired serial cables.

4.LAN Manager

LAN Manager 2.1 or later with one protocol/network in addition to AsyBEUI. LAN Manager 2.1 or later must be installed with at least one network (for example, a loopback driver, or NetBEUI plus a MAC driver) in addition to the RAS AsyBEUI. This is because RAS 1.0 and 1.1 function as a gateway and expect another network to be present.

5.User-Level Security

RAS MUST have user-level security--it does not support share-level security.

6.PDC, BDC, Member Server or Standalone Status

A RAS server can be configured as a primary or backup domain controller, a member-server, or a standalone.

Note

For details on topics other than SERIAL PORTS/DEVICE DRIVERS, refer to part 2 of this article, or query on the following words in the Microsoft Knowledge Base:

MORE INFORMATION

1. Serial Ports and OS/2 Serial Port Device Drivers

Under OS/2 1.3, serial ports cannot be accessed without serial device drivers. Each serial driver/COM-port combination has its own hardware requirements and limitations, so they are discussed separately below.

At least one serial port must be available and properly configured, but remember that COM ports have specific and sometimes unique OS/2 serial device driver requirements. Third party serial boards or proprietary built-in ports usually require their own device drivers.

For example: Digiboards require XALL.SYS.

You must install an OS/2 serial port device driver through the CONFIG.SYS file. Depending on the serial port hardware, you may also have to install proprietary device drivers.

Serial Port/Driver Combinations

1.1ISA and EISA (but not certain HP machines and 3COM 3Servers) machines

use COM01.SYS. COM01.SYS must be loaded in the CONFIG.SYS file. It supports ONLY serial ports COM1 and COM2 on ISA and EISA machines, NOT COM3 and COM4.

SERIAL 1 COM1: I/O Address = 3F8h IRQ = 4

SERIAL 2 COM2: I/O Address = 2F8h IRQ = 3

Note

RAS requires that the serial port in use be configured as above. COM01.SYS does not perform a DosOpen call to the serial port until the serial port is actually used, so COM01.SYS loads during CONFIG.SYS time even if the port is misconfigured or there is an IRQ or I/O conflict between one of the COM ports and another device. For example: if a network card is configured for IRQ3, COM01.SYS loads but a system error “SYS 1620” occurs when a MODE COM2: command is issued.

Hewlett-Packard EISA machines: use COMHP01.SYS.

Note

Find out your HP model number--this may NOT apply to all models.

1.2COMHP01.SYS

supports COM1-COM4 with COM1 and COM2 configured as above, but you need to set up COM3 and COM4 with the following I/O addresses and IRQ settings:

SERIAL 3 COM3 I/O Address = 3E8h, IRQ = 10

SERIAL 4 COM4 I/O Address = 2E8h, IRQ = 11

These are discussed (as is COMHP01.SYS) in the README.TXT file in C:\OS2\SUPPORT.

1.3MCA machines

use COM02.SYS (COM01.SYS CANNOT be used): COM02.SYS must be used on Micro Channel machines and loaded in the CONFIG.SYS file. COM02.SYS supports serial ports COM1, COM2, and COM3. IRQ3 is shared by COM2 and COM3.

COM1: I/O Address = 3F8h IRQ = 4

COM2: I/O Address = 2F8h IRQ = 3

COM3: I/O Address = 2F8h, IRQ = 3

On Micro Channel machines, COM2-8 are shared at IRQ3, and I/O ports 2F8, 3220 (hex), 3228, 4220, 4228, 5220, and 5228. In OS/2 1.3, however, COM02.SYS can support only COM1-COM3.

Some add-in serial boards are supported so that you can get ports COM2 and/or COM3 on, for example, an IBM PS/2 Model 80. One supported add-in board is the IBM DUAL ASYNC adapter, which has two 9-pin serial ports built into it.

1.4Computers with Digiboards (Micro Channel, ISA, or EISA)

use XALL.SYS. For older products, use DGX.SYS.

The information in the rest of this section was verified in April 1993:

The OS/2 XALL.SYS device driver supports the entire line of Digichannel intelligent asynchronous serial communication controllers and must be loaded in the OS/2 Config.sys file. You can adjust its functionality with device line parameters.

The OS/2 DGX.SYS device driver supports older non-intelligent serial Digiboards such as the PC4 board, and is also configured with the help of device line parameters.

Note

Digiboard does NOT ship the XALL.SYS OS/2 driver with their hardware. You must order it by calling (612) 943-9020 or obtain itfrom their BBS at (612) 943-0812.

(Communication settings: N,8,1; baud 300, 1200, 2400, 9600; V.32, V.42 and V.42bis standards are supported.)

Note

On EISA bus machines with EISA Digiboards you must verify that the XALL.SYS parameter: /p:xxxx has a 4-digit I/O address, the first digit of which is the EISA Digiboard card's bus slot number. This first digit is often forgotten, which prevents the driver from loading properly.

1.5AST 4-port serial board: use COM01A.SYS

This board is NOT supported by Microsoft, but no problems have been reported with it and we provide this information as a convenience. The driver is available on the Microsoft BBS at (425) 936-MSDL in the LAN Manager area. Load it just as you would COM01.SYS. Microsoft has not tested this driver with OS/2 1.3 and therefore does NOT guarantee proper performance.

1.63COM 3Servers

3S400 servers: use COM01S.400

3S500 AND 3S600 servers: use COM01S.500

The CONFIG.SYS file loaded by the LAN Manager installation tape has the appropriate 3COM serial port driver already referenced but still REMarked out so that it does NOT allow the serial port to be used. To make it usable, simply remove the REM on that line, save the file, shutdown and reboot your server.

Note

On 3COM servers, only COM1 and COM3 are available--the COM2 port is reserved for the built-in Localtalk port. A 3Com RAS server can use only COM1 and COM3 unless a third party driver and serial port hardware (such as Digiboard) is installed to make COM ports above COM3 available.

COM01S.400 and COM01S.500 expect the serial ports to be configured as follows (these are the defaults):

COM1: I/O Address = 3F8h, IRQ = 4

COM3: I/O Address = 2F8h, IRQ = 3

Note

The 3Com upgrade toolkits for LAN Manager 2.1 and 2.2 contain a disk for installing RAS on 3servers. For 2.1, insert this disk once you start RemSetup (Remote Setup for 3 Servers--located in the LAN Manager directory on the 3server).

Follow the same procedure for the 3COM upgrade toolkit for LAN Manager 2.2, but when you install RAS, insert the disk labeled “Services for Macintosh Remote Installation for 3Server” — the labels for the RAS and the Macintosh services are mixed up.

Note

The “LAN Manager Installation and Configuration Guide” for 3Servers incorrectly assumes that a REMarked outline in the STARTUP.CMD file exists for the RAS. Please add the following line to the STARTUP.CMD file just below the group of similar lines.

Call c:\lanman\3startms.cmd remoteaccess remoteaccess

Note

If you configure RAS for more ports than are physically present (for example, you request a COM4 on a standard 3s500 system where only COM1 and COM3 exist) then the 3Server might hang when RAS is initialized. To cure such a problem, you must edit the STARTUP.CMD file and REMark out the RAS “Call” line. For information on how to do this, refer to the LAN Manager for 3Com servers documentation explaining the CONSOLE mode of 3Servers.

1.7 X.25 drivers and cards: use the vendor's X.25 card and driver

If your server is running RAS over an X.25 network, then in addition to the X.25 card driver RAS needs a COM01.SYS or other driver in order to function and recognize COM ports present on the server. For example: the X.25 card from Eicon, Inc. emulates a maximum of 13 COM ports (COM4- COM16) if there are three regular serial ports on the server already.

Note

If more than 13 COM ports are configured, the RAS service terminates upon startup with a TRAP D during NET START REMOTEACCESS. The number of COM ports configurable also depends on other programs running simultaneously and competing for the same resources needed by the Eicon driver software, so if software of this type is running, RAS probably has to be configured for fewer ports before it can start successfully. Start out with 9 or 10 ports configured and then work your way up towards 13.

Eicon software version 2 release 2 (v2r2) is out of date as of April 1993. Please upgrade to the latest version: version 3 release 1 (v3r1).

For support with the Eicon driver installation or to upgrade to the latest version, please contact Eicon Customer Support Services at (514) 631-2592 (EST).

For more information on debugging X.25 problems with RAS, refer to the RAS 1.1 Release Notes in the RAS retail package.

For details on RAS requirements other than serial ports and device drivers, please see “Part 2 (of 2)-- Troubleshooting RAS on an OS/2 1.x Server.”

REFERENCES

RAS 1.1 Release Notes

LAN Manager “Installation and Configuration Guide”

“Remote Access Administrator's Guide,” Chapter 4, System Requirements

Additional reference words: sfm 2.10 2.1 2.10a 2.1a 2.20 2.2

KBCategory: kbnetwork

KBSubcategory: rmt

Part 2 (of 2)--Troubleshooting RAS on an OS/2 1.x Server [lanman]

ID: Q98517 CREATED: 06-MAY-1993 MODIFIED: 30-SEP-1994

2.10 2.20

MS-DOS

PUBLIC | kbnetwork

The information in this article applies to:

Microsoft LAN Manager versions 2.1, 2.1a, and 2.2

Microsoft Remote Access Service versions 1.0 and 1.1

Summary:

This is part 2 of a two-part article meant to supplement (not replace) information provided in the Remote Access Administrator's Guide, Chapter 4, “System Requirements.” It will help you troubleshoot problems by verifying that basic requirements are met.

To ensure proper operation of RAS 1.0 or 1.1 on an OS/2 1.21 or 1.3 server (OS/2 2.0 is currently not supported at all) verify that the following elements are present — preferably BEFORE running the RAS Setup program:

1.Serial Ports/Device Drivers

One or more serial ports.

One or more OS/2 serial port device drivers.

Part 1 (a separate article) provides information on item 1: serial drivers and boards for ISA, EISA, MCA, HP and 3Com computers, Digiboards, AST 4 port boards, and X.25 configurations.

Part 2 (the rest of this article) provides information on the next five required items:

2.Modems

One or more modems.

All supported modems are listed in the RAS 1.1 MODEMS.INF file.

Unsupported modems may also work.

3. Serial Cable

External modems require properly wired serial cables.

4. LAN Manager

LAN Manager 2.1 or later with one protocol/network in addition to AsyBEUI. LAN Manager 2.1 or later must be installed with at least one network (for example: a loopback driver, or NetBEUI and a MAC driver) in addition to the RAS AsyBEUI. This is because RAS 1.0 and 1.1 function as gateways and expect another network to be present.

5. User-Level Security

RAS MUST have user-level security--it does not support share-level security.

6. PDC, BDC, Member Server or Standalone Status

A RAS server can be configured as a primary or backup domain controller, a member-server, or a standalone.

Note

For details on Serial Ports/Device Drivers, refer to part 1 of this article, or query on the following words in the Microsoft Knowledge Base:

Part 1 (of 2)--Troubleshooting RAS on an OS/2 1.x Server

MORE INFORMATION

1.Modems

At least one modem must be available. RAS can use internal and external modems. Microsoft supports all modems listed in the RAS 1.1 MODEMS.INF file at a baud rate not to exceed the rate listed with the “MAXBAUD=“ parameter in each modem's section. The MODEMS.INF file is the current listing.

An unsupported modem MAY work if you:

Click a supported modem in RAS Setup that is emulated by the unsupported modem.

– Or –

Create its own MODEMS.INF file section containing the proper commands.

To do this, refer to these sources:

RAS 1.1 README.TXT file section “Using Non-Supported Modems” and “Modem Initialization String.”

“RAS Administrator's Guide” Appendix A, under “Adding a New Modem to MODEMS.INF.”

The modem manufacturer's modem manual (for the correct codes for the “COMMAND=“ line in the MODEMS.INF file).

Note

A Modem does not have to be hooked up to a serial port in order for the “NET START REMOTEACCESS” server service to load. Also the RASADMIN utility starts properly (if everything else is set up correctly) and shows the RAS server as running. However, if you access the COM port status screen through the RASADMIN “Server” menu, by selecting “Communication Ports” and then “Port Status,” you will see these text strings:

During Initialization:

Line condition: “Initializing modem”

Modem condition: “Unknown”

Unknown/No modem:

Line condition: “Line non-operational

Modem condition: “Modem not responding”

“Hardware failure”

“Hardware failure” means that the modem failed for some reason after a “No Errors” condition. Turning the modem off could also cause this condition.

RAS recognized the modem's response:

Line condition: “Waiting for Call”

Modem condition: “No Errors”

2.Serial Cable

External modems require properly wired serial cables. For wiring diagrams, see the RAS 1.0 manual, Appendix A, pages 80, 81, or the RAS 1.1 manual, Appendix A, pages 92 and 93.

Note

Serial mouse adapter cables are usually NOT wired correctly formodem communication purposes and should not be used.

3.LAN MANAGER

LAN Manager 2.1 (or later) with one protocol/network in addition to AsyBEUI.

If the loopback driver is not used, RAS requires that you install a network adapter card that uses a Certified Network Driver Interface Specification (NDIS) driver in addition to NetBEUI (or other protocol).

4.User-Level Security

User-level security is essential, because RAS relies on the User Accounts Subsystem database for keeping track of user names, passwords, and RAS permissions. Even so, users who are logged on to a RAS server can access LAN resources that have share-level security. For more information see the “RAS Administrator's Guide,” Chapter 2, “User-level Security.”

5.RAS Server Configured as PDC, BDC, Member Server, or Standalone:

If the RAS server is supposed to be separate from other domains or simply a non-networked machine, the easiest choice is primary domain controller.” (See LAN Manager 2.1 Administrator's Guide, Chapter 4, page 62: “Changing a Server's Role”).

Note

“Error 67” when starting RASADMIN on a standalone server.

Even if the server is configured as “standalone,” RASADMIN first tries to verify your administrator privilege by finding a primary domain controller with the domain name specified in the “domain = “ line of the LANMAN.INI [workstation] section. Most standalone configurations have no valid domain with that name and RAS issues the message:

Error 67: This network name cannot be found.

If LANMAN.INI specifies a valid domain name where you also have an administrator account with the same password as in your standalone RAS server's user accounts database, RASADMIN starts, but it focuses on the other machine instead of the local standalone server. However, depending on the circumstances, RASADMIN issues other errors such as:

Error 2320: The computer isn't active on this domain

– Or –

Error 5: Insufficient privilege

If you receive these errors, click OK, then type in the dialog box the standalone RAS server's computer name as it appears in the LANMAN.INI [workstation] section (for example: computername=rasserver) preceded by two backslashes:

\\rasserver (then press ENTER)

The RAS server service should now be properly installed.

Note

In LAN Manager 2.1a and later, the hardcoded domain name “standalone” allows users to log on faster if validation by a domain controller is bypassed. RASADMIN of RAS version 1.x is not aware of this feature and still responds with the errors shown above even if “domain = standalone” is specified in LANMAN.INI.

REFERENCES

RAS 1.1 Release Notes

LAN Manager “Installation and Configuration Guide”

LAN Manager 2.1 “Administrator's Guide,” “Changing a Server's Role,” page 62

Remote Access “Administrator's Guide,” Appendix A, “Adding a New Modem to MODEMS.INF”; Chapter 2, “User-level Security”

RAS 1.0 manual, Appendix A, pages 80, 81

RAS 1.1 manual, Appendix A, pages 92, 93

KBCategory: kbnetwork

KBSubcategory:

Additional reference words: 2.10 2.10a 2.20

Legal Disclaimers

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

The third-party products discussed here are manufactured by vendors independent of Microsoft; we make no warranty, implied or otherwise, regarding these products' performance or reliability.

The third-party contact information included in this article is provided to help you find the technical support you need. This contact information is subject to change without notice. Microsoft in no way guarantees the accuracy of this third-party contact information.

THESE MATERIALS ARE PROVIDED “AS-IS,” FOR INFORMATIONAL PURPOSES ONLY.

NEITHER MICROSOFT NOR ITS SUPPLIERS MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU.

NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL, INCIDENTAL, DIRECT, INDIRECT, SPECIAL, AND LOSS OF PROFITS. BECAUSE SOME STATES/JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT’S AND ITS SUPPLIERS’ ENTIRE LIABILITY IN ANY MANNER ARISING OUT OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE, SHALL NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.