Creating Scripts for RAS

The SWITCH.INF file is like a set of small batch files (scripts) contained in one file. The SWITCH.INF file can contain a different script for each intermediary device or online service that the RAS user will call.

A SWITCH.INF script has six elements: a section header, comments, commands, responses, response keywords, and macros.

Section Headers

Section headers divide the SWITCH.INF file into individual scripts. A section header marks the beginning of a script for a certain remote computer and must not exceed 31 characters. The text of a section header will appear in RAS when you activate the script. The section header is enclosed in square brackets. For example:


[Route 66 Logon]

Comment Lines

Comment lines must have a semicolon (;) in column one and can appear anywhere in the file. Comment lines contain information for those who maintain the SWITCH.INF file. For example:


; This script was created by MariaG on September 29, 1996

Commands

Each line in a script is a command from your local computer to the remote computer or a response from the remote computer to your local computer. Each command or response is a stream of data or text. For example, this command sends a username (MariaG) and a carriage return (the macro <cr>) to the remote computer.

COMMAND=MariaG<cr>

The commands and responses must be in the exact order in which the remote device expects them. Branching statements, such as GOTO or IF, are not supported.

The required sequence of commands and responses for a specific remote device should be in the documentation for the device, or, if you are connecting to a commercial service, from the support staff of that service. If the exact sequence is not available, activate the generic script provided with RAS and modify it to match the logon sequence of the remote computer as described in the section "Troubleshooting Scripts Using DEVICE.LOG," later in this chapter.

The COMMAND= statement can be used in two additional ways:


COMMAND= 
NoResponse

This is the default behavior and causes an approximate two-second delay. This can be useful when the intermediate device requires a delay.


COMMAND= string

Note

string is not followed by a carriage return (<cr>). This is useful when a device requires slow input. Instead of receiving the whole command string, the device requires characters to be sent one-by-one.

The following is an example where the intermediary device is so slow that it is only able to receive and process one character of the command PPP at a time.


COMMAND=P
NoResponse

COMMAND=P
NoResponse

COMMAND=P
NoResponse

Responses

A response is sent from the remote device or computer. To write an automatic script, you must know the responses you will receive from the remote device. If there is a gap of two or more seconds between characters, the received text is sent as a response. This gap is the only cue that a response is over. For more information, see the following section, "Getting Through Large Blocks of Text and Two-Second Gaps" later in this chapter.

Response Keywords

The keyword in a response line specifies what to do with the responses you receive from the remote computer:

OK=remote computer response<macro>

The script continues to the next line if the response or macro is encountered.

LOOP=remote computer response<macro>

The script returns to the previous line if the response or macro is encountered.

CONNECT=remote computer response <macro>

Used at the end of a successful modem script. Not generally useful for the SWITCH.INF file.

ERROR= remote computer response <macro>

Causes RAS to display a generic error message if the response is encountered. Useful for notifying the RAS user when the remote computer reports a specific error.

ERROR_DIAGNOSTICS= remote computer response <diagnostics>

Causes RAS to display the specific cause for an error returned by the device. Not all devices report specific errors. Use ERROR= if your device does not return specific errors that can be identified with Microsoft RAS diagnostics.

NoResponse

Used when no response will come from the remote device.

RAS on the local computer always expects a response from the remote device and will wait 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 will execute and stop the script at that point.

Macros

Macros are enclosed in angle brackets (< >). Macros perform the following special functions.

<cr>

Inserts a carriage return.

<lf>

Inserts a line feed.

<match> "string"

Reports a match if the string enclosed in quotation marks is found in the device response. Each character in the string is matched according to uppercase and lowercase. For example, <match> "Smith" matches Jane Smith and John Smith III, but not SMITH.

<?>

Inserts a wildcard character, for example, CO<?><?>2 matches COOL2 or COAT2, but not COOL3.

<hXX> (XX are hexadecimal digits)

Allows any hexadecimal character to appear in a string including the zero byte, <h00>.

<ignore>

Ignores the rest of a response from the macro on.

<diagnostics>

Passes specific error information from a device to RAS. This enables RAS to display the specific error to RAS users. Otherwise, a nonspecific error message appears.

New Macros in Windows NT 3.51

The following two macros enable your username and password logon credentials to be automatically passed to the remote computer.

<username>

The username entered in the RAS Authentication window is sent to the remote computer. This is not supported with SLIP connections.

<password>

The password entered in the RAS Authentication window is sent to the remote computer. This is not supported with SLIP connections.

If both of the following situations are true, a Retry Authentication dialog box appears with a message that your logon credentials have failed

1. You are calling into a system with an intermediary security device. This situation would generally not apply if you are using RAS to call an Internet provider.

2. After the security device has logged you on successfully, you are attempting to log on to a Windows NT RAS server.

The reason this message appears is that the RAS Authentication dialog box username and password boxes are used by the two new username and password macros as well as by Windows NT RAS servers.

For example, if the logon information for an intermediary security device that is plugged in between the Windows NT RAS server and its modem is username: "BB318" and password: "34554377", but on the Windows NT RAS server it is username: "BB318" and password: "treehouse", then your logon to the intermediary device will succeed, but your logon to the Windows NT RAS server will fail.

Logon will fail because the security device password of "34554377" is different from the Windows NT domain password. Windows NT will prompt you with the Retry Authentication dialog box to obtain your proper Windows NT logon credentials, in this case the password.

To eliminate the Retry Authentication dialog box, you have the following options

1. Ask your administrator to make your username and password identical on both systems, although this is not advisable because it would defeat the purpose of the security device.

2. Do not use the shared dialog box for the intermediary device logon credentials by entering the username and password in clear text into the SWITCH.INF file according to the [Generic login for YourLoginHere] script provided in SWITCH.INF. In order to keep your clear-text password confidential you need to use Windows NT file system (NTFS) file permissions to prevent other users from accessing this file.

Stepping Through an Example Script

This section describes each part of the generic script provided in the SWITCH.INF file included with RAS.

Every script must start with a command to the remote computer followed by one or more response lines. This initial command often may be simply to wait for the remote computer to initialize and send its logon banner. The default initial command is to wait two seconds for the logon banner. It would look like this in the SWITCH.INF file:

COMMAND=

If the response, (the logon banner from the remote computer) is the following:


Welcome to Gibraltar Net. Please enter your login:

then the corresponding response line in the SWITCH.INF file should be:

OK=<match>"Please enter your login:"

This line indicates that everything is correct if the remote computer sends the string "Please enter your login:". You respond by sending a command with the characters in your username and the carriage return.

COMMAND=MariaG<cr>

If the response from the remote computer is the following:


Please enter your password:

then the corresponding response line in the SWITCH.INF file should be:

OK=<match>"Please enter your password:"

To send your password, you would send the command:

COMMAND=mUs3naB<cr>

On many PPP computers, this script would automatically log you on.

Automating Log On to SLIP Computers

On SLIP systems you are also required to enter an IP address, so even though you can automate much of the logon sequence, you must manually enter your IP address in the SLIP terminal window. A permanent IP address may be provided to you in advance, or the SLIP Login Terminal window may provide a different IP Address each time you log on. This is an example of why PPP connections are usually easier to use.

However, it is possible to fully automate connections to a SLIP provider using the command-line utility RASDIAL.EXE, but only if all of the following conditions are true:

If any of the above conditions are not true, you cannot use the RASDIAL.EXE utility to connect to your SLIP provider because your IP address will not get set correctly.

Note

RASDIAL.EXE is in your systemroot\SYSTEM32 directory. The automatic redial upon link failure feature, which is present in the Remote Access program (RASPHONE.EXE), is not part of RASDIAL.EXE. For help on RASDIAL.EXE, type RASDIAL /? at a Windows NT command prompt.

Getting Through Large Blocks of Text and Two-Second Gaps

If the remote computer has a two-second gap in the data stream reponse to your computer, RAS assumes that the gap is the end of the response. These gaps may occur anywhere, including between words, and can only be detected using DEVICE.LOG. For more information, see the "Troubleshooting Scripts Using DEVICE.LOG" section later in this chapter.

If you write a script that seems to fail for no reason, consult DEVICE.LOG to see if a response ends in the middle of a word. If so, your script must account for the two-second gap. A simple way to do this is to include the command:

COMMAND=<cr>

You can skip to the end of large blocks of text that contain multiple gaps by using the LOOP= keyword and by matching text at the end of a block. For example,

COMMAND=<cr>
OK=<match>"Enter the service to start:"
LOOP=<ignore>

In this example, RAS sends a null command (waits two seconds), RAS then waits for the message "Enter the service to start:". If this is a long block of text, RAS does not find the string so RAS then moves to the LOOP command. The LOOP command causes RAS to return to the line above, and RAS waits for the words "Enter the service to start:" in the second response. In this manner, you can loop though long blocks of text until you reach the text of the desired prompt.

Commands and Carriage Returns

Usually, you must include <cr>, which indicates a carriage return, at the end of a command. The carriage return causes the remote computer to process the command immediately. If you do not include <cr>, the remote computer may not recognize the command.

In other situations, <cr> cannot be used because the remote computer accepts the command without a carriage return and requires time to process the command. This situation mainly applies when you are sending a series of commands without expecting a response.