Using & Managing PPPBy 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
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:
- Access telephone numbers; users should select a number in their local dialing area, if possible
- Username and password
- Interactive procedure, if any, to select PPP communications mode, after dialing in
- Authentication methods and procedures; some services require authentication before PPP begin; others request authentication within PPP
- The method for assigning IP addresses at both the user and service provider endpoints of a PPP connection
- The IP addresses of DNS servers, necessary for users to resolve hostname to IP addresses
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
After PPP starts, we assume the following:
- Users must authenticate themselves again with a PPP authentication method
- The communications server assigns the IP addresses for both endpoints of the connection
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:
- Configure serial interfaces.
- 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.
- 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.
- Configure PPP. This step may also include arranging authentication within PPP.
- Configure TCP/IP. This includes IP addresses and routing.
- 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.
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:
- EzPPP (Jay Painter)
- PPPSETUP (Kent Robotti)
- TkNet (Charlie Kempson)
- X-ISP (Dimitrios Bouras)
- XPPP (Peter Hofmann)
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.
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# 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/
Be sure to review the README files since they contain information useful for the installation process.
configureutility identifies the Unix platform type and sets up the necessary links to compile PPP-2.3. Here is the result:
Creating links to Makefiles.
Makefile -> linux/Makefile.top
pppd/Makefile -> Makefile.linux
pppstats/Makefile -> Makefile.linux
chat/Makefile -> Makefile.linux
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 kernelin the PPP-2.3 directory performs this task:
root# make kernel
cd linux; ./kinstall.sh
. . .
Installing into kernel version 2.0.30 in /usr/src/linux
. . .
Kernel driver files installation done.
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
- 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:
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 requires executing
makeat the top of its software distribution directory:
cd chat; make all
make: 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: Leaving directory '/usr/src/ppp-2.3.5/pppstats'
Now we can install the software. As the root user, execute
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
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
Do you plan to ONLY use loopback?
yesarranges the standalone network configuration. The resulting /etc/hosts file resembles the following code:
root# cat /etc/hosts
127.0.0.1 myhost.mydomain.org myhost
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
ppp1, etc. dynamically, whenever a PPP connection becomes active. However, no PPP interfaces should be active yet.
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
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
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
setserialutility 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 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
syslogdto record them. The
chatprograms produce facility
local2messages, respectively, at various priorities. Capturing these require the following lines in /etc/syslog.conf :
kill -1to the
syslogdprocess 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.
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
chatsucceeds, is a connection to a remote system that is ready for PPP.
chatis 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
chatconverses with the serial interface
pppdattaches to. When the
-voption is present, syslog receives messages about this conversation. Option
-findicates 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.
chatscript generally consists of strings to expect from and strings to send to a serial interface. Expect/send string pairs have spaces separating each string.
chatalso interprets certain pairs as command directives for
chatitself. A typical .pppchat file is:
ABORT "NO CARRIER"
OK "at dt 1 700 555 4545"
This chat script implements the dialog shown in Figure 6-2. The first two lines abort the script immediately if
chatreceives the word
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
CONNECTline are dial-in service-specific.
chatsupports 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
chatfrom misinterpreting them as multiple expect/send pairs. By default,
chatsends a carriage return after a send string, unless it ends with
\c. The reply following a
CONNECTis 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
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
Userpart of the string it expects immediately after the modem connects. A one-second delay after sending
pppgives time for the remote PPP to start before the user sends the first PPP frame.
pppdinvokes /usr/sbin/chat, users should configure
pppdand execute it to test and verify a chat script.
pppdrequires 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
pppdis /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
pppdoptions 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
Now create a .ppprc file as required for the PPP sign-on procedures (earlier section):
# Log PPP control frames to syslog
# Serial interface options
# Chat script
connect "/usr/sbin/chat -v -f $HOME/.pppchat"
# Link Control Protocol (LCP) options
# User name for PPP authentication
# IP Control Protocol (IPCP) options
# Use PPP peer as default gateway in system routing table
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,
pppdrequests 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
chatand its script file described previously arranges PPP startup at the remote end. As
noipdefaultindicates, the peer assigns both local and remote IP addresses.
defaultroutearranges 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
useroption defines the authentication name. However, the
remotenameis 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 *
The name and password to send is
mypass, respectively, whenever
*indicates any IP address is acceptable for this PPP connection.
Establishing the PPP Connection
pppdto initiate a PPP connection. Since configuration files reside in the user's home directory, it's important to execute
pppdas that user:
If an error message appears, it indicates an immediate fatal problem. Other problems are evident only in log files. With the
pppdgenerates extended messages for Linux syslog that appear in
/var/log/daemon, in our sample configuration.
chatmessages appear in /var/log/local2.
chatfirst controls the dial-up process. Successfully sending the string
pppat 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: abort on (BUSY)
. . .
Apr 7 22:59:20 myhost chat: send (ppp^M\d)
user$ cat /var/log/daemon
Apr 7 22:59:16 myhost pppd: pppd 2.3.5 started by user, uid 2001
Apr 7 22:59:23 myhost pppd: Connect: ppp0 <--> /dev/ttyS0
. . .
Apr 7 22:59:23 myhost pppd: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xfc86d8b7> <pcomp> <accomp>]
Apr 7 22:59:24 myhost pppd: sent [LCP ConfAck id=0x1c <mru 1500> <auth pap> <magic 0xa358edcc> <pcomp> <accomp>]
. . .
Apr 7 22:59:24 myhost pppd: sent [PAP AuthReq id=0x1 user="myname" password="mypass"]
Apr 7 22:59:24 myhost pppd: rcvd [PAP AuthAck id=0x1 ""]
. . .
Apr 7 22:59:24 myhost pppd: sent [IPCP ConfAck id=0x1d <compress VJ 0f 01> <addr 192.168.1.34>]
Apr 7 22:59:24 myhost pppd: rcvd [IPCP ConfAck id=0x2 <addr 192.168.1.35> <compress VJ 0f 01>]
. . .
Apr 7 22:59:24 myhost pppd: local IP address 192.168.1.35
Apr 7 22:59:24 myhost pppd: remote IP address 192.168.1.34
. . .
pppdreports 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
userinitiated it. Only the
rootis allowed to shut down
pppdand its corresponding connection.
When PPP is active, it alters the Linux computer's network configuration. The changes now include an additional active network interface,
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.
pppdautomatically 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
Now, any network activity via the PPP connection produces statistics visible with
IN PACK VJCOMP VJUNC VJERR | OUT PACK VJCOMP VJUNC NON-VJ
520 19 8 1 0 | 670 20 10 1 9
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
netconfigutility can help users set up these files. DNS with PPP is covered more fully in Chapter 10, Domain Name System.
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
idleoption 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
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: Connection terminated.
Apr 7 23:46:30 myhost pppd: Hangup (SIGHUP)
Apr 7 23:46:30 myhost pppd: Exit.
pppdterminates, it records disconnect messages in syslog.
pppdalso undoes other Linux system changes it made, if any. For example, it deletes the default route it previously created and removes the
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.
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:
. . .
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
swmtoolcan add Point-to-Point Protocol (
SUNWCppp) and Basic Networking (
SUNWCnet) software clusters. Together, these clusters include all the packages listed previously. Alternatively, the
pkgaddutility 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.
aspppdlogs 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
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
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
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
nscdrequires the Internet to cache DNS lookup results, for example. You may wish to disable this daemon as well.
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
Then perform a reconfiguration reboot or execute both
The device files with /dev/tty prefixes are for dial-in. If there are any inbound login services active (e.g.,
ttymonprocesses) 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."
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
Config Dialcodes Limits Sysfiles
Devconfig Dialers Permissions Systems
Devices Grades Poll remote.unknown
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
ispas 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
ispoccurs 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-ecappearing in Dialers.
If the modem successfully connects, chat returns to the Systems file and interacts directly with remote system
ispaccording 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)
Delay two seconds
Pause, 1/4 to 1/2 second
Carriage return (CR)
Line feed (LF)
Suppress carriage return at end of string
Substitute telephone number string
Substitute telephone number after translating it using the Dialcodes file
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-ecentry in the Dialers file has a
STTY=rtscts,crtsxoffdirective as a send string. These are serial interface parameters that enable hardware flow control. In UUCP chat script files, any parameter the Solaris
sttyutility supports can follow
Now that we have a chat script configured for PPP, the next step is testing it. The
cucommand 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,
cufunctions as a terminal emulator. Here, we request
cuto connect with
ispin the Systems file. A
-denables debugging and shows chat activity. By default,
cuexecutes 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.
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
aspppdat boot time.
The file /etc/asppp.cf consists of two parts. At the top are one or more
ifconfigcommands that establish PPP network interfaces. These interfaces may have names ranging from
ipdptp63, and many can exist simultaneously. Each
ifconfigstatement at minimum must include
plumb, a local IP address for the PPP connection, a remote IP address, and
up. Additional options to
ifconfigappear 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 188.8.131.52 184.108.40.206 up
# PPP network interface
# Name of remote system, the PPP peer, as defined in /etc/uucp/Systems
# LCP options
# PPP authentication with PAP
# IPCP, permit our peer to establish our local IP address
# TCP/IP, use PPP peer as default gateway
A path section consists of the word
pathfollowed 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
peer_system_namekeywords. The values of these associate the PPP network interface
ipdptp0to the remote system
ispin 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,
aspppdautomatically negotiates with its peer for PPP magic numbers, protocol field compression, address/control field compression, and MRU 1500.
default_routeis 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_routeoption creates and destroys the default route entry in the routing table for each PPP connect and disconnect cycle. If the remote system
isprequires our PPP authentication credentials,
will_do_authentication papindicates 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 220.127.116.11) unless the
negotiate_address onoption appears. This permits
ipdptp0to 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
startargument (you can use
stopto stop PPP):
root# /etc/init.d/asppp start
This executes all the
ifconfigcommands in /etc/asppp.cf and starts
aspppdis already active, you must issue a
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
Establishing the PPP Connection
Solaris PPP remains idle until a user routes outgoing IP datagrams to the workstation's PPP network interface.
aspppdinitiates 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
ifconfigutility serves this purpose:
user$ ifconfig ipdptp0
ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 8232
inet 18.104.22.168 --> 22.214.171.124 netmask ff000000
UPeven though its modem isn't yet active. To actually initiate PPP, we can route IP datagrams through
pingto the dummy IP address, 126.96.36.199. This is the current, remote (far end) IP address for
ipdptp0, even though PPP is not yet active.
user$ ping 188.8.131.52
pingtriggers 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
aspppdencounters 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
Trying entry from '/etc/uucp/Systems' - device type ACU.
. . .
. . .
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=184.108.40.206
16:24:04 start_ip: IP up on interface ipdptp0, timeout set for 600 seconds
. . .
Examining the PPP network interface
ipdptp0confirms 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 220.127.116.11 --> 18.104.22.168 netmask ff000000
aspppdto install a default route. As we expected, this route references the remote IP address for
user$ netstat -rn
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
127.0.0.1 127.0.0.1 UH 0 13 lo0
22.214.171.124 126.96.36.199 UH 2 0 ipdptp0
default 188.8.131.52 UG 0 0
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,
aspppdremoves the default route and closes the connection.
Reinstating the same PPP connection requires routing another IP datagram to the current
ipdptp0far-end IP address. Users may obtain this information again with the
ifconfigutility. Notice this IP address has changed since the last successful PPP connection. Now, it's necessary to initiate PPP with a
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,
aspppdmust 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_routeoptions in the /etc/asppp.cf configuration file. The permanent route can be the same as the one the
root# route add default 184.108.40.206 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 220.127.116.11 --> 18.104.22.168 netmask ff000000
root# route add default 22.214.171.124 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
ipdptp0local IP address at boot time. In this case,
126.96.36.199is the address to include in this file:
root# echo "188.8.131.52" > /etc/defaultrouter
It's also necessary to edit the startup file /etc/rc2.d/S69inet. The
route add defaultstatements 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
dnsin the name services switch file, /etc/nsswitch.conf. Chapter 10 presents more details about DNS and Solaris.
Solaris PPP maintains an inactivity timer and automatically shuts down a PPP connection that has remained inactive for a preconfigured time. The
inactivity_timeoutoption 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
aspppdcan still reestablish PPP connections on demand. Permanently disabling all PPP service requires permanently terminating the
root# /etc/init.d/asppp stop
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.
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
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
Configuration. Items necessary for PPP are:
Client for Microsoft Networks
Dial-Up Adapteris a network adapter that operates over a serial interface with an attached modem. If this adapter is missing, users should select
Dial-Up Adapterappears 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
TCP/IPalso appears under manufacturer
Microsoft. Users must select this and any others as necessary. After installation, these protocols appear in the main
Networksprovides 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
Modemsicon. This invokes the main
Modems Propertieswindow that appears in Figure 6-4.
Modems Propertiesmanage 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
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 Propertiesalso includes a
Dialing Propertiesbutton. This establishes dialing procedures for the user's telephone service. Another
Propertiesbutton 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
withinshould 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.
(RTS/CTS)whenever possible. In Windows 95, there is also a checkbox to
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,
Log, controls whether Windows 98 overwrites or appends the log file for each new PPP call.
Users should beware that
Modems Propertiesmostly set defaults only. A dial-out PPP configuration users define for a specific remote server can override many of the settings that appear in
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
Networkicon 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
Propertiesshould remain at their defaults. The only exception is the setting for recording PPP frame traces, useful for debugging. The
Propertiessettings are as follows:
- Driver Type tab
- These are Windows 98 system-specific settings. Be sure to set to
- 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
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
WINS, and others. The presence of these
Propertiesis 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
Propertiessettings here untouched (leave as defaults) in the
Networkcontrol 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 Propertieshere should show the following:
IP Addresstab must show
Obtain an IP address automatically.
WINS Configurationtab must show
Disable WINS Resolution.
Gatewaytab must show blank entries.
Bindingstab may show Windows 98 network client services associations to the TCP/IP protocol. Leave these as is.
Advancedtab doesn't have any settings. However, a checkbox enabled for
Set this protocol to be the default protocolmay appear.
DNS Configurationtab must show
Configuring Dial-out PPP Connections
Users manage PPP connections through the Windows 98
Networkingfolder. The default locations to access this folder are the
My Computericon on the desktop, and the
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.
Connectionshows a menu that includes
Properties. This invokes the windows (Figure 6-7) necessary to configure dial-out PPP. The
Generaltab lists all the general information Windows 98 prompted for, when it initially created the
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
Optionstab 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.
Server Typestab (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
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:
- STAC option 4
- Microsoft Point-to-Point Compression Protocol (MPPC)
PPP compression methods are independent of modem compression. E
nable software compressionmay 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:
- Microsoft CHAP (MS-CHAP)
- Shiva PAP (SPAP)
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 passwordis 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 encryptionoption 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.
connectionenables PPP trace logging. The PPP trace logs are almost identical to those users can obtain by enabling
Record a log filein the
Properties(Figure 6-5). The difference is that this setting enables logging for a PPP connection to this specific remote server. In contrast,
Propertiesare 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.
Server typestab includes a
TCP/IP Settingsbutton. 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
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
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.
addresseswon'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 compressionoften, 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 networkarranges 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 Networkingfolder (Figure 6-6). They then double-click the icon representing the remote system they wish to dial-in. This causes a
Towindow to appear, as Figure 6-10 shows.
Figure 6-10. Windows 95 initiating a PPP connection
Connect Toincludes fields for users to fill in their authentication credentials. DUN uses the
Password:information for any one or more of the following:
- As part of a dial-up script that requires this authentication data
- As the name and password for authenticating with PPP password authentication methods (either PAP or SPAP)
- As the name and key for authenticating with PPP challenge handshake authentication methods (either CHAP or MS-CHAP)
Save passwordstores user credentials for future dial-in sessions. The
Phone numberenables temporarily telephone number changes for this dial-out connection. Once all the information that appears in the
Connect Tois satisfactory to the user, he selects
Connectto initiate dial-out PPP to
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
Disconnectbutton 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:
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.
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
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
modemoption (in the
Connectiontab) arranges on-demand PPP. Users of Windows 95 may not find the Internet icon. In this case, they can obtain the icon and the
Propertieswindow 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.
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
dialingduring the PPP connect process.
Establishing a Windows 98 DUN script consists of creating a script file for a PPP connection icon (such as
Connection), which appears in the
Dial-Up Networkingfolder. The properties for the PPP connection includes a
Scriptingtab, 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
notepadas 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:
Windows 98 replaces the predefined
$PASSWORDvariables with their respective values in the
Connect Towindow (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
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 Propertiesconfiguration 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:
- Install a modem information file (.inf file), which includes a definition for a null modem
- Arrange the PPP peer to behave as a modem would, to satisfy Windows 98's need to interact with a modem
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.
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 Modemin
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
dialingis 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
# read "AT"
read line; echo "OK"
# read "ATE0V1"
read line; echo "OK"
# read "AT"
read line; echo "OK"
# read "ATDT17005554545"
read line; echo "CONNECT"
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.
Dial-out PPP requires Windows NT 4.0 Workstation to have networking services installed. Users can install it by selecting the
Networkicon 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?
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 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
Protocols. Access to the Internet requires TCP/IP.
- Serial interfaces and modems
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
Remote Access Servicedoesn't appear in
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 C
onfigurebutton to mark a modem and serial interface pair for dial-out use. The
Networkbutton 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 Setuprequire 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
Services. The active ones are:
- Remote Access Autodial Manager
- Remote Access Connection Manager
Another process is
Remote Access Server, but this serves only dial-in PPP.
Managing the Dial-up Networking Phonebook
Dial-Up Networkingis the main Windows NT 4.0 Workstation window for managing dial-out PPP connections. Users can access
Dial-Up Networkingby 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
Morebutton 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
X.25. These settings appear when users select
Edit entry and modem properties...under the
Moremenu in the
Dial-Up Networkingmain window. Online help is available by selecting
Moremenu. 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
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
Basictab 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
Access Setup. In addition, the
Dial using:field may include a special
Linesselection, 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
Configurebutton 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
Dial-up server type:in the
Servertab (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 protocolslisted, 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
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 extensionscauses Windows NT to try to negotiate several enhanced PPP options. Some of these are:
- Request LCP "Call Back" configuration option.
- Send LCP identification with string
MSRASV4.00to peer. Also send an LCP identification string with the Windows NT hostname.
- Request various multilink PPP options. This happens on Windows NT without service pack patches.
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.
After a modem completes its connection, the
Scripttab 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 windowsetting (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.
Nonesetting is suitable for remote systems that don't require any interaction to start PPP communications.
The Phonebook maintains a
Securitytab (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 authenticationis checked, Windows NT authenticates only with Microsoft CHAP and refuses all the others.
Accept only encrypted authenticationallows methods that don't transmit passwords in clear text. Finally,
textallows Windows NT to authenticate with any method it recognizes. For simple username and password authentication,
Accept anyis 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 encryptionand
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.
User preferencesmenu item in
Dial-Up Networking(Figure 6-15) has additional settings that affect dial-out PPP. Some preference items users can adjust are:
Dialingcounters and timers determine redialing behavior, when PPP connection attempts fail. Arrangements for on-demand PPP and PPP idle time-out also appear here.
Callback. Windows NT supports remote systems that impose PPP callback security. After establishing and terminating an initial PPP connection, these settings arrange a wait for callback.
Appearancecontrols cosmetic aspects of dial-up networking.
Phonebookdefines where to seek Phonebook entries. An arbitrary file may be set as the Phonebook.
Establishing a Connection
Selecting a Phonebook entry in
Dial-Up Networking(Figure 6-15) and pressing the
Dialbutton initiates a dial-out PPP connection. Windows NT usually displays PPP connection progress on-screen; users can suppress these messages in
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
mydomain, respectively, the name for PPP authentication purposes is
passwordretains 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
Securitytab (Figure 6-18) and select
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
Monitorin 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 Monitorand the
Dial-Up Networkingwindow 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 Propertiesincludes 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.
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 locationsetting in the
User preferences(see Figure 6-15) enables this feature. Another related
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:
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
regedt32utility and edit the following key:
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 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
scriptis enabled in the
Scripttab 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 scriptincludes 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
; Send nothing
; Wait for "Username:"
; Send user name from authentication window
; Wait for "Password:"
; Send password from authentication window
; Wait for "isp>"
; Send "ppp"
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
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:
Setting this value to
1and 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
Additional information about switch.inf and its script language appears in the online help for
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 PCsin
Modem Propertiesestablishes 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
CLIENTseveral 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:
Add the name
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_SKBmay also require repair.
2. When Windows NT asks,
Do you wish to use DHCP?for TCP/IP, select
© 2001, O'Reilly & Associates, Inc.