Networking Personal Computers with TCP/IP By Craig Hunt 1st Edition July 1995 1-56592-123-2, Order Number: 1232 408 pages, $32.95

Creating Login Scripts

The login sequence of the remote PPP server can be automated with a script. Windows 95 provides an optional scripting tool for just that purpose. To run the scripting tool go to the Start menu and select Programs, Accessories and then Dial-Up Scripting Tool. Don't panic if you don't find it there. It is provided on the Windows 95 CDROM, but it is not installed as part of the standard installation. See the sidebar Scripting and SLIPing for instructions on how to install this tool.

When the scripting tool starts, it opens a window similar to the one shown in Figure 6-20. All connection profiles previously defined with either the Internet Setup Wizard or the New Connection applet are listed in the Connection listbox on the left hand side of the window. Highlight the connection for which you are creating the script. In Figure 6-20 we have highlighted the Main Office connection.

Figure 6-20: Dial-Up Scripting Tool

The first step in building a login script is to create a script file. The script file is an ASCII file that can be created with any text editor. Click the Edit button in the Dial-Up Scripting Tool to open Notepad, and use it to type in the script commands. The script is constructed from the commands shown in Table 6-1.

Script Language Commands
Script Command	Function
proc name	Begin the script
endproc	End the script
waitfor "string"	Wait for string
transmit value	Send value
delay n	Pause n seconds
set port characteristic	Modify the port configuration
set ipaddr getid value	Get the local IP address from the server
set screen keyboard on|off	Enable or disable keyboard input to the script
halt	Stop the script

Five of the commands in Table 6-1 are used to build most login scripts. These are the proc, endproc, waitfor, transmit and delay commands. A sample script using these basic commands is shown below:

; Begin the script
proc main

; Pause two seconds to let the remote system
; initialize.
delay 2

; The remote system requires a carriage-return, so
; send one.
transmit "<cr>"

; Wait for the "Username:" prompt.
waitfor "name:"

; Send the username and a carriage-return.
transmit $USERID
transmit "<cr>"

; Wait for the "Password:" prompt.
waitfor "word:"

; Send the password and a carriage-return.
transmit $PASSWORD
transmit "<cr>"

; The server's command mode prompt is <.
; Wait for the prompt.
waitfor "\<"

; Send the PPP command required by this server.
transmit "enable ppp<cr>"

; End the script
endproc

Every script starts with a proc main statement and ends with an endproc statement. The proc/endproc statement pair is required by the syntax of the Windows 95 script language. The proc statement marks the beginning of the script and the endproc statement marks its end. Remember to start and end all scripts with these statements.

The delay command causes the script to wait the number of seconds specified on the command line. In the example the script waits for two seconds. A delay statement is frequently used at the beginning of the script or when the script must send data without receiving a prompt from the remote system. In both cases the delay is used to give the remote server time to complete its processing to ensure that it is ready to receive input. Sometimes delay statements are required to get a script running smoothly.

The bulk of the sample script is composed of waitfor and transmit statements. These statements are the heart of most scripts. The transmit statement sends a value to the remote system and the waitfor statement waits until a specific value is received from the remote system. The value on a waitfor command line is a string constructed of literal characters and special script language macros. Table 6-2 lists the string macros.

String Macros
String Macro	Function
<cr>	A carriage return
<lf>	A line feed
\"	A literal quote mark (")
\^	A literal caret (^)
\<	A literal less than (<)
\\	A literal backslash (\)
^char	A control character

The value on the transmit command line is either a string composed of literal characters and the macros shown in Table 6-2, or a keyword. Two keywords are used with the transmit command: $USERID and $PASSWORD. $USERID sends the username and $PASSWORD sends the password that were entered in the Connect To window. The keywords allow the login to be stored in a script without revealing the password in plain text, as would be done if the password was stored in the script as a literal. The sample script shows examples of using both of these keywords.

The first transmit command in the sample script sends a carriage-return to our imaginary PPP server. A carriage-return, which is a control-M on a standard PC keyboard, can also be sent with the following command:

transmit "^M"

Any control character, the line-feed (control-J), the bell (control-G), the null (control-@), or any other valid ASCII control character, can be sent in this way. Personally I prefer using <cr> for the carriage-return and <lf> for the line-feed because I think the meaning is clearer to someone reading the script. But if you need to send any other control characters from the 7-bit US ASCII character set, use the ^char syntax.

The other entries in Table 6-2 are escape sequences. The scripting language uses the backslash as the escape character. A few characters, quote ("), less-than (<), and caret (^), have special meaning when constructing strings for the script. A backslash preceding any one of those characters indicates that the character's literal meaning should be used instead of its special meaning. Therefor, the string "\<" in the last waitfor command in the sample script means that the system should wait until it receives a literal < (less-than) character.

The commonly used commands are all shown in the sample script. The other commands in Table 6-1 are rarely used but they are nice to have when you needed them. Most of the remaining commands start with the keyword set and are used to set the characteristics of a specific login session. The set port command takes the largest variety of variables. The port characteristics set by this command are the number of databit, the number of stop bits and the parity. The command's complete syntax is shown below:

set port databits value

Sets the number of databits for this port to the value, e.g. set port databits 7 sets the port for 7 bit data. value must be an integer from 5 through 8.

set port stopbits 1 | 2

Sets the number of stopbits to 1 bit or 2 bits.

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

Sets parity checking for this port to none, even, odd, mark or space.

You probably recall that the description of Figure 6-17 states that databits should always be 8 and parity should always be none for a PPP or SLIP connection. That's true. So why should we have commands for changing databits and parity if they must always be certain known values? The reason is that it is possible to connect to a multi-purpose terminal server that supports other protocols in addition to PPP and that does not use 8/none as its default setting. You will then need to set the parity and databits to values compatible with the remote server's defaults in order to do the login, and then set databits and parity back to 8/none in order to run PPP. A good example of this is provided with the Dial-Up Scripting Tool. The sample is in the file CIS located in the \PROGRAM FILES\ACCESSORIES directory.

The other two set commands do not set port characteristics. One sets the IP address and the other enables keyboard input. The set ipaddr command dynamically configures the IP address from data transmitted from the remote server, and it is only used for SLIP connections. The command is not used for PPP or to set a static IP address. Let me explain.

PPP has, built into the protocol, a standard facility that the server can use to provide the client with an IP address. SLIP is a very simple protocol. It has no such facility. To get around this limitation, some servers display the IP address as part of the login sequence. If the client has the proper software, it can capture the address and use it. To capture the address in a Windows 95 script use the command:

set ipaddr getid

This assumes that only one IP address is transmitted. Some servers display the server's address and the client's address. If the client's address is the second of two IP addresses in the data stream, add the number 2 to the command as follows:

set ipaddr getid 2

The set ipaddr command only works if the remote SLIP server is designed to provide the address. Most SLIP connections are configured with static IP addresses. This set command is rarely used.

The last set command is set keyboard on. This allows the user to "take over" the login process and provide input from the keyboard. Avoid keyboard input in the script. The reason for creating a script is to automate the login process and manual input runs counter to that purpose. However, you may find some conditions that require keyboard input. If you do, this command is available for that purpose.

The final command in Table 6-1 is the halt command. It terminates the script when you want to stop the script immediately, for example when an error condition occurs. A script normally terminates when it reaches the endproc command.

Using the commands from Table 6-1, you should be able to build a login script for any server. Write down every step you take to manually log in to the remote server--every prompt you see and every response you enter. Convert the system prompts into waitfor statements and the responses into transmit commands. Store these in the script file. Save the script file in the C:\PROGRAM FILES\ACCESSORIES directory and give it a file name that ends with a .SCP extension. For example, the file containing the script to log in to your office might be named MAINOFFICE.SCP. These naming conventions are not absolute requirements. A script can be named anything and placed anywhere on the system, but following these naming conventions makes it a little easier to invoke the script with the scripting tool.

Invoking a Login Script

To use the new script, link it to the correct connection profile and eliminate any conflict between the script and the terminal window used for manual logins. Use the Dial-Up Scripting Tool to do both of these things.

To link the new script to the connection profile, highlight the name of the connection in the Connections listbox and click the Browse button found in the Script section of the Dial-Up Scripting Tool window (Figure 6-20). The Browse window shown in Figure 6-21 opens. The Browse window lists the various scripts available on the PC. Notice that there are a few that you didn't write. These are sample scripts provided with the Dial-Up Scripting Tool. Highlight the name of your script in the listbox and the name appears in the File name box. Then click the Open button. You return to the Dial-Up Scripting Tool window. Click the Apply button to link the script to the connection profile.

Figure 6-21: Browsing for Dial-up Scripts

Next, make sure that there is no conflict between the new script and the manual login window. Click the Properties button found directly under the Connections listbox (see Figure 6-20). This opens the window shown in Figure 6-22 that lets you modify the properties of the connection. (We'll see this window again later when we install SLIP. For now, we use this window to turn off the manual login terminal window.)

Figure 6-22: Connection Properties

Click on the Configure button in the Connect using section of the window. The modem properties window shown in Figure 6-11 appears. This is the same window used earlier to select the login terminal window. Now we reverse the process to "unselect" that option. The modem properties window has three tabs. Select the Options tab. At the top of this tab is a section labeled Connection control. Make sure that there are no check marks in this section. If either Bring up terminal window before dialing or Bring up terminal window after dialing is checked, remove the check mark. Click OK until the Dial-Up Scripting Tool window shown in Figure 6-20 re-appears. Now you're ready to run.

Open the Dial-Up Networking folder and double-click on the connection's icon. The script automatically starts and logs the PC in to the remote server.

The first few times you run the script leave the Dial-Up Scripting Tool window open to make any changes necessary to debug the script. Check the Step through script box to help you debug it. Selecting this option opens the Automated Script Test window shown in Figure 6-23 that lets you single step through each line of the script. The line of the script pointed to by the -> indicator executes after you click the Step button. Step through each line of the script and watch the results in the terminal window that is also opened by the login script. If the script executes successfully, click the Continue button in the terminal window to complete the connection. Test the connection a few times.

Figure 6-23: Testing a Script

If the script does not run correctly, make a note of exactly where it fails. Terminate the script's execution by clicking the Cancel button in the terminal window. Return to the Dial-Up Scripting Tool window, click the Edit button and use Notepad to correct and save the script. Re-run the test by again double-clicking on the connection's icon. Repeat this "test and edit" process until each error is removed from the script, one at a time. When the script is error free, "uncheck" the Step through script box, check the Start terminal screen minimized box, and Apply the changes. Now simply double-clicking the connection icon in the Dial-Up Networking folder will bring up the PPP connection. Figure 6-23 shows all of these windows.

The AutoDial Feature

Some Windows 95 TCP/IP applications can automatically startup a dial-up network connection. The FTP application and the Telnet application described in Windows 95 Network Applications section of this chapter are both able to do this. If a network connection is not available when the application starts, the application runs a connection profile to create the connection. This feature is only available when the Internet Setup Wizard is installed. Instructions on how to install the wizard are found in Installing TCP/IP with the Internet Setup Wizard.

Enable the auto-dial feature by running the Internet applet from the Control Panel, and clicking Use AutoDial in the Internet Properties window, which is shown in Figure 6-24. Select a connection profile to use for auto-dialing. (In the figure, the profile named Main Office is selected.) If you want to create a new connection profile specifically for auto-dialing, click the New Connection button to invoke the New Connection wizard and then click the Properties button to configure that new connection. I recommend against creating a new connection profile at this time. Use an existing connection profile that you already know works. It is a bad idea to debug a new connection profile and auto-dialing at the same time.

Figure 6-24: Enabling the AutoDial Feature

Use the Auto disconnect option only if you want the system to automatically terminate the connection after a specified period of inactivity. This feature is useful for toll calls, connections to fee based services or any time you pay by the minute for the dial-up connection. Auto disconnect is also useful for forgetful people who sometimes leave the connection up when it is no longer needed.

The Perform security check before dialing option is for NetBIOS file and printer sharing. It warns the user about files that may be vulnerable to unauthorized access through the dial-up connection. This only applies when the PC is configured to allow remote systems to access its files using Microsoft Network software. This option does not apply to pure TCP/IP networks.

The Advanced tab of the Internet Properties window has nothing to do with auto-dialing. Use the Advanced tab to identify the proxy server for this PC. A proxy server provides connections across a firewall, so this option is only applicable to a PC that is connected to a LAN that is protected by a firewall and that also offers proxy servers. See Building Internet Firewalls, O'Reilly & Associates, for more information on proxy servers.

Problems and Complications

There are always problems with networked systems and dial-up networking seems particularly prone to problems. The problems with Windows 95 dial-up networking mainly fall in three areas: confusing instructions, unknown dependencies, and weird interactions. The installation instructions are often confusing because the interface is very visual, and therefor difficult to describe in a few words, and because there are often many ways to do the same thing. For example: the Properties button in the Internet Properties window, the Properties button in the Dial-Up Scripting Tool, and the Properties selection in the File menu of the Dial-Up Networking window all open the same configuration window. Instructions from different people on how to open this window will specify different techniques. Don't let it confuse you. Find a technique you like and stick with it.

An example of an unknown interaction is the problem many people report of not being able to save the password for a dial-up connection. Look at Figure 6-12. You can clearly see the Save password checkbox. On some PCs this checkbox is "greyed-out", because the user of the PC did not logon to Windows 95. Either the user clicked the Cancel button in the Welcome to Windows login box or the user was never prompted by the login box. If a user reports to you that he cannot save his PPP password:

1. Shutdown and restart Windows 95.
2. Make sure the user enters his username and password in the Welcome to Windows box, and then clicks OK. Caution the user not to select Cancel in this window.
3. If the Welcome to Windows box is not displayed, run Passwords from the Control Panel. On the User Profiles tab of the Passwords Properties window, check Users can customize their preferences. Restart the computer and provide a Windows username and password when prompted. Now things should work right.

The weird interactions that can occur between different pieces of network software are the most difficult to figure out. One problem that affects PPP appears when a new version of the Microsoft Internet Explorer is installed after the connection profiles for the system have already been defined. Remember, the Explorer package includes the Internet browser, the Internet Setup Wizard, and the Internet mail extensions for Exchange. When new versions of these products are installed on the system everything may appear to work fine until you decide to write a new script and attach it to an existing profile. The Dial-Up Scripting Tool appears to run correctly, but the script never executes. Re-installing the Dial-Up Scripting Tool after installing a new version of the Internet Explorer avoids this problem.

---

 

Back to: Networking Personal Computers with TCP/IP