Search the Catalog
Using & Managing PPP

Using & Managing PPP

By Andrew Sun
1st Edition March 1999
1-56592-321-9, Order Number: 3219
444 pages, $32.95

Sample Chapter 6:

Dial-out PPP Setup

In this chapter:
PPP Sign-on Procedures
General PPP Setup Steps
Linux PPP-2.3
Solaris PPP
Windows 3.1
Windows 98 (and 95)
Windows NT 4.0 Workstation

Computer users most commonly use PPP to dial out and connect to either the Internet or a corporate private network. The relationship between users and the network they're accessing appears in Figure 6-1. From their point of view, PPP is present only on the physical serial link that connects them to a greater network. Typical dial-out PPP arrangements support standalone PCs only. In other words, we assume users don't have networks of their own that share a PPP connection.

Figure 6-1. Dial-out PPP

 

As a network administrator or ISP, you must supply instructions for dial-out users to successfully configure their PPP software for network access. One method is to supply users with software that automatically sets up their PPP. This doesn't avoid dial-out PPP configuration tasks, but merely shifts this responsibility from users to you. Major ISPs frequently prepare and distribute free sign-up software for popular computer equipment (e.g., IBM PC-compatible) and operating system (e.g., Microsoft) combinations.

Unfortunately, PPP setup software isn't always available or appropriate for all users. As long as you offer service with PPP, authorized users with equipment that supports PPP can successfully connect. However, users who can't use some sort of automated setup software must manually configure their own PPP software. Although PPP is well standardized, its many implementations vary widely. Thus, the purpose of this chapter is to describe to you and your users how to manually configure dial-out PPP with several popular, but diverse, PPP implementations.

This chapter limits its discussion to standalone computers dialing out. PPP also supports entire networks that wish to dial-out. But this requires additional configuration work with network layer forwarding and routing, which later chapters expand on.

PPP Sign-on Procedures

Dialing out and signing-on with PPP requires users to have basic service information. Users can then arrange their computers to issue interactive command strings through its serial port, which controls and prepares communications equipment (e.g., modem, remote communication server, etc.) for PPP.

Gathering Service Information

For Internet access or other TCP/IP network access, it's the responsibility of network administrators to provide the following:

The answers to these questions can determine the PPP software choices available to dial-out users. One common constraint is PPP authentication. Those PPP software products limited to PAP (see Chapter 12, Authentication), for example, are incompatible with services requiring CHAP. It's unfortunate that some Internet providers configure their PPP service to require proprietary PPP features. This is a disservice to users, since it severely limits the computers and software combinations they can choose for dial-out. Some users may switch to other ISPs as a result.

Another problem with some Internet providers are network administrators who are unable to provide the information users need to configure their software. This situation usually arises when the ISP depends too much on some automated setup software and doesn't understand the issues faced by users of different packages. Although it's a great inconvenience, sophisticated users can still install the setup software on a computer they don't wish to use, register, locate the files containing the configuration data, and use the data in those files to do their own configuration. Needless to say, a user who goes through this process doesn't end up feeling that his ISP is helpful, or even competent.

Dial-out Commands to Initiate PPP

When PPP software dials out via a telephone line, the commands it issues and the responses it receives typically look like Figure 6-2.

Figure 6-2. Initiating a PPP session

 

In Figure 6-2, we assume that you have set up a dial-in modem pool with a communication server. This server prompts for the user's name, password, and a ppp command.

After PPP starts, we assume the following:

This configuration encompasses the cases most dial-out PPP users encounter. Thus, the software configuration examples in this chapter assume that you're trying to establish a configuration like this one.

In practice, users should need to authenticate only once. If a communications server already asked for a password, there's no reason for it to require authentication again after beginning PPP communications. Many ISPs can also automatically detect PPP traffic from users. This eliminates the need for the remote communication server interaction phase shown in Figure 6-2.

General PPP Setup Steps

Dial-out PPP setup generally begins with computer hardware, PPP software, and other related software (e.g., operating system components) installation on a user's computer.

After obtaining all software components, you should configure communications layer by layer, from the bottom up:

  1. Configure serial interfaces.
  2. Establish modem settings and determine modem commands. If a user's computer doesn't have its modem's profile, users must determine the cryptic strings to set and control the modem.
  3. Develop chat scripts, if necessary. Chat scripts may first converse with a modem to dial-out, then converse with a remote server to initiate PPP. This conversation may include user authentication, if required.
  4. Configure PPP. This step may also include arranging authentication within PPP.
  5. Configure TCP/IP. This includes IP addresses and routing.
  6. Establish, test, and use the connection.

These steps may all be rolled into the setup procedure for a single PPP software product, depending on its implementation. However, it's more likely that users must set up several interdependent software items. As an example, TCP/IP, serial communications, and PPP may all be separate items.

Linux PPP-2.3

PPP-2.3 is available on the Internet ( ftp://cs.anu.edu.au/ and others) in the form of C source code for a variety of Unix systems. At this writing, Paul Mackerras at Australian National University currently maintains this software distribution.

PPP-2.3 is very thorough in features, configuration flexibility, and the number of adjustable options. In addition, its frame-logging ability provides extensive information useful for debugging. The software is compatible with numerous Unix platforms, including Linux, Solaris, NetBSD, FreeBSD, NeXTStep, and others. PPP-2.3 for Linux, in particular, also features IPX/SPX networking, in addition to the usual TCP/IP networking support.

Here, we install PPP-2.3 on Slackware 3.4 Linux and configure it according to the assumptions in the previous section, "PPP Sign-on Procedures." We configure PPP-2.3 manually, which requires users to edit several text files.

PPP-2.3 setup frequently challenges new Linux users. As a result, Linux developers are creating graphical user interface and menu-driven PPP management utilities to assist such users. The following utilities may help with software installation and automate PPP-2.3 configuration:

Additional information about these utilities are available at numerous Linux Internet sites, under the heading "Linux Applications and Utilities." Downloads are available from Linux distribution sites, such as sunsite.unc.edu. Beware that installing the source code version of these utilities could be as complex as manually configuring PPP-2.3.

Installation

The PPP-2.3 distribution is a GNU gzipped tar file, such as ppp-2.3.5.tar.gz. Since PPP-2.3 requires Linux kernel support, users must also install the Linux kernel source code, typically in /usr/src/linux, in order to build a revised kernel.

The first step is unpacking the PPP-2.3 distribution into a directory. The Linux source directory, such as /usr/src, is one suggested destination to place these files:

root# pwd
/usr/src
root# gunzip -c ppp-2.3.5.tar.gz | tar xf -
root# cd ppp-2.3.5
root# ls -F
FAQ              README.osf       configure*       osf1/
NeXT/            README.sol2      etc.ppp/         pppd/
README           README.sunos4    freebsd-2.0/     pppstats/
README.MSCHAP80  README.svr4      include/         scripts/
README.NeXT      README.ultrix    linux/           sunos4/
README.bsd       SETUP            modules/         svr4/
README.cbcp      chat/            netbsd-1.1/      ultrix/
README.linux     common/          netbsd-1.2/
root#

Be sure to review the README files since they contain information useful for the installation process.

The configure utility identifies the Unix platform type and sets up the necessary links to compile PPP-2.3. Here is the result:

root# ./configure
Creating links to Makefiles.
  Makefile -> linux/Makefile.top
  pppd/Makefile -> Makefile.linux
  pppstats/Makefile -> Makefile.linux
  chat/Makefile -> Makefile.linux
root#

Before compiling PPP-2.3, we'll first install PPP support into the Linux kernel.

Building a Linux kernel with PPP

PPP-2.3 must install or update various C header and source files into the Linux kernel source tree. Typing make kernel in the PPP-2.3 directory performs this task:

root# pwd
/usr/src/ppp-2.3.5
root# make kernel
cd linux; ./kinstall.sh
. . .
Installing into kernel version 2.0.30 in /usr/src/linux
. . .
Kernel driver files installation done.
root#

To configure, compile, and install a new Linux kernel, Linux users must have a full understanding of the computer hardware. For Linux kernels with PPP, you should include at least the following kernel configuration options:

Loadable module support
Also include the autoloading of kernel modules (kerneld) support.
TCP/IP networking
PPP
May be built-in to the kernel, or may be a loadable module. PPP datagram compression capabilities are all loadable modules.
Standard/generic serial support
These are the RS-232 interface drivers necessary for PPP. Multiport serial controllers, if available, can substitute for generic serial support.

Obviously, these options are in addition to many others required for the Linux computer's hardware.

Here are the commands necessary to create and install a new kernel in Slackware Linux:[1]

root# cd /usr/src/linux
root# make menuconfig
root# make install
root# make modules
root# make modules_install

More detailed instructions about building kernels appear in the README file in directory /usr/src/linux. The Linux kernel HOWTO guide is another useful reference.

After installing a new kernel, you must reboot. The startup file /etc/rc.d/rc.modules includes /sbin/modprobe ppp, which loads the PPP module. The following kernel messages should appear, either onscreen or in system logs, confirming PPP support:

PPP: version 2.3.5 (demand dialing)
PPP line discipline registered.

Compiling PPP-2.3

Compiling PPP-2.3 requires executing make at the top of its software distribution directory:

root# pwd
/usr/src/ppp-2.3.5
root# make
cd chat; make  all
make[1]: Entering directory '/usr/src/ppp-2.3.5/chat'
cc -c -O2 -pipe -DTERMIOS -DSIGTYPE=void -UNO_SLEEP -DFNDELAY=O_NDELAY -o chat.o chat.c
. . .
cc -O -D_linux_ -I../include -o pppstats pppstats.c
make[1]: Leaving directory '/usr/src/ppp-2.3.5/pppstats'
root#

Now we can install the software. As the root user, execute make install:

root# make install
cd chat; make BINDIR=/usr/sbin MANDIR=/usr/man  install
. . .
install -o 0 -g daemon -c -m 600 etc.ppp/chap-secrets /etc/ppp/chap-secrets
root#

The standard Slackware Linux installation directories for PPP-2.3 are /usr/sbin, /usr/man, and /etc/ppp, for PPP binaries, manual pages, and other files, respectively. These directories vary for PPP-2.3 installations on other Unix platforms. The important executable files in /usr/sbin are pppd, chat, and pppstats.

Linux Operating System Configuration

Before setting up Linux PPP-2.3, you should complete some preliminary Linux operating system configuration tasks in the areas of basic networking, serial interfaces, and syslog.

Linux base network configuration

Linux with TCP/IP capability requires a primary network interface. If Linux has a permanent network connection, a LAN interface (such as Ethernet eth0) is usually primary. However, many users have a network connection only when PPP is active. At other times, their computer is standalone, with no networking and no IP address. Standalone computers should set their loop-back interface as primary; if an unconnected Ethernet or an inactive PPP interface is primary, system hangs could result.

The menu-driven utility for configuring networks with Slackware Linux is netconfig. One question it asks is:

If you only plan to use TCP/IP through loopback, then your
IP address will be 127.0.0.1 and we can skip a lot of the
following questions.
 
Do you plan to ONLY use loopback?

Answering yes arranges the standalone network configuration. The resulting /etc/hosts file resembles the following code: 

root# cat /etc/hosts
127.0.0.1       localhost
127.0.0.1       myhost.mydomain.org myhost
root#

Much of the networking initialization code appearing in /etc/rc.d/rc.inet/ is disabled.

Here's a base networking configuration for Linux. Linux creates PPP interfaces ppp0, ppp1, etc. dynamically, whenever a PPP connection becomes active. However, no PPP interfaces should be active yet.

root# /sbin/ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Bcast:127.255.255.255  Mask:255.0.0.0
          UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1
          RX packets:68 errors:0 dropped:0 overruns:0 frame:0
          TX packets:68 errors:0 dropped:0 overruns:0 carrier:0 coll:0
root#

Serial interfaces

Linux designates RS-232 serial interface devices as Table 6-1 shows. These are the standard devices for PCs with onboard serial interface hardware.

Table 6-1: Linux Serial Interface Devices for PCs

Linux

Device File

DOS

Equivalent

IRQ

I/O Address

Base

/dev/ttyS0

COM1:

4

0x3f8

/dev/ttyS1

COM2:

3

0x2f8

/dev/ttyS2

COM3:

4

0x3e8

/dev/ttyS3

COM4:

3

0x2e8

Sharing IRQs can prevent the conflicting serial interfaces from functioning properly. To use ttyS0 or ttyS2, for example, users must reconfigure their hardware physically to use nonconflicting IRQs or disable one of the devices. Then Linux requires serial device driver configuration to match its hardware settings. Users can use the setserial utility for this purpose.

It is absolutely essential to make sure IRQ and I/O address base assignment for a serial interface is conflict free and is consistent with what Linux believes. Users must not ignore this, even if they believe the serial interface is functioning. Hardware resource conflicts or inconsistencies can later manifest themselves as PPP problems and make troubleshooting extremely frustrating.

Syslog

Syslog is a Linux system resource responsible for recording messages pertaining to application and system activities. By default, the directory /var/log maintains the message files. Syslog categorizes messages by facility name and priority. The configuration file, /etc/syslog.conf, determines where and what the syslogd process does with incoming messages.

PPP-2.3 sends PPP debugging traces, conversational activity with remote systems, and other information, to Linux syslog. To view these messages, users must arrange syslogd to record them. The pppd and chat programs produce facility daemon and facility local2 messages, respectively, at various priorities. Capturing these require the following lines in /etc/syslog.conf :

daemon.debug                                    /var/log/daemon
local2.debug                                    /var/log/local2

A kill -1 to the syslogd process is necessary for /etc/syslog.conf changes to become effective.

Recording PPP-2.3 syslog messages is highly recommended, particularly for troubleshooting and for monitoring PPP activity.

Configuring chat

PPP-2.3 includes chat, a program that sends text strings to a serial interface, which is necessary for dialing out. It also interacts with any login and other prompts produced by a modem and a remote system. The desired result, after chat succeeds, is a connection to a remote system that is ready for PPP.

chat is not invoked directly. The main PPP program, pppd, is responsible for invoking chat, as follows, when it needs to set up a dial-out connection:

/usr/sbin/chat -v -f $HOME/.pppchat

This command is part of the startup options for pppd. chat converses with the serial interface pppd attaches to. When the -v option is present, syslog receives messages about this conversation. Option -f indicates a chat script appears in the named file. Alternatively, the script may be included as command-line arguments to chat, but this results in a lengthy and confusing line.

A chat script generally consists of strings to expect from and strings to send to a serial interface. Expect/send string pairs have spaces separating each string. chat also interprets certain pairs as command directives for chat itself. A typical .pppchat file is:

ABORT BUSY
ABORT "NO CARRIER"
"" "at&f1"
OK "at dt 1 700 555 4545"
CONNECT "\c"
name: myname
word: mypass
"isp>" "ppp\r\d\c"

This chat script implements the dialog shown in Figure 6-2. The first two lines abort the script immediately if chat receives the word BUSY or NO CARRIER. A modem that fails to connect responds with one of these. The first expect/send pair is "expect nothing" and "send at&f1," which resets the modem. All other string pairs follow this pattern. Strings following the CONNECT line are dial-in service-specific.

chat supports a collection of special characters and sequences that may be embedded in its strings. The use of double or single quotes groups contiguous strings and prevents chat from misinterpreting them as multiple expect/send pairs. By default, chat sends a carriage return after a send string, unless it ends with \c. The reply following a CONNECT is truly nothing at all. The command that starts PPP remotely is specifically ppp, carriage return (\r), delay one second (\d), suppress final carriage return (\c). Other special sequences appear in the chat manual page.

When developing a script, look for partial strings, such as name:, instead of Username:. Sometimes, the initial characters remote servers send may become corrupt or lost in transit. The user's computer could miss the User part of the string it expects immediately after the modem connects. A one-second delay after sending ppp gives time for the remote PPP to start before the user sends the first PPP frame.

Since pppd invokes /usr/sbin/chat, users should configure pppd and execute it to test and verify a chat script.

Configuring pppd

pppd requires information about its serial interface, PPP Link Control Protocol (LCP), IP Control Protocol (IPCP), authentication, and other options. We use the Linux standard RS-232 serial interface, /dev/ttyS0 (COM1:), with an attached modem as the dial-out device.

On Linux, the full path to pppd is /usr/sbin/pppd. It collects configuration options from the global file /etc/ppp/options, the file .ppprc in the user's home directory, and the command line. Since there are many options, users can place them all into their .ppprc file. To prevent potential confusion and pppd options conflicts, users should start with an empty /etc/ppp/options file:

root# cd /etc/ppp
root# mv options options.orig
root# cp /dev/null options
root# ls -l options*
-rw-r--r--  1 root            0 Feb  3 03:18 options
-rw-r--r--  1 root            5 Feb  3 03:17 options.orig
root#

Now create a .ppprc file as required for the PPP sign-on procedures (earlier section):

# Log PPP control frames to syslog
debug
# Serial interface options
/dev/ttyS0 19200
lock
modem
crtscts
# Chat script
connect "/usr/sbin/chat -v -f $HOME/.pppchat"
# Link Control Protocol (LCP) options
asyncmap 00000000
# User name for PPP authentication
user myname
remotename isp
# IP Control Protocol (IPCP) options
noipdefault
# Use PPP peer as default gateway in system routing table
defaultroute

All options may be strung together into a single line, but we show them on separate lines for readability. The manual page, /usr/man/man8/pppd.8, describes other option keywords that may be included in this file.

Unless otherwise specified, pppd requests address/control field compression, protocol field compression, MRU 1500, VJ compression, magic numbers, and several others. In the preceding .ppprc, a user is dialing out via the serial interface, /dev/ttyS0, set at 19,200 bps. Hardware flow control, crtscts, and modem control, modem, apply. The program chat and its script file described previously arranges PPP startup at the remote end. As noipdefault indicates, the peer assigns both local and remote IP addresses. defaultroute arranges the PPP connection's far end to be the default gateway for all outgoing network traffic.

With PPP-2.3, PPP authentication as client requires the user and remotename options. The user option defines the authentication name. However, the remotename is only a local option to locate the correct password to use in the /etc/ppp/pap-secrets file. Here's how pap-secrets looks:

root# cat /etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client        server  secret                  IP addresses
myname          isp     mypass                  *
root#

The name and password to send is myname and mypass, respectively, whenever pppd connects to isp as the remotename. The * indicates any IP address is acceptable for this PPP connection.

Establishing the PPP Connection

Users execute pppd to initiate a PPP connection. Since configuration files reside in the user's home directory, it's important to execute pppd as that user:

user$ /usr/sbin/pppd

If an error message appears, it indicates an immediate fatal problem. Other problems are evident only in log files. With the debug option enabled, pppd generates extended messages for Linux syslog that appear in /var/log/daemon, in our sample configuration. chat messages appear in /var/log/local2.

chat first controls the dial-up process. Successfully sending the string ppp at end of the script completes this process. Next is PPP LCP negotiations, which concludes with the exchange of LCP Config-ACK. PPP authentication follows; then IPCP negotiation establishes both IP addresses and VJ compression. The log excerpts showing this activity are:

user$ cat /var/log/local2
Apr  7 22:59:20 myhost chat[188]: abort on (BUSY)
. . .
Apr  7 22:59:20 myhost chat[188]: send (ppp^M\d)
 
user$ cat /var/log/daemon
Apr  7 22:59:16 myhost pppd[187]: pppd 2.3.5 started by user, uid 2001
Apr  7 22:59:23 myhost pppd[187]: Connect: ppp0 <--> /dev/ttyS0
. . .
Apr  7 22:59:23 myhost pppd[187]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xfc86d8b7> <pcomp> <accomp>]
Apr  7 22:59:24 myhost pppd[187]: sent [LCP ConfAck id=0x1c <mru 1500> <auth pap> <magic 0xa358edcc> <pcomp> <accomp>]
. . .
Apr  7 22:59:24 myhost pppd[187]: sent [PAP AuthReq id=0x1 user="myname" password="mypass"]
Apr  7 22:59:24 myhost pppd[187]: rcvd [PAP AuthAck id=0x1 ""]
. . .
Apr  7 22:59:24 myhost pppd[187]: sent [IPCP ConfAck id=0x1d <compress VJ 0f 01> <addr 192.168.1.34>]
Apr  7 22:59:24 myhost pppd[187]: rcvd [IPCP ConfAck id=0x2 <addr 192.168.1.35> <compress VJ 0f 01>]
. . .
Apr  7 22:59:24 myhost pppd[187]: local  IP address 192.168.1.35
Apr  7 22:59:24 myhost pppd[187]: remote IP address 192.168.1.34
. . .

After pppd reports its local and remote IP address, the PPP connection is up and ready for use.

An active PPP connection is a Linux systemwide resource. All users on the Linux computer can access this connection, even though a particular user initiated it. Only the user who started pppd or root is allowed to shut down pppd and its corresponding connection.

When PPP is active, it alters the Linux computer's network configuration. The changes now include an additional active network interface, ppp0:

user$ /sbin/ifconfig -a
lo        Link encap:Local Loopback
. . .
ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.1.35  P-t-P:192.168.1.34  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:19 errors:1 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 coll:0
. . .

Another item to check is a new default route, essential for reaching any Internet IP address destination. pppd automatically installs this route:

user$ netstat -rn
Kernel IP routing table
Destination     Gateway      Genmask         Flags   MSS Window  irtt Iface
192.168.1.34    0.0.0.0      255.255.255.255 UH     1500 0          0 ppp0
127.0.0.0       0.0.0.0      255.0.0.0       U      3584 0          0 lo
0.0.0.0         192.168.1.34 0.0.0.0         UG     1500 0          0 ppp0
user$

Now, any network activity via the PPP connection produces statistics visible with pppstat:

user$ /usr/sbin/pppstats
     IN   PACK VJCOMP  VJUNC  VJERR  |      OUT   PACK VJCOMP  VJUNC NON-VJ
    520     19      8      1      0  |      670     20     10      1      9
user$

This utility, as well as ifconfig, can detect errors at the serial interface communications layer.

Domain Name System

Networking applications, particularly the World Wide Web, refer to Internet sites by DNS name. Linux must resolve these names into IP addresses.

On Linux, DNS settings control the behavior of its name resolution libraries; these settings are entirely separate from PPP-2.3. DNS configuration requires an /etc/resolv.conf file, listing DNS servers by IP address. An /etc/host.conf file establishes when Linux uses DNS to resolve names. The netconfig utility can help users set up these files. DNS with PPP is covered more fully in Chapter 10, Domain Name System.

Shutting Down

PPP-2.3 normally remains active until the local user or the remote peer disconnects. If a user configures it to do so with an idle option in .ppprc, PPP-2.3 also disconnects automatically after a period of inactivity. Otherwise, the user that initiated the PPP connection can manually disconnect it when he and other users have completed their session with the Internet. This requires sending a kill signal to pppd:

user$ ps -auxww | grep ppp
user       236  0.0  0.4   936   316  p0 S   23:44   0:00 grep ppp
root       187  0.0  0.6   948   448  S0 S   22:59   0:00 /usr/sbin/pppd
user$ kill 187
user$ tail /var/log/daemon
. . .
Apr  7 23:46:29 myhost pppd[187]: Connection terminated.
Apr  7 23:46:30 myhost pppd[187]: Hangup (SIGHUP)
Apr  7 23:46:30 myhost pppd[187]: Exit.
user$

Before pppd terminates, it records disconnect messages in syslog. pppd also undoes other Linux system changes it made, if any. For example, it deletes the default route it previously created and removes the ppp0 network interface.

Solaris PPP

Sun Microsystems Solaris features PPP software in its distribution. Solaris is available for both SPARC workstation platforms and IBM-compatible PCs. PPP configuration is similar for both, since the software is essentially the same.

Solaris PPP supports TCP/IP networking only. It has many configurable PPP options and multiple debug levels useful for tracing chat scripts, PPP frames, and IP datagrams. One feature of Solaris PPP is its on-demand connection capability. Users establish a connection by sending traffic that requires a PPP connection. If a connection is idle, Solaris automatically disconnects after a specified time.

In the next section, PPP is configured for Solaris 2.6 on a Sun Microsystem workstation. Most aspects of Solaris PPP configuration remain unchanged since Solaris 2.5.

Installation

PPP software components are included as part of the initial "Entire Distribution plus OEM support" or "Entire Distribution" Solaris installation. To check if PPP is present, use pkginfo. The following is the list of essential Solaris PPP packages:

user$ pkginfo
. . .
system      SUNWapppr      PPP/IP Asynchronous PPP daemon configuration files
system      SUNWapppu      PPP/IP Asynchronous PPP daemon and PPP login service
system      SUNWbnur       Networking UUCP Utilities, (Root)
system      SUNWbnuu       Networking UUCP Utilities, (Usr)
. . .
system      SUNWpppk       PPP/IP and IPdialup Device Drivers
. . .

Dial-out PPP also requires the Networking UUCP Utilities packages. If there are questions concerning the installation integrity of existing packages, use the package check utility:

user$ pkgchk SUNWapppr SUNWapppu SUNWbnur SUNWbnuu SUNWpppk

If any were omitted in the initial Solaris installation, there are several methods to incrementally install PPP components. The graphical swmtool can add Point-to-Point Protocol (SUNWCppp) and Basic Networking (SUNWCnet) software clusters. Together, these clusters include all the packages listed previously. Alternatively, the pkgadd utility individually installs each of the five packages listed. More detailed instructions about Solaris software management are available in the Solaris administrator guides and the manual pages. After installation, be sure to perform a reconfiguration boot. If they didn't already exist, this may be necessary to install PPP device files, including /dev/ipd, /dev/ipdptp, and /dev/ipdcm.

The main Solaris PPP program is /usr/sbin/aspppd. This is the background PPP connections manager process. The main configuration file is /etc/asppp.cf, but chat scripts belong in the UUCP directory, /etc/uucp. aspppd logs its activities in /var/adm/log/asppp.log. There are other files including kernel modules, device files, and startup files (in /etc/rc0.d and /etc/rc2.d ), but you don't need to know these to use PPP. For reference, the important manual pages are aspppd and ppp.

Solaris Operating System Configuration

Some Solaris operating system configuration may be required to prepare Solaris for PPP. The tasks at hand are establishing a base TCP/IP networking configuration and setting up serial interfaces for dial-out. Users may also need to reconfigure any inbound login services, if they're active.

Base network configuration

A Solaris workstation requires a primary network interface. If the workstation is a permanent member of a LAN, it has a static name and IP address. The LAN interface (e.g., le0) is its primary network interface, and a PPP connection becomes an additional network interface.

For many dial-out users, the workstation has a network connection only when PPP is active. The loopback interface should be primary in this case. Although it's possible to arrange a PPP network interface as primary, I don't recommend this since the workstation could spontaneously initiate a connection, for reasons that aren't obvious.

To establish the loopback interface as primary, the Solaris workstation must have /etc/inet/hosts and /etc/hostname.xx0 files, as follows:

root# cat /etc/inet/hosts
127.0.0.1       myhost localhost loghost
root# cat /etc/hostname.xx0
myhost
root#

There may also exist similar files such as hostname.le0, hostname.hme0, hostname.be0, etc., that set permanent IP addresses for the network interface device matching the file suffix. If these files are for unused or nonexistent network interfaces, they should be removed.

After rebooting with this network configuration, but before configuring PPP, the resulting network configuration is:

root# ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
        inet 127.0.0.1 netmask ff000000
root#

Solaris may start TCP/IP routing protocol daemons in.routed and in.rdisc at boot time. These aren't needed nor desirable for the dial-out PPP arrangement assumed here. Leaving them active can trigger unnecessary PPP connections and may cause TCP/IP routing complications. You can edit the file /etc/rc2.d/S69inet and disable in.routed and in.rdisc. Alternatively, renaming the executable files also prevents them from starting at boot time. Another daemon that can trigger unnecessary PPP activity is the name services cache daemon, nscd. Unnecessary PPP activity occurs if nscd requires the Internet to cache DNS lookup results, for example. You may wish to disable this daemon as well.

Serial interfaces

On Solaris workstations, serial interface device files have names like /dev/term/a and /dev/term/b. Solaris for PCs include /dev/tty00 (COM1:) and /dev/tty01 (COM2:). The /dev/tty01 name may be missing on some PCs equipped with a second serial interface. In this case, users can edit /platform/i86pc/kernel/drv/asy.conf and enable the following lines:

name="asy" class="sysbus" interrupts=12,3 reg=0x2f8,0,0
ioaddr=0x2f8;

Then perform a reconfiguration reboot or execute both drvconfig and devlinks utilities.

The device files with /dev/tty prefixes are for dial-in. If there are any inbound login services active (e.g., ttymon processes) and bound to these device files, they should be disabled for now. Inbound login can interfere with dial-out connections, depending on how it's set up. The dial-out PPP devices are / dev/cua/a and /dev/cua/b, which should already exist. Improper permissions settings for them can also interfere with dial-out PPP. For now, dial-out device ownership and permissions may be set as follows:

root# chown uucp:uucp /dev/cua/a; chmod 666 /dev/cua/a
root# chown uucp:uucp /dev/cua/b; chmod 666 /dev/cua/b

Dial-in and dial-out devices enable one to lock out the other when a serial interface is used for both services. The dial-out device is special since it may be opened without a carrier detect signal, which is important for controlling modems that are still "on-hook."

UUCP Chat

Solaris PPP shares the same chat facilities as UUCP for initializing communications through a serial interface. UUCP chat scripts are responsible for issuing command strings and responses that prepare a serial connection for PPP (or even UUCP).

Setting up chat scripts requires editing several files residing in /etc/uucp. These files are the repository for many chat scripts that establish communications with many different remote systems:

user$ cd /etc/uucp
user$ ls
Config          Dialcodes       Limits          Sysfiles
Devconfig       Dialers         Permissions     Systems
Devices         Grades          Poll            remote.unknown
user$

Various portions of a single UUCP chat script reside in several different files. After a modem connects, the information necessary for interacting with a specific remote system appears in the Systems file. Modem initialization and dialing strings for many different modems are in the Dialers file. And, Devices associates a specific modem to a specific serial interface device file. All three files are essential for dial-out PPP.

Systems, Devices, and Dialers files appear in Figure 6-3 for use with the assumptions in the previous section "Dial-out Commands to Initiate PPP." By carefully examining this example, you should be able to develop your own UUCP chat script.

Figure 6-3. UUCP chat, System, Devices, and Dialer files

 

Solaris PPP requests a connection to a remote system by name. If this name is isp, then UUCP chat must find isp as an entry in the Systems file. This entry begins with a telephone number, the dial-out device type, and the line speed the user wishes to use to make the serial connection.

The dial-out device type and line speed must match one or more entries appearing in the Devices file. The match shown in the figure indicates that dial-out PPP to isp occurs through serial interface /dev/cua/b. This interface has attached error correcting, U. S. Robotics V.32 modem, named usrv32-ec. Chat interacts with this modem according to instructions for usrv32-ec appearing in Dialers.

If the modem successfully connects, chat returns to the Systems file and interacts directly with remote system isp according to the script information, if any, following the telephone number. At the successful conclusion of this script, PPP communications may begin.

UUCP chat file entries contain sections with strings to expect from a serial interface and strings to send to a serial interface. Each of these expect/send strings pairs can include escape character sequences for substituting telephone numbers, inserting special characters, or invoking special functions. Table 6-2 shows the ones appearing in Figure 6-3.

 

Table 6-2: UUCP Escape Character Sequences (Partial)

Sequence

Meaning

\d

Delay two seconds

\p

Pause, 1/4 to 1/2 second

\r

Carriage return (CR)

\n

Line feed (LF)

\s

Space character

\c

Suppress carriage return at end of string

\D

Substitute telephone number string

\T

Substitute telephone number after translating it using the Dialcodes file

\E

Turn on echo checking

With Solaris PPP, UUCP chat can also set serial interface parameters. Special keywords that appear as send strings perform this function. In the Systems file, we include an "expect nothing" and "send P_ZERO." Chat doesn't send this string; instead, it sets the serial interface to 8 bits and zero parity. The usrv32-ec entry in the Dialers file has a STTY=rtscts,crtsxoff directive as a send string. These are serial interface parameters that enable hardware flow control. In UUCP chat script files, any parameter the Solaris stty utility supports can follow STTY=.

Now that we have a chat script configured for PPP, the next step is testing it. The cu command is useful for this purpose:

user$ cu -d -L isp

After it executes chat scripts residing in /etc/uucp to set up a serial connection, cu functions as a terminal emulator. Here, we request cu to connect with isp in the Systems file. A -d enables debugging and shows chat activity. By default, cu executes only chat script portions in the Devices and Dialers files. A -L (login) causes it to also execute the portion in Systems that interacts with the remote system. The debug output helps isolate chat problems, if any.

For further details regarding UUCP, consult such books as Using and Managing UUCP by Ed Ravin, Tim O'Reilly, Dale Dougherty, and Grace Todino, also published by O'Reilly & Associates. The Solaris Answerbook includes more specific instructions and a list of escape characters that can be included in the UUCP files.

Configuring asppp

Solaris requires an active /usr/sbin/aspppd for PPP to function. A single configuration file, /etc/asppp.cf, defines the characteristics for all PPP connections available to this workstation. As long as this configuration file is valid, Solaris automatically starts aspppd at boot time.

The file /etc/asppp.cf consists of two parts. At the top are one or more ifconfig commands that establish PPP network interfaces. These interfaces may have names ranging from ipdptp0 to ipdptp63, and many can exist simultaneously. Each ifconfig statement at minimum must include plumb, a local IP address for the PPP connection, a remote IP address, and up. Additional options to ifconfig appear in its manual page. The second part of the configuration file are path sections. Each path section describes options for a PPP connection to a remote system.

For the configuration assumptions in the previous section, "PPP Sign-on Procedures," we need to define a PPP network interface with dummy IP addresses and one set of PPP options for the remote system named isp. Here is a suitable /etc/asppp.cf file:

root# cat /etc/asppp.cf
 
ifconfig ipdptp0 plumb 1.2.3.4 1.2.3.5 up
 
path
# PPP network interface
        interface ipdptp0
# Name of remote system, the PPP peer, as defined in /etc/uucp/Systems
        peer_system_name isp
# LCP options
        ipcp_async_map 00000000
# PPP authentication with PAP
        will_do_authentication pap
        pap_id myname
        pap_password mypass
# IPCP, permit our peer to establish our local IP address
        negotiate_address on
# TCP/IP, use PPP peer as default gateway
        default_route
# Miscellaneous
        inactivity_timeout 600
        debug_level 8
root#

A path section consists of the word path followed by option keywords and values. These words are strung together with whitespace (blanks, tabs, newlines). For readability, we include one option and its value, if any, per line. Each path requires the interface and peer_system_name keywords. The values of these associate the PPP network interface ipdptp0 to the remote system isp in the UUCP Systems file.

The remaining lines in the path section define PPP, TCP/IP, and other miscellaneous settings. A complete list of the available option keywords are in the manual page for aspppd. Unless otherwise specified, aspppd automatically negotiates with its peer for PPP magic numbers, protocol field compression, address/control field compression, and MRU 1500.

default_route is included explicitly. When PPP is up, Solaris PPP arranges the IP address of the remote system, isp, to become the default gateway for this workstation's outgoing traffic. This IP address is not known until after the PPP connection is active, and it may also change for every new PPP connection. Thus, the default_route option creates and destroys the default route entry in the routing table for each PPP connect and disconnect cycle. If the remote system isp requires our PPP authentication credentials, will_do_authentication pap indicates this workstation has a name and password it can respond with. Debugging is set at a level high enough to trace PPP frames. The connection inactivity time-out is 10 minutes (default is 2 minutes). This can be set to 0 for no time-out. We are assuming the PPP peer, isp, assigns the IP addresses for both endpoints of the PPP connection. Solaris PPP disallows IP address changes at the local end of ipdptp0 (shown initially as 1.2.3.4) unless the negotiate_address on option appears. This permits ipdptp0 to inherit a new local IP address the dial-in server assigns at PPP connect time.

If the process /usr/sbin/aspppd isn't already active, you must either reboot the workstation or execute the following command, with the start argument (you can use stop to stop PPP):

root# /etc/init.d/asppp start

This executes all the ifconfig commands in /etc/asppp.cf and starts aspppd. If aspppd is already active, you must issue a kill -1 to aspppd, causing it to reload any path section changes in its configuration file:

root# ps -e | grep aspppd
   697 pts/0    0:05 aspppd
root# kill -1 697
root# tail /var/adm/log/asppp.log
16:48:14 catch_sighup: HUP caught
16:48:14 parse_config_file: Successful configuration
root#

Establishing the PPP Connection

Solaris PPP remains idle until a user routes outgoing IP datagrams to the workstation's PPP network interface. aspppd initiates the PPP connection, as necessary when this happens. At this point in our Solaris PPP configuration, accessing a random Internet IP address won't initiate a PPP connection. The problem is that this Solaris workstation doesn't know that IP datagrams for an Internet IP address requires use of the PPP network interface, ipdptp0. In other words, there is no TCP/IP route to the Internet.

To initiate PPP, users must first inspect the current settings for ipdptp0. The ifconfig utility serves this purpose:

user$ ifconfig ipdptp0
ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 8232
        inet 1.2.3.4 --> 1.2.3.5 netmask ff000000
user$

Notice ipdptp0 is already UP even though its modem isn't yet active. To actually initiate PPP, we can route IP datagrams through ipdptp0 with a ping to the dummy IP address, 1.2.3.5. This is the current, remote (far end) IP address for ipdptp0, even though PPP is not yet active.

user$ ping 1.2.3.5

The ping triggers a series of events that appear in the log file /var/adm/log/asppp.log. The events include UUCP chat, PPP LCP, authentication, and NCP transactions. Any errors aspppd encounters are also recorded to aid debugging. Here are some log excerpts for a successful connection:

user$ cd /var/adm/log
user$ cat asppp.log
16:23:33 process_ipd_msg: ipdptp0 needs connection
conn(isp)
Trying entry from '/etc/uucp/Systems' - device type ACU.
. . .
expect: (CONNECT)
^M^JCONNECTgot it
STTY crtscts,crtsxoff
. . .
16:24:01 000138 ipdptp0 PPP DIAG OPEN
16:24:01 000139 ipdptp0 SEND PPP ASYNC 23 Octets LCP Config-Req  ID=1f LEN=18 MRU=1500 MAG#=ffab974e ProtFCOMP AddrCCOMP
16:24:02 000140 ipdptp0 RECEIVE PPP ASYNC 23 Octets LCP Config-ACK  ID=1f LEN=18 MRU=1500 MAG#=ffab974e ProtFCOMP AddrCCOMP
. . .
16:24:04 000150 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-ACK  ID=21 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=166.72.92.184
16:24:04 start_ip: IP up on interface ipdptp0, timeout set for 600 seconds
. . .

Examining the PPP network interface ipdptp0 confirms that the peer (remote server, isp) has indeed negotiated changes to all the initial dummy IP addresses:

user$ ifconfig ipdptp0
ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
        inet 166.72.92.184 --> 204.146.252.97 netmask ff000000
user$

The asppp.cf configuration instructs aspppd to install a default route. As we expected, this route references the remote IP address for ipdptp0:

user$ netstat -rn
Routing Table:
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
127.0.0.1            127.0.0.1             UH       0     13  lo0
204.146.252.97       166.72.92.184         UH       2      0  ipdptp0
default              204.146.252.97        UG       0      0
user$

This Solaris workstation now has an active PPP connection and the TCP/IP routes necessary for users to communicate with the Internet. If an idle time-out occurs after 10 minutes, aspppd removes the default route and closes the connection.

Reinstating the same PPP connection requires routing another IP datagram to the current ipdptp0 far-end IP address. Users may obtain this information again with the ifconfig utility. Notice this IP address has changed since the last successful PPP connection. Now, it's necessary to initiate PPP with a ping 204.146.252.97.

On-demand PPP connections

On-demand PPP means that the workstation automatically establishes PPP whenever users access any Internet IP address. For this to work, aspppd must detect outbound Internet IP datagrams at a PPP network interface, even if the PPP connection is down.

A permanent default route can send all Internet traffic to a PPP network interface. This eliminates the need for a dynamic route. Thus, users must remove all default_route options in the /etc/asppp.cf configuration file. The permanent route can be the same as the one the default_route option creates:

root# route add default 204.146.252.97 1

This permanent route functions correctly only as long as the remote IP address for the PPP network interface remains static. Alternatively, users can also install a default route as follows:

root# ifconfig ipdptp0
ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
        inet 166.72.92.184 --> 204.146.252.97 netmask ff000000
root# route add default 166.72.92.184 0

It's important to create this route with a zero metric and with the current local IP address of ipdptp0. This insures the default route always points to the PPP interface, ipdptp0, even if its local IP address changes later.

If the workstation user creates the file /etc/defaultrouter with an IP address as its contents, Solaris can install a permanent default route at boot time. The route must refer to ipdptp0 local IP address at boot time. In this case, 1.2.3.4 is the address to include in this file:

root# echo "1.2.3.4" > /etc/defaultrouter

It's also necessary to edit the startup file /etc/rc2.d/S69inet. The route add default statements appearing in this file need zero metric arguments. The usual metric is one, which is the normal case for default routes to gateways residing on LANs. This won't work for this PPP example, since we want the default route to point to the workstation's own PPP network interface.

With on-demand PPP, users must beware that if the PPP connection is down, it can take as much as one minute to connect. This may cause application programs accessing the Internet to time out and fail. Once PPP is up, users can try their application again, which should now behave normally.

Domain Name System

A Solaris PPP connection isn't too useful if user applications (Telnet, web) can't resolve names of Internet sites to their IP addresses.

Solaris DNS name resolution requires a /etc/resolv.conf file containing IP addresses for DNS servers. Once users create this file, Solaris must know when to perform DNS lookups when resolving names. This requires the keyword dns in the name services switch file, /etc/nsswitch.conf. Chapter 10 presents more details about DNS and Solaris.

Shutting Down

Solaris PPP maintains an inactivity timer and automatically shuts down a PPP connection that has remained inactive for a preconfigured time. The inactivity_timeout option in the asppp.cf file sets this time.

To manually terminate PPP connections before inactivity timers expire, users can send a hang-up signal to aspppd, causing it to reset:

root# ps -e | grep aspppd
   699 ?        0:07 aspppd
root# kill -HUP 699

However, this disconnect is temporary because aspppd can still reestablish PPP connections on demand. Permanently disabling all PPP service requires permanently terminating the aspppd process itself:

root# /etc/init.d/asppp stop

Windows 3.1

Microsoft Windows 3.1 doesn't include built-in networking. Therefore, Windows 3.1 PPP products add significant "plumbing." These include software components that implement a TCP/IP protocol stack, drivers for networking hardware and libraries that present the Winsock applications programming interface (API).

The Winsock API enables third-party programmers to develop user applications software (Telnet, FTP, etc.) that are compatible with a PPP product. In other words, Netscape Navigator is compatible with any number of Windows 3.1 PPP products that include Chameleon (Netmanage), PC-NFSpro (SunSoft), PC/TCP OnNet (FTP Software), Trumpet Winsock (Trumpet Software International), and others. PPP networking products must provide winsock.dll. This dynamically loadable library presents the Winsock API for applications accessing network services.

Windows 3.1 is dated, and many of its users have either migrated to Windows 95, Windows 98, or Windows NT. The later-generation Windows maintain the Winsock API model and, in fact, include the necessary Winsock libraries. Thus, many network applications that ran under Windows 3.1 should continue to operate under Windows NT/95.

Windows 98 (and 95)

Microsoft Windows 98 includes dial-up networking (DUN) as an integral component of the operating system. DUN supports PPP access to TCP/IP networks, in addition to Novell IPX/SPX networks and those using NetBEUI. In fact, users can use all three simultaneously with a single PPP connection, if the PPP peer and its remote network supports all these protocols. Note the DUN instructions presented here focus only on TCP/IP.

Microsoft Windows 98 DUN is not significantly different from Windows 95 DUN. Much of the description for Windows 98 also applies to Windows 95.

The latest, and perhaps the last, DUN software for all Windows 95 releases is DUN upgrade 1.3. This upgrade is available for download as msdun13.exe, free of charge, from the Microsoft web site. DUN 1.3 patches bugs and provides enhancements to the DUN in the original Windows 95 retail release. I suggest all dial-out PPP users obtain this upgrade before proceeding.

Installation

Windows 98 consists of many optional operating-system components users may select (or deselect) at installation time. Users can verify whether DUN components are installed by selecting Control Panel > Add/Remove Programs > Windows Setup > Communications. The following should appear with a check in their checkboxes:

If any of these items are missing, users can add them by clicking the corresponding checkbox and then "OK" the changes. Windows 98 then prompts for its CD-ROM installation media and installs the files for the missing items.

Dial-out PPP also requires Windows 98 networking components. In turn, networking requires one or more network adapters and drivers. The current setup status for Windows 98 networking appears by selecting Control Panel > Network > Configuration. Items necessary for PPP are:

A Dial-Up Adapter is a network adapter that operates over a serial interface with an attached modem. If this adapter is missing, users should select Add > Adapter. Dial-Up Adapter appears under the manufacturer Microsoft. Select it to install.

Each Windows 98 network adapter may have one or more network layer protocols bound to it. Dial-out PPP to the Internet requires TCP/IP. If TCP/IP is missing, then select Add > Protocol. TCP/IP also appears under manufacturer Microsoft. Users must select this and any others as necessary. After installation, these protocols appear in the main Network setup window.

Client for Microsoft Networks provides access to network disk drives, printer, and others services available on remote Microsoft Windows NT/98 servers. It's not essential to have this, since basic Internet connectivity doesn't require it. I recommend installing it to obtain the password caching feature for DUN. This enables Windows 98 to remember sign-on names and passwords users need for dial-out PPP.

Serial Interface and Modem Setup

The first resource users should set up on their PC is a serial interface and modem. The Windows 98 control panel shows a Modems icon. This invokes the main Modems Properties window that appears in Figure 6-4. Modems Properties manage default settings for all serial interfaces and modems attached to the PC.

Figure 6-4. Windows 98 Modems Properties

 

Users can install a new modem by selecting Add in Modem Properties. Windows 98 can either try to detect the modem model or let the user specify this manually. It's important to correctly identify the modem, since Windows 98 needs to know how to control it. Furthermore, the modem model establishes the initial settings for its serial interface.

Modems Properties also includes a Dialing Properties button. This establishes dialing procedures for the user's telephone service. Another Properties button is available for each installed modem. This controls serial interface and related modem settings. There are a total of four properties per modem definition. These are:

General tab
Establishes which serial interface the user connected her modem to. This tab also sets the serial interface bits per second (shown as Maximum Speed) for PC to modem communications. Set this to 57600 or 115200 for 28.8-Kbps data compressing modems.
Connection tab
Data bits, parity, and stop bits settings for the serial interface are here. For PPP, these should be 8 bits, no parity, and 1 stop bit. Dialing time-outs also appear in this window. Users who check Cancel the call if not connected within should make sure the delay is at least a minute.
Port Settings button
This manages the buffers available on the 16550 UART chip (see Chapter 2, Serial Interfaces and Modems). The default settings are appropriate for most dial-out PPP configurations.
Advanced button
Configures the modem to use error control (e.g., V.42) and data compression (e.g., V.42bis). Users should enable these for modems that support these features. Use flow control should be (RTS/CTS) whenever possible. In Windows 95, there is also a checkbox to Record a log file. If enabled, a modemlog.txt file (usually c:\windows\modemlog.txt) in the Windows 95 root directory records a history of modem strings Windows 95 sends and responses it receives.
Windows 98 always records a history of modem strings it sends and responses it receives in a modem log file residing in the Windows 98 root directory. The name of this file corresponds to the modem description with a .log extension. This log is particularly useful for troubleshooting modem interaction problems. The checkbox, Append to Log, controls whether Windows 98 overwrites or appends the log file for each new PPP call.

Users should beware that Modems Properties mostly set defaults only. A dial-out PPP configuration users define for a specific remote server can override many of the settings that appear in Modems Properties.

Dial-up Adapter Setup

The dial-up network adapter and the TCP/IP protocol that's bound to it, has numerous settings users can access with the Network icon in the Windows 98 control panel. Figure 6-5 illustrates some of these configuration windows.

Figure 6-5. Windows 95, Dial-Up Adapter Properties

 

Nearly all the settings that appear in Dial-Up Adapters Properties should remain at their defaults. The only exception is the setting for recording PPP frame traces, useful for debugging. The Dial-Up Adapter Properties settings are as follows:

Driver Type tab
These are Windows 98 system-specific settings. Be sure to set to Enhanced mode (32 bit and 16 bit) NDIS driver.
Bindings tab
On this list are the network protocols available for the dial-up adapter. At minimum, TCP/IP should appear with a check in the checkbox. Other network protocols may be enabled too, for users accessing remote networks that require them.
Advanced tab
This tab includes the property Record a log file. Setting this to yes causes Windows 98 to create the file ppplog.txt (usually c:\windows\ppplog.txt) in the Windows 98 root directory. This file records PPP negotiation activities with a peer, useful for troubleshooting PPP problems.

Another collection of network control panel settings for the dial-up adapter appear under TCP/IP Properties (Figure 6-5). There are six tabs for items including IP Address, WINS, and others. The presence of these TCP/IP Properties is a confusing and annoying feature of Windows 98. Equivalent and duplicate settings appear later when users configure a dial-out PPP connection. It's critically important for users to leave all dial-up adapter TCP/IP Properties settings here untouched (leave as defaults) in the Network control panel. If users inadvertently change something here, they interfere with DUN's ability to dynamically configure these items during dial-out PPP. To prevent difficult to troubleshoot problems later, the TCP/IP Properties here should show the following:

Configuring Dial-out PPP Connections

Users manage PPP connections through the Windows 98 Dial-Up Networking folder. The default locations to access this folder are the My Computer icon on the desktop, and the Start menu (Programs > Accessories > Dial-Up Networking). Figure 6-6 shows this folder.

Figure 6-6. Windows 95, Dial-Up Networking folder

 

Inside this folder is the icon Make New Connection. Users double-click this icon if they wish to configure dial-out PPP to a new remote system. Windows 98 asks for the modem, the name of the remote system, and its telephone number. This procedure creates a new icon in the name of the remote system, such as My Connection, that retains all the settings necessary to initiate a PPP connection to it.

Right-clicking My Connection shows a menu that includes Properties. This invokes the windows (Figure 6-7) necessary to configure dial-out PPP. The General tab lists all the general information Windows 98 prompted for, when it initially created the My Connection icon.

Figure 6-7. Windows 98 dial-out PPP connection properties

 

One button appears in this tab: Configure. This presents modem properties similar to the ones from the Windows 98 control panel (Figure 6-4). Although these serial interface modem settings appear identical to those in the control panel, these settings are really separate. They override the control panel settings whenever the user initiates a PPP connection to My Connection.

An additional Options tab can enable a terminal window during the PPP connect process. This lets users interactively enter login and other commands necessary to start PPP on the remote system. The previous section "Dial-out Commands to Initiate PPP" shows the interactive steps. Later, Windows 98 dial-up scripts can automate these steps. For dial-in services that can automatically detect PPP communications, dial-out PPP users should not enable terminal windows.

PPP settings

The Server Types tab (Figure 6-8) configures PPP and other network layer protocols users may choose. The first item is the dial-up server type Windows 98 is connecting to. Obviously, the correct choice is PPP. The other server types appearing in the pull-down list are for obsolete and proprietary serial line protocols.

Figure 6-8. Windows 95 dial-out PPP settings

 

One of the advanced options is Enable software compression. This tells Windows 98 to negotiate the PPP compression control protocol (CCP) with its peer. Data compression is active only if both endpoints understand and agree to:

PPP compression methods are independent of modem compression. Enable software compression may be enabled, even if Windows 98 fails to negotiate it with its peer. However, if it causes fatal PPP negotiation failures due to peer incompatibilities and bugs, you should disable this option.

The forms of PPP authentication (see Chapter 12, Authentication) Windows 98 supports are:

With Require encrypted password, Windows 98 agrees to authenticate with any method, except PAP. If a remote system requests PAP, Windows 98 refuses. This is a precaution designed to prevent transmission of passwords in clear text through a serial link and modem. Whether users can enable this feature depends on the remote system. Require encrypted password is incompatible with dial-up peers that absolutely require PAP for access.

Windows 98 also supports data encryption over PPP connections using a Microsoft encryption algorithm. The Require data encryption option is a security feature that guarantees that communication occurs only if both endpoints can understand and use Microsoft encryption. This option is only compatible with Microsoft PPP implementations. Enabling this feature can cause failures when users wish to communicate with PPP peers that don't use Microsoft software.

The Record a log file for this connection enables PPP trace logging. The PPP trace logs are almost identical to those users can obtain by enabling Record a log file in the Dial-Up Adapter Properties (Figure 6-5). The difference is that this setting enables logging for a PPP connection to this specific remote server. In contrast, Dial-Up Adapter Properties are global settings that affect all Windows 98 dial-out PPP connections.

The last group of settings in Figure 6-8 is Allowed network protocols. Windows 98 supports all the protocols shown with PPP, assuming the appropriate drivers have been installed. Users should select only the ones applicable to the remote system they're dialing into. Internet users should only select TCP/IP and disable the others. Sometimes, PPP connections can fail if Windows 98 requests the use of network protocols unrecognized by the remote system.

TCP/IP settings

The Server types tab includes a TCP/IP Settings button. This accesses TCP/IP settings (Figure 6-9) that are active when dialing out to My Connection. Users must adjust these settings to fit requirements of the remote system they're dialing into.

Figure 6-9. Windows 95 TCP/IP settings for dial-out PPP

 

At the top are the settings concerned with how Windows 98 acquires its IP address for PPP. With the assumptions in the section "Dial-out Commands to Initiate PPP," the proper setting is Server assigned IP address. The PC's local IP address is likely to change with each new dial-out connection. If the PC should have a static IP address, you can enter this in the Specify an IP address setting.

The second group of settings determines IP addresses of DNS servers. DNS resolves Internet site names to their IP address. Usually, users must configure DNS servers explicitly as shown, with DNS IP addresses of their ISP. WINS also provides name resolution, but it's proprietary and specific to Microsoft networks. There is a setting that allows the dial-in PPP server to assign DNS and WINS name server addresses. However, this functions only with remote systems that implement Microsoft's PPP extensions for DNS. Chapter 10 describes this extension in further detail. Server assigned name server addresses won't function with strictly standards-compliant PPP peers and others that don't support Microsoft features.

An additional option is Use IP header compression. IP header compression is another name for negotiating VJ compression in PPP. This compresses IP datagram headers only. Unlike the PPP CCP setting, it doesn't manipulate user data in any way. It's desirable to enable Use IP header compression often, since it reduces TCP/IP overhead. Users should disable this if their dial-up peer has a faulty VJ compression implementation or if there are PPP problems connecting.

Use default gateway on remote network arranges the default route for outbound IP datagrams to be this PPP connection. Users who have only a single network adapter (the dial-up adapter) must route all outgoing traffic through it. The circumstance requiring users to disable this default route occurs when users have additional network adapters (e.g., Ethernet) that connect them to the Internet or other TCP/IP networks.

Establishing a Connection

Windows 98 dial-up networking normally requires users to initiate a PPP connection first, before they can access Internet resources. Users must first access the Dial-Up Networking folder (Figure 6-6). They then double-click the icon representing the remote system they wish to dial-in. This causes a Connect To window to appear, as Figure 6-10 shows.

Figure 6-10. Windows 95 initiating a PPP connection

 

Connect To includes fields for users to fill in their authentication credentials. DUN uses the User name: and Password: information for any one or more of the following:

Save password stores user credentials for future dial-in sessions. The Phone number enables temporarily telephone number changes for this dial-out connection. Once all the information that appears in the Connect To is satisfactory to the user, he selects Connect to initiate dial-out PPP to My Connection.

DUN initializes a serial interface, issues modem commands, and receives modem responses for dialing out. DUN hides this process from users. If the modem successfully connects, a terminal window appears (Figure 6-11). Remember the preceding dial-out PPP connection properties include Bring up terminal window after dialing. The user must now use the keyboard to log in to the remote system and start PPP there. After PPP has started, the window may display PPP frames that appear as garbage, or nothing at all. Once PPP starts at the remote system, users select Continue. Windows 98 DUN then negotiates PPP and TCP/IP options, completing the connection.

Figure 6-11. Windows 95 Post-Dial Terminal Screen

 

An icon in the Windows 98 task bar indicates that a dial-out PPP connection is active. Connection status is available by clicking this icon, as shown in Figure 6-12. At this point, the dial-out user is online and can access Internet sites. The Disconnect button terminates the connection.

Figure 6-12. Windows 95 dial-out PPP connected

 

If dial-out connections fail, DUN includes features to help users diagnose the problem. Users can enable modem logs to record modem commands and responses. If the problem is PPP, DUN records PPP negotiations if dial-up adapter logging (see the previous section, "Dial-up Adapter Setup") is enabled. This log file is ppplog.txt in the Windows root directory. If the connection is successful, it should look like this:

C:\WINDOWS>type ppplog.txt
09-10-1998 17:34:26.82 - Microsoft Dial Up Adapter log opened.
09-10-1998 17:34:26.82 - Server type is  PPP (Point to Point Protocol).
09-10-1998 17:34:26.82 - FSA : Adding Control Protocol 80fd (CCP) to
control protocol chain.
09-10-1998 17:34:26.82 - FSA : Protocol not bound - skipping control
protocol 803f (NBFCP).
09-10-1998 17:34:26.82 - FSA : Adding Control Protocol 8021 (IPCP) to
control protocol chain.
. . .
09-10-1998 21:53:45.47 - LCP : Layer started.
09-10-1998 21:53:45.47 - PPP : Transmitting Control Packet of length: 25
09-10-1998 21:53:45.47 - Data 0000: c0 21 01 01 00 17 02 06 | .!...?..
09-10-1998 21:53:45.47 - Data 0008: 00 0a 00 00 05 06 00 c1 | ........
 
09-10-1998 21:53:47.89 - PPP : Received Control Packet of length: 18
09-10-1998 21:53:47.89 - Data 0000: 80 21 01 01 00 10 03 06 | .!......
09-10-1998 21:53:47.89 - Data 0008: c0 a8 01 01 02 06 00 2d | .......-
09-10-1998 21:53:47.89 - Data 0010: 0f 01 00 00 00 00 00 00 | ........
09-10-1998 21:53:47.89 - IPCP : Received and accepted IP address of c0a80101.
09-10-1998 21:53:47.89 - IPCP : Received and accepted compression protocol
request f 1.
. . .

Negotiation problems should be evident in this log. Once a PPP session terminates, serial interface error and traffic statistics appear at the end of this file.

Another useful Windows 98 utility is winipcfg, which shows active IP addresses, DNS server addresses, and default gateways. Route print and tracert (see Chapter 15, Troubleshooting) are available via the MS-DOS prompt. These print the TCP/IP routing table and trace routes to an IP address, respectively. The status of connections at the TCP/IP layer is available with netstat -a.

On-demand PPP connections

DUN includes provisions for on-demand PPP. The settings for on-demand PPP appear when you select the Internet icon in the Windows 98 control panel. This shows the Internet Properties window. The Connect to the Internet using a modem option (in the Connection tab) arranges on-demand PPP. Users of Windows 95 may not find the Internet icon. In this case, they can obtain the icon and the Internet Properties window after installing Microsoft Internet Explorer.

On-demand PPP enables a web browser accessing an Internet site to automatically trigger a dial-out connection. A connection can also terminate after a configurable idle time-out.

Dial-up Scripting

Windows 98 includes dial-up scripting capability for automatically sending text strings to remote system. Dial-up scripts (which is a Windows 98 term, equivalent to chat scripts) respond to prompts from the remote system and issue all commands needed to start PPP. A functioning script bypasses the need for users to Bring up terminal window after dialing during the PPP connect process.

Establishing a Windows 98 DUN script consists of creating a script file for a PPP connection icon (such as My Connection), which appears in the Dial-Up Networking folder. The properties for the PPP connection includes a Scripting tab, with buttons to managing a script file (Figure 6-13). Users can create a script by filling in a filename and selecting Edit. This invokes notepad as the text editor for the script.

Figure 6-13. Windows 98 dial-up scripting

 

DUN scripting resembles a programming language with variables, loops, and conditional statements. Its programming statements are available in the file script.doc (Microsoft Word format) DUN installs in the Windows 98 root directory (usually c:\windows). For the dial-out procedures appearing in the section "Dial-out Commands to Initiate PPP," a suitable script is:

proc main
	waitfor "name:"
	transmit $USERID
	transmit "<cr>"
	waitfor "word:"
	transmit $PASSWORD
	transmit "<cr>"
	waitfor "isp>"
	transmit "ppp<cr>"
endproc

Windows 98 replaces the predefined $USERID and $PASSWORD variables with their respective values in the Connect To window (Figure 6-10). Certain character sequences in strings have special meanings, such as "<cr>" for carriage return. Other sequences appear in the scripting language documentation. After saving the script file, be sure to check Step through script. This enables users to observe script execution line by line and is essential for detecting programming errors.

A dial-up script eliminates the need for a terminal window. Thus, users should disable the terminal window for My Connection (see Figure 6-7). The user then initiates the connect process. A script-testing window should appear that allows step-by-step script execution. If all is correct, users can complete the script installation by returning to the dial-up script settings (Figure 6-13) and disabling Step through script. Initiating a PPP connection now requires no further manual intervention.

Null Modem Connection with Windows 98

Windows 98 has a direct cable connection feature for connecting two PCs with a null modem at a fixed 19,200-bps speed. In fact, it's a PPP connection with fixed settings, but requires a special handshake procedure at the beginning of the PPP session. This handshake is similar to the null modem behavior described later with Windows NT 4.0. As a result, direct cable connection is generally compatible only when both PCs have Microsoft Windows NT, 98, or 95 installed.

To establish a generic null modem connection for PPP, it's necessary to include a null modem type in Modems Properties. Windows 98 dial-up networking must then access this modem. Unfortunately, a null modem is not valid in the Windows 98 Modems Properties configuration tab. As a result, when Windows 98 DUN initiates a PPP connection, it insists on interacting with a modem before PPP communications begin. Two solutions exist:

nullmodem.inf

This file is similar to the device files that manufacturers provide for real modems. It's available under the name nullmodem.inf at various Internet sites.

The procedure to install a null modem is identical to the procedure to install a real one (use Modems Properties). To Windows 98, a null modem is like any other. However, it has empty setup and dial-out command strings and empty responses. When initiating a PPP connection, Windows 98 progresses through an empty dialog, resulting in a physical serial connection that existed all along with its peer. PPP can then commence.

False modem

Another method to start Windows 98 PPP through a null modem is arranging the PPP peer to masquerade as a modem. Once Windows 98 believes it has a modem connection, albeit a false one, PPP communications may begin.

The modem a peer masquerades as should be a simple one. These are similar to Standard 19200 bps Modem in Modem Properties. Users must install the modem description that matches the serial interface speed for the null modem cable connection.

Windows 98 can open a Pre-dial terminal screen when Bring up terminal window before dialing is enabled for this PPP connection. A user can then interact directly with the peer system and start its modem masquerading software. Here is a program for a Unix peer:

user$ cat modem.sh
#!/bin/sh
# read "AT"
read line; echo "OK"
# read "ATE0V1"
read line; echo "OK"
# read "AT"
read line; echo "OK"
# read "ATDT17005554545"
read line; echo "CONNECT"
sleep 1
user$

At the end of the Pre-dial terminal screen, Windows 98 issues the dialing commands to the preceding program. This program generates the responses Windows 98 expects. After the dialing phase completes, Windows 98 can display a Post-dial terminal screen, which lets the user continue to interact with the peer as needed to start its PPP. At the conclusion of this terminal screen, Windows 98 starts PPP, completing the connection.

It's not always possible to arrange a Windows 98 PPP peer to masquerade as a modem. In these cases, nullmodem.inf is the only other solution.

Windows NT 4.0 Workstation

Microsoft Windows NT 4.0 Workstation features the remote access service (RAS). RAS enables its user to establish a dial-out PPP connection and access remote networks that support any combination of TCP/IP, Novell IPX/SPX, and NetBEUI. We consider only TCP/IP here.

The dial-out features available with Windows NT 4.0 RAS are nearly identical to those available with Windows 98.

Installation

Dial-out PPP requires Windows NT 4.0 Workstation to have networking services installed. Users can install it by selecting the Network icon in the Windows NT control panel. If network services are missing, the following message appears:

Windows NT Networking is not installed. Do you want to install it now?

Answering Yes starts the Network Setup Wizard, where users can select the option Remote access to network. The prompts and procedures that follow install and configure nearly all aspects of RAS, including dial-out networking protocols, serial interfaces, and modems. When Window NT asks, be sure to include TCP/IP[2] as a network protocol for RAS. Afterwards, users can define PPP connections in the dial-up networking Phonebook.

In cases where some form of networking already exists on Windows NT Workstation 4.0, users arranging dial-out PPP must verify the software components for RAS dial-up networking. They must then install and configure any missing RAS components. The section "Windows NT 4.0 Server" in Chapter 7, Dial-in PPP Setup, describes RAS installation for dial-in PPP. Most of the procedure is identical for dial-out PPP. A summary of items to check are:

Network protocols and network services
Users can add networking protocols for dial-out PPP by selecting Control Panel > Network > Protocols. Access to the Internet requires TCP/IP.
Serial interfaces and modems
Selecting Control Panel > Modems accesses Modems Properties. Each modem definition includes settings for a serial interface. Configuring modems in Windows NT is almost identical to Windows 98. Some additional details for Windows NT also appear in Chapter 7.
Remote access service
If Remote Access Service doesn't appear in Control Panel > Network > Services, then the instructions to install it is in Chapter 7.

A key difference in the RAS configuration for dial-in PPP, versus dial-out PPP, are the settings that appear in Remote Access Setup, as Figure 6-14 shows. Users must press the Configure button to mark a modem and serial interface pair for dial-out use. The Network button defines the networking protocols available for this modem. It's a good idea to select all available protocols in case unused ones are necessary later. The Phonebook (see the next section) sets the networking protocols to use for any given PPP connection.

Figure 6-14. Windows NT Remote Access Setup

 

Annoyingly, any changes to Remote Access Setup require rebooting Windows NT. Therefore, I suggest that you anticipate and configure as many RAS resources as you plan to use for dial-up networking.

A reboot starts several RAS background processes that manage PPP connections. These RAS processes appear in Control Panel > Services. The active ones are:

Another process is Remote Access Server, but this serves only dial-in PPP.

Managing the Dial-up Networking Phonebook

Dial-Up Networking is the main Windows NT 4.0 Workstation window for managing dial-out PPP connections. Users can access Dial-Up Networking by selecting its icon in My Computer. This window (Figure 6-15) manages Phonebook entries and dial-up connections.

Figure 6-15. Windows NT Dial-Up Networking

 

A named Phonebook entry is a collection of settings necessary to dial-out to a remote system. A listing of previously configured entries appears as a pull-down list below Phonebook entry to dial:. The More button presents the main menu of items for managing Phonebook entries.

Users must first create and name a new entry for a dial-in remote system they wish to access. The New... button invokes the New Phonebook Entry Wizard, which prompts for a minimal number of settings necessary to connect with a remote system. New entries frequently require further editing, even after the wizard creates them.

PPP connection settings belong in the categories Basic, Server, Script, Security, and X.25. These settings appear when users select Edit entry and modem properties... under the More menu in the Dial-Up Networking main window. Online help is available by selecting Help in the More menu. The help information is also available in file c:\winnt\system32\rasphone.hlp, which the winhlp32 utility can read.

Our configuration example arranges the settings for a dial-out PPP connection, named MyDialUpServer.

Basic tab

The basic information for a dial-out PPP connection is a telephone number, and a modem and serial interface pair to use. These settings are in the Edit Phonebook Entry Basic tab that Figure 6-16 shows. All the values correspond to the assumptions in the previous section "Dial-out Commands to Initiate PPP."

Figure 6-16. Windows NT Edit Phonebook Entry

 

Dial using: assigns a modem and serial interface pair for this connection. All pairs that appear here are listed as dial-out resources in the Remote Access Setup. In addition, the Dial using: field may include a special Multiple Lines selection, which enables Windows NT multilink PPP (see Chapter 16, What's New for PPP? ).

In more usual dial-out arrangements with one modem/interface pair, the Configure button sets the initial serial interface speed, hardware flow control, and some modem properties. These are settings that apply to this PPP connection, they take precedence over any settings that may appear in the control panel Modem Properties.

Server tab

The Dial-up server type: in the Server tab (see Figure 6-17) determines the serial line protocol Windows NT uses after its modem successfully connects. Obviously, users must select PPP, for dial-out PPP. The other choices in this pull-down menu are proprietary or obsolete serial line protocols.

Figure 6-17. Windows NT Edit Phonebook Entry, Server

 

Windows NT PPP can support all the Network protocols listed, as long as the remote system also supports them. Selecting a protocol causes Windows NT only to request it, with the dial-out peer. A protocol becomes active only if the peer agrees. I suggest that you select only the network protocols you need. In particular, TCP/IP is an Internet requirement. If Windows NT attempts negotiation for unusable and unneeded protocols, it takes time and can cause communication failures with some remote systems. The TCP/IP Settings... button presents TCP/IP settings for this PPP connection. What appears is identical to Figure 6-9 for Windows 98. The explanations are also identical to Windows 98.

If a check appears with Enable software compression, Windows NT tries to negotiate the use of PPP data compression (via the compression control protocol) with the remote system. User data compression is effective only if both PPP endpoints understand and agree to use this Windows NT-compatible compression method, Microsoft Point-to-Point Compression Protocol (MPPC).

Enable PPP LCP extensions causes Windows NT to try to negotiate several enhanced PPP options. Some of these are:

Users can enable either or both of these two checkboxes if they wish to use these enhancements with dial-out peers that support them. Otherwise, it's wise to disable these. If Windows NT negotiates for PPP enhancements a remote system doesn't understand, it's possible for the connection to fail.

Script

After a modem completes its connection, the Script tab determines what the dial-out user, or Windows NT, must do to start PPP on a remote server. Further information about script settings is provided in the previous section "Dial-up Scripting."

The scenario I described earlier in the section "Dial-out Commands to Initiate PPP" requires sending text strings and commands to the remote system in order to start PPP there. This requires the Pop up a terminal window setting (Figure 6-20), which causes Windows NT to pause and display a terminal window after dialing. You can then perform interactive steps with the keyboard to start PPP at the remote system.

The None setting is suitable for remote systems that don't require any interaction to start PPP communications.

Security

The Phonebook maintains a Security tab (Figure 6-18) for each dial-out connection. This controls how Windows NT authenticates itself to a remote system. These settings apply only to PPP authentication methods and don't affect terminal window authentication prompts that may exist before a remote system grants access.

Figure 6-18. Windows NT Edit Phonebook Entry, Security

 

Windows NT can authenticate with PAP, CHAP, Shiva PAP, or Microsoft CHAP. Users must supply authentication credentials at PPP connect time. If Accept only Microsoft encrypted authentication is checked, Windows NT authenticates only with Microsoft CHAP and refuses all the others. Accept only encrypted authentication allows methods that don't transmit passwords in clear text. Finally, Accept any authentication including clear text allows Windows NT to authenticate with any method it recognizes. For simple username and password authentication, Accept any is the only suitable setting. Be aware that if Windows NT refuses all the PPP authentication methods its dial-up peer wants, the connection fails.

The Microsoft-only setting also features Require data encryption and Use current username and password. The latter feature passes Windows NT login credentials for authentication. Unfortunately, both features are Microsoft-specific and require PPP endpoints with Microsoft-compatible software.

Other settings

The User preferences menu item in Dial-Up Networking (Figure 6-15) has additional settings that affect dial-out PPP. Some preference items users can adjust are:

Establishing a Connection

Selecting a Phonebook entry in Dial-Up Networking (Figure 6-15) and pressing the Dial button initiates a dial-out PPP connection. Windows NT usually displays PPP connection progress on-screen; users can suppress these messages in User preferences.

A Windows NT onscreen prompt that appears before the dial-out begins is an authentication window (Figure 6-19). Users must fill in credentials, if any, required by the remote system. Domain: is a Microsoft-specific feature for representing a Windows NT domain. If the User name: and Domain: are myname and mydomain, respectively, the name for PPP authentication purposes is mydomain\myname. Save password retains user authentication credentials for reuse and suppresses this on-screen prompt for future PPP connections to MyDialUpServer. To undo a previously saved password, users can return to the Edit Phonebook Entry Security tab (Figure 6-18) and select Unsave password.

Figure 6-19. Windows NT PPP connection authentication request

 

After the dial-out process completes and the modem successfully connects, a terminal window appears. This window is similar to the one for Windows 98 (Figure 6-11), and the instructions for its use are identical. Users must respond to remote system prompts with their keyboard and start PPP at the remote end of the connection.

Windows NT then negotiates PPP options and completes the connection. Errors, if any, appear onscreen. The Dial-Up Monitor in the Windows NT control panel shows the status of active connections. Another indicator is the telephone icon that appears next to the clock in the task bar. Both the Dial-Up Monitor and the Dial-Up Networking window have the controls necessary for terminating connections.

In case of problems, Windows NT offers PPP and modem trace facilities. PPP traces are available by changing the PPP logging registry value. Modems Properties includes settings to obtain modem traces. More details for enabling logging and the files they reside in are in the Windows NT Server RAS discussion in Chapter 7.

On-demand PPP

Windows NT features a limited form of on-demand PPP, which can automatically initiate PPP dial-out to selected Internet sites. The Enable auto-dial by location setting in the Dialing category of User preferences (see Figure 6-15) enables this feature. Another related Appearance setting, Always prompt before auto-dialing, determines whether Windows NT prompts users for permission to dial.

Auto-dial functions only for names and IP addresses users have visited during previous PPP connections. In other words, Windows NT remembers all the sites its applications access via PPP connection. The following command displays the auto-dial list:

rasautou -s

If a site doesn't appear, users must bring the connection up manually and then connect to it to add it to the auto-dial list. To remove entries from this list, use the regedt32 utility and edit the following key:

HKEY_CURRENT_USER\Software\Microsoft\RAS Autodial\Addresses

There's no convenient means to arrange auto-dial for all Internet destinations. This is a strange characteristic of Windows NT auto-dial, which differs considerably from the on-demand PPP available with Linux and Unix.

Dial-up Scripting

Dial-up scripting replaces procedures that normally require a terminal window. Scripts automatically respond to remote system prompts, typically for authentication and PPP start commands. A script completes when a remote system is ready with PPP. If Run this script is enabled in the Script tab settings for a PPP connection (Figure 6-20), Windows NT executes a script file.

Figure 6-20. Windows NT Edit Phonebook Entry, Script

 

The DUN script-programming language is identical to Windows 98. Sample scripts are in the c:\winnt\system32\ras directory with the .scp extension. Users may create new ones in the same directory. Further information about this language is available in the Microsoft Word file, c:\winnt\system32\ras\script.doc. A major flaw with dial-up scripts is Windows NT doesn't appear to offer any way to trace and debug the script programs.

Dial-up networking also offers an alternative script language. If Run this script includes a simple name, that name refers to a code section inside a master script file c:\winnt\system32\ras\switch.inf. Multiple scripts appear in this file, each with a named section header. A switch.inf script is of the send-and-expect type, without conditionals or looping ability. An example is:

; Section header with name
[PPP login]
; Send nothing
	COMMAND=
; Wait for "Username:"
	OK=<match>"name:"
	LOOP=<ignore>
; Send user name from authentication window
	COMMAND=<username><cr>
; Wait for "Password:"
	OK=<match>"assword:"
	LOOP=<ignore>
; Send password from authentication window
	COMMAND=<password><cr>
; Wait for "isp>"
	OK=<match>"isp>"
	LOOP=<ignore>
; Send "ppp"
	COMMAND=ppp<cr>

The lines alternate between a COMMAND= statement that sends strings to a peer and statements for matching strings in a response. Response processing is especially confusing. First, scripts consider all responses to be a received string terminated with a two-second idle time. Unfortunately, such delay can occur anywhere and can break a large response message into many smaller ones. When the OK= statement matches a substring in a response, it's an indication to proceed, apparently to the next COMMAND= statement. A LOOP= retries the previous statement and is usually set to match anything a previous OK= failed to match. This is an awkward workaround that accommodates conditions where string reception delays break up large responses into several smaller ones. A script fails if no statement matches the response strings DUN receives.

Windows NT includes tracing capability for switch.inf scripts. The following registry value controls this:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
RasMan\Parameters\Logging

Setting this value to 1 and restarting the RAS service (or rebooting) produces the log file c:\winnt\system32\ras\device.log. Consult this file if a script doesn't function. This log records activity only with switch.inf scripts.

Additional information about switch.inf and its script language appears in the online help for Dial-Up Networking.

Null Modem Connections with Windows NT

A Windows NT workstation may physically connect to another computer with a null modem cable. This cable can carry PPP, much like a modem does over a telephone line. Since there is no modem, Windows NT doesn't need to issue modem or dial commands when initiating (dial-out) a PPP connection. The Dial-Up Networking Serial Cable between 2 PCs in Modem Properties establishes this behavior. This defines a serial interface without a modem.

With a null modem connection, Windows NT can immediately start sign-on chat scripts and PPP with its peer. Unfortunately, when Windows NT dials out, it sends the string CLIENT several times without a carriage return, while it waits for its peer to respond with CLIENTSERVER. Without this response, Windows NT refuses to communicate. This is not the behavior of a true null modem configuration and can be especially frustrating to users trying to connect Windows NT to non-Microsoft platforms.

The previous section, "Null Modem Connection with Windows 98," describes methods that can also circumvent Windows NT null modem annoyances. Either the PPP peer can emulate a modem, or the user can try to locate a nullmodem.inf modem driver. Windows NT RAS also supports c:\winnt\system32\ras\modem.inf as the source for modem information, which users can edit and perhaps modify an entry into a null modem definition. Arranging RAS to use this file requires changing the registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\RAS\Protocols

Add the name EnableUnimodem of type REG_DWORD and value 0.

1. The installation procedure for ppp-2.3.5 and later versions of the Linux 2.0 series kernels may result in compilation errors for ppp.c. This requires you to forcefully copy ppp.c from the ppp-2.3.5 distribution to the kernel source tree. Furthermore, Linux version-checking statements in ppp.c pertaining to FREE_SKB may also require repair.

2. When Windows NT asks, Do you wish to use DHCP? for TCP/IP, select No.

oreilly.com Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
 International | About O'Reilly | Affiliated Companies | Privacy Policy

© 2001, O'Reilly & Associates, Inc.