Morning Star PPP
Table of Contents
TABLE OF CONTENTS...... 1
WELCOME...... 8
INSTALLING PPP...... 9
OBTAINING SOFTWARE VIA FTP...... 9 OBTAINING SOFTWARE IN OTHER FORMATS...... 9 INSTALLATION INSTRUCTIONS...... 9 UPGRADING FROM A PREVIOUS VERSION OFMS PPP...... 9 SYSTEM-SPECIFIC DETAILS...... 10
LICENSE KEYS...... 10
CONFIGURING PPP TO TEST A CONNECTION...... 11
UNDERSTANDINGPPP CONFIGURATIONF ILES...... 11 Systems, Devices, and Dialers - An Analogy...... 12 ARRANGING FORO UTBOUND ANDI NBOUND PPP CONNECTIONS...... 13 OVERVIEW...... 13 THE OUTBOUND CONNECTION...... 14 Autostart - Starting ppp...... 14 Systems - Adding an Entry for Connecting to lark...... 14 Devices - Adding an Entry for Connecting tolark ...... 15 Dialers - Adding an Entry for Connecting to lark...... 15 Connection among the configuration files...... 15 THE INBOUND CONNECTION...... 15 Adding an account for robin to log in to lark...... 15 Creating robin's Login Shell Script...... 16 Checking Permissions...... 16 TESTING THE ROBIN-LARK LINK...... 17 ADDITIONALI NFORMATION...... 18 Non-Generic Login Scripts...... 18 Creating a Simple Filter File...... 18 Note on Systems and Devices Entries...... 19 IP ADDRESSES ON THEPPPD COMMAND LINE ...... 19 Soft Addresses...... 19 Dynamic address assignment...... 20 Address Selected From a Small List...... 20 Address Calculated From tty Name...... 20 TIME-TO-CALL RESTRICTIONS...... 20 DIAL-BACK...... 21 The Dial-Back Process...... 21 Blocking SIGHUP with the Chat Script \M Option...... 21 Reversing the Instructions with the \m Option...... 21 LINK PEER AUTHENTICATION...... 22 SECUREID...... 22 MS PPP Support for SecureID Systems...... 22 The Shell Script/xprompt/Chat Script Process...... 23
1 Morning Star PPP
REPLACING GETTY WITH PPPD...... 23 Invoking pppd under HP-UX...... 23 SERIAL CONNECTIONS...... 24
INTRODUCTION...... 24 SERIAL TRANSMISSION...... 24 Synchronous and Asynchronous Transmission...... 25 SERIAL INTERFACES...... 25 Signaling ...... 25 Cabling for Serial Interfaces...... 26 DB-25...... 26 DB-9...... 27 DB-9 to DB-25 Conversion...... 28 HP Modem Cables...... 28 HP Modem Cable (700)...... 28 HP Modem Cable (800)...... 30 SPARC MiniDin-8 Modem Cable...... 30 NeXT etc. MiniDIN-8 Modem Cable...... 31 Other Serial Connectors...... 31 Null-Modem Cables...... 31 DB-25 to DB-25 Null-Modem Connections...... 32 Mini-DIN to DB-25 Null-Modem Connections...... 32 DIAL UP MODEMS...... 34 Introduction...... 34 Speed...... 34 Data Compression...... 35 Error Correction...... 35 Flow Control...... 36 Enabling Hardware Flow Control Under HPUX...... 36 Adding the devices...... 37 Setting hardware flow control...... 38 A note on Series 700 and Series 800 serial ports...... 38 Enabling Hardware Flow Control Under SunOS...... 39 Patches to SunOS if You Suspect a Hardware Flow Control Problem...... 39 Enabling Hardware Flow Control Under AIX...... 39 Notes on Serial Ports under AIX...... 40 Modem Commands...... 40 S Registers...... 41 GENERAL RECOMMENDATIONS FORM ODEMS ...... 42 CONFIGURINGM ODEMS...... 43 Introduction...... 43 Telebit Modem Settings...... 43 COMPRESSION...... 45 HDLC Frame Compression...... 46 Address and Control Field Compression...... 46 Protocol Field Compression...... 46 Van Jacobson TCP Header Compression...... 46 PPP Link Compression...... 47 Predictor-1...... 47 Stac Compression...... 47 UNIQUE PPP IMPLEMENTATIONS...... 47 Synchronous PPP...... 47 Dedicated Lines...... 48 Automatic Failover...... 48 Setting up Automatic Failover...... 49 How Automatic Failover works...... 49 Constantly-Open Telephone Calls...... 49
2 Morning Star PPP
INTEROPERABILITY WITHO THER PPP IMPLEMENTATIONS...... 50 Introduction...... 50 Configuring Telebit NetBlazer...... 50 Using NetBlazer in a LAN Hub or ISP POP...... 50 Configuring the NetBlazer to receive the call...... 50 Configuring the UNIX system to dial the call...... 51 Configuring the NetBlazer to dial the call...... 51 Configuring the UNIX system to receive the call...... 52 PPP/SLIP COMPATABILITY WITHMS PPP ...... 52 Free UNIX-based PPP implementations...... 52 FTP Software Inc’s PC/TCP Network Software for DOS...... 52 Getting a UNIX system ready to receive a call from a DOS PC...... 53 Getting a DOS PC ready to dial into a UNIX system...... 53 HP LanProbe SLIP...... 53 KA9Q...... 53 SCO UNIX/ODT PPP...... 53 MS PPP INTEROPERABILITY WITHR OUTERS AND SERVERS ...... 54 Livingston Portmaster...... 54 Network Application Technology LANB-820...... 54 Novell LAN WorkPlace for DOS...... 54 Proteon cnx500...... 54 Xylogics Annex-3...... 54 Xyplex Terminal Servers...... 55 COMMON PPPD OPTIONS...... 57
LINK MANAGEMENT...... 57 Active vs. Passive PPP Negotiations...... 57 Outbound ...... 57 Inbound ...... 58 Idle Timer Link Control...... 58 When to Invoke the Timer...... 58 Setting Idle Timer Values...... 58 Limits for Outbound Calls...... 58 Limits for Inbound Calls...... 58 The exec option ...... 59 Exec arguments...... 59 Security...... 59 Parent environment and session variables...... 59 Example ...... 60 Login shell script...... 61 Executable shell script:...... 61 The SLIP framing option...... 61 Providing Addresses in SLIP mode...... 62 SLIP Data Compression...... 62 Using SLIP to dial a cisco terminal server...... 62 Link Quality Monitoring...... 62 How LQM Works...... 62 Guides for Evaluation of Link Quality...... 63 Adjusting LQM Behavior...... 63 Weighing the Costs of LQM...... 63 LQM Response to Link Failures...... 63 Total link Failure...... 63 Failure Without Disconnection...... 64 Peer Refusal to Comply with LQM Request...... 64 IP ROUTING TIPS...... 65
CONNECTING AH OST TO A LAN...... 65 Separate Network...... 65
3 Morning Star PPP
Proxy ARP...... 66 ARP Table Manipulation...... 67 CONNECTINGT WO LANS ...... 68 Connecting a host or LAN to the Internet...... 69 SECURITY TECHNIQUES...... 70
STATIC PACKET FILTERING...... 70 Introduction...... 70 The Foundations of Security Policies...... 70 Filter File Rulesets...... 71 Filter Basics...... 71 Ruleset Design...... 71 Hostname or IP Address...... 71 Default Rulesets...... 72 Ruleset Order...... 72 The Four Filters...... 72 Defined and Default Filters...... 72 Filter Stanzas...... 73 Use of the Exclamation Mark to Negate...... 73 Implicit Filter Endings...... 73 Packets Overview...... 73 IP - The Internet Protocol...... 74 ICMP - The Internet Control Message Protocol...... 74 TCP - Transmission Control Protocol...... 75 UDP - User Datagram Protocol...... 76 Recommended Reading...... 76 Building a Stanza - General...... 77 Building a Stanza - Specifics...... 77 Numbers and Addresses...... 77 Numbers with no Qualifiers...... 77 IP Addreses...... 77 Netmasks...... 78 Keywords with Numbers...... 78 IP Protocol keywords...... 78 Port Numbers...... 78 Port Numbers and Services...... 78 Numbered ICMP Messages...... 79 Keywords with Origins and Destinations...... 79 Keywords based on TCP Packet Header Bits...... 80 The ‘syn’ Qualifying Keyword...... 80 Using Other Keywords based on TCP Packet Header Fields...... 80 Keywords based on IP Options...... 81 The ‘frag’ Keyword...... 82 The ‘all’ Keyword...... 82 Time Based Keywords...... 82 The Unreach Keyword and Sending ICMP Messages...... 83 The Log and Trace Keywords...... 84 Stanza Syntax...... 85 Writing a Stanza - A Complex UDP Example...... 85 An Unsafe Domain Name System Rule...... 86 What Happens During Domain Name Queries...... 86 Developing Safer Domain Name Request Rules...... 87 An Exercise in Simplifying Rules...... 87 Step 1 Handling Domain Name Requests...... 87 Step 2 - Rules for Domain Name Requests from Applications...... 87 Step 3 - Matching Packets as Closely as Possible...... 88 Step 4 - Minimizing External Control of Data Passing through the Packet Filter...... 89 Conclusion ...... 90 Writing a Stanza - TCP Examples...... 90
4 Morning Star PPP
A Note about SYN Bits...... 90 Two Approaches to Filtering TCP connections...... 90 Identifying Rulesets with Hostnames and Addresses...... 90 A Note on Ruleset Formatting...... 91 Ordering Stanzas Effectively...... 91 Isolating an 'Incorrect' Stanza...... 91 Working with Default Rulesets...... 91 Open Policy Default Rulesets...... 92 A Note on Using the ‘log rejected’ Filter...... 92 Closed Policy Default Rulesets...... 92 Block All Packets...... 92 Block All Packets Except Electronic Mail...... 92 Limiting Electronic Mail to a Gateway Machine...... 93 Unresolvable Hostnames and Changing IP Addresses...... 93 Conclusion ...... 93 A Note - Blocking Loose Source and Strict Source Routing Options...... 93 A Complete Filter - Closed Policy - An annotated example...... 94 A Complete Filter - Open Policy - An annotated example...... 99 Common mistakes...... 102 Incorrect hostname...... 102 Incorrect Ruleset Indentation...... 102 Incorrect Use of 'tcp' and 'udp'...... 102 Attempting to Send Hostnames Requiring Resolution over Down Network Links...... 102 Failing to Allow Passage of 'ftp' Data Packets over the 'ftp-data' Port...... 102 Blocking Packets Required for Network Access...... 103 Example of Static Packet Filter Developed for Closed Policy...... 104 Example of Static Packet Filter Developed for Open Policy...... 106 APPENDIXES...... 107
TUN(4) PROGRESSIVE SYSTEMS ...... 107 NAME...... 107 CONFIGURATION...... 107 SYNOPSIS...... 107 DESCRIPTION...... 107 IOCTLS ...... 108 EXAMPLE...... 108 ERRORS...... 109 FILES...... 109 SEE ALSO...... 109 COPYRIGHT INFORMATION...... 109 PPP.AUTH(5) MS PPP...... 110 NAME...... 110 DESCRIPTION...... 110 SECURITY CONCERNS...... 110 FORMAT...... 110 EXAMPLE...... 111 SEE ALSO...... 111 COPYRIGHT INFORMATION...... 112 PPP.DEVICES(5) MS PPP...... 113 NAME...... 113 DESCRIPTION...... 113 FORMAT...... 113 EXTERNAL DIALER...... 114 EXAMPLE...... 115 CAVEATS...... 115 SEE ALSO...... 115 COPYRIGHT INFORMATION...... 115
5 Morning Star PPP
PPP.DIALERS(5) MS PPP...... 116 NAME...... 116 DESCRIPTION...... 116 FORMAT...... 116 CHAT SCRIPT PARTICULARS...... 116 EXAMPLE...... 118 SEE ALSO...... 119 COPYRIGHT INFORMATION...... 119 PPP.FILTER(5) MS PPP...... 120 NAME...... 120 DESCRIPTION...... 120 FORMAT...... 120 Hostnames and IP addresses...... 120 Four Keywords...... 121 Stanzas ...... 121 The Special Keyword ‘all’...... 121 Network Masks...... 122 Log Filter Keywords and Flags...... 122 The SYN Keyword...... 122 The ‘src’ and ‘dst’ Keywords...... 122 The ‘unreach’ Keyword...... 122 The ‘ip-opt’ keyword...... 124 EXAMPLES...... 124 Default Behavior...... 124 Internet Firewall...... 124 The ‘pass’ Lines...... 125 The ‘bringup’ and ‘keepup’ Lines...... 125 The ‘log rejected’ Line...... 125 An Extremely Complex Example...... 126 RECOMMENDATIONS...... 127 SEE ALSO...... 128 COPYRIGHT INFORMATION...... 128 PPP.KEYS(5) MS PPP ...... 129 NAME...... 129 RESTRICTIONS...... 129 DESCRIPTION...... 129 FORMAT...... 129 EXAMPLE...... 129 RECOMMENDATIONS...... 130 SECURITY CONCERNS...... 130 SEE ALSO...... 130 COPYRIGHT INFORMATION...... 130 PPP.SYSTEMS(5) MS PPP...... 131 NAME...... 131 DESCRIPTION...... 131 FORMAT...... 131 CHAT SCRIPT PARTICULARS...... 133 EXAMPLE...... 134 RECOMMENDATIONS...... 135 Retry and Backoff Times...... 135 Using the Default...... 135 Dedicated Lines or No-Cost connections...... 135 Bi-Directional Dial Up Modems...... 135 Specifying Host Names...... 136 Automatic Failover...... 136 SECURITY CONCERNS...... 136 SEE ALSO...... 136
6 Morning Star PPP
COPYRIGHT INFORMATION...... 136 PPPD(8) MS PPP...... 137 NAME...... 137 SYNOPSIS...... 137 DESCRIPTION...... 137 DAEMON MANAGEMENT OPTIONS...... 137 COMMUNICATIONS OPTIONS...... 139 LINK MANAGEMENT OPTIONS...... 141 IP OPTIONS ...... 143 AUTHENTICATION OPTIONS...... 144 ENCRYPTION OPTIONS...... 144 MICROSOFT COMPATIBILITY OPTIONS...... 145 LOG FILE...... 145 SIGNALS...... 146 EXAMPLE...... 147 RECOMMENDATIONS...... 147 ENVIRONMENT...... 147 SECURITY CONCERNS...... 148 STANDARDS CONFORMANCE...... 148 SEE ALSO...... 148 CREDITS...... 148 COPYRIGHT INFORMATION...... 148 TROUBLESHOOTING GUIDE...... 149 FATAL ERROR MESSAGES...... 149 PPP DOESN'T CONNECT...... 150 AIX ...... 152 NEXTSTEP...... 153 SUNOS...... 153 SOLARIS ...... 153 HP-UX...... 153 COMMON PPP CONNECTION PROBLEMS...... 153 PERFORMANCE ISSUES...... 156 ROUTING ISSUES...... 157 SYSTEM SPECIFIC...... 158 NeXT...... 158 SCO...... 158 SUNOS...... 159 GLOSSARY...... 160
BIBLIOGRAPHY...... 164
RELEASE NOTES...... 165
INDEX...... 175
7 Morning Star PPP
Welcome
Thank you for choosing Progressive System's Morning Star PPP software.
From before the commercialization of the Internet, Morning Star PPP has been the connectivity tool of choice for thousands of UNIX experts everywhere. Nowhere can you find as reliable a connectivity tool than here at Progressive Systems.
Whether building a corporate Intranet, a Server in providing Internet Services, or simply as a client to the Internet, Morning Star PPP is your only choice for fast, versatile, and reliable connectivity.
We hope you'll find that Morning Star PPP provides you with the utmost quality and flexibility. We here at Progressive take pride in the job that we do, and the products that we produce. If you'd like to tell us how we've done, whether you comments are good or bad, we'll appreciate hearing about it.
Send feedback to:
[email protected] or by calling 1.800.558.7827
Thank You,
Progressive Systems
8 Morning Star PPP
Installing PPP
Obtaining software via ftp
Morning Star PPP is available via anonymous ftp from Progressive Systems, Inc. Ftp to ftp.Progressive-Systems.Com (206.236.37.16) and log in with the user id “anonymous”, giving your email address as the password. Most files are in a publicly accessible directory, except for x86 architectures. All x86 platforms require passwords which can be obtained by contacting our sales department and providing them with a zero dollar purchase order.
If you received the software via FTP, it is a compress(1)ed tar(1) archive. The naming convention of these files is as follows, MS-os-architecture-ppp-pppversion.tar, MS-os- architecture-ppp-pppversion.README and MS-os-architecture-export-ppp-pppversion.tar (for versions exported outside the United States and Canada).
Obtaining software in other formats
If you are unable to ftp the software, it is also available on 3.5 diskette and on CD. Contact our sales group if you need the software in one of these formats.
Installation instructions
The README files contain system specific installation procedures, configuration details and other system specific tips. All READMEs can be downloaded from our anonymous ftp site, ftp.Progressive-Systems.Com (206.236.37.16) in the pub/ppp directory with the naming convention, MS-os-architecture-ppp-pppversion.README.
Upgrading from a previous version of MS PPP
System specific upgrade instructions are also included in the READMEs described above.
9 Morning Star PPP
System-Specific Details
First, read the file named README that came with the software distribution for your system. The configuration files used by Morning Star PPP are identical in name and format, regardless of the underlying operating system. The chart below shows where to find the PPP daemon itself and what directory the PPP log is written to. You’ll also find a listing of the system specific information needed to construct a license key for each system.
Hardware OS Key pppd pppd.log Max Sessions HP 9000/[78]00 HP-UX 10.* hostname /usr/sbin/pppd /usr/adm 128 uname -a NeXT NeXTStep 3.3 hostname /usr/etc/pppd /usr/adm 128 hostid RS/6000 AIX 4.1/3.2.5 hostname /usr/sbin/pppd /usr/adm 128 uname -m SPARC Solaris 2.* showrev /usr/sbin/pppd /var/adm 64
SPARC SunOS 4.1.* showrev /usr/etc/pppd /usr/adm 128 x86 BSDI 2.* hostname /usr/sbin/pppd /var/log 128 x86 NeXTStep 3.3 hostname /usr/etc/pppd /usr/adm 128 x86 SCO OSR5 hostname /usr/lib/ppp/pppd /usr/adm 64 x86 Solaris 2.* showrev /usr/sbin/pppd /var/adm 64 x86 Unixware 2.* uname -X /usr/sbin/pppd /usr/adm 64
The location of $PPPHOME is now /etc/ppp on all systems except SCO where it is /usr/lib/ppp. Versions which support up to 256 simultaneous connections are available for Solaris and Unixware.
License Keys
If you are upgrading your system from any 1.4* release you will need to obtain a new license key to run MS PPP 2.0. All upgrades are free with a current support contract, otherwise there is a $50.00 US upgrade fee. A one year support contract can be purchased for $100.00 US.
To acquire a license key to run MS PPP version 2.0 on your system, install the software and run the command "pppd key-info", complete the required information, and send it to our keys group. If you are unable to run this command please fill out the following information and return it to us via email or fax. Please reference the table above for obtaining information needed to construct a license key on each type of system.
10 Morning Star PPP
Support Number: Contact Name: Company Name: Telephone: Fax Number: Email Address: Postal Address: Hardware Type: OS Version: Hostname: Serial Number: PPP Version:
If you're using MS PPP on a demonstration basis, the key will allow the PPP to run on your system for 30 days from the date the key was created. Upon receipt of your purchase order, a 45 day key will be sent. After payment is received, a permanent key will be issued, allowing MS PPP to run on your system indefinitely.
Any inquiries regarding license keys should be sent to
[email protected] or by fax to +1 614 326 4601
Configuring PPP to Test a Connection
Understanding PPP Configuration Files
These files listed below may have been installed with your operating system. If not, examples of the files were. The example files end in the extension .ex, i.e., Systems.ex. Create the Systems and Devices files and copy the lines you wish to use from the example files.
Autostart starts pppd’s for on-demand outbound calls. Login is used for inbound ppp calls. The following files are used for outbound ppp calls:
· /etc/ppp/Autostart · /etc/ppp/Systems · /etc/ppp/Devices · /etc/ppp/Dialers
Inbound ppp calls use one file:
· /etc/ppp/Login
Systems, Devices, and Dialers - An Analogy This illustration may help describe how the Systems, Devices, and Dialers files work in conjunction to allow an on-demand outbound connection. Consider the analogy that can be
11 Morning Star PPP drawn between the communication needs of a small business and the needs of a system which supports PPP connections.
Before opening the business, the owner assesses the company's communication needs. Obviously, its telecommunications system must support on-demand communications and inbound and outbound calling. The list of communications needs includes:
· a means to access communications facilities · a device to provide an interface to the communications network · an efficient means of storing and dialing frequently dialed numbers · a list of those with whom the business may interact
How are these pieces of the business's telecommunications system analogous to the pieces of the PPP configuration? The table below provides the answer:
Need Pizza Business System PPP Configuration Communications access a line to the telephone the same company's local switch over which inbound and outbound calls are transmitted
Could also need a dedicated Could also handle a line for security alarm dedicated, or Direct connection
Interface device the telephone to answer or the system's modem place calls (device), listed in the PPP Devices file
Memory for dialing the telephone's memory for the PPP Dialers file information storing numbers for one- containing modem dialing touch dialing instructions
List of potential a telephone directory the PPP Systems file communications partners including numbers, containing numbers, logins, addresses, and contact and passwords names
Of course, the contemporary business could have many other communications needs, such as voice mail, fax machines, internet service, etc. But those listed in the table are, at least, supportive of outbound, dialed connections. Hopefully they help illustrate the way the Systems, Devices, and Dialers files support on-demand, outbound PPP connections.
Arranging for Outbound and Inbound PPP Connections Throughout the following examples the local machine running MS PPP will be called robin. The peer, or remote neighbor, with which robin will establish an outbound connection to is called lark.
If you follow the steps outlined below, substituting names and addresses for your own local and remote machines, you will be able to test a simple PPP connection. These procedures are not comprehensive and contain minimal instructions about such things as setting up a packet filter for security. This, and configuration of other important PPP options, such as Link Management, Data Compression and Authentication, are explained elsewhere, and the manual pages in the appendix contain details on incorporating those features, and more, in your PPP configuration.
12 Morning Star PPP
Overview
The steps for setting up an outbound PPP connection include:
· Creating robin's Autostart file · Adding entries to robin's Systems and Devices files
The steps for setting up an inbound PPP connection include:
· Adding an entry to lark's /etc/passwd file which contains robin's password · Creating robin's login shell script, in this case, called /etc/ppp/Login
When these steps are completed and the system is re-booted, this chain of events will occur:
1. Autostart starts the ppp daemon for an on-demand connection from robin to lark 2. If IP traffic is initiated to lark, pppd will dial out to lark as follows. 3. The ppp daemon searches the lines of the Systems file looking for an entry in the name field which matches lark's hostname or IP address. 4. When the match of hostname or IP address is made, the Systems speed field provides an index to an entry in the Devices file with a matching speed. 5. The dialer field in Devices file provides an index to an entry in the Dialers file 6. Lark's phone number is dialed 7. Robin's chat script (in the Systems file) sends robin's login name and password to lark 8. Lark verifies robin's password by comparing it to the entry in in the /etc/passwd file 9. If the login is successful, /etc/ppp/Login will be run. 10. Login will start pppd on lark which will communicate with the pppd on robin The two pppd’s will negotiate and establish a PPP connection.
The Outbound Connection
Autostart - Starting ppp When robin is booted, a PPP daemon will be started for the outbound link to lark. There is no example Autostart file; you must create it. It contains the one line necessary to start pppd. In our example, here’s what we would put in Autostart.
pppdrobin:lark auto idle 150
The pppd started here has this connection configuration: local and remote hosts robin and lark daemon management option respond to the arrival of a packet by initiating a connection to peer (auto) link management option idle timer in effect (idle) idle timer value shut down the link if 150 seconds pass without receiving or transmitting a packet.
13 Morning Star PPP
Systems - Adding an Entry for Connecting tolark Add this line to robin's Systems file:
lark Any ACU 19200 5551212 in:--in: Probin word: mypasswd
FOR INFORMATION ABOUT HOWS YSTEMS AND DEVICES ENTRIES ARE MATCHED, SEE THE NOTE AT THE END OF THIS SECTION This line provides this configuration for robin's connection to lark: call what host lark when Any day and at any time (Any) using what device Any Call Unit that matches the speed listed in the next field (ACU) at what DTE speed 19200 bps (19200) at what telephone number 5551212 expect what string in: substring of login: if true, send next field. If false, send string between dashes followed by carriage return and expect in: Can be used to elicit a response out of peer. send what string send Probin followed by a carriage return (implicit) expect what string word: a substring of password : send what string mypasswd followed by a carriage return (implicit)
Devices - Adding an Entry for Connecting tolark Add this line to robin's Devices file:
T1600 cuh00 19200 This line provides this configuration for robin's connection to lark: use what modem Telebit model 1600 (T1600) on which system device outbound device (cuh00) at what speed 19200 bps (19200)
Dialers - Adding an Entry for Connecting tolark The Dialers file is already installed on robin. Here’s what the Telebit 1600 entry looks like:
T1600 ABORT NO\sCARRIER ABORT NO\sDIALTONE ABORT BUSY \ ABORT RRING\r\n\r\nRRING\r\n\r\nRRING ABORT ERROR \ TIMEOUT 5 "" AT OK-AT-OK ATS111=0DT\T TIMEOUT 60 CONNECT This elaborate dialer string will cause pppd to abort the connection attempt if any of several things go wrong with the telephone call, then will disable UUCP spoofing in the modem before dialing the destination telephone number. Look through the Dialers file for modem entries for your type of modem. If none are defined, use the dialer entry “GENERIC”.
14 Morning Star PPP
Connection among the configuration files The peer’s machine name, lark, is used as an index into the Systems file. The first matching entry found is used. The DTE speed in the Systems file is used as an index into the Devices file. Lastly, the dialer entry specified in the Devices file is used as an index into the Dialers file.
The Inbound Connection
Adding an account for robin to log in to lark. Although lark may not initiate outbound calls, and therefore may not have to start pppd at boot time, it does need to be prepared for an inbound connection from robin. To do this, add this entry to lark's /etc/passwd file and execute the following command:
Probin::105:42:Robin's PPP login:/etc/ppp:/etc/ppp/Login
# passwd Probin New password : some password Retype new password : some password #
The '105' in the password entry is a unique user ID (uid) for this PPP login. The '42' is the group ID (gid) associated with the 'ppp' group in lark's /etc/group file.
Creating robin's Login Shell Script Robin's PPP user's login shell script can be located anywhere and named whatever you choose. For purposes of this illustration, the login script will be /etc/ppp/Login.
Look carefully at the last line in the sample script shown below before you create the file and manually add the lines. Notice that the word 'hostname ' is surrounded by backquotes, not regular quotes or apostrophes. `hostname`, with the backquotes, tells the system to insert the output of the command hostname(1) in this space in the pppd command line. We recommend that you make sure backquotes are used by copying this script from /etc/ppp/Login.ex, rather than inserting them manually.
#!/bin/sh
# PPP login shell example
PATH=/usr/sbin:/usr/etc:/etc:/bin PPPHOME=/etc/ppp export PATH PPPHOME
mesg n stty -tostop exec pppd `hostname `:robin idle 150 hostname will return lark, the current machine and robin is the peer. The idle timer is set to 150 seconds.
Checking Permissions Following the creation of the shell script , make sure the script is exec utable with the following command:
15 Morning Star PPP
# chmod 755 Login
Lark's PPP daemon should be mode 4750, meaning it is suid root and executable by members of its group, but not by general users. Perform this test to find out if this is true:
# ls -l /usr/sbin /pppd
The results should look something like this:
-rwsr-x--- 1 root ppp 338527 Oct 2 07:37 /usr/sbin /pppd If not, use chmod and chown to change mode and ownership as follows:
# chmod 4750 /usr/sbin /pppd # chown root /usr/sbin /pppd # chgrp ppp /usr/sbin/pppd
Testing the robin-lark Link The PPP configuration is now complete. Follow these steps to test the outbound connection from robin to lark.
1. You can either reboot your machine or run /etc/ppp/Sysinit to start pppd. Sysinit prepares your system for a ppp connection ensuring that the tunnel drivers are loaded and any OS specific parameters have been set. For systems that require a pppd to be started at boot time Sysinit will also execute the Autostart file.
2. Check to make sure pppd was started:
# more /usr/adm/pppd .log 8/4-14:14:43-14902 Morning Star Technologies PPP 8/4-14:14:43-14902 Version 2.0 8/4-14:14:43-14902 du0 : pppd robin:lark auto idle 150
3. Use telnet to bring up the link and type ^D to exit the login. There will be a half minute pause while robin dials the phone, the modems establish a carrier, the Systems chat script completes, the answering pppd is started on lark and the two pppd’s negotiate.
# telnet lark Trying lark... Pause
Connected to lark. Escape character is '^]'.
(Operating system) (lark) (ttyp3)
lark login : ^Dconnection closed by foreign host. The log file will be appended to and will show how the link was initiated:
8/4-14:14:53-14902 tcp 137.175.2.11/1204 -> 131.187.1.131 telnet 40 syn bringup 8/4-14:14:54-14902 Dialing lark (cuh00 38400 5551212 T1600) 8/4-14:15:23-14902 PPP connected to 131.187.1.131
This log file snippet shows that the telnet session to lark caused the link to be initiated.
16 Morning Star PPP
MS PPP is installed, configured, running and connected on both ends of our links. When the link is up, users should be able to access each peer machine using any TCP/IP application such as telnet, ftp, etc.
If either machine is connected to a local area network , you can set up IP routing on the two networks so that hosts on either network can communicate with hosts on the other, using machines on the ends of the PPP links as routers.
Additional Information
Non-Generic Login Scripts In most cases, all inbound PPP logins can use the same generic Login script. But if you want a host to start pppd with a special option like 'require authentication ', make that login account use a specific login shell tailored to that host. Call it /etc/ppp/Login-host, for example, and change the pppd line to reflect whatever options you wish to have.
exec pppd `hostname `:robin idle 130 requireauth
Creating a Simple Filter File Note: The filter file is not necessary for pppd operation. It is only discussed here as an example on how you might use the Filter file.
The MS PPP Filter file specifies the ways in which static packet filtering handles outbound and inbound TCP/IP packets. Though the filtering can be very complex if desired, a simple filter will suffice for demonstration purposes between robin and lark.
An example other than the one shown below is in /etc/ppp/Filter.ex and a lengthy explanation of static packet filtering is included in this manual.
Here is the Filter file to use for testing the robin-lark link:
default bringup !ntp !3/icmp !who keepup !send !ntp !3/icmp !who pass !route log !nntp tcp/syn /recv
This filter says to: bringup the connection for any traffic other than: Network Time Protocol packets (!ntp) ICMP Network Unreachable messages (!3/icmp) packets from the in.rwhod daemon (!who) keepup the link for all packets except those sent by robin (!send) and those that will not bringup the connection (!ntp) (!3/icmp) (!who) pass all packets except for RIP routing messages between routed (!route) daemons log messages when an inbound TCP session is established (tcp/syn/recv) except for NNTP connections (!nntp)
17 Morning Star PPP
Note on Systems and Devices Entries In both Systems and Devices, pppd selects the first line that matches its search criteria. If the connection attempt fails while using the method described by that line, pppd will search for the next matching line. Pppd will report a failure only when all the criteria-matching lines have been tried and exhausted.
For example, suppose two lines in Systems differed only by the values in the telephone number field like this:
lark Any;50 ACU 38400 5551212 in:--in: Probin word: mypasswd lark Any;50 ACU 38400 5551223 in:--in: Probin word: mypasswd Pppd would first try to connect by dialing 5551212. If pppd received a BUSY from the modem, it would dial the second number, 5551223.
Similarly, suppose a host has two different modems attached which can be used for outbound calls. The Devices entries might look like this:
T3000 cuh00 38400 USRv32bis cul00 38400 Pppd would try to call out through /dev/cuh00. But suppose it's busy because an incoming UUCP connection is on /dev/ttya00. Pppd will try /dev/cul00 instead.
IP Addresses on thepppd Command Line
Soft Addresses If an IP address is input on the pppd command line, the address is offered during IPCP negotiations. However, at connection time, some terminal server s and other peers wish to assign an address for the host running MS PPP to use for the duration of the connection. Instruct MS PPP to allow assignment of an address that’s different from the one on the pppd command line, use a tilde (~) after the local ip address. For example:
pppd ‘hostname ‘˜:192.0.2.5 auto idle 300
FOR SLIP, SEE COMMON PPPD OPTIONS Because SLIP does not perform any IPCP negotiations, the tilde option will not function. See Common pppd Options for more information.
Dynamic address assignment When an answering pppd is invoked in Login, it is told a pair of IP addresses on the command line. In the Login script, use any means to decide what IP addresses are put on the command line. Have them looked up in a file or a database, calculated algorithmically based on the incoming connection's username or other distinguishing feature, or invoke a program to ask a BOOTP server. The pppd command line arguments provide the mechanism; your Login script provides the policy.
Address Selected From a Small List Here’s an example Login script that uses the tty name to guarantee uniqueness of the addresses it assigns. This works fine for a small installation with few modem server serial ports and a fairly static configuration.
18 Morning Star PPP
#!/bin/sh TTY=‘tty‘ case $TTY in /dev/tty1) IP=192.0.2.1 ;; /dev/tty2) IP=192.0.2.2 ;; esac exec pppd ‘hostname ‘:$IP idle 300
Address Calculated From tty Name This script also uses the tty name to guarantee uniqueness of the addresses it assigns. You must define ttyN in your /etc/hosts file, NIS hosts map, NetInfo hosts map, or DNS database, according to the system used. This works better in a larger installation with more ports and a configuration that tends to change more often.
#!/bin/sh TTY=‘/bin/basename \‘/bin/tty\‘‘ exec pppd ‘hostname‘:$TTY idle 300
Time-To-Call Restrictions The second field on each line in the Systems file specifies the times pppd is allowed to attempt to establish connections. Two benefits of time restrictions are: · assurance that there will always be personnel on each end of the link to monitor connection attempts · assurance that connections will take place when the most favorable telephone calling rates apply
SEE PPP.SYSTEMS(5) FOR DETAILS The when field is very flexible. It can be configured by day and by hour, with many different combinations allowed for the same connection. For example, the following entry allows connections on any day between 1 AM and 6AM or any time on Saturday and Sunday: lark Any0100-0600|Sa|Su ACU 38400 5551212 in:--in: Probin word: mypasswd
Dial-Back MS PPP supports the ability to maintain a connection when calling a modem which has a dial-back security feature. The Systems file chat script option \M allows this by disabling delivery of SIGHUP to pppd. This signal usually results from loss of Carrier Detect and tells pppd to abruptly disconnect from the active session.
The Dial-Back Process Typically, an answering modem with dial-back capability responds to a call by taking the following steps:
The modem · challenges incoming callers with a prompt string · accepts the input identifying the caller · hangs up the call · calls a number associated with the caller’s identification · re-establishes a carrier.
19 Morning Star PPP
The calling modem might then demand the same type of identification before allowing remote data to flow through its serial interface to the local system.
Blocking SIGHUP with the Chat Script \M Option
SEE PPP.SYSTEMS(5) FOR DETAILS ON\M AND \M CHAT SCRIPT OPTIONS The calling system’s pppd must be prepared for the temporary lack of a Carrier Detect signal from its modem during the dial-back from the remote modem. To avoid receiving a SIGHUP , pppd instructs the UNIX system’s serial drivers not to deliver the signal. In other words it says, “Temporarily treat the serial interface as if it were connected to a local device like a terminal or printer, instead of a modem.” Pppd does this by specifying \M in the ‘send’ phase of a Systems chat script.
Reversing the Instructions with the \m Option After the disconnection period, through the ‘send ’ phase option, \m, pppd tells the system’s serial drivers to reverse the first instruction and respect the modem’s full variety of control. For example, to dial into a system protected by a dial-back modem, the Systems chat script might be written like this:
# # This connects to a system protected by a Telebit T3000 callback # modem # with S46=2. # server Any ACU 38400 19071234567 TIMEOUT 60 \ ENTER\sPASSWORD: my_modem_password \M \ ENTER\SPASSWORD: my_modem_password \m \ ogin: my_login _name ssword: my_login_password
Link Peer Authentication Morning Star PPP implements both the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). If pppd is invoked with any of the authentication options, it will demand that the peer (either calling or called) authenticate itself. The Auth file contains pairs of either names and secrets for CHAP negotiation, or usernames and passwords for PAP negotiation. If a peer provides a name or username, its secret or password must match that found in the Auth file or the authentication phase fails and the connection is terminated. Each name/secret pair in the Auth file may be followed by address patterns restricting the peer’s negotiated IP address. If an address restriction is specified for a particular name and the peer’s negotiated IP address does not match the restriction address patterns, pppd will terminate the connection.
The rechap interval option instructs pppd to periodically (every interval seconds) challenge the peer to authenticate itself. If the peer fails the new challenge, the link is terminated.
SecureID Sometimes an incoming call must penetrate the answering machine’s SecureID system before it’s offered a login prompt. SecureID is a credit card sized device which provides the caller a code that matches one held by the answering system. The code changes frequently, but the card and the SecureID system are synchronized so that each has the same code at any given time.
20 Morning Star PPP
MS PPP Support for SecureID Systems MS PPP allows standard output from the xprompt program to populate a field in the Systems file. If you have xprompt and C compiler, you can develop the means to input the current SecureID code into your Systems chat script. Ultimately, the chat script passes the caller’s code to the SecureID system during the login process.
You can obtain the source for Xprompt via anonymous ftp at ftp.morningstar.com/pub/tools/xprompt.tar.Z.
Suppose the SecureID system answers incoming calls with the string ‘Identify Yourself!’, expecting the incoming user to type the secret string that appears on the user’s SecureID card. The Systems file entry for the calling system looks like this with an exec utable shell script called SecureCode in backquotes :
peer Any ACU 38400 5551212 self! ‘SecureCode‘ in: Pfoo word: bar
SecureCode is installed in the pppd’s search path set by the Autostart script that starts pppd. SecureCode would look something like this:
#!/bin/sh DISPLAY=:0.0 export DISPLAY prompt="‘tr -d "\015" | tail -1‘" /usr/local/bin/X11R4/xprompt -rlen 20 -p $prompt
The Shell Script/xprompt/Chat Script Process The integrated process described below provides a means for dialog between the user and the remote SecureID system. When pppd brings up the link on demand, the Systems chat script progresses until it sees ‘‘self!’’. These steps follow:
· The script invokes the SecureCode script · SecureCode, in turn, invokes xprompt · An xprompt window appears on the workstation’s screen · The user types the secret string into the xprompt window and hits a carriage return. · xprompt exits, putting that secret string on its standard output (stdout). · SecureCode exits, putting that secret string on its stdout.
When SecureCode, the command between the backquotes , exits, pppd reads the ouput from SecureCode and sends it across the modem to the SecureID barrier, just as if it had been typed directly by the user. If the string sent to the answering system matches the expected string, the user is identified and the expect/send couplets of the chat script continue.
Replacing getty with pppd Incoming calls most often invoke the getty program because it enables login on a serial port. However, in some cases, pppd can be invoked in place of getty. Invoking pppd offers additional security because people find the beginning of LCP option negotiations much more difficult to crack into than a simple ‘login:’ prompt. When the modem answers an incoming call and raises the Carrier Detect signal, the caller sees a burst of what looks like line noise.
Some UNIX systems’ serial drivers and configuration methods allow the administrator to specify any arbitrary program to be invoked in response to an incoming call, not just getty. For example, on a system running SunOS 4.1.*, /etc/ttytab could contain a line like
21 Morning Star PPP
ttya “usr/etc/pppd my-hostname: idle 120 rtscts requrechap \ netmask oxffffff00 38400 acct /var/adm/pppd.act” unknown on (This would all be one line in /etc/ttytab-it’s only broken here to fit on the page.) When the modem answers an incoming call and raises the Carrier Detect signal, the caller sees a burst of what looks like line noise, but is actually the beginning of LCP option negotiations. Most callers find this much more difficult to crack into than if they see a simple ‘login:’ prompt, but CHAP is still strongly recommended for security.
This option only works on systems which provide different tty devices for incoming and outgoing modem connections. Pppd does not implement the device locking techiques necessary to replace getty on systems without the dual-device trick.
Invoking pppd under HP-UX To trade pppd for getty, first use SAM to set up a getty on the serial port. When setting up the serial port through SAM, be sure to choose “Receive Incoming Calls (start getty process)”. This will add a getty (or uugetty) line to the /etc/inittab file. As an example, suppose the line added to /etc/inittab by SAM was:
a0:3:respawn:/usr/lbin/uucp/uugetty -r -t 60 -h ttyd0p1 19200
You can replace the uugetty with the pppd process and invoke it with any arguments you like. Example:
a0:3:respawn:/usr/sbin/pppd localhost: idle 120 requireauth ttyd0p1 19200
It should be noted that the device (ttyd0p1) and speed (19200) should be specified on the pppd command line as the ppp daemon needs to know what device to open and at what speed.
Note that Challenge Handshake Authentication Protocol (CHAP) is still strongly recommended for security.
Serial Connections
Introduction Properly installed and configured, MS PPP and your system's serial port connections allow you to transmit data to remote locations through a modem or null-modem cable. Modems convert the system's digital signals to the analog signals which are transmitted over telephone company equipment. Most systems are equipped with internal modems, although you can use a cable to connect an external modem or other system to a serial port.
This section on serial connections includes information about types of transmission, proper cabling between serial ports , and modem configuration. The information is general and the MS PPP manual is not a substitute for specific instructions that were provided with your
22 Morning Star PPP system and/or the modem you plan to use for dial up communications. The system and modem manuals should take precedence if you have any questions about configuration and equipment.
However, where possible, we have supplied advice derived from our testing of MS PPP on many types of equipment and operating systems.
Serial Transmission Serial transmission uses a single channel to send data as a series of signal elements over a span of time. Parallel transmission, the alternative, sends signal elements over multiple channels simultaneously. However, serial transmission is a better solution than parallel transmission over almost any distance. Parallel does work well when sending information from a workstation to a local desktop printer, because the machines can easily be connected by a six to ten foot cable with multiple transmission channels. However, it is usually prohibitively expensive to use long multi-channel cable for parallel transmission. Therefore, most data transmissions between remote locations are serial, including those supported by MS PPP.
Synchronous and Asynchronous Transmission Data transmitted serially must be recognizable, so, in some fashion, the remote end must be able to correctly separate the elements it receives. Simply, this becomes a matter of timing, which can be synchronous or asynchronous.
Synchronous transmission requires two perfectly matched external clocks. Each end of the connection times the transmission elements by its own clock. For example, each end agrees that a new message will contain a certain number of elements that will begin at a prearranged interval. Therefore, if the ends agree that new messages will begin every five seconds, the receiving end knows that each element it receives at five, ten, fifteen, and twenty seconds will be the start of a new message. The drawback to synchronous transmission is the necessity to keep the clocks at each end in sync with each other.
Asynchronous transmission does utilize timing, so it is not unsynchronous. But the timing is continuously reset using elements of the data transmitted. Through negotiations, each end agrees that a particular message will signal the start of a transmission. As in synchronous transmission, each message that is not a "start" message contains a certain number of elements, delivered at a prearranged interval. The difference is that a "start" message controls the timing, not two clocks which must be kept in sync. Timing begins when a "start" message is received. This prevents the decay of local and remote synchronization over time.
Serial Interfaces The de facto standard serial interface is a RS 232 port. The Electronics Industries Association's developed RS 232 standards in 1969 and they have been updated several times. Each pin, or wire, used by an RS 232 connection passes a particular type of signal between data terminal equipment (DTE ) and data circuit-terminating equipment (DCE ). DTE is the computer system and DCE is the modem.
Signaling The types of signaling carried by the RS 232 interface are listed below:
SIGNAL DESCRIPTION
23 Morning Star PPP
Signal Ground (SG) Common electrical ground path for all interface circuits
Transmit Data (TD) Command codes or data sent from DTE to DCE; won't be sent unless RTS, CTS, DSR and DTR are set to on
Receive Data (RD) DCE responses to DTE commands or data received from a remote DCE
Request To Send (RTS) Set to on, the DTE tells the DCE to remain in transmit mode; set to off, the DTE tells the DCE to receive
Clear To Send (CTS) Set to on, the DCE reports it is ready to receive; set to off, the DCE tells the DTE not to transmit
Data Set Ready (DSR) Set to on, the DCE reports it is ready to operate
Data Terminal Ready (DTR) Set to on, the DTE tells the DCE to connect to a communications channel; required to be on for automatic answering by DCE; set to off the DTE tells the DCE to break the connection when it has finished the current transmission
Ring Indicator (RI) Set to on, the DCE reports it detects the presence of a ringing signal on the communications channel; set to off the DCE indicates the absence of a ringing signal
Carrier Detect (CD) Set to on, the DCE reports receiving a signal from the communications channel that a connection can be established
Cabling for Serial Interfaces
DO NOT ATTEMPT TO The RS 232 standard utilizes 9 pins for signaling, although many serial interfaces provide 25. CONNECT A MODEM The other 16 pins can be used for testing or secondary signaling. Smaller, 9 pin connectors, WITH A SERIAL support standard signaling and save space. PRINTER CABLE. IT WILL NOT WORK.
DB-25 25 pin connectors, or DB-25, use pins 2 though 8 and pins 20 and 22 as shown:
PIN SIGNAL SIGNAL DIRECTION 1 Protective Ground both
2 Transmit Data (TD) from DTE
3 Receive Data (RD) from DCE
4 Request To Send (RTS) from DTE
5 Clear To Send (CTS) from DCE
6 Data Set Ready (DSR) from DCE
7 Signal Ground both
8 Carrier Detect (CD) from DCE
20 Data Terminal Ready (DTR) from DTE
22 Ring Indicator (RI) from DCE
24 Morning Star PPP
DB-9 Standard 9 pin connectors, called DB-9, use the following pin setup:
PIN SIGNAL SIGNAL DIRECTION 1 Carrier Detect (CD) from DCE
2 Receive Data (RD) from DCE
3 Transmit Data (TD) from DTE
4 Data Terminal Ready (DTR) from DTE
5 Signal Ground both
6 Data Set Ready (DSR) from DCE
7 Request To Send (RTS) from DTE
8 Clear To Send (CTS) from DCE
9 Ring Indicator (RI) from DCE
25 Morning Star PPP
DB-9 to DB-25 Conversion This wiring diagram shows the standard conversion from DB-9 to DB-25:
SIGNAL DB-9 PIN DB-25 PIN Carrier Detect (CD) 1 8
Receive Data (RD) 2 3
Transmit Data (TD) 3 2
Data Terminal Ready (DTR) 4 20
Ground 5 7
Data Set Ready (DSR) 6 6
Request To Send (RTS) 7 4
Clear To Send (CTS) 8 5
Ring Indicator (RI) 9 22
HP Modem Cables Most HP systems do not use straight through modem cables to connect the modem to the system. Make sure you are using the correct cable that is proper for your system. HP Modem Cable (700) The Hewlett-Packard 9000/700 series workstation provides a DB-9 port for connection to aysnchronous serial devices. Hewlett-Packard recommends you use their cable, part number 24542M to connect a 9000/700 system to a DB-25 asynchronous modem. A similar part number, 24542G describes a printer cable. Do not confuse the two part numbers if you order the Hewlett-Packard cable. If you cannot get the authentic HP part use a cable like the one described in the table below.
SIGNAL DIRECTION DB-9 PIN DB-25 PIN Carrier Detect (CD) from 1 8 Modem Receive Data (RD) from 2 3 Modem Transmit Data (TD) from DTE 3 2
Data Terminal Ready (DTR) from DTE 4 20
Ground both 5 7
Data Set Ready (DSR) from 6 6 Modem Request To Send (RTS) from DTE 7 4
Clear To Send (CTS) from 8 5 Modem Ring Indicator (RI) from 9 22 Modem
26 Morning Star PPP
HP Modem Cable (800) For an 800 series system with a model 5062-3054 MDP "Full Modem" connector panel use the HP part #40233A modem cable. If you cannot get the authentic HP part, use a cable like the one described in the table below.
CPU DIRECTION MODEM GND 1 BOTH 1 GND TD 2 from Modem 3 RD RD 3 from DTE 2 TD RTS 4 from Modem 8 DCD DSR 6 from DTE 20 DTR GND 7 BOTH 7 GND DCD 8 from DTE 4 RTS 9 from Modem 22 RI DTR 20 from Modem 6 DSR RI 22 from Modem 5 CTS
SPARC MiniDin-8 Modem Cable The serial ports on the Sun SPARCstation IPC/IPX have MiniDIN-8 connectors. Though they may look similar, these connectors are not the same as the connectors on Apple Macintosh products, and Mac modem cables will not work correctly with any of these MiniDIN-8 UNIX systems. A cable to connect a SPARCstation IPC or IPX systems to a DB-25 asynchronous modem are described in the table below:
SIGNAL DIRECTION SPARC DB-25 MINIDIN- PIN 8 PIN Data Terminal Ready (DTR) from DTE 1 20
Clear To Send (CTS) from Modem 2 5
Transmit Data (TD) from DTE 3 2
Ground both 4 7
Receive Data (RD) from Modem 5 3
Request To Send (RTS) from DTE 6 4
Data Carrier Detect (DCD) from Modem 7 8
N/C Receive Clock 8 N/C (sync only) Data Set Ready (DSR) from Modem N/C 6
Ring Indicator (RI) from Modem N/C 22
The serial ports on the NeXTstation, Tadpole SPARCbook, and Silicon Graphics Personal Iris have MiniDIN-8 connectors. Though they may look similar, these connectors are not the same as the connectors on Apple Macintosh products, and Mac modem cables will not work correctly with any of these MiniDIN-8 UNIX systems. A cable to connect one of these UNIX systems to a DB-25 asynchronous modem is described in the table entitled “NeXT etc. MiniDIN-8 Modem Cable” below:
NeXT etc. MiniDIN-8 Modem Cable
27 Morning Star PPP
SIGNAL DIRECTION SPARC DB-25 MINIDIN- PIN 8 PIN Data Terminal Ready (DTR) from DTE 1 20
Data Carrier Detect (DCD) from Modem 2 8 Transmit Data (TD) from DTE 3 2
Ground both 4 7
Receive Data (RD) from Modem 5 3 Request To Send (RTS) from DTE 6 4
N/C N/C 7 N/C
Clear To Send (CTS) from Modem 8 5 Data Set Ready (DSR) from Modem N/C 6 Ring Indicator (RI) from Modem N/C 22
Other Serial Connectors
Null-Modem Cables Two systems' serial ports can be directly connected by a null-modem cable. Null-modem cables connect pins of one machine to their symmetric counterparts on another machine. For example, pin 2, the Transmit Data (TD) pin of machine A, is paired with the pin 3, the Receive Data (RD) of machine B. If this is not done, both machines would try to use pin 2 to transmit data and neither could receive the others transmission. Sometimes only pins 2, 3, and 7 are connected in a null-modem cable, but hardware handshaking may require optional connections of other pins. Data Set Ready (DSR) and Carrier Detect (CD), pins 6 and 8, may be joined together and connect to the other machine's Data Terminal Ready pin, number 20.
The table below shows typical null-modem pin connections between two DB-25 ports.
28 Morning Star PPP
DB-25 to DB-25 Null-Modem Connections
DTE SIGNAL DTE DCE DCE SIGNAL PIN PIN Protective Ground 1 1 Protective Ground
Ground 7 7 Ground
Transmit Data (TD) 2 3 Receive Data (RD)
Receive Data (RD) 3 2 Transmit Data (TD)
Data Set Ready (DSR) & 6+8 20 Data Terminal Ready (DTR) Carrier Detect (CD)
Data Terminal Ready (DTR 20 6+8 Data Set Ready (DSR) & Carrier Detect (CD)
Request To Send (RTS) 4 5 Clear To Send (CTS)
Clear To Send (CTS) 5 4 Request To Send (RTS)
Mini-DIN to DB-25 Null-Modem Connections The serial ports on the NeXTstation, Tadpole SPARCbook, and Silicon Graphics Personal Iris have MiniDIN-8 connectors. A null-modem cable to connect one of these systems to another system that has DB-25 connectors is described in the table below:
DTE SIGNAL DTE DCE DCE SIGNAL PIN PIN Data Terminal Ready (DTR) 1 8 Data Carrier Detect (DCD)
Data Carrier Detect (DCD) 2 20 Data Terminal Ready (DTR)
Transmit Data (TD) 3 3 Receive Data (RD)
Ground 4 7 Ground
Receive Data (RD) 5 2 Transmit Data (TD)
Request To Send (RTS) 6 5 Clear To Send (CTS)
N/C 7 N/C N/C
Clear To Send (CTS) 8 4 Request To Send (RTS)
Data Set Ready (DSR) N/C 6 Data Set Ready (DSR)
Ring Indicator (RI) N/C 22 Ring Indicator (RI)
The serial ports on the NeXTstation, Tadpole SPARCbook, Silicon Graphics Personal Iris, and Sun SPARCstation IPC/IPX have MiniDIN-8 connectors. A null-modem cable to connect a pair of these systems is described in the table entitled “NeXT etx. Null-Modem Cable” below:
29 Morning Star PPP
DTE SIGNAL DTE DCE DCE SIGNAL PIN PIN Data Terminal Ready (DTR) 1 2 Data Carrier Detect (DCD)
Data Carrier Detect (DCD) 2 1 Data Terminal Ready (DTR)
Transmit Data (TD) 3 5 Receive Data (RD)
Ground 4 4 Ground
Receive Data (RD) 5 3 Transmit Data (TD)
Request To Send (RTS) 6 8 Clear To Send (CTS)
N/C 7 7 N/C
Clear To Send (CTS) 8 6 Request To Send (RTS)
Dial Up Modems
Introduction MS PPP works well with any number of brand-name, non-proprietary, dial up modems. Modems for dial up protocols like PPP should conform to non-proprietary standards because the local user will probably have little knowledge of the equipment at the remote end of the connection. A non-proprietary modem's ability to match carrier speed will make a usable connection with whatever type of modem is operating at the other end of a connection.
This section discusses, generally, a few features of modem performance and configuration. Beyond speed of transmission, these features include error correction , data compression, flow control, command mode, and S registers.
Speed This is the easiest feature to understand. The higher the number associated with the modem, the faster the data transmits. There are two ways to gauge modem speed. One figure, usually between 9600 and 28800 bps , measures the amount of data which can be transmitted or received between modems. The other, a much higher figure, perhaps 38400 to 115200 bps, describes data throughput between a system and its modem. You will use this type of speed when you configure MS PPP, choosing the highest modem throughput that can be supported by the system. Typically, this speed will be 38400. The figure can be found in the files /usr/include/sys/ttydev.h or /usr/include/sys/termio.h. This allows you to receive the maximum advantage of the modem's data compression capability.
Data Compression Enable data compression if your modem supports it, unless your application performs better without it. Data compression maximizes the amount of information crossing a PPP connection. Generally, executable (binary) files don't compress well and files which have been compressed before transmission are difficult to further compress, but most protocols provide at least 2 to 1 compression ratios for other types of data. Micrcom, Inc.'s Microcom Networking Protocol 5 (MNP 5) protocol can double the data transmitted, and MNP 7 offers
30 Morning Star PPP
3 to 1 compression. CCITT-sanctioned V.42bis can compress data 4 to 1 under the best conditions. If your modem offers a choice between an MNP protocol and V.42bis, choose the latter. In addition to having a better compression algorithm, it works better with precompressed data streams.
Run the serial port at its maximum speed to gain the most benefit from in-modem data compression. Usually this is 38400 bps. Some modem's data compression adds significant latency to data throughput, adversely affecting interactive responsiveness between local and remote users. Experiment with your modem and the type of data you transmit to find the best configuration.
MS PPP supports several other kinds of compression that work at different layers of the communications stack. For more information on the following types of compression supported by MS PPP, see the Appendix.
· HDLC Frame · Address, Control and Protocol Fields · Van Jacobson TCP Header · PPP Link · Predictor-1
Error Correction In addition to data compression protocols, Microcom, Inc. developed error correction protocols with similar names. Its MNP4 is one of two major protocols for error correction. The other is Link Access Procedure for Modems (LAPM). Many modems support one of the two, or both. Some manufacturers have developed their own proprietary error control protocols, but the CCITT V.42 standard requires a modem support MNP4 and/or LAPM to be compliant or compatible with the standard. The receiving and transmitting modems negotiate to discover the highest level of error correction protocol each can support.
Error correction verifies data that has traveled across the communications connection. Noisy lines destroy data in transmission, especially when the transmission is high speed . Depending on the protocol, bits, bytes or packets are subjected to some form cyclical redundancy check to ensure the integrity of the received data. The connection's receiving end informs the transmitting end when the data has been damaged. The protocol used determines whether just the corrupted data, or all data sent since the error was discovered, is transmitted again. MNP 4 and later protocols can also respond to poor transmission quality by causing the data to be shipped in smaller packets, increasing the number of checks and decreasing the amount of data corrupted by line bursts.
Flow Control Flow control provides the modem a buffer for storing received data from the system. This is beneficial because data transmission between the modem and system or between two systems connected by a null-modem cable, is much faster than transmission between modems. Flow control keeps system-to-modem data from being lost during the modem-to-modem transmission.
If your UNIX system supports it, use out-of band ‘hardware’ (RTS/CTS) flow control COMPUTER AND MODEM MUST USE between your system and your modem, or between two systems over a null-modem cable. THE SAME TYPE OF On most systems, specify ‘rtscts’ either on the pppd command line, or in the Optional FLOW CONTROL.
31 Morning Star PPP
Parameters field of the line in Devices(5). On a NeXT, specify ‘cufa’ in the Device field in Devices(5) and use the name “ttydfa” in /etc/ttys.
If, for whatever reason, you are forced to use in-band ‘software’ (XON/XOFF, ^Q/^S) flow control, then specify ‘xonxoff’ on the pppd command line or in Devices(5), and use ‘cua’ on a NeXT.
Flow control can be provided by system software or modem hardware . Although the MS PPP daemon's default status is no flow control, you should use hardware or software flow control if your system supports flow control. Hardware flow control is recommended.
Hardware flow control is managed by the Request To Send (RTS) and Clear To Send (CTS ) signals. If you use hardware control, make sure the connecting cable carries both signals. Also make sure the modem is configured for hardware flow control. Lastly, on a HPUX system, you must configure the device to use hardware flow control. Instructions on how to do this are below in the section Enabling Hardware Flow Control Under HPUX.
If you choose to use software flow control , then make sure the modem is configured for software flow control. You should also instruct pppd to use software flow control by using the option xonxoff either in the Devices file or on the pppd command line.
COMMUNICATIONS If you configure for software control, make sure both ends of the PPP connection have the BETWEEN SYSTEMS 0x000A0000 bits turned on in their Async Control Character Maps. This is the default for MS DIFFERENT FLOW PPP. A computer and modem using software flow control can talk to a computer and CONTROL METHODS modem using hardware flow control, but both ends must have the asyncmap set to accommodate software flow control.
Enabling Hardware Flow Control Under HPUX
The following example explains a common method for setting hardware flow control in HPUX 10.x 700 and 800 series machines. However, remember that HP technical support is the best resource for information about setting up hardware flow control.
The example is presented in two phases:
· adding devices with the SAM interface · setting bits in the minor device number to enable hardware flow control.
In this example an outbound device, /dev/cul0p1, and an inbound device, /dev/tty0p1, are added without hardware flow control. Next, the new devices are renamed and the mknod command is used to set hardware flow control for the devices.
To use this example to set up hardware flow control on your own system, substitute your device names where appropriate. Additional information may be obtained from the manual page termio(7).
Adding the devices 1. Use SAM to add the modem devices Choose "Peripheral Devices ", then "Terminals and Modems".
2. Write down the names of the devices you create.
32 Morning Star PPP
Outbound devices begin with the string "cu" and inbound devices begin with the string "tty."
3. Type the following, substituting device names you wrote down in step 2 for the italicized device names in this example:
ls -l /dev/ cul0p1 /dev/ttyd0p1
Output similar to the following appears.
crw-rw-rw- 1 root sys 193 0x000101 Jul 8 13:51 cul0p1 crw--w---- 1 uucp bin 193 0x000102 Jul 8 13:51 ttyd0p1
The output contains important device configuration information.
crw--w---- 1 uucp bin 193 0x000102 Jul 8 13:51 ttyd0p1
major indicates inbound or outbound number device 1 = outbound , 2 = inbound indicates status of hardware flow control 0 = off, 1 = on
4. Type the entry below, inserting the major number as shown. As you can see, in this example, the major number is 193.
lsdev 193
Output similar to the following appears.
Character Block Driver Class 193 -1 mux2 tty
5. Proceed to Setting hardware flow control if the name “tty” appears under the heading, “Class”.
NOTE: Do not proceed if the name under the heading “Class” is "pseudo". If “pseudo” appears, the tty driver is assigned a (potentially) new major number each time the system is rebooted. The next section only applies if your system's major numbers are static, which is usually the case. If your system does not have static major numbers, you will need to contact HP technical support for further instructions on how to set up hardware flow control for your tty devices.
Setting hardware flow control The output in step 3 of Adding the devices shows that neither device has hardware flow control set. This is indicated by the zero (0) in the next to last place of the minor device number in each line. This example shows how to turn on hardware flow control by creating new devices with the proper minor mode bits set to one (1).
1. Write down the following information before proceeding to the first step of setting the hardware flow control:
· the major number (193 in the above examples) · the minor number(s) (0x000101 and 0x000102 in the above examples)
33 Morning Star PPP
2. Rename the devices by issuing the following commands. This saves your original device configurations under new names. If you ever need to revert to devices that do not have hardware flow control set, you can move the x.orig files back into place.
mv /dev/cul0p1 /dev/cul0p1.orig mv /dev/ttyd0p1 /dev/ttyd0p1.orig
3. Use the mknod(1) command, as shown, to create new devices with hardware flow control, changing only the hardware flow control bit from “0” to “1”.
mknod /dev/cul0p1 c 193 0x000111 mknod /dev/ttyd0p1 c 193 0x000112
4. Type the following and check your work by examining the output.
ls -l /dev/cul0p1 /dev/ttyd0p1
crw-rw-rw- 1 root sys 193 0x000111 Jul 8 14:09 cul0p1 crw--w---- 1 uucp sys 193 0x000112 Jul 8 14:09 ttyd0p1
Notice that the hardware flow control bit is now set to “1”. Make sure your modem is setup for hardware flow control as well. For closure, set the permissions and ownership to be the same as they were when the devices were first created via SAM.
A note on Series 700 and Series 800 serial ports We have seen some modems which refuse to answer the phone if RTS recognition is enabled and RTS from the HP is low. Even when uugetty is used to enable incoming calls on the port, these modems will not answer the call because uugetty does not assert the RTS signal into the modem. The solution is to turn off RTS recognition on the modem. This is usually done with the modem command AT&R1. Unfortunately, hardware flow control will no longer work reliably on this port. If you encounter problems, you should consider using software flow control instead.
Enabling Hardware Flow Control Under SunOS
SunOS 4.1.1 implements hardware flow control on the native CPU serial ports only for transmission. Workstations running this OS respect the modem’s use of CTS (Clear To Send) to indicate its readiness to receive characters from the host, but do not use RTS (Request To Send) to throttle the modem’s (incoming) data stream to the host. This means that when presented with a heavy incoming traffic load, the Sun’s native CPU serial ports will be overloaded, and the console will report a series of occasional ‘zsx: silo overflow’ errors. This is unfortunate but unavoidable by pppd, introduces no errors into the user data being transferred across the network, and does not significantly affect the PPP link’s throughput or responsiveness.
Patches to SunOS if You Suspect a Hardware Flow Control Problem If you are running under SunOS 4.X, you should make sure that you have installed the Jumbo tty patch to your operating system to enable hardware flow control on your serial ports. Sun has released a patch to SunOS 4.1.1 - SunOS 4.1.3 which included software written by Brian Katzung
34 Morning Star PPP
Unfortunately, there was a problem with the patch related to streams flow control. The problem for pppframe is that the 100513-04 and 101621-02 patch does not send data to the pppframe driver when expected.
Until such time as Sun releases an updated version of Patch # 100513 and 101621, you have two choices. If you have installed the 100513-04, you must make sure you either do not load the pppframe driver (comment it out of the Startup script) or that you install Brian Katzung's binary patch to the SunOS patch 100513-04. The patch is available from: ftp://ftp.mcs.com/mcsnet.users/katzung/drivers/Sun/BK_zs-940304
If you have installed 101621-02 you may try to install the zs driver from the 100513-04 patch along with Brian's patch or you should make sure you do not load the pppframe driver.
Enabling Hardware Flow Control Under AIX
As the documentation states, the "rtscts" option to pppd is not supported under all operating system. AIX doesn't provide access to the usual ioctl() parameter by which a user program can tell a tty device to apply RTS/CTS flow control to its communications. That means that the Morning Star software cannot change the flow control settings on the serial port.
You must independently set up the serial ports permanently to use hardware flow control. If you wish to use hardware flow control--which you almost certainly will want to do--add the "rts" option to the runmodes for the serial port that is being used for PPP connections. This can be done either with SMIT or chdev.
You can check view the current runmodes with "lsattr -E -l tty1 -a runmodes" command or using the menus available via SMIT (from a shell prompt, you can type "smitty" to run SMIT).
Devices TTY Change / Show Characteristics of a TTY [here, you will be prompted and should pick a tty to use] Change/Show TTY Program STTY attributes for RUN TIME
On a few customers' systems, we have encountered a separate menu item for selecting rts/cts, off the same menu as STTY attributes for RUN TIME. Also, we have been told that you can follow the directions for setting up serial ports for IBM's slip product and Infoexplorer in the latest AIX manuals.
Notes on Serial Ports under AIX Enabling Inbound and Outbound Connections
If you're going to use serial ports for both inbound and outbound connections, modify the getty configuration using smit to set the "Enable LOGIN" field to "delay".
You will then be using "/etc/getty" with "delay" for inbound calls and pppd for outbound calls.
Login Script
35 Morning Star PPP
Do not use the "stty" commands given in some of our example login scripts. Comment them out by inserting "#" before the section that is identified to be used with AIX/RS6000.
Modem Commands Most modems are intelligent and recognize commands sent to them by the system during DTE to DCE transmission. Commands are different than signals exchanged by the DTE and DCE, like RTS and CTS . Generally, signals indicate the state of the DTE or DCE. Commands tell the modem to perform special tasks or modify dialing procedures. Common commands cause the modem to answer an incoming call, use touch tone dialing, terminate the current connection, or pause before sending the next number in a string. The modem recognizes system commands because they are preceded by the characters AT. Therefore, the commands are referred to as the AT command set.
COMMON DESCRIPTION COMMANDS A answer incoming call; overrides S0 register
En echo command; E0 disables echo to monitor; E1 enables echo
Hn switch hook control; H0 hangs up; H1 goes on-line
O switch from command mode to data mode
Xn select call progress code set
&Cn select Carrier Detect option
&Fn load factory setting number n
&V list modem's stored configuration files
&Wn save current modem settings as n
\Nn select error control mode
\Qn select serial port flow control
S Registers S registers are settings stored in the modem's memory. The S register format is Sr=n where r is the register's number and n is the register's value. For example, S0=1 indicates the modem should answer an incoming call after the first ring. S7=30 tells the modem to wait 30 seconds after dialing before establishing a connection. There are 256 possible S registers, although some are reserved and many are not used at all. Each manufacturer has a proprietary license to use S registers as it likes, but some registers are fairly consistent. Some are shown in the table below, although there is no guarantee they will match your modem's settings. The best advice is to review your system or modem documentation to determine the meanings and values of your modem's S registers.
36 Morning Star PPP
S REGISTER DESCRIPTION S0 in auto answer mode, which ring to answer on
S1 ring counter
S2 escape character; default is +
S3 carriage return character; default ASCII 13
S4 line feed character; default is ASCII 10
S5 backspace character; default is ASCII 18
S7 seconds to wait after dialing to establish a connection
S9 tenths of seconds to wait before issuing carrier detect signal
S46 select error control and data compression
General Recommendations for Modems
· Choose the highest asynchronous serial speed both modem and computer can support
· Enable error correction If possible, choose CCITT V.42 for compatibility with CCITT V.42bis data compression.
· Enable data compression We recommend CCITT V.42bis for higher maximum compression ratios and handling of precompressed data streams.
· Enable flow control Use hardware instead of software flow control if possible.
· Use default modem parameters for purposes outside PPP protocol, including other inbound applications
· Set up dialers for UUCP or PPP outbound connections Dialers' PPP-specific register settings ensure that a general purpose modem used for PPP will work as intended during an PPP session
THE NEXT SECTION · Allow bidirectional connections over any available modem CONTAINS SEVERAL Try the following suggestions to configure bidirectional modems and to allow modem CONFIGURATION use by other applications, such as uucp, tip, cu and remote logins: EXAMPLES · Set S0 register value at 1 to answer after one ring. · Lock the DTE interface to the selected speed . Many modems don't support a speed register, but you can store the current value with the &W command · Disable modem printing of result codes when processing incoming calls. You may have to disable result codes too. Start the dialer with ""ATE1 or its equivalent. · Set the modem to print extended result codes, like Busy, when dialing out. Better dialer performance is possible. Enter this in the Dialers file, if necessary.
37 Morning Star PPP
· Set the modem so it only asserts the Carrier Detect (CD) signal when the carrier is established with another modem · Set the modem to disconnect the call and restore its saved values when the computer deasserts the Data Terminal Ready (DTR) signal
Configuring Modems
Introduction The file Dialers is installed with MS PPP. It contains dialer descriptions for several modems including register setup and switch setting summaries. You may wish to create a separate list of modem descriptions in a file named Dialers.local. You can use the entries from the Dialers file to help guide you as you create new entries in the Dialers.local. Entries in the Dialers.local will take precedence over entries in the Dialers. See the ppp.Dialers(5) manual page for more information about setting up dialer entries.
Since your modem may be used for purposes besides PPP (e.g. UUCP or interactive users), it’s best to set the modem’s default parameters to accommodate dial-in applications and have outgoing UUCP or PPP dialers change them if necessary. The PPP-specific register settings in Dialers or Dialers.local ensure that an otherwise general-purpose modem will work as well as possible with MS PPP for the duration of the PPP session.
In the next section you will find some suggestions for Telebit modem settings which have worked well during Morning Star's testing procedures. The examples here show the complete register settings for a Telebit T1600 and a description of what the settings accomplish. Following this information are some command strings which will provide the proper register settings for Telebit's T1600, Qblazer and T3000 modems. Most modems should provide equivalent settings. Check your modem’s user guide for help in composing the command string for similar settings.
Telebit Modem Settings During testing we used the following commands to configure settings for a trio of Telebit modems and discovered the settings work quite well.
T1600: at &f s0=1s7=120s48=1s51=6s58=2s59=15s61=0s63=2tq2x12&c1&d3&s1 &w T3000: at &f9 s0=1s7=120s48=1s51=6s58=2s59=15s61=0s63=1tq2x12&c1&d3&s1 &w Qblazer: at &f s0=1s7=120s48=1s51=6s58=2s59=15 s61=0s63=2tq0x4&c1&d3&s1 &w
The commands produced the following list of settings for the Telebit T1600 . The list is the output from the command AT&V.
at&v T1600 - Version LA1.00 -Active Configuration B1 E1 L0 M0 Q2 T V1 X12 Y0 &C1 &D3 &G0 &J0 &L0 &Q0 &R3 &S1 &T4 &X0
S000:1 S001=0 S002=43 S003=13 S004=10 S005=8 S006=2 S007:120 S008=2 S009=6 S010=14 S011=70 S012=50 S018=0 S025=5 S026=1 S038=0 S041=0 S045=0 S046=0 S047=4 S048:1 S050=0 S051:6 S056=17 S057=19 S058:2 S059:15 S060=0 S061:0 S062=15 S063:2 S064=0 S068=255 S069=0 S090=0 S093=8 S094=1 S100=0 S102=0 S104=0 S105=1 S111=255 S112=1 S180=2 S181=1 S183=25 S190=1 S253=10 S254=255 S255=255 OK
The table below shows the features and S register values set by the T1600 commands. Many of these settings, particularly the S registers, only apply to Telebit modems. However,
38 Morning Star PPP your own modem will likely respond to a different command or register value in the same way the T1600 does to these. Use your modem’s command set and register semantics to set features like RTS/CTS hardware flow control. Refer to the Dialers file for descriptions of several more modem configurations.
39 Morning Star PPP
COMMAND RESULT OR SETTING &f load factory default settings s0=1 answer after one ring s7=120 wait 120 seconds for a valid carrier tone to be sent from the remote modem s48=1 compare all eight bits when checking for control characters s51=6 latch the DTE interface at 38400 bps s58=2 use full-duplex RTS/CTS flow control so the modem sends data to the DTE when RTS is on and will not send data to the DTE when RTS is off s59=15 use the following result code suffixes: Possible link protocol suffixes: nothing, REL, or LAPM Possible compression suffixes: nothing or COMP s61=0 local reaction to a break signal on the serial interface is the same as specified in S63 s63=2 discard buffered data and send the break signal when a break signal is transmitted by the local DTE during an error controlled connection q2 report result codes when originating a call, but do not return result codes when answering a call t use DTMF tone dialing x12 result codes include the following: BUSY,DIALING, ERROR, NO CARRIER, NO DIALTONE, OK, RING, RRING, CONNECT 300, CONNECT 1200, CONNECT 2400, CONNECT 4800, CONNECT 7200, CONNECT 9600,CONNECT 12000, CONNECT 14400, CONNECT 19200, and CONNECT 38400
&c1 turn ON the DCD signal when a remote modem carrier is detected and turn DCD OFF when the carrier is dropped
&d3 recall the current user configuration parameters from nonvolatile memory and enter command mode when the DTR signal is switched from ON to OFF
&s1 turn DSR ON after the answer tone is detected and leave it ON throughout the connection
&w save the current configuration settings to nonvolatile RAM.
Compression In addition to in-modem data compression , Morning Star PPP supports compression at several different layers of the communications stack.
HDLC Frame Compression The PPP frame format is based on the established HDLC 1 format. Synchronous PPP links almost always use the full PPP/HDLC frame because the links' hardware supports it. But lower-speed asynchronous links typically handle framing in software and several of the fields
1 Simpson, W.,ed., ‘PPP in HDLC Framing’, RFC 1549.
40 Morning Star PPP
carry the same contents in each message. Therefore it makes sense to amend the full HDLC frame for aysnchronous PPP.
Address and Control Field Compression A full PPP frame contains the HDLC ALLSTATIONS value (0xFF) in the Address field, and the HDLC Un-numbered Information value (0x03) in the Control field. These fields are unnecessary because they always carry the same information and increase the latency of a low-speed link. During the Link Control Protocol phase, asynchronous PPP links usually negotiate to drop both fields. When the LCP layer is Opened, the fields are not transmitted in PPP frames.
Protocol Field Compression The two-octet PPP Protocol field in an asynchronous PPP frame tells the receiving PPP whether the incoming frame carries an IP network datagram, a Link Quality Report , a link option (re)negotiation, or any of several other types of data. Though option negotiations and other link-level traffic always require two octets, most of an established link's traffic is network-layer (e.g. IP) datagrams. PPP’s network-layer protocol field values always place a null octet (0x00) before the octet that distinguishes IP (0x21) from Appletalk (0x29) datagrams. That octet almost always contains the same value (0x00), and asynchronous PPP links usually negotiate it away to reduce latency.
Van Jacobson TCP Header Compression Each layer a TCP/IP datagram passes through adds a header to the user data. For example, many streams can potentially pass between two hosts. Therefore, in addition to its source and destination addresses, each packet contains a tag to identify which stream it belongs to. These headers are very large, and a comparison between successive packets reveals strong similarities.
RFC 1144 "VJ" TCP header compression reduces the packet header size by transmitting only the header segments that change from one packet to the next. TCP and IP header overhead is reduced from over 40 octets to as few as 4. TCP header compression has a dramatic effect on interactive responsiveness over low-speed links, because it reduces a typical single-character Telnet or rlogin packet from over 40 octets to 5 or 6 octets. It has a much smaller effect on batch data throughput, like X bitmap displays, or FTP or rcp file transfers. That sort of data flows in much larger packets. Reducing frame size from 1500 to 1460 octets produces a much smaller percentage improvement than a reduction from 45 to 5 octets.
OTHER OPTIONS FORVJ The option vjslots followed by a numerical value between 3 and 256 sets the number of COMPRESSION ARE compression slots for Van Jacobson compression. The default is 16 slots. DISCUSSED IN THE PPPD MANUAL PAGES TCP header compression is enabled by default on async PPP and SLIP links, and disabled by default on synchronous PPP links.
PPP Link Compression Like in-modem data compression , PPP link compression reduces the amount of data that must flow across a low-bandwidth telephone line, thus increasing its effective bandwidth. Since PPP link compression in pppd is performed on the UNIX system, less data flows across the serial interface. This is advantageous in the following situations: · the host's serial interfaces are incapable of high asynchronous data rates · the host's inefficient serial I/O subsystem causes an onerous interrupt load on the host processor.
41 Morning Star PPP
· two computers are directly connected and there are no modems to compress the data · The modem or CSU/DSU communication device doesn't support data compression.
PPP link compression over modems that support V.42bis compression may provide no performance advantage, except in cases where the link’s bandwidth is limited by slow serial interfaces.
Predictor-1 Predictor-1 compresses typical binary data 1.5:1, absorbs relatively little of the host’s CPU, and adds very little latency to interactive traffic. It’s well suited to wringing even better performance from higher-speed synchronous PPP connections.
Stac Compression The Stac LZS algorithm for data compression is an IETF compression standard for PPP . The algorithm can maintain an average 2:1 compression ratio and, depending on the type of data that’s being compressed, the ratio may be as high as 3:1 or 5:1 . The Stac LZS algorithm is based on the Lempel-Ziv algorithm and is the same as that used in Stac Electronics retail software.
Unique PPP Implementations Although most implementations of PPP occur over aysnchronous dial up connections, PPP can be used for synchronous transmission over high speed serial interfaces. It can also be used on dedicated lines and constantly open telephone lines. The latter is a dial up connection, but it is not on-demand.
Synchronous PPP Morning Star PPP can run in synchronous mode using a high speed serial interface at line speeds up to T1 (1.544Mb/s). To prepare your UNIX system to use a high speed interface, follow the instructions in the hardware installation guide.
If you use MS PPP over an interface like MS’s SnapLink, connecting in synchronous mode at T1 speeds to another host or router using port 0 and emulating SCSI disk device 2 on its own SnapLink , use a Systems entry like this:
hostname Any;5 rsd2a/0 1536000
The Devices entry looks like this:
Direct rsd2a/0 1536000
Dedicated Lines Use pppd's dedicated argument if the PPP implementation uses asynchronous serial connections that are always available. These connections often use high-speed asynchronous short-haul modems over a building or campus wiring plant. Dedicated instructs pppd to never give up on the connection. If the peer tells pppd to disconnect, pppd will continuously attempt to reconnect and connectivity is reestablished as soon as possible if one end of the link goes down.
42 Morning Star PPP
If there is a fatal disconnect, through LQM failures or loss of the Carrier Detect signal, pppd closes the device and consults the Systems file to find another matching entry. If none is available, pppd waits for the call retry delay to pass and tries the original connection again. Normally, no getty or login process is run on a dedicated line device and both ends of the circuit actively try to connect to their peer . Each machine’s Autostart script should contain a line like:
pppd local:remote auto dedicated
The Systems file should specify a device name like cuh00 in the device field. ACU, for “Any Call Unit”, should not be used. For example:
remote Any cuh00 38400 0
The Devices file should contain a line like:
Direct cuh00 38400
The Dialers file is ignored when “Direct” is found in the dialer field of the Devices field. See the discussion below regarding line failovers and using an auto -dial modem as a backup link.
Automatic Failover The Automatic Failover option is a dial-up backup that maintains connectivity so that IP traffic can continue when a synchronous or dedicated asynchronous connection is dropped. User services will continue even if the dedicated line becomes unavailable, although the user may notice the link is slower.
Setting up Automatic Failover To set up the dial-up connection, add an entry referencing a dialup modem after the entry for the dedicated link in the Systems file. The added line might look like the following:
remote Any ACU 19200 5551212 in:--in: pppbackup word: password The remote hostname must match the remote hostname entered in the Autostart file entry described in the section Dedicated Lines. You also need an entry in the Devices file that accesses a device the modem is attached to. Instead of using “Direct ” in the dialer field subsitute a dialer entry for your modem. For example:
USR-SPORTSTER cuh00 19200
In this example, the Dialers file would have a “USR-SPORTSTER” dialer entry to use to dial out. The modem would be attached to a serial port which is accessed through device “cuh00” with a DTE speed of 19200.
How Automatic Failover works By default, pppd will ask the peer to send LCP Link-Quality-Report messages. When the dedicated line fails, pppd stops receiving the reports. pppd terminates the connection when SEE LQTHRESHOLD IN the lack of Link Quality Reports drives measured link quality below the configured threshold. THE SECTION ONL INK QUALITY MONITORING After unsuccessfully attempting to reestablish the connection on the same line, pppd will automatically fail over to the second entry in the Systems file, and uses the modem to dial up and reestablish IP traffic. Note that if the dedicated connection is restored, you must manually cause the dialup modem to hangup the line. Then pppd attempts to reconnect using the next entry in Systems, or, if no additional entries exist, pppd will wrap around to the first entry in the file which is the dedicated connection.
43 MANUALLY HANGUP THE DIALUP LINE WHEN THE DEDICATED CONNECTION Morning Star PPP IS RESTORED
Constantly-Open Telephone Calls Some PPP connections are always up. The system doesn't use pppd’s on-demand dialing to reestablish a link for new traffic. This is not the same as using a dedicated line, because modems on constantly open connections must be dialed, or a login negotiated, before PPP frames can be exchanged. In the 'constantly up' situation, use the up argument on pppd’s DON'T USE THE UP ARGUMENT WITH THE command line. Up instructs pppd to make every effort to keep the connection up. For IDLE ARGUMNET. SEE example, when the connection goes down, pppd will immediately redial the modem, rather PPPD OPTIONS. than waiting for traffic demand. Don't use the up and idle arguments together.
Interoperability with Other PPP Implementations
Introduction MS PPP has been tested successfully with several other PPP implementations, routers and terminal servers, including those shown in the alphabetical list below. MS PPP also runs successfully in SLIP mode with SLIP implementations in several types of terminal servers, PCs, LAN probes, Macintoshes, and other workstations.
INFORMATION ABOUT Following the list is configuration information which may be useful if your users connect to PPP CONNECTIONS systems using some of these applications or hardware . The first section on configuration BETWEEN DOS PC'S deals exclusively with Telebit NetBlazer hubs, the second with PPP implementations, and the AND UNIX SYSTEMS IS IN THE SECTION ONFTP third with routers. SOFTWARE'S PC/TCP SOFTWARE · 3Com NETBuilder · Brixton Systems BrxPPP · cisco AGS and CGS · Free Perkins/Clements/Fox/Christy UNIX-based PPP · FTP Software PC/TCP · HP LanProbe SLIP · KA9Q · Merit PPP servers · Network Application Technology LANB-820 · Novell LAN WorkPlace for DOS · Proteon cnx500 · SCO PPP · Telebit NetBlazer · Xylogics Annex-3 · Xyplex terminal server s
Configuring Telebit NetBlazer
Telebit’s NetBlazer software, version 1.41x11, has been successfully tested with of MS PPP . Try this adjustment if your NetBlazer runs an earlier release: put novjcomp on the pppd command line.
44 Morning Star PPP
Using NetBlazer in a LAN Hub or ISP POP This extensive information about Telebit NetBlazer software provides insight into workstation and hub configurations for inbound and outbound connections between UNIX stations and NetBlazer hubs.
Configuring the NetBlazer to receive the call This configuration can occur when several remote workstations dial into a NetBlazer serving as a hub for a LAN, or when connecting a remote workstation or LAN to the Internet through an IP connectivity vendor’s NetBlazer point of presence (POP ). The NetBlazer may be set up as if the UNIX machine were just another remote ‘dynamic-interface’ NetBlazer, using the PPP encapsulation protocol in ‘packet mode’.
· Configure the NetBlazer as described in chapter 3 of the NetBlazer Reference Manual, noting particularly the discussion of the ipdial command in the section on Setting Up Remote IP Destinations. · Enter the UNIX system name when asked for the ‘Name of dial IP interface to add’. MS PPP’s authentication mechanisms have not been tested with the NetBlazer’s ‘crypto handshake’. · Use PPP rather than SLIP · Specify 1500 for the MTU . · Make note of the password when asked to enter the UNIX system's dial -in user's password. It must be included in the UNIX station's Systems entry describing how to dial into this Net-Blazer.
Configuring the UNIX system to dial the call · Use the UNIX system's name for the username provided by the login portion of the Systems file chat script · Use the password provided when establishing the NetBlazer's dial-in user, above · Use the Autostart script to start the MS PPP daemon, just as you would when calling another MS PPP site.
Configuring the NetBlazer to dial the call This arrangement works if a hub NetBlazer needs to connect to several remote workstations on demand.
· Add the following entry to the NetBlazer’s CHAT.TXT file:
#For a UNIX system running Morning Star Technologies PPP #no crypto challenge/response, longer timeouts, short #expect strings login shell script must ‘echo Packet mode #enabled‘ before ‘exec pppd‘ :unix e1,20,30,2,in: u2,5,100,3 s3,5,100,4,\r e4,10,30,5,word: o99,Packet mode enabled p5,5,100,6 s6,5,100,7,\r e7,20,30,99,Packet mode enabled o32,in:
s30,5,100,31,\r\r e31,20,100,32,in: u32,5,100,33 s33,5,100,34,\r e34,10,100,35,word: o99,Packet mode enabled p35,5,100,36 s36,5,100,37,\r e37,20,100,99,Packet mode enabled
45 Morning Star PPP
o100,in:
r99,0 r100,1 #
· Reboot the NetBlazer to cause any CHAT.TXT changes to take effect. · Specify unix for the chat script, rather than the default ics when configuring NetBlazer’s dynamic interface to call the UNIX system as described above in Configuring the NetBlazer to receive the call
Configuring the UNIX system to receive the call The following changes must be made to a UNIX system running MS PPP to accommodate inbound calls from a NetBlazer: SEE GETTYDEFS(4) · Find an entry in /etc/gettydefs that sets up the serial port for 8 data bits and no parity 2. FOR INFORMATION · Use this entry in your /etc/inittab file with the getty process that is started on the serial port with the modem. · Create $PPPHOME/Login-netblazer, the NetBlazer connection 's login shell script, by following the example shown below. The login shell script must tell the NetBlazer ‘Packet mode enabled’ before the connection's PPP LCP option negotiation phase starts.
#!/bin/sh PATH=/usr/sbin:/usr/etc:/etc:/bin mesg n stty -tostop echo Packet mode enabled exec pppd ‘hostname ‘: idle 130
· Make sure it is executable:
# chmod 755 Login-netblazer
If the NetBlazer hangs up, it might be receiving too much text from the UNIX system before it sees the ‘Packet Mode Enabled’ welcome message. Keep that ‘user’ from seeing the /etc/motd by entering the command shown below where netblazer-login is the name of the Netblazer ’s entry in the UNIX system’s passwd database:
# touch ˜ netblazer-login/.hushlogin
PPP/SLIP Compatability with MS PPP
Free UNIX-based PPP implementations Several PPP implementations for UNIX systems are freely available, though not in the public domain. Many are based on work by Drew Perkins, Greg Clements, Karl Fox, Greg Christy, and other maintainers and contributors. They seem to share a common bug, as discussed in the section on Link Quality Monitoring above: · Specify echolqm on the pppd command line or your link will be terminated within one minute of connection.
2 Note: This parity change will adversely affect some users with other machines and other applications who attempt to dial into this port. Future releases of the NetBlazer software may include the ability to talk to a typical 7- bit UNIX getty. If so, using an 8-bit gettydefs entry would be unnecessary and all normal UNIX dial-ins would work as expected. Check your NetBlazer documentation for more information.
46 Morning Star PPP
FTP Software Inc’s PC/TCP Network Software for DOS This section includes information about preparing a UNIX system for an inbound DOS PC and vice versa.
FTP Software’s PC/TCP PPP (PC-227) versions 2.10 and 2.11 interoperate with MS PPP with some adjustments. · Specify nolqm on the pppd command line. These versions of PC/TCP PPP don’t correctly Configure-Reject LQM during LCP negotiations.
FTP Software’s PC/TCP PPP version 2.05 requires these adjustments to interoperate with MS PPP: · Specify both rfc1172-addresses and nolqm on the pppd command line.
Getting a UNIX system ready to receive a call from a DOS PC · Specify the UNIX system's and the PC's IP addresses in the PC's login script · Specify passive which will smooth the option negotiation process · Specify nolqm if the PC/TCP predates version 2.2. · Do not specify an idle timer. PC/TCP can't re-open a timed-out connection.
Getting a DOS PC ready to dial into aUNIX system Configure the PC as described in FTP Software’s manual. No special arrangements are required in order to talk to a UNIX system running Morning Star PPP.
HP LanProbe SLIP The Hewlett-Packard HP 4995A LanProbe II/Ethernet SLIP implementation interoperates with MS PPP running the SLIP option if you make this adjustment: · Specify extra-slip-end on the pppd command line.
KA9Q KA9Q NOS PPP for MS-DOS interoperates with MS PPP with this adjustment: · Specify nolqm on the pppd command line. Without this option, your link will be terminated within one minute of connection
SCO UNIX/ODT PPP The PPP implementation included with SCO TCP /IP version 1.2, which is also part of SCO Open Desktop 2.0, interoperates with MS PPP with this adjustment: · Specify asyncmap 0xffffffff on the MS pppd command line. SCO’s PPP doesn’t comply with RFC 1548's second full paragraph of section 5 and the associated Implementation Note.
SCO Open Desktop 3.0 with TCP/IP 1.2.1 solves the above problem. However, different adjustments must still be made: · Specify either echolqm or nolqm on the MS pppd command line. SCO’s PPP by default doesn’t respond with a Configure-Reject during LCP negotiations. · Handle IP addresses in one of the following two ways: · Instruct the SCO PPP to send its IP address during IPCP negotiations
47 Morning Star PPP
· Specify rfc1172-addresses or both the local and remote IP addresses on the MS pppd command line.
MS PPP Interoperability with Routers and Servers
Livingston Portmaster MS PPP interoperates with the Livingston Portmaster 2e terminal server/dialup router. Use no special measures for the UNIX system to dial into the Portmaster. Portmaster's Login script for dialing into the UNIX system should resemble this:
#!/bin/sh NOTE THE ADDITIONAL PATH=/usr/sbin:/usr/etc:/etc:/bin ‘ECHO PPP’ TO mesg n ACCOMMODATE THE stty -tostop PORTMASTER’S CHAT echo PPP SCRIPT NEEDS. exec pppd ‘hostname ‘: idle 300 Network Application Technology LANB-820 MS PPP interoperates with Network Application Technology’s LANB-820 router . · You must specify the nomru, nomagic, noipaddress, and nolqm options on the pppd command line, or the NAT router will send malformed LCP Configure-Ack messages to MS PPP.
Novell LAN WorkPlace for DOS MS PPP Interoperates with version 4.1 of Novell’s Lan WorkPlace for DOS . · It appears that you must specify both the UNIX system’s IP address, as well as the PC’s IP address, on the MS pppd command line. · Negotiations will progress a little faster if you specify rfc1172-addresses as well.
Proteon cnx500 MS PPP interoperates with the Proteon cnx500 router , if the cnx500 is running software load ‘V12.0c [PPP fix]’, 12.1, or release 13.
Xylogics Annex-3 MS PPP interoperates with the Xylogics Annex-3 communications server running v7.0.10beta of the Annex firmware. · You must specify rfc1172-vj on the pppd command line, or your interactive responsiveness will suffer.
Xyplex Terminal Servers MS PPP interoperates with Xyplex terminal servers running PPP. · You must specify either echolqm or nolqm on the pppd command line unless the Xyplex terminal server is running software "special" version V5-0-1S19.
48 Morning Star PPP
Common pppd Options
The MS PPP daemon has nine sets of configuration options for fine-tuning PPP communications. The sets include over eighty different selections that affect daemon management, communications, link management, Internet Protocol, authentication, encryption, compression, logging and signaling. Pppd running on most links is basic, defined by a handful of options, but the number ways configuration can be tweaked means each daemon can be remarkably different, or merely personalized by a minor change of options.
TOPICS IN THIS AND This section addresses some of the more common, yet useful, options, and reasons you might UPCOMING add them to the pppd command line. Most, like the active, passive and idle timer options, SECTIONS - control some aspect of link management. One important pppd option, filter, is discussed at
SEE SECURITY FOR length in the section on security later in the manual. Beyond this discussion of options for A COMPLETE link management are short sections on synchronous PPP connections, MS PPP-supported DISCUSSION OF THE compression options, and IP address assignment. FILTER AND LOG PPPD OPTIONS Link Management Link management options define how PPP establishes, maintains and monitors a communications link. These factors, and the condition of the link, help PPP decide when to bring a link up and down in situations other than on-demand dialups.
Active vs. Passive PPP Negotiations MS PPP, like most PPP implementations, expects to actively initiate the negotiation process.. By default, when a line is connected, pppd immediately sends PPP messages, anticipating that a PPP implementation on the other end is ready to negotiate. In auto mode, this directly follows completion of a Systems chat script login procedure. When pppd is not in auto mode, messages are sent when the daemon starts.
Outbound The default behavior works correctly in almost all situations. However, sometimes it's better to let the other end send its messages first when calling another system's dial up modem. A few PPP implementations get confused when a peer speaks first and negotiations may be slow if both ends are active . In these situations, assign pppd the passive option. The passive option makes pppd wait until the other end communicates before it sends messages.
This is an example of the pppd command line for outbound passive connection:
pppd hostname :peer auto passive
Inbound When a PPP that gets confused by the other end's active negotiations dials an MS PPP system, it would be wise to make the calling pppd passive if possible. However, if it is not possible, negotiations may proceed faster if the Login script invokes the passive option on the receiving pppd.
49 Morning Star PPP
Idle Timer Link Control The idle option allows you to limit the number of seconds that can pass without receiving or transmitting the type of packets specified in the filter file's keepup field. The timer shuts down the link when the specified number of seconds elapse. The idle option works on both the calling and the answering pppd. If both have the idle option set, the end that specifies the shorter interval shuts down the line first. The default is to never shut down the link.
When to Invoke the Timer Don't invoke the idle option when pppd is talking to a system running PPP software that does not implement on-demand auto -dialing. The session may not stay intact if the link is taken down by the idle timer. These systems include those running most free PPP implementations, or MS-DOS PCs running FTP Software’s PC/TCP .
Setting Idle Timer Values The two criteria for determining idle timer values are: · the cost of maintaining a connection · the scarcity of resources
Limits for Outbound Calls
MINIMUM SETTINGS TO Set a relatively brief idle timeout for the system placing a call if the connection carries a ALLOW A CONNECTION monetary cost per minute • e.g., a long-distance telephone call. On the other hand, if the TO BE ESTABLISHED telephone billing scheme is based on the number of calls rather than their duration, set a longer idle timer, or none at all, on the calling system's pppd. Keep in mind that it can take 25 seconds or more to allocate a modem, dial out, complete the call, login to the remote system, and negotiate PPP connectivity. The minimum idle timer setting should be 30 seconds to accommodate the connection and negotiations. All ABORT and TIMEOUT strings must be written with the same thought in mind.
Limits for Inbound Calls Set a relatively brief timeout for an answering system if it has too few modems to accommodate a large number of incoming connections. The answering system might also benefit from a shorter idle timeout value if it acts as a hub and provides its services via a toll- free WATS (800) number. On the other hand, if it provides its services via a 976 or 900 number scheme, you may not want to specify any timeout interval since each unit of connection time increases the answering system's revenue.
The exec option The exec option invokes a command or shell script when a link is brought up or taken down. Exec can be used on the link’s calling or answering end and the command or shell script is executed immediately when the link changes state.
Exec arguments The first argument of the command or shell script invoked by exec is either “up” or “down”. The second argument is the peer ’s IP address. Exec’s third and subsequent arguments are those with which pppd was invoked.
50 Morning Star PPP
Security
PPPD IS ROOT AND pppd runs suid root and anything specified in the Exec script is run as root. This can be a risk EXEC COMMANDS if mismanaged. Take appropriate security precautions with the exec script so it cannot be WILL RUN AS ROOT. modified by non-root users. BE CAREFUL.
Parent environment and session variables The entire parent environment is exported to exec scripts (i.e the environment when pppd was invoked.) You should attempt to make the environment as small as possible because the environment will take up space for each pppd that is running. The exec script may also include variables that describe the current session. These variables include:
VARIABLE DESCRIPTION PPPHOME AS YOU’D EXECT, BUT ALWAYS SET
PPP_COMMANDLINE ALL ARGUMENTS FROM THE ORIGINAL COMMANDLINE
PPP_LOCALADDR LOCAL ADDRESS OF LINK WHILE UP (NEGOTIATED)
PPP_REMOTEADDR REMOTE ADDRESS WHILE UP
PPP_NETMASK NETMASK WHILE UP
PPP_ORIG_LOCALADDR ORIGINAL LOCAL ADDRESS (FROM COMMANDLINE)
PPP_ORIG_REMOTEADDR ORIGINAL REMOTE ADDRESS
PPP_ORIG_NETMASK ORIGINAL NETMASK
PPP_INTERFACE NAME OF PPP INTERFACE (DUX)
PPP_DEVICE NAME OF DEVICE BEING USED FOR SERIAL STREAM
PPP_LOGFILE SELF EXPLANATORY
PPP_ACCTFILE SELF EXPLANATORY
PPP_AUTHNAME PEER NAME IF CHAP/PAP IS USED, ELSE “NAME” PARAMETER FROM COMMANDLINE, IF GIVEN, ELSE USERNAME OF USER THAT STARTED PPPD
PPP_PID PPPD USER PROCESS PID
PPP_SHUTDOWN SHUTDOWN REASON IF LINK IS GOING DOWN AND A SHUTDOWN REASON IS AVAILABLE, ELSE NON EXISTENT
Example This example uses a Login shell script to invoke an executable shell script called $PPPHOME/Exec that causes sendmail to run its queue whenever a remote system establishes a connection, possibly triggering a delivery to the remote system.
51 Morning Star PPP
Login shell script
#!/bin/sh PATH=/usr/sbin:/usr/etc:/etc:/bin PPPHOME=/etc/ppp export PPPHOME PATH
mesg n stty -tostop exec pppd ‘hostname ‘: idle 130 exec $PPPHOME /Exec
Executable shell script:
#!/bin/sh case "$1" in up) echo link is up at ‘date‘ > /dev/console ; /usr/lib/sendmail -q < /dev/null ;; down) echo link is down at ‘date‘ > /dev/console ;; esac
The SLIP framing option If you must link with a peer host that can't use the Point-to-Point Protocol, use the Serial Line Internet Protocol (SLIP) option. SLIP, a non-standard but popular protocol, is really only a framing convention for arranging IP packets on a link. Many other MS PPP pppd options are SLIP/ MS PPP PPPD available when running the SLIP option. Automatic dialing, idle line hangup , packet filtering, OPTION the exec option, and most other management facilities can be invoked in conjunction with COMPATABILITY SLIP.
However, SLIP provides few of the PPP protocol's advanced facilities. Pppd invoked with the slip option cannot provide the following:
· LCP and IPCP negotiations PPP SERVICES · PAP and CHAP authentication SLIP DOESN'T SUPPORT · Link Quality Monitoring · Asynchronous Control Character Mapping or the escape option
And there are connection restrictions when running pppd with the SLIP option:
· Links must be Asynchronous SLIP'S LINK · Cannot be used with the HDLC 14 device driver RESTRICTIONS · Connections must be completely transparent to all 8-bit character values · Flow control selection must be hardware or no flow control at all · Link must not interpret passing data as flow control
Providing Addresses in SLIP mode Unlike PPP, SLIP cannot perform IPCP negotiations. Therefore a SLIP connection cannot be assigned an address by a peer at connection time. Normally PPP can use the tilde (~) on the pppd command line for this purpose. To obtain a similar "feature" a remote side SLIP connection must provide the IP address during the connection process and a new local address must be obtained using the Systems file `\A` chat script feature.
The Login script can tell the peer its address textually, just before invoking pppd, if you include something like this in the script:
52 Morning Star PPP
#!/bin/sh localaddr=‘calculate‘ peeraddr=‘calculate‘ echo my address is $localaddr and your address is $peeraddr exec pppd $localaddr:$peeraddr slip idle 120 ... The incoming peer is responsible for parsing the "my address is" line, and doing something sensible with the addresses it finds there.
SLIP Data Compression If you specify vjcomp and SLIP as pppd options, pppd will always use RFC 1144 ‘VJ’ TCP header compression with the default 16 slots. This is useful for talking to ‘CSLIP’, a SLIP SEE VAN JACOBSON COMPRSSSION IN protocol that allows compression. By default, pppd running with the SLIP option does not use DATA COMPRESSION VJ header compression, although it will start sending VJ-compressed packets if it first SECTION receives VJ-compressed messages from its peer . Header compression can be completely disabled with the novjcomp option. SLIP’s default MRU and MTU (maximum receive unit and maximum transmission unit) are 1006.
Using SLIP to dial a cisco terminal server You can use Morning Star PPP in its SLIP framing mode to dial into a cisco Systems terminal server. Since the SLIP protocol supports no option negotiations, cisco terminal servers print the incoming system’s IP address in text on the serial line, before beginning the SLIP protocol. Pppd parses when the ‘\A’ token is inserted in the ‘expect’ phase of the Systems file chat script. The daemon passes the assigned address to the UNIX end of the point-to-point networking interface. See Systems.ex for an example use of this facility.
Link Quality Monitoring
How LQM Works The Link Quality Monitoring option is defined in the PPP protocol specification. When the PPP implementation supports LQM, PPP can make policy decisions based the observed quality of the link between peers.
When LQM is invoked, pppd requests that the other end of the connection send Link Quality Report (LQR) packets back to the pppd. If the link goes down or is degraded, many, or all, of the LQR packets will be lost. This also indicates that data packets have been lost and the connection is too bad to warrant continued traffic. Pppd counts the arriving LQRs, and if too many have been lost, pppd closes the connection. Link Quality Monitoring packets do not count against an idle line disconnection timer , since they are part of the Point-to-Point Protocol rather than user data.
Guides for Evaluation of Link Quality Pppd bases its evaluation of the link status on the arguments of two associated options, lqrinterval and lqthreshold. The value of the lqrinterval option tells pppd how often to request LQR packets from the peer machine. The default value is every ten seconds, or five per minute allowing for timing slop. Lqthreshold's argument is the minimum acceptable link quality. The default lqthreshold is one out of five packets. With the default values in place, the link will shut down if no LQR packets arrive during the previous minute.
53 Morning Star PPP
Adjusting LQM Behavior The default LQM behavior, one successful packet out of five sent every minute, is fairly permissive. Pppd will be more demanding about line quality if you change the defaults. Either evaluation setting can be changed to make LQM more stringent. For example, you can demand that at least one LQR arrive per minute by specifying
lqrinterval 5 lqthreshold 1/12
Or you can demand that no more than one LQR be lost each minute by specifying
lqrinterval 5 lqthreshold 11/12
Weighing the Costs of LQM Pppd will discover line failures more quickly if you decrease the lqrinterval because LQR 's will arrive more frequently . However, sending more LQR's, increases monitoring traffic, slowing down the transfer of user data. So you should remember to also consider raising the lqthreshold. If the lqthreshold is ’lqthreshold 5/6’ , no more than one LQR can be dropped per minute. If two LQRs in a row are dropped, pppd shuts down the line.
LQM Response to Link Failures
SEE FAILOVER Total link Failure PROTECTION IN THE LQM is particularly useful for detecting and responding to total link failures. The response DISCUSSSION OF can include failover protection which switches the connection to an available dial up modem. DEDICATED LINES IN THIS CHAPTER Most total failures, e.g. a backhoe digging through the telephone company’s cable, cause the connection's CSU/DSU or modem to deassert the Carrier Detect signal. Pppd observes this as a hangup event.
Failure Without Disconnection But some failure modes, like misconfigured flow control and over-reliance on in-band XON/XOFF flow control, leave modems connected even though the PPP peers are unable to communicate. In this situation, the peers will observe a LQM failure and take appropriate action, usually disconnecting and redialing. LQM is also useful if an intercontinental telephone connection is of such poor quality that significant numbers of packets are damaged in transit. Again, the PPP implementations can decide, based on LQM measurements, to hang up and redial in hopes of getting a better connection. This is a very rare occurrence if your modems provide V. 42 or MNP4 error correction, but it does occasionally happen. Whatever the cause, the disconnection and redial operation can happen without user intervention or application awareness, because even if PPP frames are damaged or lost, the upper protocol layers will arrange for retransmission as needed to provide the user with a complete data stream. The user will simply experience a pause while the modems reestablish the connection.
Peer Refusal to Comply with LQM Request If, during LCP option negotiation, the peer refuses to send Link-Quality-Reports, pppd will instead begin sending LCP Echo-Request messages at the requested lqrinterval and use the arriving LCP Echo-Response messages to make the link quality decision. If the peer doesn’t correctly use a LCP Configure-Reject message to tell MS PPP to switch to LCP Echo-Requests, MS PPP can be given either the echolqm argument, to dispense with the negotiation phase and begin directly with Echo-Requests, or the nolqm argument, to disable link quality
54 Morning Star PPP
monitoring completely. At pppd’s debugging verbosity level 4, the log file will receive summary messages like this:
5/7-13:45:27-1514 LQM : Pkt: 1/1 Oct: 53/53 LQRs: 5/5
This means that, during the last testing interval, this system transmitted one packet and USING DEBUGGING received one packet. 53 octets crossed the link in each direction. And this system has received LEVEL 4 TO CHECK LQM responses to all five of the most recent five Link Quality Report s it sent. The LQR packet is 36 octets long, and the default lqrinterval of ten seconds will cause the additional traffic to be unnoticed on most connections. However, if the application is very sensitive to speed and requires absolutely every bit of available line bandwidth, use the nolqm argument to disable Link Quality Monitoring.
55 IP Routing Tips
The UNIX host’s IP implementation sees MS PPP as a point-to-point network connection between two known addresses. If neither end-point resides on an IP-based local area network (LAN), packets will simply flow in both directions as soon as the PPP connection is established. When the PPP link connects a remote host to a LAN, or provides a connection between two LANs, or connects a host or a LAN to the worldwide Internet , the systems involved must be concerned with routing .
The examples below describe how to establish static routes when the machines boot. This is cumbersome, because any topology change requires that all the machines even remotely involved be reconfigured by editing their boot-time shell script s. An alternative to static routes would be to use some automated system for updating all the hosts’ routing tables. This is usually implemented as a daemon running on all the hosts involved. Many networks use the RIP protocol3 and run routed on their UNIX systems. If you use routed to propagate routing information, you’ll need to specify the PPP link as leading to a passive gateway.
Some sites prefer other routing protocols, and they use the Gate Daemon 4 instead. If you use gated, you should invoke pppd with the netmask argument set to the same value as used on the LAN, if that subnet mask is different from the default for the class of your network.
Connecting a Host to a LAN There are two conventional approaches for connecting a set of standalone hosts to a LAN via PPP.
Separate Network The method that will cause the least confusion is to assign a network or subnet for use by all the remote machines. For example, suppose the organization’s class B network number is 134.19, and they are subnetting with a class C-sized network mask of 0xffffff00. The departmental LAN is subnet 134.19.5.0, populated by hosts alpha (134.19.5.22) and bravo (134.19.5.41). A modem is attached to one of alpha’s serial ports, and alpha’s Login shell script is a generic one as shown below. A laptop named nomad wishes to connect to the network.
#!/bin/sh PATH=/usr/sbin:/usr/etc:/etc:/bin mesg n stty -tostop exec pppd `hostname`: idle 180
3 Hedrick, C.L., ‘Routing Information Protocol’, RFC 1058, Rutgers, June 1988. 4 gated.cornell.edu:pub/gated/gated-2.1.tar .Z or gated-alpha.tar.Z, also available via anonymous PPP /FTP from Progressive Systems. Morning Star PPP
134.19.5.0
alpha bravo 134.19.5.22 134.19.5.41
nomad 134.19.6.17
Designate subnet 6 for remote machines. Assign nomad the IP address 134.19.6.17. The MS PPP daemon on nomad would be started in the Autostart script as:
pppd 134.19.6.17:134.19.5.22 auto idle 180 or, if all the names can be found in the local /etc/hosts (or resolved via NIS /YP, NetInfo, the Domain Name Service, or some other mechanism without first needing to bring up the PPP link), it could look like
pppd nomad:alpha auto idle 180 The next line in nomad’s Autostart would set up an IP route through the dial-in gateway:
route add -net 134.19.0.0 134.19.5.22 1 Alternatively, and necessarily if the LAN were also connected to the Internet ,
route add default alpha 1 Similarly, the PPP daemon on alpha would be started as
pppd alpha:nomad auto idle 180 Bravo needs to have a network route for 134.19.6.0 pointing through alpha.
route add -net 134.19.6.0 alpha 1
Proxy ARP The Proxy ARP5 daemon can be used in a subnetted environment to accommodate hosts with older IP implementations that don’t work correctly with subnetting. Suppose, in the ‘Separate Network’ example above, the host bravo were running an older IP implementation. To enable bravo to find its way to nomad,one could run a proxyarpd on alpha and provide it the following proxytab configuration file:
#Proxy ARP table for proxyarpd #Service provided for hosts on 134.19.5.0 that do not understand #internet subnetting. # #Fields are:
5 Available from ftp .cis.ohio-state.edu:pub/proxyarp proxyarpd.shar.Z or via anonymous PPP /FTP from Progressive Systems.
57 Morning Star PPP
#1)interface to service (same as on command line) #2)net to tell attached hosts that we "are" #3)host on net 1) to send traffic to (gateway) # le0 134.19.6.0 134.19.5.22
ARP6 Table Manipulation If a separate subnet number is unavailable for use by remote-access machines, it is possible to assign them addresses on the same subnet number as the departmental LAN . As above, suppose the organization’s class B network number is 134.19, and they are subnetting with a class C-sized network mask of 0xffffff00. The departmental LAN is subnet 134.19.5.0, populated by hosts alpha (134.19.5.22) and bravo (134.19.5.41). A modem is attached to one of alpha’s serial ports, and alpha’s Login shell script is the generic one described above. A laptop named nomad wishes to connect to the network.
Assign nomad the IP address 134.19.5.114. The MS PPP daemon on nomad would be started in
134.19.5.0
alpha bravo 134.19.5.22 134.19.5.41
nomad 134.19.5.114 the Autostart script as
pppd 134.19.5.114:134.19.5.22 auto idle 180 or, if all the names can be found in the local /etc/hosts,
pppd nomad:alpha auto idle 180 The next line in nomad’s Autostart would set up an IP route through the dial-in gateway:
route add -net 134.19.0.0 134.19.5.22 1
Alternatively, and necessarily if the LAN were also connected to the Internet ,
route add default alpha 1
Similarly, the PPP daemon on alpha would be started as
pppd alpha:nomad auto idle 180
Alpha would run the following command at boot time :
arp -s nomad 8:0:9:30:dc:91 pub
6 Plummer,D.C., ‘Ethernet Address Resolution Protocol’, RFC 826, Symbolics, November 1982.
58 Morning Star PPP
(The hexadecimal sequence 8:0:9:30:dc:91 is the Mac address of the ethernet card in alpha. Substitute the Mac address for your machine’s ethernet card in the command above.) This would add a permanent entry to alpha’s ARP table, and cause it to be provided to other systems on the local Ethernet. Any time a host on that LAN tries to find the Ethernet address corresponding to nomad’s IP address, the request will be answered with instructions to forward the packets to alpha. Since nomad appears to be directly connected to the LAN, no hosts on the LAN, nor on any other IP-connected network, would require routing table modifications.
Connecting Two LANs Suppose gate-a (192.9.200.63) and ws-a (192.9.200.66) are on one LAN , with gate-a supporting a modem. Also suppose gate-b (134.19.14.29) and ws-b (134.19.14.102) are on another LAN across town, with gate-b supporting a modem.
ws-a gate-a gate-b ws-b 192.9.200.66 192.9.200.63 134.19.14.29 134.19.14.102
gate-b’s PPP daemon should be started as
pppd gate-b:gate-a auto idle 130 and gate-b should have a route like
route add -net 192.9.200.0 gate-a 1 ws-b should have a route like
route add -net 192.9.200.0 gate-b 1
Similarly, gate-a’s PPP daemon should be started as
pppd gate-a:gate-b auto idle 130 and gate-a should have a route like
route add -net 134.19.14.0 gate-b 1 or, depending upon the structure of LAN b, maybe
route add -net 134.19.0.0 gate-b 1 ws-a should have a route like
route add -net 134.19.14.0 gate-a 1 or, again depending upon the structure of LAN b, perhaps
route add -net 134.19.0.0 gate-a 1
59 Morning Star PPP
Connecting a host or LAN to the Internet If your LAN is connected to the Internet, or if you have arranged an account at a Point Of Presence (POP) of a PPP or SLIP-talking Internet connectivity vendor (say,foo.net), then you should arrange for your default route to point through the gateway at the other end of the PPP connection. If hotel supported a modem to call a POP, it would start its PPP daemon like
pppd hotel:pop.foo.net auto idle 240 and would arrange a route as
route add default pop.foo.net 1
Any hosts on the LAN ‘behind’ hotel would set a route like
route add default hotel 1
A machine’s default route should point to the next machine along its path ‘outward’ to the Internet. If hotel were a remote machine dialing into one machine in a complex corporate internet, its default route should point to that hub machine, expecting that the hub will deal with the issues of routing hotel’s packets to their destination, whether on the LAN or elsewhere on the corporate internet or onto the Internet.
60 Morning Star PPP
Security Techniques
It's impractical to impose thorough security policies on each internal host of the networks linked by an MS PPP connection. But MS PPP's strong security features support a variety of techniques that strengthen your network's ability to prevent loss.
In most cases, a single connection can be supported by more than one of MS PPP 's security features. For example, a connection might use the following:
· Progressive Systems' packet filtering technology · Time to Call Restrictions · Dial Back · CHAP Authentication · SecureID
These features, and others, are discussed in the sections below.
Static Packet Filtering
Introduction
SECURITY We recommend that you establish a security policy before you write a packet filter. A CONSIDERATION- security policy is a statement based on thorough analysis of access needs, vulnerabilities, and DEVELOPING POLICY real, or perceived, threats to your assets. You must identify the types of network traffic associated with these issues before you can create a packet filter that supports your security policy.
Progressive Systems’ flexible filter-writing mechanism will also support your policy as you create your filter. Our philosophy is to provide a mechanism that won’t force policy changes for the sake of writing acceptable rules.
The Foundations of Security Policies
2 SECURITY POLICY In general, all security policies are based on one of two opposing strategies. Both types of PHILOSOPHIES policies are supported by MS filters.
The first strategy permits a few specific services and blocks everything else. If you follow this philosophy, a service will be unavailable if you commit an error of omission. This is a fail- safe, or closed, policy.
The second strategy blocks only specific services and permits everything else. If you begin from this premise, an error of omission may leave you unintentionally vulnerable when a fragile service is not blocked.
61 Morning Star PPP
SECURITY If you need aid in developing security policies, or would like more general information about CONSIDERATION - network security and packet filtering, we recommend you begin by reading two books, RESOURCES "Firewalls and Internet Security" by Bill Cheswick and Steve Bellovin 7 and "Building Internet Firewalls" by Brent Chapman and Elizabeth Zwicky. 8
Filter File Rulesets
Filter Basics When pppd starts, the software checks for a filter file. If one is present, it is parsed and installed. The default filter filename for pppd is ‘Filter'. If you want to give the file a different name, specify the new name as the argument for the pppd ‘filter’ option. Only add the filter option if you want to change the name of the filter file.
A filter file contains rulesets for filtering packets. Each ruleset begins with one of the following:
· an IP address · a hostname · the special keyword, ‘default'.
You may write a specific ruleset for each connecting host, or a default ruleset will be used. The pppd parser will search for a ruleset that matches the IP address or hostname of the remote PPP/SLIP host, called the peer. This usually corresponds to the IP address placed on the right hand side of the colon on the pppd command line.
Ruleset Design
Hostname or IP Address Rulesets are designed on a per-connecting-host basis rather than a per-interface basis. This RULESETS ARE provides support for devices acting as PPP or SLIP routing hubs. A hub workstation allows DESIGNED PER HOST, NOT PER INTERFACE multiple hosts to establish IP connections and may support multiple hosts establishing connections at different times on the same interface.
If a hub supports different classes of users, MS PPP filters allow you to define different access policies for each group. A single hub workstation may support all of the following PPP/SLIP connections, each defined by a different ruleset:
· a connection to the home of a developer who is allowed to access multiple hosts and proprietary data · connections for a traveling sales team which only requires electronic mail access · connections to customers seeking support who may only access the anonymous FTP host
Default Rulesets
7 Bellovin, Steven and Cheswick, William, Firewalls and Internet Security Addison-Wesley, 1994. ISBN 0-201-63357-4
8 Chapman, Brent and Zwicky, Elizabeth, Building Internet Firewalls O‘Reilly & Associates, 1995 ISBN 1-56592-12-4-0
62 Morning Star PPP
Default rulesets are permitted. They simplify configuration when a single machine supports similar multiple hosts/connections which can be controlled by the same security policy.
Ruleset Order
DEFAULT RULESETS The order in which rulesets appear is important. Default rulesets should appear early in the SHOULD APPEAR file because, after they are parsed, the parser continues searching for more matching rulesets. EARLY IN THE FILTER However, when addresses or hostnames in packets and rulesets match, the packet is FILE processed and the parser stops its search.
When a match is found and the ‘non-default’ ruleset is processed, its individual filters replace any default filters "remembered" from earlier in the file. This means that packet filtering may behave differently if the ‘default' rule appears early or late in the file.
The Four Filters A ruleset is made up of one to four filters which regulate the response to a packet. The filter’s actions are defined by its initial keyword. Each type of filter may be used one time per connection. This table explains the keywords, the types of packets affected by the filters, and the filter’s actions:
KEYWORD PACKET TYPE ACTION
BRINGUP OUTGOING DIALUP DEFINES PACKETS WHICH CAUSE A CONNECTION TO BE ESTABLISHED
KEEPUP INBOUND AND OUTBOUND DEFINES PACKETS WHICH CAUSE THE IDLE TIMER TO DIALUP BE RESET, PREVENTING THE CONNECTION FROM GOING DOWN
PASS ALL PACKETS DEFINES PACKETS WHICH ARE ALLOWED TO PASS THROUGH THE FILTER. PACKETS WHICH DON’T PASS DON’T BRINGUP
LOG ALL PACKETS DEFINES THE CHARACTERISTICS WHICH WILL CAUSE A MESSAGE ABOUT A PACKET TO BE ADDED TO A LOG FILE
Defined and Default Filters Filters defined in a ruleset replace any previous default definition for that filter. Defined MOST FILTERS HAVE AN IMPLICIT DEFAULT filters are not additive with a default filter. If one of the keyword filters does not appear in a OF 'ALL' ruleset, that filter is defined by its the most recently parsed default ruleset. If there is no previous default ruleset, the implicit default is ‘all', except for the log filter, which defaults to ‘!all'.
Filter Stanzas Each filter is composed of a filter name followed by one or more stanzas (i.e., rules). Each packet passing through the interface is compared to the rules in the stanzas until a match is found, completing the filter operation. The ordering of the stanzas is therefore extremely important. Packets may match on many types of values, including:
· host or network address
63 Morning Star PPP
· port number · protocol type · IP option · TCP SYN, FIN, ACK and RST bits · direction of traffic.
Use of the Exclamation Mark to Negate A stanza optionally begins with the negation operator, the exclamation mark (!). The mark is (!) followed by one or more values and keywords, each separated by a slash (/). These value THE EXLAMATION MARK IS THE and keyword combinations create a specification for a packet. NEGATION OPERATOR IN FILTER STANZAS An exclamation mark is a powerful specification in any filter rule. If an exclamation mark is placed at the beginning of a rule, it negates the action of the stanza’s keyword. For example, compare the defaults for the Pass and Log filters:
Pass all Log !all
The specification for Pass, and the lack of an exclamation mark, indicates the default is to pass all packets. On the other hand, the ‘!all’ default designation for Log means no packets are logged.
Implicit Filter Endings
SECURITY Each filter ends with an implicit stanza. The implicit ending stanza is ‘all’ if the last stanza CONSIDERATION - specified is negated by beginning with ‘!’. The implicit ending stanza is ‘!all' if the last stanza DEFINE THE FINAL is not negated. While this is convenient and makes it unnecessary to actually define the final STANZA "match everything else" stanza, it is a good idea to explicitly specify this stanza to avoid simple errors that can greatly change the meaning of a filter.
Packets Overview Each stanza represents a template used to find matching packets. The features you can place ANY PACKETS CAN MATCH ON THE in your stanzas correspond to the fields in network messages. This allows you to filter at the DIRECTION OF TRAVEL IP level or the TCP/UDP/ICMP level. I.E., SEND OR RECV
IP - The Internet Protocol
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 VERSION IHL TYPE OF SERVICE TOTAL LENGTH
IDENTIFICATION FLAGS FRAGMENT OFFSET
TIME TO LIVE PROTOCOL HEADER CHECKSUM
SOURCE ADDRESS
DESTINATION ADDRESS
OPTIONS PADDING
*RFC-791 [IP] The fields available at the IP level include the protocol (e.g., 1
64 Morning Star PPP
[ICMP], 2 [IGMP], 6 [TCP], 8 [EGP], 17 [UDP], etc.), an address (i.e., the source or destination address ) and IP options (e.g., rr, lsrr, etc.), and fragmentation.
MS PPP does not provide a filter keyword for matching the version, IHL, TOS, length, ID, TTL or checksum header fields.
ICMP - The Internet Control Message Protocol
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TYPE CODE CHECKSUM
* RFC-792 [ICMP] ICMP messages may be filtered on the type and code fields.
In general, it is not a good idea to block all inbound or outbound ICMPmessages because ICMP messages are an important way that status information is conveyed over an IP network. For instance, blocking ICMP Source Quench messages (Type 4), used to tell a packet source to slow down, can cause problems for other users and sites.
It is true that you should probably not permit ICMP Redirect messages (Type 5) to pass through your router since the routing on an internal node should not be changed by an external site.
If you want to block ping from being used for host discovery, then you should block inbound ICMP Echo packets (Type 8).
65 Morning Star PPP
TCP - Transmission Control Protocol 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 SOURCE PORT DESTINATION PORT SEQUENCE NUMBER ACKNOWLEDGMENT NUMBER DATA |U|A|P|R|S|F| OFFSET RESERVED |R|C|S|S|Y|I| WINDOW |G|K|H|T|N|N| CHECKSUM URGENT POINTER OPTIONS PADDING DATA
* RFC-793 [TCP] The TCP header fields available for matching include port numbers (i.e., the source or destination port), the presence of the SYN bit without ACK, and the ACK, FIN and RST bits.
MS does not provide a method for filtering on TCP options, the presence of URG/EOM bits in the TCP options, or other TCP header fields.
TCP CONNECTION Establishing a TCP connection requires synchronization. Each side REQUESTS CAN BE must send it's own initial sequence number, receive a confirming IDENTIFIED WHEN acknowledgment from the other end, receive the other end’s initial THE SYN BIT IS SET sequence number and send the confirming acknowledgment. AND THE ACK BIT IS NOT. The steps in the sequence look like this: PERMIT ONLY OUTBOUND TCP BY STEP PATH TCP BIT MESSAGE BLOCKING INBOUND 1 A B SYN MY SEQUENCE NUMBER IS X PACKETS WITH THE 2 A B ACK YOUR SEQUENCE NUMBER IS X BIT SET SYN 3 A B SYN MY SEQUENCE NUMBER IS Y 4 A B ACK YOUR SEQUENCE NUMBER IS Y
Packets 2 and 3 are normally combined into a single "SYN ACK" packet This is called a three way handshake.
The SYN bit is set, with no ACK bit set, to show a TCP connection request. By blocking packets with the SYN bit set in a single direction, you may permit TCP connections in a single direction.
66 Morning Star PPP
UDP - User Datagram Protocol
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 SOURCE PORT DESTINATION PORT LENGTH CHECKSUM DATA
* RFC-768 [UDP] The UDP header fields available are the source and destination port numbers.
UDP does not permit a router to differentiate between inbound packets requesting new services and inbound packets returning data to outbound requests. This means that static filters which allow inside users access to services based on UDP also allow outside users to access the same service inside your network.
Recommended Reading
SUGGESTED If the diagrams and information shown above are difficult to follow, we highly recommend REFERENCES ON these books on networking and the TCP/IP protocols: NETWORKING AND TCP/IP PROTOCOLS TITLE: Computer Networks, 2nd edition AUTHOR: Andrew S. Tanenbaum PUBLISHER: Prentice-Hall EDITION: 1988 ISBN: 0-13-162959-X
TITLE: Internetworking with TCP/IP Vols I, II and III AUTHORS: Douglas Comer and David Stevens PUBLISHER: Prentice-Hall EDITIONS: 1991 - 2 ISBN: 0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2 (III)
TITLE: TCP/IP Illustrated: the protocols AUTHOR: W. Richard Stevens PUBLISHER: Addison-Wesley EDITION: 1994 ISBN: 0-201-63346-9 (v.1)
67 Morning Star PPP
Building a Stanza - General
Listed below are some general concepts to remember when writing a stanza:
· Each stanza includes one or more numbers, addresses, or keywords, separated by slashes (/) · Each number, address, or keyword adds an additional qualifier to the stanza · Each qualifier or pattern must match for the rule to be applied to the packet · A stanza can be used to either permit or deny a matching packet · Begin with the negation operator (!) to block or deny a packet · Any stanza that is not negated permits matching packets · Comments begin with a ‘#' character and extend through the end of the line
Building a Stanza - Specifics
The section below explains how different features of a stanza should be written and the ways you include them in a stanza to affect the operations of the filter. The features are described in subsections which include a general explanation, an example, and a comment on the action caused by the example. The comments are shown on the same line as the example and begin with a ‘#’ character.
WE RECOMMEND We recommend that readers who are unfamiliar with filtering take the time to read this THAT YOU READ THIS section from beginning to end. The topics and examples build on one another. Therefore, SECTION ON BUILDING skipping through the examples, you may see references to keywords you do not recognize or STANZAS FROM BEGINNING TO END miss the significance of relationships between some keywords. These topics are covered:
· Numbers and Addresses · Keywords · Directions of Packets · Time based Restrictions · ICMP messages · Logging and Tracing
Numbers and Addresses
Numbers with no Qualifiers A number by itself, without an associated protocol name such as tcp or udp, represents an IP protocol number. IP protocol numbers have a range of 0-255 and are assigned by the Internet Assigned Number Authority (IANA). The current list of IP protocols can be found in the ASSIGNED NUMBERS RFC 9.
Example: !89 # block Open Shortest Path First (OSPF) Interior Gateway # Protocol (IGP)
IP Addreses An IP address may be represented in hexadecimal (e.g., 0xc0000201) or dotted quad (e.g., 192.0.2.1) notation and represent either a host address or a network address. Network
9 RFCSTD2
68 Morning Star PPP
addresses are simply used to represent contiguous ranges of hosts and therefore do not necessarily correspond to actual networks. A network address uses all zeros for the host portion of the address.
Example: !192.168.199.1 # block packets to/from host 192.168.199.1
Netmasks You must specify a netmask if the host portion of the network address does not match the "natural" netmask. A netmask may be represented in either hexadecimal or dotted quad notation. A network address must also be present or the netmask will be assumed to be an IP address.
Example: 10.7.123.0/255.255.255.0 # permit 10 .7.123.0-10.7.123.255
Alternatively, you may specify the netmask after the address using a semicolon followed by the number of one bits in the network mask.
Example: 10.7.123.0;24 # permit 10.7.123.0-10.7.123.255
Keywords with Numbers A number of keywords can describe features of the packets, including data within the packet header and the direction of travel.
IP Protocol keywords ONLY USE ONE Keywords exist for the most commonly used IP protocols, ‘tcp', ‘udp', and ‘icmp'. Use these PROTOCOL keywords to prevent ambiguity when specifying port numbers or types. You must use KEYWORD PER 17/tcp' or ‘6/udp'to avoid ambiguity.. STANZA
Port Numbers ‘udp' or ‘tcp' combined with a number represents a port number 10.
Example: 25/tcp # permit SMTP mail
You may specify a range of ports using a hyphen-separated pair of numbers.
Example: !0-1023/udp # block privileged UDP ports
Port Numbers and Services Many systems provide a list of well known UDP and TCP port numbers in a services file or they supply contents of the file through a database service such as NIS or NetInfo. Filter stanzas may use the symbolic names for these port numbers.
Example: smtp # permit SMTP (25/tcp) service
10 RFC STD2
69 Morning Star PPP
USE KEYWORDS TO However, symbolic port names (i.e., services) can be ambiguous. For example, ‘domain' may IDENTIFY SERVICES be either ‘tcp' or ‘udp' port 53. When using keywords that are specific to a protocol like TCP , SUPPORTED BY you must add the ‘tcp' keyword to the stanza to avoid errors. MORE THAN ONE PROTOCOL Example: !domain/tcp
NOTE THAT THE Services are not the same as applications or protocols. Specifying ‘!telnet' in the filter file does TELNET APPLICATION not prevent the ‘telnet' application from talking to the ‘smtp' port on the host, nor does it IS NOT THE SAME AS prevent someone from using the telnet protocol to talk to a telnet daemon (telnetd) running THE TELNET SERVICE on a port number other than 23.
Numbered ICMP Messages MORE INFORMATION ON ‘icmp' with a single number represents an ICMP message type. ‘icmp' with two numbers NUMBERED ICMP represents a specific ICMP type and code combination. ICMP type and code values can be MESSAGES IS found in the ASSIGNED NUMBERS RFC 11 or in the /usr/include/netinet/ip_icmp.h file INCLUDED IN THE UNREACH KEYWORD directory on many systems. SECTION BELOW Example: !icmp/5 # block ICMP Redirect messages
Example: !3/0/icmp # block ICMP Unreachable "bad net" messages
Keywords with Origins and Destinations Frequently, a host acts as a router between two end points so packets may not originate or terminate at that host. Use the ‘src' keyword to specify the point of origin or source and the ‘dst' keyword to specify the endpoint or destination. The source or destination can be either an IP address or a service or port.
Example: route/dst # permit packets to UDP port 520 on any host
The ‘src' or ‘dst' keyword applies to all addresses and ports in the stanza. Thus, you cannot specify both the source port and destination address or vice versa in the same stanza using the ‘src' or ‘dst' keywords.
Example: 10.0.0.1/route/dst # permit UDP packets to 10.0.0.1 port 520
Even more specific rules may be written by using the keywords ‘srcport', ‘dstport', ‘srcaddr', ‘dstaddr', ‘srcmask', and ‘dstmask' keywords in place of ‘src' or ‘dst'. The syntax of these keywords is ‘keyword=value'.
Example: !srcaddr=10.7.127.0/srcmask=255.255.255.0/dstaddr=192.168.5.0 # block packets between the 10.7.127.0-10.7.127.255 and # 192.168.5.0-192.168.5.255 networks
EXAMPLE OF The workstation running the daemon is your point of reference regarding the direction of a ANTI-SPOOFING packet. Packets written by the host are outbound , or sent, and are specified by the ‘send' RULES keyword. Packets read by the host are inbound , or received, and are specified by the ‘recv'
11 RFC STD2
70 Morning Star PPP
keyword. The two rules in the following example prevent spoofed packets for an internal network 192.168.12.0
Example: !recv/src/192.168.12.0 # block receiving packets from outside which claim to # be from 192.168.12.0-192.168.12.255 !send/dst/192.168.12.0 # block sending packets to outside which claim to be # going to 192.168.12.0-192.168.12.255
Keywords based on TCP Packet Header Bits
ONLY ONE TCP FIELD Some qualifiers (i.e., keywords) may only be used in combination with other CAN BE SPECIFIED IN qualifiers. For example, ‘syn', ‘fin', ‘rst', ‘ack' and ‘estab' are options or fields in TCP packet A RULE. SPECIFYING headers and may only be used when the qualifier ‘tcp', is directly stated in the rule or implied MORE IN THE SAME RULE IS A SYNTAX by a TCP protocol service. If the definition of a service allows it to use TCP and UDP packets ERROR. the ‘tcp' qualifier must be explicitly added to the service name in the rule.
Example: !tcp/syn/recv # block inbound TCP connection requests smtp/syn # permit SMTP (25/tcp) connection requests domain/tcp/syn # permit DNS (port 53) TCP connection requests
The ‘syn’ Qualifying Keyword A rule which qualifies a session with ‘recv' or ‘send' prevents the session from being started or logged unless it is initiated in the indicated direction. The initiator sends a SYN packet to the recipient to open a TCP data stream. This permits the filter to distinguish between outbound and inbound uses of TCP applications such as telnet or FTP. The special keyword ‘syn' allows you to filter or log these connection starters. Unlike most other qualifiers, ‘syn' is actually a compound qualifier that tests for just the initial packet, which has a SYN bit set but not the ACK bit.
Using Other Keywords based on TCP Packet Header Fields · The special keyword ‘estab' identifies any TCP packet that does not have the SYN bit set. ‘estab’ is to ‘existing’ as ‘syn' is to ‘beginning’.
· The special keyword ‘ack' allows you to filter or log the packets that have the ACK bit set.
· The special keyword ‘rst' allows you to filter or log the packets that reset TCP connections.
· The special keyword ‘fin' allows you to filter or log the packets that close TCP connections.
Keywords based on IP Options The ‘ip-opt=' keyword can be used to select packets based on whether they bear various IP options, including those described in the table below 12:
12 The IP options and their meaning are covered in RFC 791 and RFC 1122.
71 Morning Star PPP
OPTION DESCRIPTION rr Record Route is used to trace the route an internet datagram takes
ts Time Stamp
security Security is used to carry Security, Compartmentation, User Group (TCC), and Handling - Restriction Codes compatible with DOD requirements
lsrr Loose Source Routing is used to route the internet datagram based on information supplied by the source
satid SATNET Stream Identifier (obsolete)
ssrr Strict Source Routing is used to route the internet datagram based on information supplied by the source
srcrt Either Loose Source Routing or Strict Source Routing
any Any IP option including the ‘No Operation’ option.
Example: !ip-opt=srcrt # block source routed packets
The ‘frag’ Keyword The ‘frag’ keyword permits filtering of IP fragments. When IP packets are larger than the media permits, the datagram can be fragmented into smaller segments, transmitted, and reassembled at the destination. IP datagrams can be up to 65,535 bytes long, but most physical networks do not support datagrams that large. Ethernet supports datagrams 1500 bytes long. SLIP’s default is 1024 bytes.
The ‘all’ Keyword The special keyword ‘all’ matches any packet. It typically appears at the end of a filter to either permit or block all unspecified packets. The software automatically implicitly adds ‘!all' at the end of a stanza list if the last stanza is not negated, and ‘all’ at the end of a stanza list if the last stanza is negated. While not strictly necessary, it is a good a idea to explicitly state your preference.
Time Based Keywords You may add time-based restrictions to your packet filter, limiting the types of traffic passing through the packet filter during the workday, or enabling additional access after business hours or on weekends.
Two keywords define time-based rules. They are the ‘weekday’ and ‘daytime’ keywords.
The syntax for using the keyword ‘weekday’ in a qualifier is 'weekday=when', where ‘when' is a string indicating the days the rule should be applied. The ‘when' portion may be a list containing any of ‘Su’, ‘Mo’, ‘Tu’, ‘We’, ‘Th’, ‘Fr’ or ‘Sa’.
Example : !ftp/syn/send/weekday=MoTuWeThFr # prevents any weekday outbound ftp connection requests
72 Morning Star PPP
The syntax for the keyword ‘daytime’ qualifier is ‘daytime=time’, where ‘time’ is a string that indicates the hours of a day the rule should be applied. You may indicate hours in a range (for example, ‘daytime=0800-1800').
Example: !ftp/syn/send/weekday=MoTuWeThFr/daytime=0800-1800 # prevents weekday outbound ftp connection requests # between 8am and 6pm.
The Unreach Keyword and Sending ICMP Messages In addition to permitting the packet to be passed or blocked, keywords also allow you to specify additional actions to take with any packet that matches the template. For example, you can silently drop the packet and/or send an ICMP message to notify the sender of the action.
The ‘unreach=' keyword causes an ICMP Destination Unreachable message to be sent to the packet's source address , bearing the indicated code field. The ICMP Code may be specified numerically or mnemonically. A list of the messages appears on the following page. See the footnotes below for information on related RFCs. 13,14
Example: !ip-opt=srcrt/unreach =srcfail # block source routed packets and # notify sender of failure !tcp/113/unreach =1 # block RFC1413 Identification Protocol # packets and send a Destination # unreachable host message.
13 RFC 1812 deprecates the use of messages 8 through 10 so their mnemonic codes have been removed. They can still be used by specifying them numerically. 14 The uses of ICMP Destination Unreachable messages have grown. The list of message codes and their meanings is spread across a number of RFCs. ICMP Destination Unreachable messages are covered in RFC 792, RFC 1122,and RFC 1812.
73 Morning Star PPP
The currently available mnemonic codes are:
# NAME DESCRIPTION 0 net The destination network is unreachable
1 host The destination host is unreachable
2 prot or protocol The designated transport protocol is not supported
3 port The designated transport protocol (e.g., UDP) is unable to demultiplex the datagram but has no protocol mechanism to inform the sender
4 needfrag Fragmentation is needed and the Don't Fragment flag is set
5 srcfail Source route failed
6 net-unknown The destination network is unknown. This code normally should not be generated. It implies that the destination network does not exist. Code 0 (Network Unreachable) should be used in place of Code 6. 7 host-unknown The destination host is unknown.
8 *see footnote The source host is isolated. Routers should not generate Code 8; 14 whichever of Codes 0 (Network Unreachable) and 1 (Host Unreachable) is appropriate should be used instead.
9 *see footnote Communication with the destination network is administratively 14 prohibited. This code was intended for use by end-to-end encryption devices used by U.S military agencies. Routers should use the newly defined Code 13 (CommunicationAdministratively Prohibited) if they administratively filter packets.
10 *see footnote Communication with the destination host is administratively 14 prohibited. Same reasoning as message 9 above.
11 net-tos Destination network unreachable for the designated type of service
12 host-tos Destination host unreachable for the designated type of service
13 prohibited Communication Administratively Prohibited
14 precedence Host Precedence Violation
15 precedence- Precedence cutoff in effect cutoff rst This is a special keyword which will not send an ICMP Destination Unreachable message but instead a TCP RST packet.
The Log and Trace Keywords Use the keywords ‘log’ and ‘trace’ to log actions taken by the packet filter or dump the contents of the matching packet (in hex) to the system log.
Example 1: !frag/trace # block and dump the contents of any IP fragment # received Example 2: tcp/syn/send/log # pass and log all outbound TCP connection # requests
74 Morning Star PPP
There are two ways to invoke the ‘log ’ keyword. The log filter allows you to define, in one location, all the packets you wish to log. Or you can add the log keyword to the individual rules in the ‘pass' filter as shown in the above examples. Generally, it is easier to add a rule in the log filter requiring all rejected packets be logged rather than adding a ‘log' qualifier to all rules that block packets.
Stanza Syntax The syntax of a stanza is very flexible. In general, the order of the values and keywords in the stanza are not fixed, although certain combinations of keywords are not allowed. The rules that do exist are:
· Each value and keyword in a stanza must be separated by a single ‘/’ · In a negation, the ‘!’ must be the first character of the stanza · When a network mask accompanies a network address, the mask must follow the address · Since white space created with a space, tab, or newline entry separates stanzas, no white space is permitted within a stanza · Only one protocol (e.g. tcp/udp/icmp) may be specified per stanza · syn, fin, ack, rst, or estab may not appear in the same stanza
Example: The following rules describe the same packet filtering, and would cause the same template to be invoked.
Example 1: !telnet/syn/recv/192.0.2.0/255.255.255.0 Example 2: !192.0.2.0/recv /syn/255.255.255.0/telnet
Writing a Stanza - A Complex UDP Example
The following section describes the writing of a rather complex packet filter involving the Domain Name System (DNS ). It provides a good example of why you need to understand the applications in use when writing packet filters. It also shows the difficulty of writing static packet filters for UDP packets without permitting inbound network access in order to permit outbound service.
A brief explanation follows each rule. The explanation attempts to illustrate the security considerations which prompted the creation of the rule.
An Unsafe Domain Name System Rule Your security policy should allow access for packets that need to cross the link to fulfill your needs, while still keeping out as many unrelated packets as possible. Look at the following example of a rule concerning domain name queries. It is one of easiest rules you could add to permit domain name queries, but it is also the most insecure.
1. domain/udp
75 Morning Star PPP
Think of the stanza as though it were translated into this simple pseudo-code:
if protocol is UDP AND source or destination port is domain (53) then permit the packet to pass
This means that a user on an outside host sending a UDP packet from port 53, could reach ANY UDP destination port on ANY host on your local network, including privileged ports used by other services. This would not be "safe".
What Happens During Domain Name Queries In the simplest case for domain queries, hosts on your network will send all ‘domain’ IF YOU DO NOT RUN A LOCAL DOMAIN NAME requests to your domain name server. Your server will check to see if it has the information SERVER YOUR cached. If not, it will query other domain name servers on the Internet to obtain the QUERIES WILL LOOK information. MOST LIKE THE FINAL CASE EXAMINED The packet exchange will look similar to those shown below, where the entries mean the following:
· ‘dns’ is the IP address of the domain name server, · ‘domain’ is UDP port 53, · ‘any’ is any IP address on the inside or outside network (as appropriate), · the arrow, or , represents the direction of travel:
dns.domain any.domain # the outbound domain request dns.domain any.domain # the inbound response to the request
In appearance, this is similar to an actual log file entry. The diagram explains fields in a normal log entry.
udp 192.168.199.11/domain -> 10.0.5.1/domain 124 ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | + packet size (bytes) | | | | | + foreign port | | | | + foreign address | | | + direction | | + local port | + local address + protocol
76 Morning Star PPP
Developing Safer Domain Name Request Rules
An Exercise in Simplifying Rules This section illustrates a process you might go through to develop domain name rules. Throughout the steps, the illustration includes two paths you might take. The first shows how individual rules might be developed. The second shows how the first rules can be condensed with the same results. After each group of rules, we will evaluate the progress, considering loopholes which might be created by the way the rules have been written. Throughout the examples we will use 192.168.199.11 to represent the IP address of the domain name server.
Step 1 Handling Domain Name Requests The first example attempts to map each packet description into a separate rule to permit these packets through the pass filter. This results in two rules similar to the following: a) udp/srcaddr=192.168.199.11/srcport=domain/send /dstport=domain udp/dstaddr=192.168.199.11/dstport=domain/recv /srcport=domain
Alternatively, group (a) can be combined and simplified into a single rule similar to:
2) udp/192.168.199.11/dstport=domain/srcport=domain
Both the outbound request and the inbound response match this template and no packets to UDP ports other than domain (53) are permitted by the rule.
Domain Name Requests from Other Domain Name Servers In general, domain name servers on the Internet will also want to query your domain name server to obtain information. The packet exchange will be very similar to the outbound request but reversed in order:
dns.domain any.domain # the inbound domain request dns.domain any.domain # the outbound response to the request This means that both the individual rules in example (a) and the combined rule in example (2), which were created to handle requests from outside hosts, are still functionally correct.
Step 2 - Rules for Domain Name Requests from Applications There is a limitation associated with rules (a) and (2) concerning domain name queries. It arises because not all queries from the Internet will come from a domain name server. Some will come from applications, such as ‘nslookup’ or ‘host’ that use an unprivileged port (i.e., a port in the range of 1024-65535).
The packet exchange for such an inbound domain query resembles the following, where ‘unpriv’ is any port from 1024-65535.
dns.domain any.unpriv # the inbound domain request dns.domain any.unpriv # the outbound response to the request
Because the query comes from an unprivileged port you will need to add two additional rules to example (a) to cope with the new packets. You will now need four stanzas to deal with domain queries.
77 Morning Star PPP
(b) udp/dstaddr=192.168.199.11/dstport=domain/recv /srcport=1024-65535 udp/srcaddr=192.168.199.11/srcport=domain/send /dstport=1024-65535
In this situation, if you combined the original rules as in example (2), it can be modified to permit the inbound request by removing the restriction on ‘srcport'. However, the revised rule (2) will still block the outbound response, causing the query to fail. To permit the outbound packet, you must add another rule following rule (2). Call it rule (3).
(2) udp/192.168.199.11/dstport=domain (3) udp/srcaddr=192.168.199.11/srcport=domain/send /dstport=1024-65535
Comparing the examples (a) and (b) to examples (2) and (3), you have reduced the number of rules needed from 4 to 2.
Checking the Outcome of Simplifying in Step 2
SECURITY When trying to simplify, it is important you double check your assumptions. You should not CONSIDERATION - use "udp/192.168.199.11/srcport=domain", although it would permit the query to succeed, DOUBLE CHECK because it will also match packets that should not be permitted. That rule is similar in YOUR ASSUMPTIONS! function to this pseudo code that follows it.
(2) udp/192.168.199.11/srcport=domain
if protocol is UDP AND source or destination IP address is 192.168.199.11 AND source port is domain (53) then permit the packet to pass
This means an outside host sending a UDP packet from port 53 to 192.168.199.11 can access ANY destination port, including privileged ports used by other services. This would not be "safe".
Similarly, if an internal user on the domain name server uses an application such as ‘nslookup' to send a query directly to another domain name server, rather than sending the query to the local domain name server, the packet traces and rules needed to deal with them will change.
dns.unpriv any.domain # the outbound domain request dns.unpriv any.domain # the inbound response to the request
Step 3 - Matching Packets as Closely as Possible SECURITY If you want your templates to match the packets as closely as possible, you must add two CONSIDERATION - further rules (c) to (a) and (b). You now have 6 rules if you have not attempted to condense MAKE YOUR the rules. TEMPLATE MATCH THE PACKETS AS CLOSELY AS (c) udp/srcaddr=192.168.199.11/srcport=1024-65535/send /dstport=domain POSSIBLE udp/dstaddr=192.168.199.11/dstport=1024-65535/recv /srcport=domain
If you have simplified rules (a) and (b) and have used rules (2) and (3), the additional packets also cause rule (3) to block some of the necessary traffic. This is because the inbound packet, while originating from the domain port, does not have a source address of the domain name server. After making the change to accommodate the differences, by removing the restriction on direction (‘send') and relaxing the restriction on address, you have replaced rule (3) with the edited rule resembling (4).
78 Morning Star PPP
(2) udp/192.168.199.11/dstport=domain (4) udp/192.168.199.11/srcport=domain/dstport=1024-65535
Step 4 - Minimizing External Control of Data Passing through the Packet Filter Up to this point the rules have always been based on the trust of data under local control. With static filtering, the second rule now permits data that is under external control through the packet filter.
if protocol is UDP AND source or destination IP address is 192.168.199.11 AND source port is domain (53) AND destination port is in the range 1024-65535 then permit the packet to pass
This means that an external host can send UDP packets from port 53 to any unprivileged port on the domain name server without requiring an internal initiator. Unfortunately, there are a number of assigned ports, such as the normal default NFS port (2049/udp), which are SECURITY allocated out of the unprivileged port range and can present security problems. You can CONSIDERATION - MINIMIZE RISK BY minimize the risk by reducing services on your domain name server and by adding REDUCING SERVICES additional rules to block access to those services before the second rule. If you explicitly ON YOUR DOMAIN block access to the port first, the packet will not reach the rule that gives it permission to pass NAME SERVER because the filter will stop as soon as a match is found
Finally, an internal user on a local host other than the domain name server may use the ‘server’ command of ‘nslookup’ to change the default server. In this case, the packet will not be sent to the local domain name server but directly to the external domain name server.
any.unpriv any.domain # the outbound domain request any.unpriv any.domain # the inbound response to the request
Once again, permitting the traffic to pass requires adding two additional rules, labeled (d) in the example, to group (a) (b) and (c). Now there are a total of 8 rules.
(d) udp/srcaddr=192.168.199.0/srcport=1024-65535/send /dstport=domain udp/dstaddr=192.168.199.0/dstport=1024-65535/recv /srcport=domain
The condensed version of the rules also requires that rule (4) be modified to permit proper operation. The modification is required because the outbound packet has a destination port domain’ , but it is not to or from the IP address of the domain name server (192.168.199.11). After removing the IP address restriction, the final set of simplified rules is:
(2) udp/dstport=domain (5) udp/srcport=domain/dstport=1024-65535
Conclusion
SECURITY Domain name service offers a strong example of the tradeoff between functionality and CONSIDERATION - security. It also illustrates the complexity of maintaining security. The level of service you LET POLICY DICTATE decide to offer should strongly affect the rules you use. Your security policy should dictate THE LEVEL OF SERVICE YOU OFFER the level of service you offer. You should not, in general, let the desired functionality dictate your security policy.
79 Morning Star PPP
Writing a Stanza - TCP Examples
A Note about SYN Bits To open a TCP data stream, the initiator sends a packet to the intended recipient. The SYN bit (with no ACK bit) is set in the TCP header to show a TCP connection request. The special keyword ‘syn’ will match packets which have the SYN bit set, but no ACK bit set. This allows you to filter or log packets which start connections.
The TCP protocol requires more than a single SYN packet for a TCP connection to work. This means you cannot enable TCP connections with a single ‘syn ’ rule.
Two Approaches to Filtering TCP connections There are two approaches to filtering TCP connections. The first approach is to block ‘syn ’ packets you do not want to establish a service, while permitting all other packets for the service.
Example: !telnet/syn/recv # block inbound telnet connection requests telnet # permit all other telnet packets
The second approach is to permit the ‘syn’ packets you do want to establish a connection, followed by permitting any other non-SYN packets. The opposite of using the ‘syn ’ keyword is the ‘estab’ keyword. ‘estab’ describes any TCP packet that does not have the SYN bit set or that has both the SYN and ACK bits set in the TCP header.
Example: telnet/syn/send # permit outbound telnet connection requests telnet/estab # permit packets to established connections
Identifying Rulesets with Hostnames and Addresses The first line of a ruleset must contain a hostname , IP address, or ‘default’ that identifies the interface you wish to use the ruleset. For pppd , use the peer, or remote, IP address. This hostname or IP address must not be indented because the name/address will be assumed to be part of a rule and may or may not cause a syntax error.
SECURITY We recommend that you use an IP address, but, if you use a hostname, it is important that the CONSIDERATION - system can resolve the hostname locally. If the link must be up to resolve the name, the USE AN IP ADDRESS hostname matching will fail and the interface will be forced to use the default ruleset. This OR A HOSTNAME WHICH CAN BE changes the meaning of your filter file and causes long delays because the connection will RESOLVED LOCALLY timeout while waiting for name resolution.
A Note on Ruleset Formatting Each additional line of a ruleset (continuation lines) must be indented, using one or more white space characters (space or tab). If a line is not indented, the first word on the line is assumed to be a hostname for a new ruleset.
POUND SIGNS(#) Any information which follows a ‘#’ character on a line is assumed to be a comment and is IDENTIFY COMMENTS ignored. IN A RULESET
80 Morning Star PPP
Ordering Stanzas Effectively When a ruleset has been selected, each stanza is applied in order, top to bottom, and left to right. The filter returns when it finds a matching stanza. It is therefore important that you order stanzas in the Filter file in most specific to least specific (most general) order. If the SECURITY order is reversed, the most general rule will match first and the filter will never reach the CONSIDERATION - more specific rules. PLACE STANZAS IN MOST SPECIFIC TO LEAST SPECIFIC Example: (CORRECT) ORDER domain/192.0.2.1 # permit DNS to/from 192.0.2.1 !domain # prevent all (other) DNS
Example: (WRONG) !domain # prevent all DNS domain/192.0.2.1 # this rule is never reached
Isolating an 'Incorrect' Stanza
USE ONE STANZA When pppd finds an error in the Filter file, the line number that caused the failure is reported. PER LINE TO ISLOATE When a packet is rejected due to a filter and the 'log rejected' keyword is used, the line PROBLEMS number that caused the rejection can be recorded in the log file . Therefore, when tracking down problems, you can quickly isolate the correct stanza if only one stanza is used per line.
Working with Default Rulesets The hardwired default ruleset is:
default bringup all pass all keepup all log !all
This is probably an unacceptable default if you are trying to filter packets. Your default SECURITY should be the same as your most restrictive ruleset because it will keep your site secure if CONSIDERATION - REDUCE MISTAKEN connection specific filtering fails due to a misconfigured IP address or hostname. ASSUMPTIONS BY REQUIRING THE The following sections deal with two approaches to writing default rulesets. The difference DISPLAY OF ALL DEFAULTS between the two approaches is apparent from their names, the "closed policy" and the "open policy." Open Policy Default Rulesets
If you are willing to accept most packets from a site from which you have not previously accepted traffic, a reasonable default filter might be:
default bringup all SECURITY pass !exec !tftp all CONSIDERATION - keepup all BLOCK TFTP AND log rejected !all REXEC PROTOCOLS Notice the use of ‘all’ rather than ‘!all’ at the end of each filter. This default ruleset will only block ‘tftp’ packets and ‘rexec’ packets, two protocols that normally should never cross organizational boundaries.
A Note on Using the ‘log rejected’ Filter In the previous example, and in the following Closed Policy examples, we use the ‘log SECURITY CONSIDERATION - rejected’ filter. This is a good default log filter to use. When testing, it permits you to see that USE THE LOG REJECTED FILTER AS A DEFAULT
81 Morning Star PPP
your filter is working as expected and keeps track of outside attempts to connect through to blocked services.
Closed Policy Default Rulesets The closed policy default rulesets in the examples that follow illustrate the way services can be safely and incrementally allowed for a remote site. This approach begins from the premise that no packets should be allowed to pass .
Block All Packets If your security policy changes and you must block packets from a formerly acceptable site, you might change the default filter to the following:
default bringup !all pass !all keepup !all log rejected !all
Block All Packets Except Electronic Mail However, most sites are not this "paranoid" and are willing to permit electronic mail through the workstation or system. For this, and the following examples, it is important that you have the smtp service defined in your services file. To help prevent any problems due to this assumption, you could use the explicit port number, protocol, and IP address to test. Then you might write the default this way:
default bringup !all pass 25/tcp !all keepup !all log rejected !all
SECURITY The filter file is easier to read and comprehend if you use the service name . Still, specifying CONSIDERATION- the explicit port number and protocol can also prevent someone from changing the meaning SPECIFY EXPLICIT of your rulesets by subverting NIS . The benefit may be negligible, though, if the information PORT NUMBERS AND PROTOCOLS is only checked against the local services file. Intruders able to modify the services file could also modify the filter file.
Limiting Electronic Mail to a Gateway Machine If you wish to limit electronic mail access to a gateway machine, you need to add the qualification to the smtp stanza. The next two examples use the fictitious name/address bignfast/192.0.2.1.
default bringup !all pass smtp/bignfast !all keepup !all log rejected !all
Unresolvable Hostnames and Changing IP Addresses In the last example we used the hostname 'bignfast'. But consider the inherent problem of using a hostname instead of the IP address. If the host address cannot be resolved, you may reach a state of "deadlock" because the name must be resolved for the service to begin , but the service must begin for the name to be resolved. The example below may be more reliable.
default bringup !all pass smtp/192.0.2.1 !all keepup !all log rejected !all
However, nothing is perfectly reliable. Being explicit can cause other problems if you change SECURITY CONSIDERATION - the address of the server. The reliability of using an IP address instead of a hostname, or vice EXPLICIT IP versa, may only be decided on a site-by-site basis. Still, we strongly favor using IP addresses ADDRESSES PREVENT over using hostnames. One benefit is that specifying the explicit IP address prevents people DNS SPOOFING from changing the meaning of your rulesets by DNS spoofing.
82 Morning Star PPP
Conclusion Build up the list of what you would let an unknown site do a little at a time as you discover services you wish to allow. The important thing is to remember to place ‘!all’ at the end of each filter. You and any future manager can quickly see you are blocking all but specific packets and you reduce the chance that someone will accidentally change the meaning of the implicit ending stanza to ‘all’.
A Note - Blocking Loose Source and Strict Source Routing Options SECURITY Using the IP Source Routing options, it is possible for people to send packets to you that look CONSIDERATION - BLOCK LSRR AND like they are coming from a host on your network. Prevent this sort of attack by blocking SSRR IP OPTIONS packets that have the Loose Source Routing or Strict Source Routing IP options set. If you want to be restrictive, add the line below to all your rulesets, including your default ruleset in the default pass filter:
!ip-opt=srcrt
83 Morning Star PPP
A Complete Filter - Closed Policy - An annotated example
Here's an example static filter configuration, appropriate for a system using pppd to create a PPP/SLIP link between the system 192.168.199.1 and a peer , 10.0.0.1, that is acting as the gateway to the Internet. The complete filter, minus the comments, follows this section.
The filter design reflects a fail-safe, or closed, policy.
default DEFAULT pass !all # block all other packets log rejected # packets rejected by packet filter
First, we define a default ruleset that is very restrictive. This is a failsafe ruleset that will not pass any packets through the filter, but will notify you of all traffic you are missing.
10.0.0.1 IP ADDRESS
This ruleset will be applied to any packet crossing the link connecting this host to the peer (10.0.0.1).
bringup BRINGUP FILTER !3/icmp # ICMP unreachable messages !5/icmp # ICMP redirect messages !11/icmp # ICMP time exceeded messages !who # WHO service (513/udp) !route # routed /gated RIP service (520/udp) !ntp # Network Time service (123/udp) all # all other packets
If the link is configured for ‘dial on demand ’ connections, the ‘bringup’ filter describes those packets that will cause a call to be placed and a connection to be initiated. The ‘bringup’ filter should be used to prevent the connection from being brought up inappropriately. It is a good idea to block packets that are responses to "bad" inbound packets, such as ICMP Destination unreachable messages, because they aren't "interesting" enough to dial the modem. You should also block services, such as the WHO service, that send packets at a regular intervals and would therefore never permit the link to stay down long. Any other sort of traffic will initiate a dial connection.
pass PASS FILTER !recv /ip-opt=srcrt/unreach =srcfail # Block SRCRT attacks
Don't allow any incoming packets with the Source Route option set in the IP header. Respond with an ICMP Destination Unreachable message with the Source Route Failed code value.
!192.168.199.0/recv /src/unreach=net # Block IP spoofing attacks !192.168.199.0/send /dst/unreach=net # Block IP spoofing attacks
Block any incoming packets that claim to be from your net, and block any outgoing packets that claim to be destined for your net. Respond with an ICMP Destination Unreachable message with the Bad Net code value. 15
!127.0.0.0;8 # Block IP spoofing attacks
15 See CERT Advisory CA 95:01
84 Morning Star PPP
Silently block all packets that claim to be either to or from the loopback network.
dstport=nntp/dstaddr=192.168.199.10/srcaddr=10.0.5.6 dstport=nntp/srcaddr=192.168.199.10/dstaddr=10.0.5.6 dstport=nntp/dstaddr=192.168.199.10/srcaddr=172.31.12.13 dstport=nntp/srcaddr=192.168.199.10/dstaddr=172.31.12.13 !nntp/unreach =rst
Allow Network News (Usenet ) exchanges with only your known news neighbors (10.0.5.6 and 172.31.12.13) and your news server 192.168.199.10). Block any other NNTP traffic, and respond with a TCP RST message.
domain/tcp/192.168.199.11/dst /syn/recv # (53/tcp) !domain/tcp/syn /recv domain/tcp/192.168.199.11
Allow outside hosts to obtain Domain Name Service zone transfers only if your end of the stream is really being handled by your domain name server. In this example, you first permit inbound requests to the domain name server, then block all other inbound requests, and finally allow any TCP packets to pass over the link if they are to or from the host 192.168.199.11 and to or from the domain port to pass over the link. The sender will not be notified that the packets are being dropped.
dstport=domain/udp/192.168.199.11 # permit domain queries (53/udp) !domain # block domain (53/tcp, 53/udp)
Allow Domain Name Service (DNS ) queries to and from the DNS server. Block all other domain requests. This second rule is not strictly necessary, since the final rule is ‘!all’, however adding this rule makes it failsafe.
smtp/192.168.199.14/dst /syn/recv # (25/tcp) !smtp/syn /recv smtp
Allow incoming electronic mail connection requests to reach your SMTP server, allow no other incoming SMTP connection requests, and allow yourself unlimited outbound SMTP access.
www/syn /recv/192.168.199.13/dst # (80/tcp) !www/syn /recv/unreach=host # www #
Allow incoming World Wide Web connection requests to reach your WWW server. Allow no other incoming WWW connection requests. And allow yourself unlimited outbound WWW access.
!dstport=ident/recv /unreach=rst # block IDENT service (113/tcp)
You don't use the RFC 1413 identification services, so you might as well bounce the queries at the gateway instead of having inetd refuse the connection. Respond with a TCP RST message. This does not improve the security of your packet filter, since the packets would be blocked by the final ‘!all’, but it does reduce the delay in services that make use of ‘ident’.
!telnet /syn/recv/unreach=prohibited # block inbound TELNET # requests telnet # permit TELNET messages
Allow outbound telnet connections from your network to anywhere else.
85 Morning Star PPP
!finger /syn/recv/unreach=prohibited # block inbound FINGER # requests finger # permit FINGER messages Block incoming finger requests until you install a safe finger daemon .
ftp /syn/recv/dst/192.168.199.12 # permit inbound FTP for anon FTP !ftp /syn/recv/unreach=host # block inbound FTP # requests
Allow incoming FTP (file transfer) traffic that uses your Anonymous FTP server system, but block any other incoming FTP requests. Respond with an ICMP Destination Unreachable message with the Bad Host code value.
ftp # permit FTP messages srcport=ftp -data/dstport=1024-65536/syn !ftp -data/syn # block other FTP-DATA connections ftp -data # permit FTP-DATA messages
After blocking the traffic specified above, allow both FTP command streams and FTP data streams to cross the link, both inbound and outbound.
dstport=33410-33515/udp/send # permit outbound traceroute operation
The traceroute tool probes high-numbered UDP ports and is so useful that you should let it through.
!5/icmp # block ICMP _REDIRECT 8/icmp/192.168.199.1 # permit ping of gateway 8/icmp/192.168.199.10 # permit ping of NNTP server 8/icmp/192.168.199.11 # permit ping of DNS server 8/icmp/192.168.199.12 # permit pi ng of FTP server 8/icmp/192.168.199.13 # permit ping of WWW server 8/icmp/192.168.199.14 # permit ping of SMTP server !8/icmp/recv # block inbound ping address # scanning icmp # permit ICMP messages
Block ICMP redirect messages since the routing on an internal node should not be changed by an external site. Permit ICMP echo request packets, sent by ‘ping ’, to reach all hosts providing external services. Block all other inbound ping packets to prevent IP address probes. Finally, allow other ICMP messages to pass freely.
!all # block all other packets
Silently block all traffic not explicitly permitted to pass . Pass through the firewall only those packets explicitly permitted to pass.
keepup KEEPUP FILTER !send # outbound traffic !3/icmp # ICMP unreachable messages !5/icmp # ICMP redirect messages !11/icmp # ICMP time exceeded messages !who # WHO protocol !route # routed/gated RIP protocol !ntp # Network Time Protocol all # permit all other packets
The link will be considered active (non-idle) if any packet passes that's not specified in the keepup filter as being blocked. Since there are certain link failure modes that will allow your system to continue sending even though the peer is unresponsive, no outbound packets are permitted to reset the idle timer .
86 Morning Star PPP
log LOG FILTER !8/icmp # ICMP ECHO packets rejected # packets rejected by packet # filter tcp/syn # all TCP connection requests !all # block all other packets
Log any packet blocked by the ‘pass' filter above, except ICMP Echo messages. Also log all TCP connection requests.
87 Morning Star PPP
A Complete Filter - Open Policy - An annotated example
This example of a filter is the product of an open policy. It was developed for the same system configuration as was used in the previous example demonstrating a filter developed for a closed policy. The system uses pppd to create a PPP/SLIP link between the system 192.168.201.1and a peer , 10.0.0.1, that is acting as the gateway to the Internet .
default DEFAULT
Since this ruleset is declared as the default ruleset and no ruleset has been defined for 10.0.0.1, it will be applied to any packet crossing the link connecting this host to any peer , including the Internet gateway (10.0.0.1).
bringup BRINGUP FILTER !3/icmp # ICMP unreachable messages !5/icmp # ICMP redirect messages !11/icmp # ICMP time exceeded messages !who # WHO service (513/udp) !route # routed/gated RIP service # (520/udp) !ntp # Network Time service (123/udp) all # all other packets
If the link is configured for ‘dial on demand ’ connections, the ‘bringup’ filter describes those packets that will cause a call to be placed and a connection to be initiated. The ‘bringup’ filter should be used to prevent the connection from being brought up inappropriately. It is a good idea to block packets that are responses to "bad" inbound packets, such as ICMP Destination unreachable messages, that aren't "interesting" enough to dial the modem. You should also block services, such as the WHO service, that send packets at a regular intervals and would therefore never permit the link to stay down long. Any other sort of traffic will initiate a dial connection.
pass PASS FILTER !recv /ip-opt=srcrt/unreach =srcfail # block SRCRT attacks
Don't allow any incoming packets with the Source Route option set in the IP header. Respond with an ICMP Destination Unreachable message that has the Source Route Failed code value.
!192.168.199.0/recv /src/unreach=net # block IP spoofing # attacks !192.168.199.0/send /dst/unreach=net # block IP spoofing # attacks Block any incoming packets that claim to be from your net, and block any outgoing packets that claim to be destined for your net. Respond with an ICMP Destination Unreachable message that has the Bad Net code value. 16
!127.0.0.0;8 # block IP spoofing attacks
Silently block all packets that claim to be either to or from the loopback network.
!dstport=ident/recv /unreach=rst # block IDENT service (113/tcp)
16 See CERT Advisory CA 95:01
88 Morning Star PPP
You don't use the RFC 1413 identification services, so you might as well bounce the queries at the gateway instead of having inetd refuse the connection. Respond with a TCP RST message. This does not improve the security of your packet filter, since the packets would be blocked by the final ‘!all’, but it does reduce the delay in services that make use of ‘ident’.
!chargen/unreach =prohibited # block chargen service # (19/tcp,19/udp) !discard/unreach =prohibited # block discard service # (9/tcp,9/udp) !echo/unreach =prohibited # block echo service # (7/tcp,7/udp) Block access to your ‘‘character generator'' port, and two others, because they are only meant as testing facilities and could be used by someone outside to swamp your network's bandwidth with unwanted, but otherwise harmless, traffic.
!5/icmp # block ICMP _REDIRECT
Block ICMP redirect messages since the routing on an internal node should not be changed by an external site.
!sunrpc # block portmap (sunrpc 111/tcp,111/udp) !exec # block rexecd (512/tcp) !login # block rlogind (513/tcp) !shell # block rshd (514/tcp) !syslog # block syslogd (514/udp) !printer # block lpd (515/tcp) !2049/udp # block nfsd (2049/udp)
Block access to a number of services that depend upon IP addresses for authentication, or that have no authentication built-in.
!tftp # block tftp (69/udp)
Block access to the tftp port because it is sometimes buggy and thus permit access to files that should not be distributed, such as password files. It is normally only used locally and should not be receiving requests from outside the local area network .
all # permit all other packets
Permit all traffic except that which you've explicitly specified as blocked, through the firewall.
keepup KEEPUP FILTER !send # outbound traffic !3/icmp # ICMP unreachable messages !5/icmp # ICMP redirect messages !11/icmp # ICMP time exceeded messages !who # WHO protocol !route # routed /gated RIP protocol !ntp # Network Time Protocol all # all other packets
The link will be considered active (non-idle) if any packet passes that's not specified as blocked in the keepup filter. Since there are certain link failure modes that will allow your system to continue sending even though the peer is unresponsive, no outbound traffic counts against the idle timer.
89 Morning Star PPP
log LOG FILTER rejected # packets rejected by packet filter !all # block all other packets Log any packet blocked by the ‘pass' filter above.
Common mistakes A number of errors are common enough to be specifically pointed out.
Incorrect hostname Earlier documentation for MS PPP used "internet-gateway" to define the ruleset. This is the example hostname that was chosen to illustrate what the hostname might be. Many people have become confused and thought it was a special keyword. It is not! You must supply a real hostname or IP address or the keyword ‘default’.
Incorrect Ruleset Indentation Another common mistake is to accidentally indent the ruleset identifier (e.g. hostname , IP address, or ‘default'). This causes the software to assume that it is a part of the previous ruleset rather than defining the start of a new ruleset.
Yet another common mistake is not indenting all the parts of a ruleset after the initial ruleset identifier. This will cause the software to assume that the stanza is the start of a new ruleset. This will cause both failures and/or delays as the software tries to resolve the stanza into an IP address.
Incorrect Use of 'tcp' and 'udp' A different error is to fail to specify ‘tcp’ or ‘udp’ when a service can use either service but the keywords are applicable to only one. An example of this is the domain name service (DNS ), which uses UDP for normal queries, but TCP for zone transfers. If you try to block inbound requests for a zone transfer you must remember to add the ‘tcp’ qualifier to the service name ‘domain’ to prevent a syntax error.
Attempting to Send Hostnames Requiring Resolution over Down Network Links You can easily, but mistakenly, use a hostname that needs to be resolved because it is is not defined or requires DNS , over a network link that is down. This causes failures and/or delays. Therefore, we would strongly recommend the use of only IP address in filter files.
Failing to Allow Passage of 'ftp' Data Packets over the 'ftp-data' Port Less commonly, some people who do not fully understand the protocol only permit ‘ftp’ packets to pass through their filter. The FTP protocol actually uses two channels; the first channel is used for commands and the second port is for used for data. The second channel uses a separate port, commonly ‘ftp-data’, but that is actually determined during the FTP negotiations. The second channel is normally a reverse channel used to transfer data back to the client.
90 Morning Star PPP
Blocking Packets Required for Network Access Finally, carefully make sure you permit passage of all packets required for your network access. Some Internet Service Providers (ISPs) require the use of a routing protocol and will mark the link inactive if they do not receive routing packets. This may require a rule in the pass clause of your ruleset to permit the route packets to traverse the link (e.g., ‘route’).
91 Morning Star PPP
Example of Static Packet Filter Developed for Closed Policy default pass !all # block all other packets log rejected # packets rejected by packet filter 10.0.0.1 bringup !3/icmp # ICMP unreachable messages !5/icmp # ICMP redirect messages !11/icmp # ICMP time exceeded messages !who # WHO service (513/udp) !route # routed/gated RIP service (520/udp) !ntp # Network Time service (123/udp) all # all other packets pass !recv /ip-opt=srcrt/unreach =srcfail # block SRCRT attacks !192.168.199.0/recv /src/unreach=net # block IP spoofing attacks !192.168.199.0/send /dst/unreach=net # block IP spoofing attacks !127.0.0.0;8 # block IP spoofing attacks dstport=nntp/dstaddr=192.168.199.10/srcaddr=10.0.5.6 dstport=nntp/srcaddr=192.168.199.10/dstaddr=10.0.5.6 dstport=nntp/dstaddr=192.168.199.10/srcaddr=172.31.12.13 dstport=nntp/srcaddr=192.168.199.10/dstaddr=172.31.12.13 !nntp/unreach =rst domain/tcp/192.168.199.11/dst /syn/recv # (53/tcp) !domain/tcp/syn /recv domain/tcp/192.168.199.11 dstport=domain/udp/192.168.199.11 # permit domain queries (53/udp) !domain # block domain (53/tcp, 53/udp) smtp/192.168.199.14/dst /syn/recv # (25/tcp) !smtp/syn /recv smtp www/syn /recv/192.168.199.13/dst # (80/tcp) !www/syn /recv/unreach=host www !dstport=ident/recv /unreach=rst # block IDENT service (113/tcp) !telnet /syn/recv/unreach=prohibited # block inbound TELNET requests telnet # permit TELNET messages !finger /syn/recv/unreach=prohibited # block inbound FINGER requests finger # permit FINGER messages ftp /syn/recv/dst/192.168.199.12 # permit inbound FTP for anon FTP !ftp /syn/recv/unreach=host # block inbound FTP requests ftp # permit FTP messages srcport=ftp -data/dstport=1024-65536/syn !ftp -data/syn # block other FTP-DATA connections ftp -data # permit FTP-DATA messages dstport=33410-33515/udp/send # permit outbound # traceroute operation !5/icmp # block ICMP _REDIRECT 8/icmp/192.168.199.1 # permit ping of gateway 8/icmp/192.168.199.10 # permit ping of NNTP server 8/icmp/192.168.199.11 # permit ping of DNS server 8/icmp/192.168.199.12 # permit ping of FTP server 8/icmp/192.168.199.13 # permit ping of WWW server 8/icmp/192.168.199.14 # permit ping of SMTP server !8/icmp/recv # block inbound ping # address scanning icmp # permit ICMP messages !all # block all other packets keepup !send # outbound traffic !3/icmp # ICMP unreachable messages !5/icmp # ICMP redirect messages !11/icmp # ICMP time exceeded messages !who # WHO protocol !route # routed/gated RIP protocol !ntp # Network Time Protocol all # permit all other packets log !8/icmp # ICMP ECHO packets rejected # packets rejected by # packet filter tcp/syn # all TCP connection requests !all # block all oth er packets
92 Morning Star PPP
Example of Static Packet Filter Developed for Open Policy default bringup !3/icmp # ICMP unreachable messages !5/icmp # ICMP redirect messages !11/icmp # ICMP time exceeded messages !who # WHO service (513/udp) !route # routed/gated RIP service (520/udp) !ntp # Network Time service (123/udp) all # all other packets pass !recv /ip-opt=srcrt/unreach =srcfail # block SRCRT attacks !192.168.199.0/recv /src/unreach=net # block IP spoofing attacks !192.168.199.0/send /dst/unreach=net # block IP spoofing attacks !127.0.0.0;8 # block IP spoofing attacks !dstport=ident/recv /unreach=rst # block IDENT service (113/tcp) !chargen/unreach =prohibited # block chargen service # (19/tcp,19/udp) !discard/unreach =prohibited # block discard service # (9/tcp,9/udp) !echo/unreach =prohibited # block echo service # (7/tcp,7/udp) !5/icmp # block IC MP_REDIRECT !sunrpc # block portmap (sunrpc # 111/tcp,111/udp) !exec # block rexecd (512/tcp) !login # block rlogind (513/tcp) !shell # block rshd (514/tcp) !syslog # block syslogd (514/udp) !printer # block lpd (515/tcp) !2049/udp # block nfsd (2049/udp ) !tftp # block tftp (69/udp) all # permit all other packets keepup !send # outbound traffic !3/icmp # ICMP unreachable messages !5/icmp # ICMP redirect messages !11/icmp # ICMP time exceeded messages !who # WHO protocol !route # routed/gated RIP protocol !ntp # Network Time Protocol all # all other packets log rejected # packets rejected by # packet filter !all # block all other packets
93 Morning Star PPP
Appendixes
TUN(4) Progressive Systems
NAME tun - IP network tunnel driver
CONFIGURATION pseudo-device tun[n]
SYNOPSIS #include
DESCRIPTION When IP packets are written to /dev/tunn or /dev/tunn+M, they are received by the kernel ’s IP layer on the network interface du n . When the kernel’s IP layer sends packets to the IP interface dun, they are available for reading on /dev/tunn or /dev/tunn+M.
Instead of having hardware and an associated kernel interface that support network functions, the tun driver allows a network interface to be implemented as a user-space process. While talking to the same set of tunnel driver s on the same system, different network interface processes can implement different IP encapsulation methods, such as RFC 877 for use over CCITT X.25-based public data networks, or RFC 1055 SLIP or RFC 1661/1332 PPP for use over dedicated lines and dialup modems.
The tun driver provides support for a pair of devices collectively known as an IP tunnel. The two devices comprising a tunnel are known as the inbound and outbound sides, similar to the pairing between /dev/ttyn (the inbound terminal) and /dev/cun (the outbound ‘auto-call unit’ available on many systems). The outbound side’s minor device number is that of the inbound side plus M, which is 64, though they together appear to IP as one interface. If both the inbound and outbound sides of a tunnel device are open, packets received from IP are delivered to only the inbound side.
If a TCP packet received from IP is part of a telnet, rlogin, or FTP command stream, it will be put in a fast queue. All packets in the fast queue are delivered to the user before any packets in the normal queue.
IOCTLS A few special ioctls are provided for use on the /dev/tun* devices to supply the functionality needed by applications programs to emulate real hardware interfaces. The complete list of supported ioctls is:
94 Morning Star PPP
TUIOSPTPT Set or clear the IFF_POINTOPOINT in the associated network interface. TUIOSADRMD Set or clear ‘address mode', in which packets read are prefaced with four octets containing the destination IP address in network byte order. The third argument is a pointer to an integer containing either a zero or a one, indicating whether ‘address mode' should be cleared or set, respectively. If both ‘address mode' and ‘packed buffer mode' are set, each packet's length will come first, followed by the packet's destination address, followed by the packet itself
TUIOGADRMD Get the current status of ‘address mode'.
TUIOSPKBMD Set or clear ‘packed buffer mode' where multiple packets are encoded in single read/write buffers. The third argument is a pointer to an integer containing either a zero or a one, indicating whether ‘packed buffer mode' should be cleared or set, respectively. If set (1), each packet is preceded by four octets representing the next packet's length in octets. The following packet will then be aligned to the next multiple of four octets. If cleared (0), packets will be delivered one per read(3) from the tunnel device. If both ‘address mode' and ‘packed buffer mode' are set, each packet's length will come first, followed by the packet's address, followed by the packet itself.
TUIOGPKBMD Get the current status of ‘packed buffer mode'.
TUIOSPKMAX Set the max number of IP frames to send back in a packet buffer read.
TUIOGPKMAX Get the PKMAX value.
TUIOSPKPAD Set the number of long word zeroes to put on the front of each packet read in packed buffer mode.
TUIOGPKPAD Get the number of pad words.
TUIOSNAME Set the interface name (may only be invoked by the superuser).
TUIOGNAME Get the interface name.
FIONBIO Set or clear non-blocking mode for I/O operations
EXAMPLE #include
tun_fd = open("/dev/tun0", O_RDWR); ioctl(tun_fd, TUIOSNAME, "du"); len = read(tun_fd, packet, size); write(tun_fd, packet, len);
ERRORS If a packet is delivered to the interface for an address family other than AF_INET, EAFNOSUPPORT will be returned.
FILES /dev/tun0 through /dev/tunM-1 ‘inbound' tunnel devices
95 Morning Star PPP
/dev/tunM through /dev/tun2*M-1 ‘outbound' tunnel devices
SEE ALSO ppp.Auth(5), ppp.Devices(5), ppp.Dialers(5), ppp.Filter(5), ppp.Keys(5), ppp.Systems(5), pppd(8), RFC 1661, RFC 1332, RFC 1144, RFC 1055, RFC 877
COPYRIGHT INFORMATION Copyright 1991-1997 Progressive Systems Inc.; all rights reserved.
96 Morning Star PPP
PPP.AUTH(5) MS PPP
NAME ppp.Auth - PPP authentication file format
DESCRIPTION The file /etc/ppp/Auth contains values used by MS PPP's implementation of the link-level authentication protocols, CHAP (Challenge Handshake Authentication Protocol) and PAP (Password Authentication Protocol). This implementation of both CHAP and PAP conforms to RFC 1334, PPP Authentication Protocols.
CHAP is a stronger authentication mechanism. Use CHAP whenever possible instead of PAP. Earlier versions of MS PPP provided interoperability with draft versions of CHAP pppd's oldchap or olderchap command line options. However, these options are long out of date and have been eliminated from this version of the software.
SECURITY CONCERNS The file /etc/ppp/Auth should be mode 600 or 400, and owned by root .
FORMAT · Each authentication specification is on its own single line of up to 1023 characters. · Comments begin with a '#' and extend to the end of the line. Blank lines, or lines beginning with a `#', are ignored. Fields are separated by horizontal white space through the use of blanks or tabs. · If pppd is using CHAP authentication, the first word on the line must match the peer 's Name as received in a CHAP Challenge or Response packet and the second word is used for the Secret. · If pppd is using PAP authentication, the first word on the line must match the Peer-ID in a transmitted or received PAP Authenticate-Request packet and the second word is used for the Password. · The default value used for the Name in transmitted CHAP packets or for the Peer-ID in transmitted PAP packets is the hostname(1) of the machine pppd is running on.
In the midst of the Name/Peer-ID and Secret/Password strings, ^x is translated into the appropriate control character before matching, and \xxx represents the character corresponding to the octal number xxx. Other special sequences are:
\s Matches a space character (ASCII 0x20)
\t Matches a horizontal tab character (ASCII 0x09)
\n Matches a line feed character (ASCII 0x0a)
\r Matches a carriage return character (ASCII 0x0d)
97 Morning Star PPP
The fields have the following meaning: name The Name field of a sent or received CHAP Challenge or Response message, or the Peer-ID field of a sent or received PAP Authenticate-Request message. For transmitted packets, this is the hostname unless overridden by the pppd name option. secret The secret word that the peer also knows. optional address A set of zero or more patterns restricting the addresses restrictions that are allowed to be used with the named peer. Patterns are separated by spaces or tabs and are parsed from left to right.
Each pattern may begin with an exclamation mark to indicate that the following pattern should not be allowed.
The rest of the pattern consists of digits and periods, and optionally a leading or trailing asterisk, which will match anything. If none of the patterns match, then the address will be allowed if the last pattern began with an exclamation point, and will be disallowed otherwise.
If the optional address restriction field consists of only a single address, it replaces the the destination address configured on the command line.
EXAMPLE The following Auth provides pppd with a secret for use when a peer claims to be other-host, robin, or 'Jack's machine'.
# # Auth - PPP authentication name/secret file # Format: #name secret optional ad dress restrictions other-host secret-key !137.175.9.2 137.175.9.*/0xffffff00 robin dK3ig8G8hs 137.175.11.4 Jack's\smachine I\sam\sa\sjelly\sdonut.
SEE ALSO tun(4), ppp.Devices(5), ppp.Dialers(5), ppp.Filter(5), ppp.Keys(5), ppp.Systems(5), services(5), pppd (8), RFC 792, RFC 1661, RFC 1332, RFC 1334.
Brian Lloyd and William A. Simpson, "The PPP Authentication Protocols," Internet Draft, May 1992.
COPYRIGHT INFORMATION Copyright 1991-1997 Progressive Systems Inc.; all rights reserved.
98 Morning Star PPP
PPP.DEVICES(5) MS PPP
NAME ppp.Devices - PPP physical device description file format
DESCRIPTION The file /etc/ppp/Devices associates dialer types with physical devices and speeds. Pppd examines it when placing a call to a neighboring machine. If no suitable speed is found, or if all devices associated with that speed are busy, pppd will try again later.
FORMAT · Entries are one to a line · Blank lines are ignored · Comments begin with a `#’ and extend to the end of the line · Upper/lower case distinctions are significant · Fields on a line are separated by horizontal white space created by blanks or tabs · Each entry must contain three or more fields, in this order: dialer Contains either the string `Direct’, the name of the modem dialing chat script in Dialers to use with this device, or the name of an external dialer program. device The name of the device in the /dev directory (ttya, cua, etc.). Device names for SnapLink connections are followed by a slash and the port number in use (rsd2a/0, rrz4a/2, etc.) . speed The baud rate of the synchronous connection, or a string to be matched against the speed field of entries in Systems when the Systems device field is set to ACU (Any Call Unit). Speeds must either be valid async baud-rate numbers as found in
99 Morning Star PPP
There is also a fourth field for describing options: optional parameters Any special handling for this device. Currently supported values are shown in the table below. rtscts Specifies that the line be conditioned for out-of-band EIA RS-232-D ‘hardware’ (RTS/CTS) flow control. The default is to use no flow control. For an outbound connection, this may be specified either in Devices or on the pppd command line. On NeXT systems, enable ttydfa or ttydfb in /etc/ttys instead. On Silicon Graphics systems, use /dev/ttyf2 for a modem with hardware flow control instead. crtscts a synonym for rtscts xonxoff Specifies that the line be conditioned for in-band (`software’) flow control, using the characters DC3 (^S, XOFF, ASCII 0x13) to stop the flow and DC1 (^Q, XON, ASCII 0x11) to resume. The default is to use no flow control. For an outbound connection, this may be specified either in Devices or on the pppd ommand line. internal-clocking The SnapLink will provide the synchronous clock signal. By default, it expects the modem, CSU/DSU or modem eliminator to provide the clock signal. Internal-clocking cannot be used with RS-232 cables on the SnapLink.
32-bit-fcs A SnapLink will calculate 32-bit FCS values for transmitted frames, and check received frames with 32-bit FCS calculations. This is not negotiable at connection establishment time. 32-bit FCS is only available when running synchronous PPP on the SnapLink. min-flags=min flags The number of additional HDLC flag characters a SnapLink should insert between data frames. The default and minimum is 2; the maximum is 16. ignore-cd Ignore the state of the CD (Carrier Detect, also called DCD, Data Carrier Detect) signal. This is useful for systems that don’t support CD but want to run PPP over a dedicated line.
EXTERNAL DIALER The external dialer program is run with the following arguments :
device name The contents of the Device field from the Devices entry
speed The contents of the Speed field of the Systems and Devices entries.
telephone number The contents of the Phone Number field of the Systems entry.
This program also allows for optional parameters:
optional Copied from the Optional Parameters section of the Devices entry. parameters If the external dialer program exits with status 0, then the dial attempt is considered to have succeeded. Any other exit status indicates a failure.
100 Morning Star PPP
EXAMPLE # # Devices - PPP devices file # #Dialer device speed Optional parameters T2500-PEP cuh00 19200-PEP T1600 cul00 38400 Direct rsd0a/0 1536000 internal-clocking Oddball rsd0a/1 64000 cua 9600 5551212
In the last line of this example, the 64Kb synchronous modem on the SnapLink’s port 1 has an asynchronous dialer interface attached to the workstation’s port `a’ The Systems line would look like host Oddball rsd0a/1 64000 0 There must be a program (or an exec utable shell script) called /etc/ppp/Oddball that dials the modem when invoked as Oddball rsd0a/1 64000 0 cua 9600 5551212 A warning message will be printed for each unrecognized optional parameter if the debug level is 2 or more.
CAVEATS The external dialer is invoked as root, so you should take appropriate security precautions with its content and file protection.
SEE ALSO tun(4), ppp.Auth(5), ppp.Dialers(5), ppp.Filter(5), ppp.Keys(5), ppp.Systems(5), pppd(8), RFC 1661, RFC 1332, RFC 1144, RFC 1055.
COPYRIGHT INFORMATION Copyright 1991-1997 Progressive Systems Inc.; all rights reserved.
101 Morning Star PPP
PPP.DIALERS(5) MS PPP
NAME ppp.Dialers - PPP dialer description file format
DESCRIPTION The file /etc/ppp/Dialers describes how to dial each type of modem attached to the UNIX system that is to be made available for outbound PPP calls. After looking for modem dialers in /etc/ppp/Dialers.local, pppd examines Dialers when placing a call to a neighboring machine. Entries in Dialers.local take precedence over those in Dialers.
When pppd selects a line from Systems, it uses the 'speed' field to select an entry in Devices, from which it uses the 'dialer' field to select an entry in Dialers. Pppd then interprets the 'chat script' field from that dialer description.
FORMAT · Entries are one to a line; blank lines are ignored. · Comments begin with a `#' and extend to the end of the line. · Upper/lower case distinctions in the dialer field are significant for matching purposes, as are strings in the chat script. · Fields on a line are separated by horizontal white space created by blanks or tabs. · If a chat script ends with a backslash (`\'), the next line is considered a continuation of the chat script. Continuations may only occur in the midst of a chat script. · Each entry must contain these fields, in this order:
dialer The name of this dialer, to be matched against the dialer field in Devices file.
chat-script A description of the conversation that pppd holds with the modem.
CHAT SCRIPT PARTICULARS A chat script takes the form of a space-separated list of expect-send pairs. At minimum, each pair consists of a field to expect the "remote" end to send, followed by a field to send in response. Unless a 'send' string ends with \c, pppd will follow it by sending a carriage return character (ASCII 0x0d).
Chat scripts are 'expect send expect send ...' , or 'expect-send-expect send ...', where the 'send' following the hyphen is executed if the preceding expect fails to match received text.
Certain special words may be used in the chat script to control the behavior of pppd as it attempts to dial. Both ABORT and TIMEOUT must be in the 'expect' phase of the chat script.
102 Morning Star PPP
ABORT abort-string If pppd sees abort-string while executing the remainder of the chat script, abort the dialing attempt and note the failure in the log file.
TIMEOUT timeout-time While executing the current chat script, wait timeout-time seconds for a response before considering the dialing attempt to have timed out. Writes have a fixed 60-second timeout.
The expect-send couplet of "" P_WORD sets the line parity accordingly:
P_AUTO Set transmission parity based on the parity observed in characters received in 'expect' strings. This is the default
P_ZERO Transmit characters with the parity bit set to 0 (8 bits, no parity).
P_ONE Transmit characters with the parity bit set to 1.
P_EVEN Transmit characters with even parity.
P_ODD Transmit characters with odd parity.
In the midst of either an 'expect' string or a `send ' string, ^x gets translated into the appropriate controlcharacter, and \x gets translated into x. Other special sequences are:
103 Morning Star PPP
\s Send or receive a space character (ASCII 0x20)
\t Send or receive a horizontal tab character (ASCII 0x09)
\n Send or receive a line feed character (ASCII 0x0a)
\r Send or receive a carriage return character (ASCII 0x0d)
\\ Send or receive a backslash character (ASCII 0x5c)
\^ Send or receive a carat character (ASCII 0x5e)
^
\ddd Send or receive a character, specified in octal digits
\p Pause for .25 second before proceeding (send only)
\d Delay for 2 seconds before proceeding (send only)
\K Send a break (.25 second of zero bits)
\M Disable hangups (sets CLOCAL or LNOHANG)
\m Enable hangups (unsets CLOCAL or LNOHANG) (the default)
\c Don't append a carriage return character after sending the preceding string (send only)
\q Don't print succeeding send strings (e.g. a password) in any debugging or logging output. Subsequent \q sequences toggle 'quiet' mode.
\T Insert the telephone number found in the fifth field of Systems here
EXAMPLE # # Dialers - PPP dialers file # # Dialer Chat script T1600 ABORT NO\sCARRIER ABORT NO\sDIALTONE ABORT BUSY \ ABORT RRING\r\n\r\nRRING\r\n\r\nRRING \ ABORT ERROR TIMEOUT 5 "" AT OK-AT-OK \ ATS111=0DT\T TIMEOUT 60 CONNECT # T2500-PEP \ ABORT NO\sCARRIER ABORT NO\sDIALTONE ABORT BUSY \ ABORT RRING\r\n\r\nRRING\r\n\r\nRRING \ ABORT ERROR TIMEOUT 5 "" AT OK-AT-OK \ ATS111=0DT\T TIMEOUT 60 CONNECT\sFAST # USRv32bis \ ABORT ERROR ABORT NO\sANSWER ABORT NO\sCARRIER \ ABORT BUSY ABORT RRING\r\n\r\nRRING\r\n\r\nRRING \ ABORT NO\sDIAL\sTONE TIMEOUT 5 "" AT&F \ OK-ATQ0-OK ATB0E0X7 &B1&H1&I0&K3&R2&S1 OK-AT-OK \ ATS01=1S02=255S19=0 OK-AT-OK ATDT\T TIMEOUT 60 \ CONNECT
SEE ALSO tun(4), ppp.Auth(5), ppp.Devices(5), ppp.Filter(5), ppp.Keys(5), ppp.Systems(5), pppd(8), RFC 1661, RFC 1332, RFC 1144, RFC 1055.
104 Morning Star PPP
COPYRIGHT INFORMATION Copyright 1991-1997 Progressive Systems, Inc.; all rights reserved.
105 Morning Star PPP
PPP.FILTER(5) MS PPP
NAME ppp.Filter - PPP packet filter specification file format
DESCRIPTION The file /etc/ppp/Filter describes how on-demand PPP links are managed. By default , any type of packet may:
· cause the link, if down, to be brought up · traverse the link · reset the idle timer, preventing the timer from expiring which, in turn, will shut down the link.
A LARGE DESCRIPTION These actions are not always appropriate and packet traffic should be controlled. The filter OF STATIC PACKET file allows individual control based on many of the packet’s attributes and components, FILTERING, INCLUDING including type, source, destination, direction, and service. These selection criteria may be ANNOTATED EXAMPLES, specified for any of the situations listed at the beginning of the paragraph. MAY BE FOUND IN THE MANUAL AT THE BEGINNING OF THE The details of the filtering which are recorded by a fourth activity, packet logging, may also SECTION ONS ECURITY be selected using packet information.
FORMAT · Comments begin with a ‘#’ and extend to the end of the line · Blank lines, or lines beginning with a ‘#’, are ignored · Upper/lower case distinctions are ignored in hostname specifications, but are significant elsewhere · Fields are separated by horizontal or vertical white space created by blanks, tabs or newlines. If a newline is followed by white space, that line is a continuation of the filtering specification already in progress.
Hostnames and IP addresses Lines beginning with a hostname or IP address or the special word ‘default ’, are considered the beginning of a new set of filtering specifications. The filtering specifications are applied to any packet crossing the point-to-point link connecting the host to the peer named by that initial hostname or IP address.
· The hostname or IP address in the first column of the filter file refers to the peer at the remote end of the point-to-point link, which may be a system or router or terminal server. · The hostname or IP address associated with the link peer is unrelated to the source or destination IP address of any packet crossing the link. · If the link peer's address doesn't match any name or address specified in the first column of filter file, the filter specification following the special word ‘default’ will be used.
106 Morning Star PPP
Four Keywords There are four keywords to describe the actions taken by pppd in response to a particular packet:
bringup Describes those packets that will cause a call to be placed and a connection initiated. Packets of this sort also must qualify to ‘pass’ across the link, either by being explicitly mentioned or by inclusion in a larger class in the ‘pass’ section. pass Describes those packets that will be allowed to traverse the link on an already-established connection. Only packets which would be passed can cause the link to be brought up. Any packet that is not passed is optionally logged, then discarded. keepup Describes packets that will reset the idle timer, thereby keeping the line connected. log Describes packets whose headers or contents are to be noted in the log file.
Stanzas After each action keyword comes stanzas, separated by white space, describing packets that fit the criteria for that action. Each stanza is processed in the order shown in the file, and contains restrictions or permissions on the packets encountered. As soon as a pattern or a condition is found that matches the packet in question, pppd takes the indicated action and ignores the rest of the listed stanzas (i.e. inclusive or with shortcut evaluation).
Stanzas may contain: · IP protocol numbers which are optionally hyphen-separated ranges of TCP or UDP port numbers defined by the ‘/tcp’ or ‘/udp’ qualifier · Numbers representing ICMP message types or codes along with the ‘/icmp’ qualifier. (ICMP numbers are listed in
The Special Keyword ‘all’ Usually, it is unnecessary to use ‘all’ because pppd automatically adds a ‘!all’ at the end of a stanza list if the last stanza is not negated or ‘all’ at the end of a stanza list if the last stanza is negated.
For example, in the typical case of ‘log ’ this sensibly results in only those packets matching the stanzas shown being logged, and no others. In the typical case of ‘pass ’, this results in certain listed packets being restricted, and all others being passed.
Network Masks If a network is specified, either by name or by address, the corresponding network mask must also be specified if it is of a different size than the default for that class of network. The network mask and additional ‘and’ conditions within a stanza are separated by slashes (/), and may be specified either as a series of decimal numbers separated by periods, or as a single 32-bit hexadecimal number. The sense of a stanza may be negated by prefixing it with an exclamation mark (!).
107 Morning Star PPP
Log Filter Keywords and Flags In the ‘log’ filter specification, the special keyword ‘trace ’ causes the contents (as well as the headers) of the indicated type of packet to be written to the log file . Also in the ‘log’ filter specification, the special flag ‘rejected ’ signifies that the packet is to be logged only if it was rejected by the ‘pass’ filter.
The SYN Keyword
Pppd can distinguish between outbound and inbound packets, i.e. those which originate at the host versus those that originate at the other end of the link. TCP data streams are opened when the initiator sends a SYN packet to the intended recipient when using of TCP applications such as telnet or FTP. The special keyword ‘syn ’ allows filtering or logging these connection-starting packets. Qualifying it with ‘recv ’ or ‘send’ allows a session to be started or logged only if it is in the indicated direction. The special keyword ‘fin ’ allows filtering or logging the packets that close TCP connections.
The ‘src’ and ‘dst’ Keywords The ‘src’ and ‘dst’ keywords refer to source and destination and are used to distinguish a packet’s ports, addresses or hostnames. If both are applied to the same stanza, e.g. …/src/dst, both the source and destination address and/or port must match.
The ‘unreach’ Keyword The ‘unreach=’ keyword causes an ICMP Destination Unreachable message to be sent to the packet's source address , bearing the indicated code field, which may be chosen from the table shown below. The ‘umreach’ messages are described in RFCs 792, 1122 and 1812.
The currently available mnemonic ICMP Unreachable codes are:
108 Morning Star PPP
# NAME DESCRIPTION 0 net The destination network is unreachable
1 host The destination host is unreachable
2 prot or The designated transport protocol is not supported protocol
3 port The designated transport protocol (e.g., UDP) is unable to demultiplex the datagram but has no protocol mechanism to inform the sender
4 needfrag Fragmentation is needed and the Don't Fragment flag is set
5 srcfail Source route failed
6 net-unknown The destination network is unknown. This code normally should not be generated. It implies that the destination network does not exist. Code 0 (Network Unreachable) should be used in place of Code 6.
7 host-unknown The destination host is unknown.
8 * The source host is isolated. Routers should not generate Code 8; whichever of Codes 0 (Network Unreachable) and 1 (Host Unreachable) is appropriate should be used instead.
9 * Communication with the destination network is administratively prohibited. This code was intended for use by end-to-end encryption devices used by U.S military agencies. Routers should use the newly defined Code 13 (Communication Administratively Prohibited) if they administratively filter packets.
10 * Communication with the destination host is administratively prohibited. Same reasoning as message 9 above.
11 net-tos Destination network unreachable for the designated type of service
12 host-tos Destination host unreachable for the designated type of service
13 prohibited Communication Administratively Prohibited
14 precedence Host Precedence Violation
15 precedence- Precedence cutoff in effect cutoff
rst This is a special keyword which will not send an ICMP Destination Unreachable message but instead a TCP RST packet.
109 Morning Star PPP
The ‘ip-opt’ keyword The ‘ip-opt=' keyword can be used to select packets based on whether they bear various IP options (RFC 1122 section 3.2.1.8 and RFC 791 section 3.1 (pps 16ff)), selected from
rr Record Route is used to trace the route an internet datagram takes
ts Time Stamp
security Security is used to carry Security, Compartmentation, User Group (TCC), and Handling Restriction Codes compatible with DOD requirements.
lsrr Loose Source Routing is used to route the internet datagram based on information supplied by the source.
satid SATNET Stream Identifier (obsolete)
ssrr Strict Source Routing is used to route the internet datagram based on information supplied by the source.
sscrt Either Loose Source Routing or Strict Source Routing
any Any IP option, could even match the No Operation option.
EXAMPLES
Default Behavior
The following Filter file describes the default behavior of pppd, either in the absence of a filter specification file or in the case of an empty file:
# Filter - PPP configuration file, # binding packet types to actions. # Describes the default behavior of the daemon: default bringup all pass all keepup all log !all
The default behavior is no restriction of packets, and no logging.
Internet Firewall
A ‘pass’ line like this might be appropriate as a security firewall between an organizational network and the larger Internet :
internet-gateway bringup !ntp !3/icmp !5/icmp !11/icmp !who !route !nntp !89 pass nntp/137.39.1.2 !nntp telnet/syn/recv/137.175.0.0 !telnet/syn/recv !ftp/syn/recv !login/syn/recv !shell/syn/recv !who !sunrpc !chargen !tftp !supdup /syn/recv !exec !syslog !route !6000/tcp/syn /send keepup !send !ntp !3/icmp !5/icmp !11/icmp !who !route !89 log rejected
The ‘pass’ Lines The ‘pass’ specification:
110 Morning Star PPP
· Allows NNTP (Usenet news) transactions with one peer and no others. ex. pass nntp/137.39.1.2 !nntp · Allows incoming Telnet sessions from hosts on only one network ex. pass telnet/syn/recv/137.175.0.0 · Disallows all other incoming Telnet, SUPDUP, and FTP sessions · Allows all outgoing Telnet SUPDUP, and FTP sessions. · Allows X Window System clients running elsewhere to display on local window servers · Disallows local X clients to use displays located elsewhere. · Disallows all SUN RPC traffic, thereby guarding the local YP/NIS and NFS servers from outside probes and filesystem mounts.
Alas, the ‘pass’ specification also disallows local machines from mounting filesystems resident on NFS servers elsewhere, but this can't be helped because NFS uses RPC which is a UDP service. UDP does not use the SYN and FIN packets that can be used to characterize the direction in which a TCP stream is being initiated.
· Blocks several other sorts of traffic that could be used for nefarious purposes · Allows passage of any traffic not explicitly blocked because the filter does not end with ‘!all’
The ‘bringup’ and ‘keepup’ Lines The ‘bringup’ and ‘keepup’ lines are appropriate for an intermittent dial-up connection, so that various error conditions won’t cause the link to be established, nor keep the call open beyond its usefulness.
· OSPF (Open Shortest Path First) routing packets, identified by the IP protocol number 89, will cross the link, but won’t cause it to be brought up, nor keep it up if it's otherwise idle. · Usenet news traffic won't bring up the link, but once started, the link won't be shut off in the middle of a news batch.
The ‘log rejected’ Line The ‘log rejected’ line keeps a record of every packet that is blocked by the ‘pass ’ line, so that unsuccessful penetration attempts will be noted.
An Extremely Complex Example
The following Filter file provides these instructions for the PPP daemon: · Allow any packet except those generated by NTP, ICMP Destination Unreachable, and rwhod. to bring up a connection to any neighbor except the host ‘backbone’
If those are the only types of packets flowing across the link, it will not be kept up, but all packets are allowed to cross the link while it is up.
· Disallow outbound packets to reset the idle timer · Allow packets received from the peer to reset the idle timer · Hang up the connection and retry if the idle command-line argument has been specified when the peer goes down and modem problems cause the phone not to be hung up · Allow Domain Name System queries to bring up the link and keep it up if otherwise idle
111 Morning Star PPP
· In the special case of the host ‘backbone’, such as a network connectivity vendor server, only bring up the link or keep it up if otherwise idle, for the following: Þ telnet and FTP sessions Þ SMTP electronic mail Þ NNTP network news · Once the link is up, allow all the above plus NTP clock chimes and ICMP messages to flow across the link. · Block all packets to or from a particular host, · Block any packets except Domain Name System queries and responses for any host on subnet 42 of the class B network 137.175 and don’t allow them to bringup the link. would they cause the link to be initiated · Allow telnet and FTP sessions only if they are initiated in the outbound direction. · Log one-line descriptions of various ICMP problem messages including Unreachable and Time Exceeded · Log the complete contents of ICMP messages reporting IP header problems. Log all telnet and FTP sessions, including inbound attempts (though they will fail because they are excluded in the ‘pass ’ specification above · Log the header of the first packet of any electronic mail message flowing over this link on its way to or from a specific host.
# # Filter - PPP configuration file binding packet # types to actions. # # For packets that would pass , these services # will bring up the link: # backbone bringup smtp nntp domain telnet ftp # # Once brought up, these will pass (or not): # pass !131.119.250.104 domain/137.175.42.0/255.255.255.0 !137.175.42.0/0xffffff00 # (alternative ways of # expressing subnet mask) !telnet/syn/recv !ftp/syn/recv domain smtp nntp ntp icmp telnet ftp # # Packets received for the services shown will # reset the idle timer . # keepup !send smtp nntp domain telnet ftp # # Only these messages will have headers or contents # logged, unless higher-level debugging is set: # log 3/icmp 11/icmp 12/icmp/trace telnet/syn ftp/syn smtp/syn/terminus.netsys.com # default bringup !ntp !3/icmp !who keepup !send !ntp !3/icmp !who
RECOMMENDATIONS Simpler filter specifications allow pppd to start up quicker and run faster, with less processing overhead for each packet, but that overhead is likely to present a problem only at very high line speeds (like T1). The ‘backbone’ example shown above is severe overkill for the sake of illustration, evolved over a period of several weeks, and took the authors several tries to get right. Start with a simple filter specification and add each special case only as the
112 Morning Star PPP need arises, usually as the result of watching packet logs. Then test carefully to ensure that your change had only the desired effect.
Be very careful with header logging and even more careful with packet content tracing. Make the selection criteria very narrow, or the log file will grow extremely large in a short period of time. Also, if the daemon is running on a diskless workstation or if the log file is on a NFS-mounted file system, excessive amounts of logging information will drastically impede the daemon's ability to process at high packet rates. Remember, NFS writes are synchronous.
If you specify host names, be sure that their addresses are available locally, even with the connection down. If you find that you must bring up a connection to resolve a domain name, consider using that host's IP address (decimal numbers separated by periods) in both Filter and Systems instead.
If you want to specify all Domain Name System traffic, use ‘domain’ which will be expanded to entries for both 53/tcp and 53/udp. (Some DNS traffic uses each transport.) To allow queries but disable domain transfers, use ‘!domain/tcp’. Similarly, some systems' older /etc/services files, as distributed by the manufacturer, list NTP as a TCP service. When the current UDP NTP implementation was installed on your system, the administrator may have left the old 123/tcp entry along with the correct 123/udp. The correct solution is to remove the 123/tcp entry from /etc/services. A workaround would be to specify 123/udp in Filter.
If your /etc/services file is missing some application-level protocols that you consider useful, you can populate it with entries from the Assigned Numbers RFC , number 1700. For example, you may find it useful to add lines like:
gopher 70/tcp
gopher 70/udp
kerberos 88/tcp
kerberos 88/udp
snmp 161/tcp
snmp 161/udp
nextstep 178/tcp
nextstep 178/udp
prospero 191/tcp
prospero 191/udp
x11 6000/tcp
If you augment /etc/services this way you can using Filter file entries like,
pass !x11/syn /send which is much more readable than the alternative:
pass !6000/tcp/syn /send
113 Morning Star PPP
A list of TCP and UDP service numbers and names, culled from the Assigned Numbers RFC , is available in Examples/services.ex.
SEE ALSO tun(4), ppp.Auth(5), ppp.Devices(5), ppp.Dialers(5), ppp.Keys(5), ppp.Systems(5), services(5), pppd(8), RFC 791, RFC 792, RFC 1055 , RFC 1661, RFC 1332, RFC 1122, RFC 1144, RFC 1700 RFC 1812.
COPYRIGHT INFORMATION Copyright 1991-1997 Progressive Systems Inc.; all rights reserved.
114 Morning Star PPP
PPP.KEYS(5) MS PPP
NAME ppp.Keys - PPP encryption keys file format
RESTRICTIONS Encryption is not available in software exported from the USA.
DESCRIPTION The keys file named in the gw-crypt option on the pppd command line contains key values used by MS PPP’s implementation of link-level encryption . Before transmission, packets with source and destination address es matching the endpoints on a keys file line are encrypted using DES with the key specified on that keys file line. Upon reception, packets with source and destination addresses matching those on a keys file line are decrypted using DES with the key specified on that keys file line.
FORMAT Each key specification is on its own single line of up to 1023 characters. Comments in the keys file begin with a '#' and extend to the end of the line; blank lines, or lines beginning with a `#’, are ignored. Fields are separated by horizontal white space (blanks or tabs). The first two words on a key line are compared with the source and destination addresses of each packet to be transmitted and each received packet. The endpoint address specifications may contain either host or network names, or host or network addresses. If a network is specified, either by name or by address, then the corresponding network mask must also be specified if it is of a different size than the default for that class of network. The mask is separated from the network name or address by a slash (/),and may be specified either as a series of decimal numbers separated by periods, or as a single 32-bit hexadecimal number, optionally with a C-style `0x’ prefix. The remainder of the key line is a 56 bit (14 digit) hexadecimal number (without the C-style `0x’ prefix), used as theDES key between the specified pair of hosts or networks. The digits may be separated by horizontal white space for readability. If the key contains fewer or more than 14 hexadecimal digits, the line is ignored. If the key is weak or semi-weak, a warning message will be printed in the log file and the specified key will be used for encryption anyway.
EXAMPLE The following keys file provides pppd with keys for use when encrypting or decrypting traffic between the indicated pairs of hosts or networks: # # Keys - PPP encryption keys file # # Format: #endpoint endpoint key frobozz.foo.com glitznorf.baz.edu feed face f00d aa 147.225.0.0 38.145.211.0/0xffffffc0 b1ff a c001 d00d 1 128.49.16.0/0xffffff00 198.137.240.100 0123456789abcd 193.124.250.136 143.231.1.0/0xffffff00 e1c3870e1c3870
115 Morning Star PPP
RECOMMENDATIONS Avoid using weak or semi-weak keys . These are weak DES keys: 00000000000000 FFFFFFFFFFFFFF 1E3C78F1E3C78F E1C3870E1C3870
These are semi-weak DES keys : 01FC07F01FC07F FE03F80FE03F80 1FC07F00FE03F8 E03F80FF01FC07 01C007001E0078 E003800F003C00 1FFC7FF0FFC3FF FE3FF8FFE1FF87 003C00F001C007 1E007800E00380 E1FF87FF1FFC7F FFC3FF0FFE3FF8
SECURITY CONCERNS The keys file should be mode 600 or 400, and owned by root . Packets’ IP headers are not encrypted, though their TCP , UDP, or ICMP headers are encrypted along with the user data portion. This allows encrypted packets to traverse normal internetworks, but permits snoopers to analyze traffic by its endpoints. Since the TCP, UDP, or ICMP header is encrypted, protocol-based filters along the packet’s path will be unable to discern whether it is SMTP , Telnet, or any other network service. This means that encrypted traffic will only permeate packet-filtering firewalls if the firewall allows all traffic between the endpoints, regardless of traffic type. MS PPP /SLIP software for UNIX systems, when deployed as the endpoint gateways of the encrypted traffic, decrypt incoming encrypted traffic before applying their configured packet filtering rules.
SEE ALSO tun(4), ppp.Auth(5), ppp.Devices(5), ppp.Dialers(5), ppp.Filter(5), ppp.Systems(5), pppd(8), RFC 792, RFC 1661, RFC 1332, RFC 1334.
COPYRIGHT INFORMATION Copyright 1993, 1994, 1995, 1996 Progressive Systems Inc.; all rights reserved.
116 Morning Star PPP
PPP.SYSTEMS(5) MS PPP
NAME ppp.Systems - PPP neighboring systems description file format
DESCRIPTION The file /etc/ppp/Systems describes how to connect with neighboring systems via PPP .
FORMAT · Entries are one to a line; blank lines are ignored. · Comments begin with a `#' and extend to the end of the line. · Upper/lower case distinctions are ignored in hostname specifications, but are significant elsewhere. · Fields on a line are separated by horizontal white space created by blanks or tabs. · If a chat script ends with a backslash (\), the next line is considered a continuation of the chat script. Continuations may only occur in the midst of a chat script. · Each entry must contain six fields, in the following order:
name The hostname or IP address of the destination machine, which should be resolvable locally.
when A string that indicates the days of the week and the times of day when the system can be called. The day portion may be a list containing any of: Su, Mo,Tu, We, Th, Fr or Sa, Wk, or Any.
Hours in a range are written as those from a 24 hour clock, 0800- 1230 for example. If you do not specify a time, calls will be allowed at any time. A time range that spans 0000 is permitted. For example, 0800-0600 means that all times are allowed except times between 6 AM and8 AM.
Examples: MoTuTh0800-1740 Wk0800-1230, (same as MoTuWeThFr) Any0900-1700, (same as SuMoTuWeThFrSa)
Multiple date specifications are separated by a vertical bar (|). This example shows that the system can be called any day between 1 AM and 6 AM or any time on Saturday and Sunday.
Example: Any0100-0600|Sa|Su
The entire sequence of days and times may be followed by a semicolon and up to three decimal numbers separated by hyphens as described in the table below:
117 Morning Star PPP
DURING THE DELAY one If only one number follows the semi-colon, it is used FOLLOWING AN as the redial delay, which is the initial time (in UNSUCCESSFUL seconds) before a failed call will be retried. CALL, ANY LEVEL6 For example, Any;60 means call any time, but wait at DEBUGGING least 60 seconds after a failure has occurred before MESSAGES WRITTEN trying to call again. TO PPPD.LOG WILL HAVE THE MESSAGE If a call retry fails, pppd doubles the delay before `DIAL FAILED' trying again. If no initial retry delay is specified, 10 APPENDED. seconds is assumed.
two If two numbers follow the semicolon, the second number is the maximum redial delay, or the maximum time (in seconds) to delay before retrying a call. The retry time double with each unsuccessful call until it reaches this value, after which the call will be retried every time the maximum number of seconds passes.
If no maximum retry delay is specified, 3600 seconds is assumed.
three If three numbers follow the semicolon, the first is used as the callback delay, the second as the redial delay and the third as the maximum redial delay. The callback delay is the time (in seconds) to wait before attempting to re-establish a previously active connection that ended because of an abrupt line disconnection (a Hangup or SIGHUP event in the log file).
The default is not to delay before calling back.
device If set to `ACU', any device in Devices with a matching speed may be used. The device's dialer chat script will be executed first, followed by the Systems chat script.
If set to the name of a device in the /dev directory (tty00, cua, etc.), there may be an optional corresponding Direct entry in Devices, Dialers will not be consulted, and only the Systems chat script will be executed.
If set to `tcp', it must be followed by a slash, then the hostname or IP address of the system that will serve as the destination of the PPP link, then another slash, then the socket number on which to contact the remote PP daemon.
speed The speed of the connection. If the device field is ACU, the speed field will be string matched against entries in Devices. Speeds must either be valid speed numbers or must begin with them (2400, 38400, 19200-PEP, etc.). If the device field is `tcp...' or `telnet...', the speed field is ignored, but must be present as a place-holder.
phone number The value to replace the \T escape sequence in the dialer script. If the device field names an entry in /dev, the phone number field is optional. If the device field is `tcp...' or `telnet...', the phone number field is ignored if present, but must be present as a place- holder.
chat script A description of the conversation that pppd holds with the remote machine.
118 Morning Star PPP
CHAT SCRIPT PARTICULARS A chat script takes the form of a space-separated list of expect-send pairs. At minimum, each pair consists of a field to expect the "remote" end to send, followed by a field to send in response. Unless a 'send' string ends with \c, pppd will follow it by sending a carriage return character (ASCII 0x0d).
Chat scripts are 'expect send expect send ...' , or 'expect-send-expect send ...', where the 'send' following the hyphen is executed if the preceding expect fails to match received text.
Certain special words may be used in the chat script to control the behavior of pppd as it attempts to dial. Both ABORT and TIMEOUT must be in the 'expect' phase of the chat script.
ABORT abort-string If pppd sees abort-string while executing the remainder of the chat script, abort the dialing attempt and note the failure in the log file.
TIMEOUT timeout-time While executing the current chat script, wait timeout- time seconds for a response before considering the dialing attempt to have timed out. Writes have a fixed 60-second timeout.
The expect-send couplet of "" P_WORD sets the line parity accordingly:
P_AUTO Set transmission parity based on the parity observed in characters received in 'expect' strings. This is the default.
P_ZERO Transmit characters with the parity bit set to 0 (8 bits, no parity).
P_ONE Transmit characters with the parity bit set to 1.
P_EVEN Transmit characters with even parity.
P_ODD Transmit characters with odd parity.
The backquote character (`) surrounds the name of a program that is to be run before proceeding. If the program is run in the `send ` phase of a chat script couplet, its standard output will be sent to the peer when the program exits. Chat script processing continues when the program exits.
In the midst of either an 'expect' string or a `send ' string, ^x gets translated into the appropriate control character, and \x gets translated into x. Other special sequences are:
\s Send or receive a space character (ASCII 0x20)
\t Send or receive a horizontal tab character (ASCII 0x09)
\n Send or receive a line feed character (ASCII 0x0a)
\r Send or receive a carriage return character (ASCII 0x0d)
\\ Send or receive a backslash character (ASCII 0x5c)
\^ Send or receive a carat character (ASCII 0x5e)
119 Morning Star PPP
^
\ddd Send or receive a character, specified in octal digits
\p Pause for .25 second before proceeding (send only)
\d Delay for 2 seconds before proceeding (send only)
\K Send a break (.25 second of zero bits)
\M Disable hangups (sets CLOCAL or LNOHANG)
\m Enable hangups (unsets CLOCAL or LNOHANG) (the default)
\c Don't append a carriage return character after sending the preceding string (send only)
\q Don't print succeeding send strings (e.g. a password) in any debugging or logging output. Subsequent \q sequences toggle 'quiet' mode
\A Parse the incoming string as an IP address, written as four decimal numbers separated by periods, and use it for the local end of the point-to-point connection (receive only)
EXAMPLE In the example below:
· You call host`everyone', using a Telebit PEP modem with its DTE interface set at 19200 b · You call host`nobody', using a V.32/V.42/V.42bis modem capable of driving a 38400 DTE · You are connected to host `someone' via a direct cable attached to /dev/ttya, running asynchronous PPP. · You talk to `anyone' via a T1 CSU/DSU attached to port 0 on a SnapLink. · You connect with pseudo-one via a PPP connection tunneled across a TCP stream to port 77 on realone.somewhere.com.
If you are unsuccessful at connecting with `someone' you will try again in two seconds. If that attempt fails, you will wait four seconds before the next attempt; then eight, then sixteen, then thirty two, then forty seconds. You will continue attempting to contact `someone' every forty seconds.
Your retry intervals and maximum backoff values for `everyone' and `nobody' are the default `10-3600'.
The notation "" "" means to expect nothing, then send nothing, followed by a carriage return. The implicit carriage return is often useful for eliciting a response from a remote system.
# # Systems - PPP systems file # everyone Any ACU 19200-PEP 5551212 in:--in: Pwe word: \qfoObar nobody Any ACU 38400 5551213 in:--in: Pthey word: \qbaZz1ng someone Any;2-40 cua 38400 0 in:--in: Pthem word: \qmeumBle anyone Any rsd0a/0 1536000 pseudo-one Any;2-2 tcp/realone.somewhere.com/57
120 Morning Star PPP
RECOMMENDATIONS
Retry and Backoff Times Using the Default The default retry time and backoff (i.e. Any;10-3600) are appropriate for use with dialup connections where the PPP connection must be reestablished as quickly as possible after an interruption but where it is not desirable to continuously redial a host that may be down.
Dedicated Lines or No-Cost connections A much shorter maximum would be appropriate for a dedicated line between two systems, or where call attempts cost nothing.
Bi-Directional Dial Up Modems Moderate call retry times, such as 60 seconds, work well on systems that can establish connections in either direction using dialup modems, to avoid deadlocks waiting for telephone busy signals from each calling the other at the same time. Because of the difference between the behaviors of originating and answering modems, the 60-second clocks will usually start ticking at different times, allowing one side to call the other without interference. Alternatively, different call retry times may be specified at either end of a link to help keep the two systems from calling each other simultaneously.
Specifying Host Names If you specify host names, be sure that their addresses are available locally, even with the connection down. If you find that you must bring up a connection to resolve a domain name, consider using that host's IP address in dotted quad format in Filter and Systems instead.
Automatic Failover Automatic failover recovery can be arranged between systems that each have multiple modems, or multiple connection methods. If two systems are connected via a dedicated line (sync or async), that entry should be first in Systems, followed by another entry describing an on-demand dial-up connection. See the MS PPP User Guide for more details.
SECURITY CONCERNS The file /etc/ppp/Systems should be mode 600.
SEE ALSO tun(4), ppp.Auth(5), ppp.Sevices(5), ppp.Dialers (5), ppp.Filter(5), ppp.Keys(5), pppd(8), RFC 1661, RFC 1332, RFC 1144, RFC 1055.
COPYRIGHT INFORMATION Copyright 1991-1997 Progressive Systems Inc.; all rights reserved.
121 Morning Star PPP
PPPD(8) MS PPP
NAME pppd - PPP daemon
SYNOPSIS pppd [options...]
DESCRIPTION Pppd is a daemon process used in UNIX systems to manage connections to other hosts using PPP, the Point to Point Protocol, or SLIP, the Serial Line Internet Protocol. It uses the UNIX host's native serial ports or the Morning Star SnapLink SCSI-attached high speed serial interface. It communicates with the UNIX kernel 's own TCP/IP implementation via the Morning Star IP tunnel driver. (see tun(4))
DAEMON MANAGEMENT OPTIONS
FIELD DESCRIPTION auto Requires the remote address. Start in 'autocall' mode and detach from the controlling terminal to run as a daemon. Initiate connection in response to a packet specified in the filter- file`bringup' category. up When used with auto, bring the link up immediately rather than waiting for traffic. If the link goes down, attempt to restart it after the call retry delay timer expires. Don't wait for an outbound packet. dedicated Implies up. Treat the connection as a dedicated line rather than a demand-dial connection.
This option tells pppd to never give up on the connection. If the peer tries to shut down the link, pppd does, but will immediately try to reestablish the connection. Similarly, when first trying to connect, pppd will not give up after sending a fixed number of Configure-Request messages. As with dial-up connections, hangup events (LQM failures, loss of Carrier Detect) will cause the device to be closed,and the Systems file is then checked for alternate entries. If none are available, the connection will be re- established after the call retry delay timer expires. Use a short call retry delay timer on dedicated circuits. Something like Any;5-30 should work well.. nodetach Don't detach from the controlling terminal in 'autocall' mode. When used with log - , this is useful for watching the progress of the PPP session. log log-file Append logging messages to log-file (default: /usr/adm/pppd.log). acct acct-file Append session accounting messages to acct-file. If acct-file is the same as log-file, the session accounting messages is interleaved with other logging information.
122 Morning Star PPP
filter filter-file Look in filter-file for packet filtering and link management information (default: /etc/ppp/Filter) debug debug-level Set the log file verbosity to debug-level, chosen from the following table:
0 Daemon start messages
1 Link status messages, calling attempts (the default)
2 Chat script processing, input framing errors
3 LCP, IPCP, PAP and CHAP negotiation
4 LQM status summaries
5 IP interface changes
6 IP message summaries
7 Full LQM reports
8 All PPP messages (without framing)
9 Characters read or written
10 Procedure call messages
11 Internal timers the lower-numbered levels exec exec-cmd Run 'exec-cmd up addr args' when the link comes up, and 'exec- cmd down addr args' when it goes down. Addr is the IP address of the peer, and args is the list of arguments given to pppd. nonice Run at a normal user process priority, rather than using the nice() library routine to elevate pppd’s scheduling priority to -10.
COMMUNICATIONS OPTIONS asyncmap async-map Set the desired Async Control Character Map to async-map, expressed in C-style hexadecimal notation (default: 0xA0000). noasyncmap Disable LCP Async Control Character Map negotiation. escape odd-character In addition to characters specified in the PPP Async Control Character Map, which can include only 0x00 through 0x1F, apply the escaping algorithm when transmitting odd-character. The value of odd-character must be between 0x00 and 0xFF, and cannot be 0x5E, 0x7D or 0x7E.
Odd-character can be specified as a decimal number, in C-style hexadecimal notation, or as an ASCII character with optional '^' control-character notation. For example, the XON character could be specified as 17, 0x11, or ^Q.
A warning will be printed in the log file and the character specified on the command line will not be escaped if a character specified with the escape argument is the same as a character contained in the peer's negotiated Async Control Character Map when the character is transformed into its escaped form.
Pppd will print an error message and exit if a character specified
123 Morning Star PPP
with the escape argument is the same as a character specified in another escape argument on the daemon's command line when transformed into its escaped form. device Communicate over the named device (default: /dev/tty). comm-speed Set communications rate to comm-speed bits per second. poll poll-rate Set SnapLink polling frequency, in polls per second. Recommend values are 20, 50, or 100 (default 50). internal-clocking A SnapLink will provide the synchronous clock signal (TXCLK and RXCLK). By default, it expects the modem, CSU/DSU or modem eliminator to provide the clock signal. Internal-clocking cannot be used with RS-232 cables on the SnapLink. ignore-cd Ignore the state of the CD (Carrier Detect, also called DCD, Data Carrier Detect) signal. This is useful for systems that don't support CD but want to run PPP over a dedicated line. rtscts Set the line to use out-of-band EIA RS-232-D ‘hardware’ (RTS/CTS) flow control. (The default is to use no flow control.) For an outbound connection, this may be specified either in Devices or on the pppd command line. This option is not available on all systems. On NeXT systems, enable ttydfa or ttydfb in /etc/ttys instead. On Silicon Graphics systems, use /dev/ttyf2 for a modem with dardware flow control instead (see serial(7)). On SCO systems, rtscts cannot be used with either rtscts-rtsflow or rtscts- crtsfl. crtscts A synonym for rtscts. rtscts-rtsflow As above in rtscts, but sets both CTSFLOW and RTSFLOW. (SCO UNIX systems only, and cannot be used with either rtscts or rtscts-crtsfl). crtscts-crtsflow A synonym for rtscts-crtsfl. rtscts-crtsfl As above in rtscts, but sets CRTSFL and clears both CTSFLOW and RTSFLOW. (SCO UNIX systems only, and cannot be used with either rtscts or rtscts-rtsflow). crtscts-crtsfl A synonym for rtscts-crtsfl. gw-crypt keys-file Encrypt traffic between the pairs of hosts or networks specified in the designated keys file (see ppp.Keys(5)). xonxoff Set the line to use in-band ('software') flow control, using the characters DC3 (^S, XOFF, ASCII 0x13) to stop the flow and DC1 (^Q, XON, ASCII 0x11) to resume. For an outbound connection, this may be specified either in Devices or on the pppd command line. telnet When used on an answering pppd command line, negotiate the telnet binary option and understand telnet escape processing. Not for use with device or auto.
LINK MANAGEMENT OPTIONS nooptions Disable all LCP and IPCP options. noaccomp Disable HDLC Address and Control Field compression. noprotcomp Disable LCP Protocol Field Compression.
124 Morning Star PPP
compress Offer all supported link compression types when negotiating. The default is to propose and accept no link compression type. compress-pred1 Accept any supported compression type, but prefer Predictor type 1 compression. compress-stac Accept any supported compression type, but prefer Stac LZS compression. nopred1 Never use Predictor-1 compression. nostac Never use Stac LZS compression. slip Use RFC 1055 LIP packet framing rather than PPP packet framing. Disables all option negotiation, and implies noasyncmap, noipaddress, vjslots 16, novjcid, nomagic, nomru, and mru 1006. vjcomp is implied if peer sends a header-compressed TCP packet. extra-slip-end When running in SLIP mode, prepend a SLIP packet framing character (0xC0) to each frame before transmission, even if this frame immediately follows the previous frame. By default, pppd transmits only one framing character between adjacent SLIP frames. nomagic Disable LCP Magic Number negotiation. mru mru-size Set LCP Maximum Receive Unit value to mru-size for negotiation. The default is 1500 for PPP and 1006 for SLIP. The value must be greater than 128. nomru Disable LCP Maximum Receive Unit negotiation, and use 1500 for the interface. active Begin LCP parameter negotiation immediately. Active is the default passive Do not send our first LCP packet until we receive an LCP packet from the peer. timeout restart-time Set the LCP, IPCP, CCP, PAP, and CHAP option negotiation restart timers to restart-time. The default is 3 seconds. lqrinterval time Send Link-Quality-Reports or Echo-Requests every time seconds (default 10 seconds). If the peer responds with a Protocol- Reject, send LCP Echo-Requests every time seconds instead, and use the received LCP Echo-Replies for link status policy decisions. lqthreshold min/per Set a minimum standard for link quality by considering the connection to have failed if fewer than min out of the last per LQRs we sent have been responded to by the peer (default 1/5). The per number can be no greater than 256 and cannot be 0. echolqm Use LCP Echo-Requests rather than standard Link-Quality-Report messages for link quality assessment and policy decisions. The peer can override this if it actively tries to configure Link Quality Monitoring unless the nolqm parameter is also specified. nolqm Don't send or recognize Link-Quality-Report messages. If echolqm is also specified, Echo-Request messages will be used to detect link failures. idle idle-time Shut down the link when idle-time seconds pass without receiving or transmitting a packet specified in the 'keepup' category in the filter file. The default is to never shut down. max-configure tries Set the PPP Max-Configure counter to the value of tries. This is the maximum number of Configure-Requests sent without a
125 Morning Star PPP
response. max-terminate tries Set the PPP Max-Terminate counter to the value of tries. This is the maximum number of Terminate-Requests to be sent without a response. max-failure tries Set the PPP Max-Failure counter to the value of tries. This is the maximum number of Configure-Naks to be sent without a positive response. Default is 5, in accordance with RFC 1661.
IP OPTIONS local:remote The address of this machine, followed by the expected address for the remote machine. Can be specified either as symbolic names or as literal IP addresses, if their addresses cannot be discovered locally without using the PPP link.
Both addresses are optional, but a colon by itself is not valid, and the remote address is required when running as a daemon in 'autocall' mode. If only 'local:' is specified when receiving an incoming call, the remote address will be discovered during IPCP IP-Address negotiations.
If either address is followed by a tilde character ('~'), or if the tilde appears alone, pppd accepts the IP address given by the peer during IPCP negotiations, whether for the local end or the peer's end of the link. (not available in SLIP mode)
Because SLIP cannot perform option negotiations, including IPCP, both addresses should normally be specified, and the tilde option is unavailable. To obtain a similar "feature", the peer must provide the IP address textually during the login process, and a new value must be obtained using the Systems file '\A' chat script feature (see ppp.Systems(5)). netmask subnet-mask Set the subnet mask of the interface to subnet-mask, expressed either in C-style hexadecimal (e.g. 0xffffff00) or in decimal dotted- quad notation (e.g. 255.255.255.0). The default subnet mask will be appropriate for the network (class A, B, or C), assuming no subnetting. noipaddress Disable IPCP IP-Address negotiation. need-ip-address Force IPCP to ask the peer to assign us an IP address even if pppd was invoked with a local address on the command line. vjcomp Enable RFC 1144 'VJ' Van Jacobson TCP header compression negotiation with 16 slots and slot ID compression (this is the default with PPP framing). 'VJ' compression is enabled by default for async connections, and disabled by default for sync connections. novjcomp Disable RFC 1144 'VJ' Van Jacobson TCP header compression (this is the default with SLIP framing, until the peer sends a header- compressed TCP packet). vjslots vj-slots Set the number of VJ compression slots (min 3, max 256, default 16). novjcid Disable VJ compression slot ID compression (enabled by default). rfc1172-vj Backwards compatibility with older PPP implementations (4-byte VJ configuration option), but with the correct option negotiation value of 0x002d. rfc1172-typo-vj Backwards compatibility with older PPP implementations (4-byte VJ configuration option) that conform to the typographical error in RFC
126 Morning Star PPP
1172 section 5.2 (Compression-Type value 0x0037).
rfc1172-addresses Backwards compatibility with older PPP implementations that conform to RFC 1172 section 5.1 (IP-Addresses, IPCP configuration option 1) and not with the newer RFC 1332 (IP- Address, IPCP configuration option 3), but that respond with something besides a Configure-Reject when they receive an IPCP Configure-Request containing an option 3.
AUTHENTICATION OPTIONS rechap interval Demand that the peer re-authenticate itself (using CHAP) every interval seconds. If the peer fails the new challenge, the link is terminated.
requireauth Require either PAP or CHAP authentication. Equivalent to individually specifying requirechap, requiremschap and requirepap .
requirechap Require CHAP authentication as described in RFC 1334.
requiremschap Require Microsoft MS CHAP authentication
requirepap Require PAP authentication as described in RFC 1334.
nochap Don’t allow CHAP authentication nomschap Don’t allow MS-CHAP authentication nopap Don’t allow PAP authentication name identifier Provide the identifier used during PAP or CHAP negotiation. This option is necessary if the PPP peer requires authentication. The default value is the value returned by the gethostname(2) system call or the hostname(1) command.
ENCRYPTION IS NOT ENCRYPTION OPTIONS AVAILABLE IN SOFTWARE Note: Encryption software is not available outside the United States and EXPORTED FROM THE UNITED STATES therefore is not available in internaitional licenses.
127 Morning Star PPP
gw-crypt keys-file Encrypt traffic between the pairs of hosts or networks specified in the designated keys file (see ppp.Keys(5)).
MICROSOFT COMPATIBILITY OPTIONS ms-dns address Set the Microsoft DNS address to provide to the peer. First occurrence of this option on the command line sets the primary address. Second occurrence sets the secondary address. ms-nbns address Set the MS NBNS address to provide to the peer. First occurrence of this option on the command line sets the primary address. Second occurrence sets the secondary address.
LOG FILE Status information is recorded in the log file by each copy of pppd running on a single machine. The default file for logging is /usr/adm/pppd.log. Each line in the file consists of a message preceded by the date, the time, and the process ID number of the daemon writing the message. The quantity and verbosity of messages are controlled with the debug option and with the log filter (see ppp.Filter(5)).
Any packet at debug level 6 or higher, or each packet that that matches one of the conditions shown below causes a one-line description of the packet to be written to the log file.
· The packet brings up the link at debug level 1 or more · The packet matches a rule in the log filter at any debug level
The parts of the message are as follows: 1. The protocol (tcp, udp, icmp, or a numeric protocol value). For ICMP packets, the keyword icmp is followed by the ICMP message type and sub code, separated by slashes. 2. An IP address and, optionally, a TCP or UDP port number, followed by an arrow indicating whether the packet was sent ( ) or received ( ) 3. Another address and port number. For transmitted packets, this is the source address . For received packets, this is the destination address . Well known TCP and UDP port numbers are replaced by the name returned by the getservbyport() library function. 4. The length of the packet in bytes before VJ TCP header compression. 5. Zero or more keywords. The keywords and their meanings are:
128 Morning Star PPP
frag the packet is a middle or later part of a fragmented IP frame
syn the packet has the TCP SYN bit set
fin the packet has the TCP FIN bit set
rst the packet has the TCP RST bit set
bringup the transmitted packet matches the bringup filter and is bringing up the link
!keepup the packet has been rejected by the keepup filter
!pass the packet has been rejected by the pass filter
dial failed the packet was dropped because pppd is waiting for the call retry timer to expire
(c) the received packet is VJ TCP header compressed
(u) the received packet is VJ TCP header uncompressed
For example, the following log file line indicates that at 2:06:26 PM on September 6, process ID 83 sent a 44-byte TCP packet with the SYN bit set from port 1050 on 63.1.6.3 to the SMTP port on 8.1.1.9.
9/6-14:06:26-83 tcp 63.1.6.3/1050 8.1.1.9/smtp 44 syn
SIGNALS When the following signals are received by pppd it closes and reopens the log file, re-reads the filter and key files, then takes the indicated actions: WARNING: DO NOT USE THE SIGKILL SIGNAL SIGKILL Don't use this. Never, never use this. Since pppd won't be able to UNDER ANY shut down gracefully, it will leave your serial interfaces (whether CIRCUMSANCES /dev/tty or a SnapLink) and your IP tunnel driver in some unknown state. Use SIGTERM instead, so pppd will shut down cleanly, and leave the system in a well-defined state.
SIGINT Disconnect gracefully from an active session. If in 'autocall' mode, reset the call retry backoff interval. If up was specified, attempt to re-establish the link. Exit if not in 'autocall' mode.
SIGHUP Disconnect abruptly from an active session. If up was specified, attempt to re-establish the link. Exit if not in 'autocall' mode.
SIGTERM Disconnect gracefully from an active session, clean up the state of any serial and IP interfaces that are open, then exit.
SIGUSR1 Increment the verbosity level for logged debugging information.
SIGUSR2 Reset the debugging verbosity level to the base value (1, unless debug 0 was supplied on the command line).
SIGALRM Take no action except to re-read the filter and key files.
EXAMPLE To run a pair of daemons on 'oursystem', one maintaining a constant link with 'backbonesystem' and the other prepared to initiate outbound calls to a neighboring machine named 'theirsystem', do the following.
129 Morning Star PPP
Create an executable shell script /etc/ppp/Autostart and add to it:
#!/bin/sh
PATH=/usr/etc:/bin:/usr/sbin:/etc
echo -n "Starting PPP daemons:" >/dev/console
pppd oursystem:backbonesystem auto up (echo -n ' backbonesystem') >/dev/console pppd oursystem:theirsystem auto idle 120 (echo -n ' theirsystem') >/dev/console
echo '.' >/dev/console
To allow a PPP implementation running on 'theirsystem' to dial into 'oursystem', insert the following into /etc/passwd on 'oursystem':
Pthem:?:105:20:Their PPP :/etc/ppp:/etc/ppp/Login where group 20 is the gid of the ppp group which owns /usr/sbin/pppd, and /etc/ppp/Login is an executable shell script that looks something like
#!/bin/sh PATH=/usr/sbin:/usr/etc:/bin mesg n stty -tostop exec pppd `hostname `:
RECOMMENDATIONS Use hostnames when running /etc/ppp/Autostart only if they are known locally. If a PPP connection to a DNS server is required to resolve a host name, use its literal IP address instead.
ENVIRONMENT The environment variable PPPHOME, if present, specifies the directory in which pppd looks for its configuration files (Filter and Auth for all connections, along with Systems, Devices, and Dialers if the connection is 'outbound'). You can specify PPPHOME either in the Sysinit script or in an incoming connection's Login script. If PPPHOME is not present, pppd will expect to find its configuration files in /etc/ppp/*.
SECURITY CONCERNS Pppd should be mode 4750, owned by root , and executable only by the members of the group containing all the incoming PPP login 'users'.
STANDARDS CONFORMANCE MS PPP implements the IETF Standard Point-to-Point Protocol and many of its options and extensions, conforming with RFCs 1661, 1549, 1332, 1333, 1334, and 1144. It can be configured to conform with earlier specifications of the PPP protocol, as described in RFCs 1134, 1171, and 1172. MS PPP also implements the nonstandard SLIP protocol as described in RFCs 1055 and 1144.
130 Morning Star PPP
SEE ALSO tun(4), ppp.Auth(5), ppp.Devices(5), ppp.Dialers(5), ppp.Filter(5), ppp.Keys(5), ppp.Systems(5), RFC 1661, RFC 1549, RFC 1332, RFC 1333 , RFC 1334, RFC 1172, RFC 1144, RFC 1055, ds.internic.net:/internet-drafts/draft-ietf-pppext-compression -04.txt.
CREDITS Parts of the protocol engine are derived from code written by Drew D. Perkins
COPYRIGHT INFORMATION This software and associated documentation is Copyright 1991-1997, Progressive Systems Inc., all rights reserved.
This daemon contains code that is Copyright 1989 Carnegie Mellon University, all rights reserved. It also contains code that is Copyright 1989 Regents of the University of California, all rights reserved. It also contains code that is Copyright 1990, RSA Data Security, Inc., all rights reserved
131 Morning Star PPP
Troubleshooting Guide
FATAL ERROR MESSAGES
Scenario: Pppd won't dial out; the log file says ‘Device is locked’.
Solution: Pppd uses lock files compatible with other programs to avoid using a device already in use by another program, and to keep other programs from interfering with devices in use by pppd. If the pppd.log file says ‘Device is locked’, look for a lock file such as LCK..cua in /usr/spool/locks, /usr/spool/ uucp, /usr/spool/uucp/LCK, /var/spool/locks, or wherever your system keeps tty lock files. Each lock file should contain the process id of the owner process. If the lock file is 4 bytes long, the process id is a 32-bit binary number. If the lock file is 11 bytes long, the process id is printed in ASCII. Look in the lock file for the owner pid (use od -d for binary files and cat for ASCII lock files), and then use ps to look for the owner.
The University of Toronto SLIP implementation for SunOS 4.1 uses lock files that are name-compatible with those used by HDB UUCP and Morning Star PPP. That is, they're in /usr/spool/locks named LCK..cua or LCK..ttyb or whatever is appropriate. Unfortunately, UTSLIP's lock files are of zero length, which makes it impossible to determine the pid of the owner process. Later instances of uucico or pppd will examine the contents of any lock files they find, to see whether the creating process is still running, or whether it perhaps died ungracefully and didn't clean up its lock files. If the latter, uucico and pppd know that they can usurp the claimed but expired lock on that interface.
When pppd finds a lock file of zero length, it has no way of knowing the pid of the process that created it, so to be safe, it gives up trying to open the associated tty.
Scenario: Fatal error: Interface 'du0' already in use
Solution: Another process is already using this interface, probably another pppd. List the processes running on your system with a "ps" and then kill this process id.
Scenario: Fatal system error: License key missing or damaged or Fatal System error: no License key found for
Solution: The license key is either not installed, installed incorrectly, or the wrong information has been used to make the License key. Double check to see that the key file is correctly named, License or Lisense, and that the correct ownership and permissions have been set. If you are still having problems, call Progressive
132 Morning Star PPP
Systems technical support at 614-326-4600 or email them at [email protected].
Scenario: Pppd dies with a `Fatal error: ...' or `Fatal system error: ...'message.
Solution: If not otherwise described in this section, that's probably a bug. Send e-mail to [email protected] containing relevant portions of pppd.log and your configuration files (edit out the passwords and phone number first) and we'll fix it.
PPP DOESN'T CONNECT
Scenario: Pppd dials, the modems connect, the modem data lights flash briefly, and then the log file shows `Hangup' or `SIGHUP'.
Solution: Increase pppd's debug level to 2 (chat script processing) to see if any error messages are printed by the peer at startup. ‘Login incorrect’ indicates that the login and/or password in the calling machine's Systems file don't match those in the answering machine's passwd file. ‘/etc/ppp/Login: Permission denied’ indicates a file protection problem with the login shell script. ‘/usr/etc/pppd: Permission denied’ indicates that the PPP user account cannot execute the daemon, probably because the user account is not in the ‘ppp’ group that owns the daemon, while the daemon is mode 4750 for security reasons.
A SIGHUP (HangUP SIGnal) means that the kernel detected the Carrier Detect signal (DCD) from the serial port is no longer asserted and sent the process attached to the serial port a signal. In general, both "SIGHUP" and "Hangup" normally mean that the system was unable to see a DCD signal from the modem. (See below for a description of the "Hangup" error message.) If you see the "Hangup" in your log, it probably means that Carrier Detect was lost but that the operating system did not detect it.
As a safety precaution, MS PPP polls the state of Carrier Detect (aka CD or DCD) (using ioctl(tty_fd, TIOCMGET, &modem_bits) to check the status of TIOCM_CAR) before write()ing each packet because some operating systems don't reliably deliver signals, and we find that we occasionally miss a SIGHUP. If this test returns a failure then pppd issues a "Hangup" message and tries to close the link.
Either the RS-232 DCD (Data Carrier Detect) signal has dropped or the device driver is not properly implementing the tty IOCTLs defined by the operating system. You can check the former using a "breakout" box or serial analyzer. If DCD is properly being asserted on the RS-232 interface, then we recommend contacting the manufacturer of the serial port driver.
Make sure the modem is configured to raise Data Carrier Detect (DCD) only when carrier is present. If the DCD is always asserted then the system has no way to know when the connection is dropped. As a work-around, you can use the "ignore-cd" option on the pppd command line. If the carrier is truly dropping, using "ignore-cd" will only mask a problem and the session will fail.
133 Morning Star PPP
Scenario: Pppd dials out, the modems connect, the log file says ‘Call succeeded’, but ps shows pppd's state to be ‘connecting’ until the modems disconnect about a minute later.
Solution: Check the log file for messages indicating negotiation problems. Increase pppd's debugging level to 2 (input framing errors). Look in the pppd.log file for warnings indicating damaged received messages such as ‘Bad FCS received’, ‘Frame too long’, or ‘Missed ALLSTATIONS’.
Increase pppd's debugging level to 9 (show all characters read or written) to see if the peer is sending anything at all. PPP messages should initially look like 7E FF 7D 23 ... 7E. Look for corrupted characters (e.g. 7F instead of FF) or other parity bit problems.
"Bad FCS received" means that a frame was damaged in transit. This may be at any point and for any reason (bad phone line, flow control problem, etc.). A few of these per session is nothing that should concern you.
Specifically, the FCS (Frame Check Sequence) is transmitted after all data in a PPP frame. The sending system computes a 16-bit value based on the data portion of the frame and appends it to the frame. When the packet reaches the receiving system, the receiver computes its own FCS and compares it against the last 16 bits of the frame. This ensures that the receiver does not try to interpret any damaged frames that reach it.
This will not mean any harm to your session except in high numbers. The TCP portion of the TCP/IP protocols will make up for lost data by asking for retransmission of lost packets. You will probably not be able to notice the delay resulting from a few lost packets.
If you have many FCS errors or your session fails after several errors, the first thing to check is flow control. Make sure hardware flow control is set on the serial ports and modems and that the Devices file contains the proper information (rtscts except on HP-UX, AIX, and NeXTSteP). Your cable should be wired straight through between the modem and computer and should carry the RTS and CTS signals.
9/14-08:43:46-17451 Missed ALLSTATIONS, flushing frame
The log message above is evidence that PPP did not receive a valid PPP frame. "ALLSTATIONS" refers to the PPP frame's "Address" field (always "FF"), which normally follows the characters ("7E") that separate two PPP frames. Here, the connecting system is sending something besides the expected "FF" after the frame separator or flag, "7E".
You might see one or more of these messages in the log at the start of a successful session, while text such as a log message scrolls by after you have logged in. This is not evidence of a problem, but just an indication that we are still waiting for an LCP Configure-Request to come to us from the other system. If the message occurs after LCP frames have been received from the other side of the PPP link, this is evidence of data being corrupted as it traverses the link.
134 Morning Star PPP
Please check cables to ascertain if they carry the rts and cts signals, the modem to make sure it is configured correctly.
Scenario: When I use telnet, ping or some other program to attempt a connection, the modem doesn't start dialing and nothing is written to the log.
Solution: Increase pppd's debugging level to 6 (IP message summary). If it now shows the packets, but says `dial failed', then PPP is waiting after a failed call attempt until the call retry delay timer expires. Use SIGINT to tell pppd to reset the timer, change the Systems file entry if it is set to use too long a delay, or wait until the timer expires.
Scenario: PPP won't connect and the log file shows ‘IPCP: Received bad Configure-Reject’
Solution: Restart pppd with the novjcomp option. If this fixes the problem, then the peer may be using a buggy IPCP option negotiation algorithm. Try running pppd with the rfc1172-vj or the rfc1172-typo-vj option. If they don't work, go back to novjcomp and complain to the vendor of the peer's implementation of PPP.
Scenario: PPP won't come up, and the peer complains that it is has received a request for IPCP configuration option 3.
Solution: Restart pppd with the rfc1172-addresses option, and report a bug to the vendor of the peer's implementation of PPP. If the peer doesn't recognize IPCP configuration option 3, it should respond with an IPCP Configure-Reject rather than exiting altogether.
Scenario: Log reports: No available IP tunnel devices
Solution: In general, this message indicates that either the installation was not completed, and the device drivers are not available to or are not loaded into the Unix kernel, or that the device nodes--usually in /dev/tun*, with some exceptions--do not exist. Two steps may be required to resolve the problem. First, run the Install script provided with Morning Star PPP or on Solaris and Unixware, run pkgadd. Then on NeXTSteP, AIX, and SunOS, make sure the Sysinit script is executed each time you reboot your computer system.
AIX
If you have not run the Sysinit script, you may receive the "No IP tunnel devices available" error. When you first get your software, you must first uncompress and tar it. Then, run the Install script. AIX uses loadable device modules.
The Sysinit script loads the tunnel device driver into the kernel and creates the correct devices in the /dev directory. The Sysinit script must be run each time the system boots. This is normally done in the /etc/rc.net file (see rc.local.ex for an example). You can check whether the tunnel device driver has been loaded with the "lsdev" command, lsdev -C -c if -s tun. Expect to see the output: tun Available N/A
135 Morning Star PPP
NEXTSTEP
When you first get your software, you must first uncompress and tar it. Then, un-package it via the normal method for installing software on NeXT. Finally, run the Install script, which most likely will be in /LocalApps/ppp. NeXT uses loadable device modules.
Commands in the default Sysinit script loads the tunnel device driver into the kernel and creates the correct devices in the /dev directory. The Sysinit script must be run each time the system boots. We encourage you to call the Sysinit script in the /etc/rc.local file. You can check whether the device driver has been loaded by executing /usr/etc/kl_util -s. The output should include "tun", the tunnel device driver.
SUNOS
Initially, you must use the Install (for inbound and outbound calling) or the Quickinstall (for outgoing calling) script to install the software. SunOS uses loadable device modules. The Sysinit script loads the tunnel device driver into the kernel and creates the correct devices in the /dev directory. The Sysinit script must be run each time the system boots. We encourage you to call the Sysinit script in the /etc/rc.local file. The command modstat will tell you if the tun driver is installed on your system. For example, see if tun is installed, modstat | grep tun
SOLARIS
You may see this error if you have not done a pkgadd in order to install the software. Solaris uses loadable device modules. The command " modstat" will tell you if the tun and pppframe drivers are installed on your system. For example, see if tun is installed, use, modstat |grep tun. Check for the presence of the device driver with ls -alg /usr/kernel/drv/tun* and check for the presence of nodes by executing ls -alg /devices/pseudo/tun* and ls -alg /dev/tun*.
HP-UX
You may see the "No available IP tunnel devices" error if you have not run the Install script after receiving and unpacking the software. You may also see it if you have installed for a number of peers that is other than 16. To correct this, up the value of "NTUN" in a link command in the Install script to the number of peers that you chose during the installation process.
COMMON PPP CONNECTION PROBLEMS
136 Morning Star PPP
Scenario: PPP connects, and I can ping the other end, but I can't use telnet, rlogin, or ftp.
Solution: Check the log file for any messages indicating negotiation problems. Increase pppd's debugging level to 2 (input framing errors). Look in the pppd.log file for warnings from ppp indicating damaged messages such as ‘Bad FCS received’, ‘Frame too long’, ‘Missed ALLSTATIONS’, ‘Bad protocol’, or ‘Short frame received’.
Increase pppd's debugging level to 6 (IP message summary). When telnet is started, make sure a tcp packet is sent. A tcp packet should be received in response.
Restart pppd with the novjcomp option. If this fixes the problem, then the peer may be using a buggy IPCP option negotiation algorithm. Try running pppd with the rfc1172-vj or the rfc1172-typo-vj option. If they don't work, go back to novjcomp and complain to the vendor of the peer's implementation of PPP.
If you have a Filter file installed, temporarily disable it as you may have an incorrect rule in your filter. Please be aware that this will compromise security on your system.
Scenario: PPP connects and everything works, but it is slow and erratic.
Solution: Increase pppd's debugging level to 2 (input framing errors). Make sure that received frames are arriving undamaged and that you aren't getting an excessive number of FCS errors.
Make sure that the telephone lines are relatively clean. Noisy phone lines can cause FCS or other transmission errors, or can cause V.42 or MNP error correcting protocols to retransmit excessively, or can cause the modems to retrain frequently, slowing the connection.
Make sure the serial port is not running faster than your computer can comfortably handle.
Make sure that flow control is set up properly on the modem and on the serial port it is connected to. If you are using hardware flow control, make sure the cable connects RTS and CTS (RS-232 pins 4 and 5).
Is your Telebit modem using the PEP protocol? PPP over PEP is normally slow and erratic.
Scenario: The PPP link comes up and carries IP traffic, but a minute later the log file shows ‘LQM: LQRs: 0/5’, then ‘LQM: Too many Link-Quality-Reports lost’, then pppd closes the connection.
Solution: Restart pppd with either the echolqm or the nolqm option, and report a bug to the vendor of the peer's implementation of PPP. If the peer doesn't support Link Quality Monitoring, it should issue a Configure-Reject during LCP negotiations. If, even after sending a LCP Configure-Ack in response to MS PPP's LCP
137 Morning Star PPP
Configure-Request containing LQM, the peer doesn't recognize a Link Quality Report, it should respond with a Protocol-Reject rather than not responding at all. When pppd sees the Protocol-Reject, it will fall back to using LCP Echo- Requests for its link status monitoring functions.
A LQM failure one minute after connection startup, particularly during successful user data transfers, indicates that the peer neither properly Configure-Rejected LQM during LCP negotiations, nor properly Protocol- Rejected MS PPP's first LQR.
Scenario: When the modem abruptly gets hung up, pppd doesn't notice.
Solution: Make sure that the modem drops the Carrier Detect (CD), also called DCD, Data Carrier Detect) signal when carrier is lost. On a Telebit T1600, set ‘&C1’.
Make sure that the cable properly connects CD (RS-232 pin 8) from the modem through to the serial port, and that the pppd command line doesn't include the ignore-cd option.
Scenario: Shortly after the Systems chat script completes, the log file records a SIGHUP and the connection drops. But the remote modem didn't actually hang up the connection, and tip works correctly.
Solution: Make sure that the modem asserts Carrier Detect (CD, also called DCD, Data Carrier Detect) signal when it is actually talking to a remote modem. On a Telebit T1600, set ‘&C1’.
Make sure that the cable properly connects CD (RS-232 pin 8) from the modem through to the serial port. pppd doesn't check the state of DCD until after the Systems chat script completes, about the time that PPP negotiations begin. If the modem isn't asserting DCD, or if the cable isn't delivering the signal to the serial port, pppd won't be able to tell that the modem is connected. To test this, or to work around a defective cable, start pppd with the ignore-cd option.
Scenario: Pppd won't hang up the phone, even though it was started with idle 300.
Solution: Increase pppd's debugging level to 6 (IP frame summary) and watch for logged frames that don't say ‘!keepup’. If you don't want those messages to keep your line active, put them in the ‘keepup’ filter in the Filter file ($PPPHOME/Filter by default).
Scenario: When you telnet to test if the answering PPP account is set up correctly, you will be greeted with what looks like line noise. This is the PPP Link Control Protocol Configure-Request packet, but it takes a long time for pppd to give up and go away.
Solution: The easy way to instruct the answering pppd to exit and close the connection is to type the four-character sequence of a tilde (‘~’, ASCII 0x7E) followed by three control-Cs (^C, ASCII 0x03). If the pppd is running on a Sun where the pppframe module is loaded, you'll also need to type another tilde after the three control-Cs to flush the ^C characters through the STREAMS.
138 Morning Star PPP
The ‘~^C^C^C’ sequence only works in PPP mode, not in SLIP mode. And in PPP mode, if you specified ‘passive’ on the command line, ‘~^C^C^C’ only works after receipt of a good PPP packet.
Scenario: Even though UUCP is using the modem, pppd tries to use it to place an outbound call. And when pppd has an active link, UUCP tries to make an outbound call.
Solution: The outbound ‘Auto Call Unit’ (‘ACU’) names used in PPP's Devices must match the names used for similar purposes in UUCP's Devices file. For example, if your UUCP configuration knows it as cua0 but PPP knows it as cua, each facility will be unable to discover the lock file indicating that the other is active.
Scenario: With the debugging verbosity level set to 2 or more, I get messages in the log file like ‘Bad FCS received’, ‘Bad protocol (even), flushing frame’, ‘Short frame received (3 bytes)’, ‘Frame too long, flushing frame’, ‘Missed ALLSTATIONS, flushing frame’, or ‘Missed UI, flushing frame’.
Solution: Some of the incoming messages are getting damaged in transit. If your throughput is erratic or lower than you expect, then refer to the section above starting with ‘PPP connects and everything works, but it is slow and erratic’.
If you see ‘Missed ALLSTATIONS’ while the link is coming up, after ‘Chat script succeeded’ but before the first ‘Received LCP Configure-Request’, don't worry about it. The calling daemon is scanning the characters it sees coming from the answering system, looking for the start of a PPP frame that signifies the beginning of option negotiations. While the contents of the answering machine's /etc/motd scrolls by, it's likely that the calling daemon will flushs several of what it had thought to be frames, but that turned out to be more text.
If the messages happen while the link is active, but only rarely, then don't worry about them. The errors may be due to intermittent line noise in the phone lines, or your computer may occasionally lose incoming characters. Suspect this last possibility if the errors tend to occur when receiving large amounts of data.
PERFORMANCE ISSUES
Scenario: Using Morning Star PPP in its SLIP mode, the peer receives only alternating frames. Every other frame is discarded.
Solution: The peer's SLIP implements only the optional framing style suggested in the second paragraph in the PROTOCOL section on the second page of RFC 1055, and cannot receive adjacent frames separated by only one END character (0xC0). Add extra-slip-end to the pppd command line.
Scenario: /etc/resolv.conf points at a name server out on the Internet somewhere, across the PPP link. When /etc/resolv.conf is in place and ppp connection is up, connectivity between internal host is fine. When /etc/resolv.conf is in place and
139 Morning Star PPP
the ppp connection is down, connectivity between internal host comes to a crawl. Once the /etc/resolv.conf is removed, connectivity returns to normal.
Solution: That's because local applications are trying to reverse-resolve incoming connection addresses (even on the local net) into names, whether for authentication (e.g. /.rhosts and /etc/hosts.equiv), or just normal operations (e.g. telnetd making entries into /etc/utmp and /var/adm/wtmp). When the DNS resolver routines can't reach the nameserver, they don't return a value meaning "I don't know" until some timeout interval has passed. This is probably happening on every connection attempt.
The fix is to run a local nameserver that's either SOA (Start of Authority) or an authoritative secondary NS (Name Server) for your name space (forward mapping) and your address space (reverse mapping). An authoritative secondary NS is one that's listed in the SOA's RR (Resource Record) for that domain.
Scenario: Using Morning Star PPP on a system or network where Frame (a WYSIWYG document production system) is installed, pppd dials the modem hourly even though no users are actively using it. The pppd.log file shows a line (broken to fit on this page) like
9/23-18:48:34-83 udp 192.0.2.1/3680 -> 192.0.2.2/sunrpc 45 bringup
Solution: This is Frame's copy license manager probing for other license managers on the network. To avoid bringing up the link for this sort of packet, append ‘!sunrpc’ to the ‘bringup’ filter in the Filter file.
ROUTING ISSUES
Scenario: Pppd installs a route when it starts (as shown by netstat -r), but after a while it disappears.
Solution: Are you running in.routed? Routed is sometimes ill-suited to use with point-to- point connections; its RIP protocol can't adequately describe them to other routed's, and it gets confused about intermittent connections, over which it sometimes can't hear from another routed to reassure itself that the link is still up, and therefore deserving of a route. Make ‘passive’ entries in /etc/gateways, similar to those in Examples/gateways.ex (see routed(8)), to persuade routed not to gratuitously remove routes it thinks aren't active anymore.
If routed can't solve your routing topology problems, we suggest running gated instead, available via anonymous FTP from gated.cornell.edu or via anonymous PPP/FTP from Progressive Systems, Inc.
If both routed and gated are too cumbersome, and your network is simple enough, don't run either routing daemon. Use static routes instead.
140 Morning Star PPP
Scenario: To avoid using a separate subnet, you have set up your network as described in the section entitled ‘Connecting a Host to a LAN: ARP table manipulation’. The remote workstations can exchange packets with everything on that LAN, but not with any hosts or networks that are reachable through a particular router.
Solution: Some routers implement a security feature that causes them to not believe the second IP address that is claimed to be associated with a particular Ethernet address. If your remote workstation can exchange packets with all the hosts on your LAN but not with any that are reachable only through a particular router, then that router is probably skeptical of your ARP entry. Luckily, this router security feature is usually configurable. If not, you must put the remote workstations on their own subnet as described in the section entitled ‘Connecting a Host to a LAN: Separate Network’, and configure the router so that it knows that your office hub is the gateway to that subnet.
SYSTEM SPECIFIC
NeXT
Scenario: My NeXT system can't run Morning Star PPP, but it has always run Marble Teleconnect just fine. Whenever the MS PPP daemon starts, the it complains in the log file about problems using du0.
Solution: Remove Marble Teleconnect and reboot your NeXT system. Its use of the device name du0 collides with MS PPP's use of the name, and there's nothing Marble can do that MS PPP can't do.
SCO
Scenario: Using Morning Star PPP on SCO UNIX with SCO TCP 1.2, when attempting to start a new PPP or SLIP connection, pppd.log reports something like
/etc/pppd: Fatal system error: Error opening IP device '/dev/inet/ip': No such device or address
Solution: That probably means you've run out of STREAMS networking slots into which the STREAMS-based IP tunnel driver can attach itself. Edit /etc/conf/pack.d/ip/space.c and increase the values of IPCNT and IPPROVCNT from 8 and 16 to something like 32 and 64, respectively. Then `cd /etc/conf/cf.d; ./link_unix' and reboot. If you need more than 8 peers, see /usr/lib/ppp/Examples/README for instructions.
141 Morning Star PPP
Scenario: Using Morning Star PPP on SCO UNIX, pppd dials the modem immediately after it's started, but before any user processes would be using the link. The pppd.log file shows a line like
9/23-18:48:34-83 udp 192.0.2.1/60000 -> 192.0.2.2/60000 45 bringup
Solution: This is SCO's copy protection scheme, broadcasting the serial number of this system. If a SCO UNIX system ever receives a broadcast message containing a serial number identical to its own, it shuts down. To avoid bringing up the link for this sort of packet, append `!60000/udp' to the `bringup' filter in the Filter file (/usr/lib/ppp/Filter by default).
Scenario: Calling into a system running SCO UNIX or ODT or some other operating system derived from System V, the calling pppd's Systems chat script sees the `login:' prompt and sends the correct login string, but never sees a `Password:' prompt.
Solution: The stock System V getty flushes its input buffers just after printing the `login:' prompt. Since pppd progresses into the `send' phase of the expect/send chat script immediately upon completion of the `expect' phase, the calling pppd may be sending the login string before the answering getty is ready to listen for it. So the calling system's Systems entry should look something like
SysVbox Any ACU 38400 5551212 in:--in: \dProbin word: mypasswd
SUNOS
Scenario: With Sun patch ID 100513-04 installed on a SPARC system running SunOS 4.1.2, PPP link traffic flows well until the volume picks up and RTS/CTS flow control is needed. Then the line stalls, no more packets can cross. Solution: Comment out the section of /etc/ppp/Startup that modloads the ppframedriver, then reboot your SPARC system.
142 Morning Star PPP
Glossary
Active-Open -- An event internal to the PPP configuration finite state machine that causes PPP to start sending Configure-Request messages to the peer.
Bps -- Bits per second.
CCITT -- The French acronym of the International Telegraph and Telephone Consultative Committee, an organization that publishes international data communications standards.
Challenge Handshake Authentication Protocol -- A challenge-response LCP authentication protocol resistant to playback attacks. CHAP runs after LCP negotiation is complete but before any NCPs are started.
CHAP -- See Challenge Handshake Authentication Protocol .
DNS -- See Domain Name System.
Domain Name System -- The distributed host and network name database system used to translate between Internet addresses and their associated host and network names. RFC 1034, Domain Names - Concepts and Facilities is an introduction to the DNS. RFC 1035, Domain Names - Implementation and Specification describes the protocols and data types used.
FCS -- See Frame Check Sequence.
Frame Check Sequence -- The (usually) 16-bit field transmitted after all data in a frame but before the closing flag. Its value is computed using the data portion of the frame and a binary polynomial, and its purpose is to provide the receiver with a fairly reliable check against data corruption during transmission. An ``FCS error'' indicates that a frame was damaged in transit.
FTP -- The internet File Transfer Protocol, described in RFC 959, is used to copy data files across TCP/IP networks. hardware flow control -- Out of band flow control defined in EIA RS-232-D that provides bidirectional flow control using the RTS (Request To Send) and CTS (Clear To Send) signals. The DTE (typically a computer) asserts RTS when it is able to accept input, and the DCE (typically a modem) asserts CTS when it is able to accept input.
HDLC -- High-Level Data Link Control, defined in ISO 3309, is a bit-oriented framing and addressing scheme which is used as the basis for most modern synchronous wide-area data communications protocols, including PPP, X.25, SNA, OSI, and Frame Relay.
Internet Protocol -- The layer of the Internet family of protocols that is responsible for packet routing and datagram fragmentation and reassembly.
Internet Protocol -- The NCP for IP, the Internet Protocol.
143 Morning Star PPP
IP -- See Internet Protocol.
IPCP -- See Internet Protocol Control Protocol.
ISO -- The International Standards Organization publishes a broad range of international standards for industry, including a large number that are identical or nearly identical to CCITT standards.
LCP -- See Link Control Protocol.
Link Control Protocol -- The protocol that establishes, configures, and tests the data link connection.
Link Quality Monitoring -- A negotiable feature of LCP that allows a PPP implementation to determine when and how often the link is losing data. If both ends of a PPP link agree to perform LQM, they will periodically send Link-Quality-Report messages to their peer containing various sequence numbers, state variables, and byte and packet counts. This information is then used to measure how reliable the connection is, and can be used to decide when to shut the connection down and perhaps try again.
Link-Quality-Report -- An LCP message sent after successfully negotiating the LQM option. The LQR contains various state variables, packet counts, and byte counts.
LQM -- See Link Quality Monitoring.
LQR -- See Link-Quality-Report.
Magic Number -- A 32-bit random number, unique to each end of each PPP link, used to determine if the link is looped back. If a PPP implementation discovers that its peer has the same Magic Number, it will strongly suspect that it is talking to itself.
MNP -- The Microcom Network Protocols include several error correction and data compression schemes for use in modems.
Maximum Receive Unit -- The size of the data field in the largest PPP message a PPP implementation can receive.
Maximum Transmission Unit -- The size of the largest IP datagram an IP interface can send.
MRU -- See Maximum Receive Unit.
MTU -- See Maximum Transmission Unit.
NCP -- See Network Control Protocol.
Network Control Protocol -- Any of a group of protocols that run after LCP has successfully connected and whose purpose is to establish and configure a network-layer protocol.
Network-Layer Protocol -- The member of any protocol family corresponding to Level 3 on the ISO protocol stack. One example is IP.
144 Morning Star PPP
NFS -- The Sun Network Filesystem protocol, described in RFC 1094, provides transparent remote access to shared files across networks using the Sun RPC protocol.
NNTP -- The Network News Transfer Protocol, described in RFC 977, is used for transporting and reading network news articles across internet connections.
NTP -- The Network Time Protocol, described in RFC 1129, is used to keep the clocks of internet-connected hosts synchronized.
PAP -- See Password Authentication Protocol.
Passive-Open -- An event internal to the PPP configuration finite state machine that causes PPP to move from the Closed state to the Listen state, where it awaits Configure-Request messages from the peer.
Password Authentication Protocol -- A simple LCP authentication protocol that sends an identifying name and an associated password. PAP runs after LCP negotiation is complete but before any NCPs are started. peer -- The PPP implementation at the other (far) end of the link.
PEP -- The Packetized Ensemble Protocol is a proprietary modulation and error correction technique used in some Telebit modems. It can achieve throughput of up to 16000 bps, and is able to establish and maintain connections over noisy lines better than V.32, but it is asymmetric, with slow line turnaround and latency.
Point-to-Point Protocol -- The Internet standards-track data-link protocol for carrying multi- protocol datagrams (including IP) over serial links.
PPP -- See Point-to-Point Protocol.
Request For Comments -- The Internet name for a standard.
RFC -- See Request For Comments.
RPC -- The Sun Remote Procedure Call protocol, described in RFC 1050, is used to distribute applications over multiple networked computers.
SCSI -- The Small Computer System Interface is a standard for connecting high-speed intelligent peripherals, such as disk or tape drives, to computers.
Serial Line Internet Protocol -- A simple protocol for carrying IP datagrams over serial links. No error detection or configuration negotiation is included.
SLIP -- See Serial Line Internet Protocol.
SMTP -- The Simple Mail Transfer Protocol, described in RFC 821, is used to deliver electronic mail messages across internet networks. telnet -- The protocol used to establish terminal sessions across internet networks. See RFC 854 for the protocol specification. There are many other related RFCs that describe various telnet options.
145 Morning Star PPP
UUCP -- The Unix-to-Unix Copy Program is used to transfer data files and electronic mail, usually across dial-up modem connections, between Unix systems.
V.32 -- A 9600 bps full-duplex modem modulation scheme with fallback to 4800 bps.
V.32bis -- A 14400 bps full-duplex modem modulation scheme with fallback to 12000, 9600, 7200, and 4800 bps.
V.42 -- An error correction scheme used by many V.32 and V.32bis modems that carries asynchronous data using the LAPM protocol over a synchronous connection.
V.42bis -- A data compression method used by many V.32 and V.32bis modems. V.42bis can only be used over V.42.
VJ -- The initials of Van Jacobson, an engineer at Lawrence Berkeley Laboratories who has done lots of good things for the Internet protocols, including inventing a TCP header compression method described in RFC 1144.
146 Morning Star PPP
Bibliography
We recommend that newly-connected Internet users and administrators become familiar with the contents of the following documents, some are themselves reading lists. You can get RFCs via anonymous FTP from nic.ddn.mil:/rfc* or from ftp.uu.net:/inet/rfc/*.
RFC-1180 A TCP/IP Tutorial by T. Socolofsky and C. Kale (1991, 28 pps.)
An Introduction to the Internet Protocols by Charles L. Hedrick (1987, 27 pps.) ftp.morningstar.com:pub/papers/hedrick-intro.Z
RFC-1206 Answers to Commonly asked "New Internet User" Questions by G. Malkin and A. Marine (1991, 32 pps.)
RFC-1207 Answers to Commonly asked "Experienced Internet User" Questions by G. Malkin, A. Marine, and J. Reynolds (1991, 15 pps.)
RFC-1208 A Glossary of Networking Terms by O. Jacobsen and D. Lynch (1991, 18 pps.)
RFC-1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet. by J. VanBokkelen (1990, 5 pps.)
Introduction to Administration of an Internet-based Local Network by Charles L. Hedrick (1988, 46 pps.)
RFC-1118 The Hitchhiker's Guide to the Internet by Ed Krol (1989, 24pps.)
RFC-1462 What is the Internet? by E. Krol and E. Hoffman (1993, 11 pps.)
RFC-1463 Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings for the Network Novice by E. Hoffman and L. Jackson (1993, 4 pps.)
RFC-1325 Questions and Answers - Answers to Commonly asked "New Internet User" Questions by G. Malkin and A. Marine (1992, 42 pps.)
RFC-1175 Where to start: A bibliography of internetworking information by K. Bowers, T. LaQuey Parker, J. Reynolds, K. Roubicek, M. Stahl, A. Yuan (1990, 42 pps.)
RFC-1392 Internet Users' Glossary by G. Malkin and T. LaQuey Parker (1993, 53 pps.)
Internetworking with TCP/IP Principles, Protocols, and Architecture \(em by Douglas Comer (1988, Prentice-Hall, 261 pps. plus 5 appendices, bibliography, and index; ISBN 0- 13-470154-2)
We also recommend that the following be kept available for convenient reference:
147 Morning Star PPP
Improving The Security Of Your UNIX System by David A. Curry (1990, 51 pps.)
RFC-Index Citations for the Internet Requests For Comment. (continuously updated by the Network Information Center)
RFC-822 Standard for the format of ARPA Internet text messages by David Crocker (1982, 47 pps.)
RFC-1035 Domain Names \(em Implementation and Specification by Paul Mockapetris (1987, 55 pps.)
A Brief Tutorial on Sendmail Rules attributed to Charles L. Hedrick (1985, 16Kb).
RFC-1036 Standard for interchange of USENET messages by Mark Horton and Rick Adams (1987, 19 pps.)
RFC-977 Network News Transfer Protocol by Brian Kantor and Phil Lapsley (1986, 27 pps.)
RFC-1129 Internet time synchronization: The Network Time Protocol by Dave Mills (1989, 27 pps.)
RFC-1122 Requirements for Internet Hosts \(em Communications Layers. (1989, 116 pps.)
RFC-1123 Requirements for Internet Hosts \(em Application and Support. (1989, 98 pps.)
RFC-1200 IAB Official Protocol Standards (1991, 31 pps.)
RFC-1087 Ethics and the Internet. (1989, 2pps.)
RFC-1178 Choosing a Name for Your Computer by D. Libes (1990, 8 pps.)
Inter-Network Mail Guide by John J. Chew et al (1990 and 1991, 20 Kb)
USENET Software History and Sources by Gene Spafford (1991, 15 Kb)
Release Notes
List of Active Newsgroups by Gene Spafford (1991, 37 Kb)
6 February 1997 Michael Freeze version 2.0
4 February 1997, Ge' Added 'syncaccess' pppd command line parameter for the Solaris 2.x X86 release. Solaris 2.x tends to develop a corrupted interface list when a lot of tunnel devices/network interfaces are used concurrently. 'syncaccess' provides a workaround by serializing all operations. 'syncaccess' currently requires SYSV userland semaphores. Add a line to /etc/system:
set semsys:seminfo_semmnu = 128
148 Morning Star PPP
and reboot before using this feature. The number should be at least equal to the maximum number of PPP daemons that can be active on the system.
12 August 1996, Sam Readded support for nochap, nomschap and nopap. The no*ap options have higher precedence than the require*ap options. The order they are specified on the command line is irrelevant.
11 April 1996, Karl Allow the log filter keyword to take a string, e.g. ‘/log=spoofed’.
Add extern=
Print ‘corrupt’ on logged IP summaries of packets for which the filter code has detected inconsistent IP and higher-level protocol length fields.
15 March 1996, Karl Add bits= filter keyword.
14 March 1996, Laine Export the entire parent environment to exec scripts, along with the following variables describing the current session:
PPPHOME - as you'd expect, but always set PPP_COMMANDLINE - all arguments from original commandline PPP_LOCALADDR - local address of link while up (negotiated) PPP_REMOTEADDR - remote address while up PPP_NETMASK - netmask while up PPP_ORIG_LOCALADDR - original local address (from commandline) PPP_ORIG_REMOTEADDR - original remote address PPP_ORIG_NETMASK - original netmask PPP_INTERFACE - name of PPP interface (duX) PPP_DEVICE - name of device being used for serial stream PPP_LOGFILE - self explanatory PPP_ACCTFILE - ditto PPP_AUTHNAME - peer name if chap/pap used, else "name" parameter from commandline if given, else username of user that started pppd. PPP_PID - pid of pppd process PPP_SHUTDOWN - shutdown reason if we are going down and a shutdown reason is available, else non-existent
NOTE: The environment will take up space for each pppd that is running. You should attempt to make the environment as small as possible before running pppd.
13 March 1996, Laine Treat ENXIO (No Such Device or Address) on write as a hangup, not a fatal error - this agrees with the documentation for write().
149 Morning Star PPP
Fix MTU setting on Solaris - use ifr_metric rather than ifr_flags.
Change the method of binding the tunnel driver to IP to hopefully eliminate failures in stream_ip_open.
27 February 1996, Laine Protect against multiple simultaneous incoming connections using the same interface/IP address.
23 February 1996, Laine SCO OSE 5.0, Irix 5.3, and HP-UX 10.x with Streams IP are now supported.
15 February 1996, Karl Keep unanswered TCP SYN packets from installing dynamic keep alive rules into packet filters that then take an hour to time out.
Fix humorous recursive "missing filter name" error message when parsing filter files..
14 February 1996, Karl Look for modem dialers in Dialers.local in addition to the Dialers file. Entries in Dialers.local take precedence over those in Dialers.
10 February 1996, Karl Force a hangup if CD doesn't rise within 60 seconds on an HDLC dial-on-raising-DTR link.
9 February 1996, Karl Allow an explicit address of 255.255.255.255 in filter rules.
7 February 1996, Karl Support RealAudio(tm) in SecureConnect filters.
Print `rst' when logged TCP packets have the RST flag bit set.
Print the Filter file line number on all logged packets.
5 February 1996, Karl Enable Stac compression as per draft-ietf-pppext-stacker-04.txt, but allowing neither of the two Check Modes that use techniques patented by Motorola. We only support Check Mode 0 (no checking) and Check Mode 3 (sequence number checking).
26 January 1996, Laine On Solaris2, SCO, and Unixware, switch from using SystemV's signal() to using the POSIX-conformant sigaction(). In tests, this appears to make signal catching more reliable.
Switch SCO 3.0 from using LLI network device interface to using DLPI.
Installs for all platforms now verify that group ppp exists before continuing. Solaris and Unixware now set /etc/pppd to group ppp, as has always been the case on the BSD platforms.
150 Morning Star PPP
24 January 1996, Karl Don't re-read the filter file on signals if we don't have the tunnel driver open.
Remove support for oldchap and olderchap.
Add support for Microsoft CHAP through the new requiremschap option and now through requireauth. Remove support for nochap and nopap. Make requirechap, requiremschap, and requirepap additive, and make requireauth be equivalent to individually specifying the other three.
9 January 1996, Karl Expand the use of the Address Restrictions field of the Auth file to replace the destination address configured on the command line if the Address Restrictions field consists of only a single address.
Add support for Microsoft DNS (ms-dns) and NBNS (ms-nbns) Primary and Secondary server IPCP options.
Don't Ack an IPCP Option 3 (IP-Address) containing 0.0.0.0; some consider it bad form. Send a Configure-Reject instead.
Don't transmit an LCP MRU or ACCM option containing the default value (1500 or 0xffffffff, respectively), as per RFC 1661 section 5.1 under `Description'.
Use the same Identifier field in retransmitted Configure-Requests if none of the options has changed and if we haven't heard any response, as per RFC 1661 section 5.1 under ‘Identifier’.
5 December 1995, Karl Fix nasty CCP bug that could cause core dumps. We were calling ccp_close() with an invalid argument.
31 October 1995, Karl Fix gw-crypt file parsing bug that caused the wrong netmask for subnets to be computed if no netmask was explicitly given.
4 August 1995, Karl Print more informative messages when installing filters.
13 July 1995, Karl Print the username or uid in the peer name field of the accounting file entry if we don't have a PAP or CHAP name for our peer.
7 April 1995, Karl Add ‘trigger=
Fix missing line number on log messages from negated dynamic filter trigger rules.
20 March 1995, Karl Add new unreach= values to the packet filtering code, including the tcp-only ‘rst’, which only sends TCP RST packets, and remove three unreach= values which the new router requirements rfcs says not to use.
151 Morning Star PPP
7 March 1995, Karl Change default max-failure from 10 to 5 in accordance with RFC 1661.
6 March 1995, Karl Apply Close-in-Starting-state change from RFC 1661.
27 February 1995, Laine On NeXT Step systems, eliminate "/LocalApps/ppp does not exist" error during initial installation; also check hardware architecture to protect against customers installing the wrong software on the wrong system.
24 February 1995, Karl Make packet filters check the packet length before looking at a field that might actually be in a subsequent fragment.
20 February 1995, Karl Fix dstmask= and srcmask= filter parsing bug on little endian machines.
17 February 1995, Laine Tunnel drivers for SunOS 4.1.3, SCO, and ISC are built to maximum possible number of tunnel devices (128 for SunOS, 64 for SCO & ISC).
16 February 1995, Laine Ignore existing tty lockfiles on inbound connections.
10 February 1995, Laine Eliminate lingering old host route on HP-UX when IP address is changed at negotiation time.
9 February 1995, Laine On all NeXT Step platforms, only create 10 tunnel devices, to avoid a bug in NeXT Step which passes an improper unit # to the driver during ioctls for unit numbers greater than 10.
8 February 1995, Laine On Solaris Sparc and x86, any device with a name starting with "zsh" is now considered to be a synchronous device.
8 February 1995, Karl + Laine Properly report name of tunnel devices >= du10 on NeXTStep. Default configuration for NeXTStep changed to 128 devices (was 16)
2 February 1995, Karl When a packet filter wants to send an ICMP Destination Unreachable message with a !.../unreach, send a TCP RST (reset) packet instead if the blocked packet is for an established TCP session.
1 February 1995, Karl Print symbolic ip-opt= and unreach= values in filter dumps instead of numbers.
Print ‘rst’ flag in addition to ‘syn’ and ‘fin’ on logged TCP packets.
152 Morning Star PPP
30 January 1995, Karl Correct timer scope in dynamic filters so that outer timeouts don't time out inner keepalives.
26 January 1995, Karl Rewrite ip-opt parsing code to avoid NeXT scanf() bug.
23 January 1995, Karl Print ‘!all/unreach=1’, not ‘!unreach=1’ when we dump the filter file.
16 January 1995, Karl Print the magic numbers we expected and got when we print the ‘LQM: ... peer may have changed’ error message.
10 January 1995, Karl Add new ‘need-ip-address’ option to force IPCP to ask the peer to assign us an IP address even if we already provide a local IP address on the command line. This is to work around bugs in Solaris and Unixware, as well as in Ascend routers.
8 January 1995, Laine make a proper lockfile for SnapLink devices on SysVr4 (Solaris, Unixware)
3 January 1995, Karl Make authentication messages from the peer more verbose.
19 December 1994, Laine Solaris versions: fork() and setsid() at each async or sync tty open/close so that SIGHUPs are properly and reliably caught. When closing and async tty, first drop DTR and set baudrate to 0, then wait up to 5 seconds until CD drops. Then close the device. After this, wait up to 5 seconds for a SIGHUP to arrive - this aids cooperation with ttymon. Note that the pid given in the logfile will now change at each hangup.
16 December 1994, Laine Flush input/output when opening an async tty to get rid of stray modem responses from previous open.
15 December 1994, Laine Install driver links for SunOS 4.1.4
8 December, 1994 Solaris, Solaris x86, and Unixware now install 64 tunnel drivers rather than 16. Include note for Unixware about modifying IP kernel parameters to allow >3 ppp interfaces.
5 December 1994, Karl Add TCP /estab and /rst filter modifiers.
2 December 1994, Karl Add /log filter modifier and allow /trace in all filters.
29 November 1994, Karl Fix ambiguous port followed by ‘dst’ filter bug.
153 Morning Star PPP
23 November 1994, Karl Fix the TUIOGNAME code in the tunnel driver to not translate du10? into du1?. This limited the number of useful tunnel devices to 100 on all BSD-based systems.
Allow negated dynamic trigger rules.
17 November 1994, Karl Add ‘ftppasv’ filter keyword.
15 November 1994, Karl Print the current filter file to
11 November 1994, Karl Fix infinite looping in nested dynamic rule creation.
10 November 1994, Karl Allow redundant specification of protocol in Filter files (as in smtp/tcp).
3 November 1994, Karl Make sure nopap, nochap, name, requireauth and requirechap work together in unsurprising fashion.
28 October 1994, Karl Fix MTU size used with Predictor-1 compression.
27 October 1994, Karl Add the ‘ftp227’ filter file keyword for detecting the ftp ‘227’ response to the PASV command.
Print the relevant numbers when we get the "Too-long packet received" error.
26 October 1994, Karl Add new nested syntax for dynamic rules. Add ack, max=, timeout=, timeout, keepalive=, and keepalive keywords. Add "implicit" template-only keywords srcport, srcaddr, dstport, and dstaddr.
20 October 1994, Laine Add support for SGI Irix 5.2
19 October 1994, Karl Plug buffer leak in Configure-Request and Reset-Request handlers.
Print more information about received Protocol-Reject and Code-Reject packets at debug 3.
18 October 1994, Karl Clear our map of discarded characters once we've printed it.
12 October 1994, Karl Print the filter file number on every logged packet, not just blocked packets.
154 Morning Star PPP
11 October 1994, Karl Shut down pppd with a fatal error if it encounters a Filter file error the first time it reads it, else just print a warning and don't install it.
10 October 1994, Karl Include the year in the acct file date field.
4 October 1994, Karl Allow specifying speed on the command line for SnapLink devices.
3 October 1994, Karl Fix dialing ‘too much data’ problem when waiting for a receive string.
2 October 1994, Karl Plug minor CHAP memory leak.
30 September 1994, Karl Rewrite filter code; add filtering on frags and ftp PORT commands, plus dynamic filtering.
29 September 1994, Karl Add support for PPP tunnels over UDP.
20 September 1994, Laine Don't use posix libraries on NeXTStep to avoid log files filled with null caused by a bug in said library.
20 September 1994, Karl Try harder to remove lock files if pppd exits suddenly.
19 September 1994, Karl Shut down properly if the idle timer expires while we're waiting for CD to rise.
15 September 1994, Karl Fix license key address restriction code on little endian machines.
12 September 1994, Karl Make sure the mru argument value is in the valid range.
1 September 1994, Kim The Startup.ex script should export its idea of PATH for use by modload.
26 August 1994, Karl Don't let our PAP peer pretend to be us. Require the peer to use a name different from ours.
23 August 1994, Karl Rearrange unreach= parsing to avoid NeXT scanf bug.
8 August 1994, Karl Don't try to close and reopen the device on a dedicated line at SIGHUP time if auto is also specified.
155 Morning Star PPP
5 August 1994, Karl Add the ability for Filter clauses to match simultaneously on source and destination ports and addresses (and their netmasks).
4 August 1994, Karl Add code to the NeXT tunnel driver to handle SIOCGIFMTU ioctls. This fixes a bug that would cause an incoming pppd call to set the MTU to zero at disconnect time if an auto pppd were sleeping in the background.
3 August 1994, Karl The ICMP unreach=xxx packet generated from a Filter file entry had the bytes swapped in the ip_src field on little-endian machines.
2 August 1994, Karl Don't let SYN-without-ACK TCP packets permanently mark a TCP session for split idle; instead, time them out if we never receive a response.
When we get an error parsing the filter file, print a warning message and don't install the defective filter rather than exiting.
20 July 1994, Kim If we get a WILL SUPPRESS GO AHEAD, then respond with DO SUPPORESS GO AHEAD, instead of DONT SUPPRESS GO AHEAD, which is exactly what we _dont_ want.
11 July 1994, Laine Eliminate "IFF_POINTTOPOINT not set" console message on Solaris.
11 July 1994, Karl Don't display LQM throughput percentages in the command line if LCP isn't up.
8 July 1994, Karl Count ifInOctets, ifOutOctets and ifOutUniPackets on SLIP links.
Print the value of LastOutPackets in the verbose received LQR message, not the value of LastOutLQRs instead.
7 July 1994, Laine Modify Unixware tunnel driver to account for a discrepency between the printed unixware documentation and the example source in the SDK. This fixes the problem of Unixware not allowing more than one incoming ppp at the same time.
5 July 1994, Karl Work around a bug in Solaris and Unixware that would cause pppd to get a segmentation violation on inbound TCP and TELNET connections.
5 July 1994, Laine Silently ignore 0-byte tty reads on Solaris systems rather than interpreting it as EOF (which causes a hangup).
30 June 1994, Karl
156 Morning Star PPP
Port to NetBSD on SPARC processors.
22 June 1994, Karl Fix a problem that caused excessive CPU use on HP 700's.
15 June 1994, Karl Add the ability to define two idle timers, one for when no TCP sessions are active and the other for when there are.
2 June 1994, Karl Ignore malformed Configure-Requests; don't Configure-Reject them.
Compare the value size, not just the value, when checking a received CHAP Response.
Don't flush packets because of bad protocol bytes (odd or even) -- let the upper layers handle that.
Discard too-long received packets.
Nak LCP MRU, Asyncmap, and Magic-Number options with bogus lengths rather than Rejecting them.
Nak received Magic-Number options with zero values.
Send our negotiated Magic-Number in transmitted Echo-Reply messages rather than sending zeros when nolqm was specified.
Truncate transmitted Code-Reject and Echo-Reply messages that exceed the established MRU of the peer.
Discard received NCP messages with length field less than 4.
Ignore received Terminate-Ack messages with mismatching ID fields.
Interpret empty Code-Reject messages as RXJ+ rather than the more severe RXJ- FSM event.
Ignore received Protocol-Reject messages with length field less than 6.
Shut down LCP immediately after sending a PAP Authenicate-Nak.
Ignore received PAP Authenticate-Ack and Authenticate-Nak messages with mismatching ID fields.
1 June 1994, Karl Freeze version 1.4.1.
157 Morning Star PPP
Index
cisco Systems, 62 cnx500 router, 54 —A— compressed, 35, 47, 62, 141, 143, 146 ABORT, 15, 58, 117, 118, 133 compression, 34, 35, 42, 45, 46, 47, 57, 62, 141, active, 21, 57, 58, 97, 101, 132, 142, 146 143, 144, 148 ACU, 14, 19, 20, 21, 22, 48, 49, 113, 132, 135 CSU/DSU, 63, 114, 135, 140 Address and Control Field Compression, 46 CTS, 25, 26, 27, 28, 30, 32, 34, 36, 40, 44, 45 address assignment, 20, 57 Any Call Unit, 14, 48, 113 —D— Appletalk, 46 arguments, 20, 24, 49, 59, 114, 139 daemon, 13, 14, 16, 18, 24, 36, 51, 57, 62, 65, 66, ARP, 66, 67, 68 67, 68, 69, 79, 80, 96, 126, 127, 132, 137, 139, ARP table, 67, 68 140, 143, 145, 148 asynchronous, 25, 28, 42, 46, 48, 115, 135 data compression, 34, 35, 42, 45, 47, 62 Asynchronous Control Character Mapping, 61 DCD, 30, 45, 114, 140 asynchronous serial connection, 48 DCE, 25, 26, 27, 32, 34, 40 asyncmap, 36, 53, 139 debug, 115, 139, 145, 147 Auth, 22, 109, 110, 111, 115, 119, 128, 130, 136, debugging, 64, 118, 127, 132, 134, 147 147, 148 debugging verbosity level, 64, 147 authentication, 18, 22, 51, 57, 61, 100, 110, 111, dedicated, 12, 47, 48, 49, 63, 107, 114, 135, 136, 144 137, 140 auto, 14, 17, 19, 42, 48, 57, 58, 66, 67, 68, 69, 107, dedicated line, 12, 47, 49, 63, 107, 114, 135, 136, 137, 141, 147 137, 140 Autostart, 11, 13, 14, 48, 49, 51, 66, 67, 147 default, 18, 36, 42, 43, 45, 47, 49, 51, 57, 58, 62, 63, 64, 65, 66, 68, 69, 71, 72, 73, 82, 89, 90, 91, 92, 93, 94, 99, 102, 104, 106, 110, 114, 117, —B— 118, 120, 121, 122, 124, 127, 129, 132, 133, backquotes, 16, 22, 23 134, 135, 138, 139, 140, 141, 142, 143, 144, 145 bandwidth, 47, 100 destination address, 46, 74, 79, 111, 122, 129, 145 bidirectional, 42 device field, 48, 132, 133 binary, 35, 47, 141 Devices, 11, 12, 13, 14, 15, 19, 36, 37, 48, 49, 109, boot time, 15, 68 111, 113, 114, 115, 116, 119, 128, 130, 132, bps, 14, 15, 34, 35, 45 141, 147, 148 bringup, 17, 18, 72, 91, 92, 93, 94, 99, 104, 106, Dial Back, 70 121, 124, 125, 126, 127, 137, 146 dialer, 13, 15, 43, 48, 49, 113, 114, 115, 116, 132, Brixton Systems, 50 133 BrxPPP, 50 dialer field, 13, 48, 49, 116 Dialers, 11, 12, 13, 15, 42, 43, 44, 48, 49, 109, 111, 113, 115, 116, 118, 128, 130, 132, 136, 148 —C— Direct, 48, 49, 113, 115, 132 Cabling, 26 DNS, 20, 80, 85, 91, 93, 95, 97, 102, 105, 127, 145, call retry delay timer, 137 147 Carrier Detect, 21, 23, 26, 27, 28, 31, 32, 43, 48, DOS, 50, 52, 53, 54, 58 63, 114, 137, 140 dst, 79, 80, 95, 96, 99, 104, 106, 122 CCITT V.42, 35, 42 DTE, 14, 15, 25, 26, 27, 28, 30, 31, 32, 34, 40, 43, CCITT V.42bis, 42 45, 49, 134, 135 CD, 26, 27, 28, 31, 32, 43, 114, 140 du0, 17 chat script, 17, 21, 22, 23, 51, 54, 57, 62, 113, 116, 117, 131, 132, 133, 134, 143 —E— checksum, 74 chmod, 16, 17, 52 echolqm, 52, 54, 64, 142 chown, 17 encryption, 57, 84, 123, 129 cisco, 50, 62 error correction, 34, 35, 42, 64
158 Morning Star PPP
Ethernet, 53, 67, 68, 82 Interoperability, 50, 54 exec, 16, 18, 20, 22, 35, 51, 52, 54, 59, 61, 62, 92, ioctls, 108 100, 106, 115, 125, 139, 147, 148 IP, 13, 18, 19, 20, 22, 46, 48, 49, 50, 51, 53, 54, 57, executable, 16, 22, 35, 52, 115, 147, 148 59, 61, 62, 65, 66, 67, 68, 71, 73, 74, 76, 77, 78, 79, 81, 82, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 97, 99, 100, 102, 104, 106, 107, 108, 120, —F— 121, 124, 125, 126, 127, 130, 131, 132, 134, failover, 63, 136 136, 137, 139, 143, 144, 145, 146, 147 fast queue, 107 IP address, 13, 19, 20, 22, 53, 54, 57, 59, 62, 66, FCS, 114 67, 68, 71, 77, 78, 79, 86, 87, 88, 89, 90, 91, 92, Filter, 18, 70, 71, 73, 78, 89, 91, 92, 94, 97, 99, 93, 97, 100, 102, 108, 120, 121, 127, 131, 132, 101, 102, 104, 106, 109, 111, 115, 119, 120, 134, 136, 139, 143, 145, 147 122, 124, 126, 127, 128, 130, 136, 139, 145, IP options, 74, 81, 93, 124 147, 148 fin, 80, 85, 122, 146 —K— finger, 96, 104 flow control, 34, 36, 37, 38, 39, 41, 42, 44, 45, 61, KA9Q NOS PPP, 53 64, 114, 141 keepup, 18, 58, 72, 91, 92, 93, 97, 101, 106, 121, framing, 46, 61, 62, 139, 141, 143 124, 125, 127, 142, 146 ftp, 18, 22, 66, 83, 96, 102, 104, 105, 124, 126, 127 kernel, 107, 137 keys, 129, 130, 141, 145 —G— —L— gated, 65, 94, 97, 99, 101, 104, 105, 106 getty, 23, 52 LAN, 50, 54, 65, 66, 67, 68, 69 gettydefs, 52 LCP, 23, 46, 49, 52, 53, 54, 61, 64, 139, 141, 142 gid, 16, 147 Link Quality Monitoring, 49, 52, 61, 62, 63, 142 group, 16, 71, 87, 89, 147, 148 Link Quality Report, 46, 49, 63, 64 Livingston Portmaster, 54 local area network, 18, 65, 100 —H— log, 15, 17, 18, 19, 57, 64, 72, 80, 84, 85, 86, 90, hangup, 49, 61, 63, 137 91, 92, 93, 94, 97, 102, 104, 105, 106, 117, 121, hardware, 31, 36, 37, 38, 39, 42, 44, 46, 48, 50, 61, 122, 124, 125, 127, 129, 132, 133, 137, 138, 107 139, 140, 145, 146 HDLC, 35, 46, 61, 114, 141 log file, 17, 64, 72, 86, 91, 117, 121, 122, 127, 129, help, 12, 43, 57, 92, 135 132, 133, 139, 140, 145, 146 host names, 127, 136 login, 13, 14, 15, 16, 17, 18, 21, 22, 23, 49, 51, 52, hostname, 13, 16, 18, 19, 20, 48, 49, 52, 54, 58, 61, 53, 57, 58, 100, 106, 125, 143, 148 71, 90, 91, 92, 93, 102, 110, 111, 120, 121, 131, LQM, 48, 53, 62, 63, 64, 137, 139 132, 147 LQR, 63, 64 HP LanProbe, 50, 53 lqthreshold, 49, 63, 142 HPUX, 36 lsdev, 37
—I— —M— ICMP, 18, 73, 74, 77, 79, 83, 84, 94, 95, 96, 97, 98, major number, 37, 38 99, 100, 101, 104, 105, 106, 121, 122, 123, 126, manual pages, 13, 47 130, 145 maximum receive unit, 62 idle option, 58 mknod, 37, 38 idle timer, 14, 16, 53, 57, 58, 72, 97, 120, 121, 126, MNP4, 35, 64 127 MRU, 62 idle timer values, 58 MTU, 51, 62 IETF, 47, 148 in.rwhod, 18 —N— inbound, 11, 12, 13, 15, 18, 19, 37, 42, 52, 72, 74, 75, 76, 80, 85, 86, 87, 88, 89, 90, 94, 95, 96, 97, name/secret, 22, 111 99, 102, 104, 105, 107, 109, 122, 126 netmask, 65, 78, 143 installation, 20, 48 Network Time Protocol, 18, 97, 101, 105, 106 Internet, 50, 57, 61, 65, 66, 68, 69, 71, 74, 77, 86, Network Unreachable, 18, 84, 123 87, 94, 99, 103, 124, 137 NFS, 89, 125, 127
159 Morning Star PPP
NIS, 20, 66, 78, 93, 125 PPP_ORIG_NETMASK, 59 NNTP, 19, 95, 97, 105, 125, 126 PPP_ORIG_REMOTEADDR, 59 nolqm, 53, 54, 64, 142 PPP_REMOTEADDR, 59 Novell LAN WorkPlace, 50, 54 pppd, 11, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 36, 47, 48, 49, 50, 51, 52, 53, 54, 57, 58, 59, 61, 62, 63, 64, 65, 66, 67, 68, 69, 71, 90, 91, 94, —O— 99, 110, 111, 113, 114, 115, 116, 117, 119, 121, on demand, 23, 51, 94, 99 124, 127, 128, 129, 132, 133, 137, 138, 139, outbound, 11, 12, 13, 14, 15, 17, 18, 19, 37, 42, 57, 141, 143, 145, 146, 147 72, 74, 75, 76, 80, 83, 85, 86, 87, 88, 89, 90, 95, PPPHOME, 16, 52, 59, 61, 147 96, 97, 101, 105, 106, 107, 109, 114, 116, 122, Proteon cnx500 router, 54 126, 137, 141, 147, 148 Protocol Field Compression, 46, 141 proxyarp, 66 —P— proxytab, 66 Packet Filter, 70, 89, 104, 106, 120 —R— parity, 52, 117, 133 pass, 14, 18, 19, 46, 58, 72, 73, 74, 85, 86, 87, 88, rechap interval, 22, 144 89, 91, 92, 93, 94, 95, 97, 98, 99, 102, 103, 104, recv, 18, 19, 73, 80, 85, 87, 88, 89, 90, 94, 95, 96, 106, 121, 122, 124, 125, 126, 128, 142, 146 97, 99, 100, 104, 105, 106, 122, 124, 125, 127 passive, 53, 57, 58, 65, 142 register, 40, 41, 42, 43, 44 passwd, 13, 15, 16, 52, 147 rejected, 85, 91, 92, 93, 94, 97, 102, 104, 105, 106, password, 13, 14, 16, 21, 22, 49, 51, 100, 118, 134 122, 125, 146 PC/TCP, 50, 52, 53, 58 requireauth, 18, 24, 144 peer, 13, 14, 15, 16, 17, 22, 48, 49, 57, 58, 59, 61, requirechap, 144 62, 64, 71, 90, 94, 97, 99, 110, 111, 120, 121, requiremschap, 144 125, 126, 134, 137, 139, 140, 141, 142, 143, RFC, 46, 53, 62, 65, 67, 74, 75, 76, 77, 78, 79, 81, 144, 145 83, 96, 100, 107, 110, 111, 119, 124, 128, 141, peer host, 61 142, 143, 144, 148 ping, 74, 97, 105 RFC 1055, 107, 128, 141, 148 Point Of Presence, 69 RFC 1058, 65 POP, 50, 69 RFC 1144, 46, 62, 143, 148 ports, 20, 24, 31, 38, 39, 40, 65, 67, 78, 79, 86, 87, RFC 1333, 148 88, 89, 97, 122, 137 RFC 1334, 110, 111, 144, 148 PPP, 11, 12, 13, 14, 15, 16, 17, 18, 19, 21, 22, 24, RFC 1661, 107, 111, 128, 142, 148 25, 34, 35, 36, 42, 43, 45, 46, 47, 48, 49, 50, 51, RIP, 19, 65, 94, 99, 101, 104, 105, 106 52, 53, 54, 57, 58, 59, 61, 62, 64, 65, 66, 67, 68, rlogin, 46, 107 69, 70, 71, 94, 99, 102, 107, 110, 111, 113, 114, root, 16, 17, 37, 38, 59, 110, 115, 130, 148 115, 116, 118, 120, 124, 126, 129, 130, 131, routed, 19, 65, 82, 83, 94, 97, 99, 101, 104, 105, 132, 135, 136, 137, 138, 139, 140, 141, 142, 106 143, 144, 147, 148 router, 48, 54, 74, 76, 79, 120 PPP Link Compression, 47 routing, 18, 19, 65, 68, 69, 71, 74, 97, 100, 103, ppp.Auth, 109, 110, 115, 119, 128, 130, 136, 148 125 ppp.Devices, 109, 111, 113, 119, 128, 130, 148 ppp.Dialers, 43, 109, 111, 115, 116, 128, 130, 136, —S— 148 ppp.Filter, 109, 111, 115, 119, 120, 130, 136, 145, SCO TCP/IP, 53 148 SecureID, 22, 23, 70 ppp.Keys, 109, 111, 115, 119, 128, 129, 136, 141, Security, 57, 59, 70, 71, 73, 82, 88, 89, 90, 91, 92, 145, 148 93, 120, 124, 148 ppp.Systems, 20, 21, 109, 111, 115, 119, 128, 130, send, 14, 15, 18, 21, 23, 24, 45, 49, 54, 57, 63, 64, 131, 143, 148 67, 73, 75, 80, 83, 84, 85, 86, 87, 88, 89, 90, 93, PPP_ACCTFILE, 59 94, 95, 96, 97, 99, 101, 104, 105, 106, 108, 116, PPP_AUTHNAME, 59 117, 118, 122, 123, 125, 127, 128, 133, 134, PPP_COMMANDLINE, 59 135, 142 PPP_DEVICE, 59 sendmail, 61 PPP_INTERFACE, 59 serial ports, 20, 24, 31, 38, 39, 40, 65, 67, 137 PPP_LOCALADDR, 59 shell script, 13, 16, 22, 51, 52, 59, 61, 65, 67, 115, PPP_LOGFILE, 59 147 PPP_NETMASK, 59 SIGHUP, 21, 132, 146 PPP_ORIG_LOCALADDR, 59 SIGINT, 146
160 Morning Star PPP
SIGKILL, 146 Telebit T1600, 43, 44 SIGTERM, 146 Telebit T3000, 21 SIGUSR1, 147 telnet, 17, 18, 79, 80, 85, 90, 96, 104, 107, 122, SIGUSR2, 147 124, 125, 126, 127, 132, 133, 141 SLIP, 19, 47, 50, 51, 52, 53, 61, 62, 69, 71, 82, 94, terminal server, 19, 50, 54, 62, 120 99, 107, 130, 137, 141, 142, 143, 148 TIMEOUT, 15, 21, 58, 91, 117, 118, 119, 133, 142 SLIP framing, 61, 62, 143 trace, 82, 84, 85, 122, 124, 127 SMTP, 78, 80, 95, 97, 105, 126, 130, 146 traceroute, 96, 97, 105 Soft Addresses, 19 tunnel device, 107, 109 source address, 83, 89, 122, 145 tunnel driver, 107, 137, 146 speed, 13, 14, 15, 24, 34, 35, 42, 43, 46, 47, 48, 49, 64, 113, 115, 116, 132, 137, 140 speed field, 13, 113, 132 —U— src, 79, 80, 95, 99, 104, 106, 122 uid, 16 stty, 16, 52, 54, 61, 147 unreach, 83, 94, 95, 96, 99, 100, 104, 106, 122 suid, 16, 59 Usenet, 95, 125 supdup, 125 UUCP, 15, 42, 43 superuser, 108 support, 12, 26, 35, 36, 38, 42, 43, 47, 61, 70, 71, 82, 107, 114, 140 —V— syn, 17, 18, 19, 80, 83, 85, 90, 95, 96, 97, 104, 105, V.32, 135 122, 124, 125, 127, 128, 146 V.42bis, 35, 42, 47, 135 synchronous, 25, 47, 48, 57, 113, 114, 115, 127, Van Jacobson, 35, 46, 47, 62, 143, 148 140 verbosity, 64, 139, 145, 147 Systems, 11, 12, 13, 14, 15, 17, 19, 20, 21, 22, 23, vjcomp, 62, 141, 143 48, 49, 50, 51, 57, 62, 111, 113, 115, 116, 119, vjslots, 47, 141, 143 127, 128, 130, 131, 132, 135, 136, 137, 143, 147, 148 —W— —T— World Wide Web, 96 WWW, 96, 97, 105 talk, 36, 52, 53, 79, 135 tar, 22, 65 TCP, 18, 19, 35, 46, 47, 50, 52, 53, 58, 62, 73, 74, —X— 75, 76, 78, 79, 80, 84, 90, 95, 96, 97, 100, 102, xonxoff, 36, 114, 141 105, 107, 121, 122, 123, 125, 127, 128, 130, xprompt, 22, 23 135, 137, 141, 143, 145, 146, 148 Xyplex Terminal Servers, 55 TCP/IP, 18, 46, 53, 76, 137
161