PPP Setup Notes

Rolling with the changes...

Please note that I am no longer with the service provider that prompted this page. My commentary reflects the frustration of dealing with unannounced and unanticipated changes while receiving the run-around from Tech Support. Fortunately, I have found another provider and am pleased with their service.

First of all, thanks to John Goerzen for giving this page a link from the Air Capital Linux Users Group homepage! On this page are various scenarios that I've worked through with my PPP connection to netspaceonline.com/midusa.net through their Wichita node. I recommend setting up for a first time connection using Scenarios 1, 2, 3, and 4 and then modify Scenario 1 per Scenario 6. This is the current working configuration for me. The sample files and file locations/permissions are based on Slackware '96. On to the info...

When a person sets up a PPP link, usually it's a done deal once the chat script is debugged and the link is working normally. However, a person may wind up signing up for service only to find occasional and annoying changes to the login process in such a way that the chat script must be changed. Weird, I know, but the following is true. The curious thing is that in all these scenarios, Windows '95 continued to login (I assume it was able to detect the need for PAP automatically) even when the shell login procedure was changed dramatically (I'm betting that with the way I'm set up now per Scenario 6, PAP only login obviates the need to detect the various text prompts). Why these changes were made, or if they are even intentional, are unknown to me.

Without further adieu, I present...

Page index

Using Linux with PPP

One of the first things a new Linux user wishes to try is connecting his or her new box to the Internet. In and of itself, PPP is not terribly complicated, but there are some strange twists the road can take, particularly if strange things occur to hinder the login process (honest!). In this section I will give a number of examples of how the pppd package can be configured based on actual experience with my current ISP.


Scenario 1 -- The simple login

I'll call this the simple login since it really amounts to not much more than editing the various script files installed with the pppd(8) package. The first file you need to edit is /usr/sbin/ppp-on (you will need to be root to do this). I've marked in emphasized text that information you'll need to change for your setup. I strongly recommend you get a copy of the PPP-HOWTO and use my notes to help you with that.



# Script to initiate a ppp connection. This is the first part of the
# pair of scripts. This is not a secure pair of scripts as the codes
# are visible with the 'ps' command. However, it is simple.

# These are the parameters. Change as needed.
TELEPHONE=555-1212	# The telephone number for the connection
ACCOUNT=george		# The account name for logon (as in 'George Burns')
PASSWORD=gracie		# The password for this account (and 'Gracie Allen')
LOCAL_IP= 	# Local IP address if known. Dynamic =
REMOTE_IP= 	# Remote IP address if desired. Normally
NETMASK= 	# The proper netmask if needed

# Export them so that they will be available at 'ppp-on-dialer' time.

# This is the location of the script which dials the phone and logs
# in. Please use the absolute file name as the $PATH variable is not
# used on the connect option. (To do so on a 'root' account would be
# a security hole so don't ask.)


# Initiate the connection

# I put most of the common options on this command. Please, don't
# forget the 'lock' option or some programs such as mgetty will not
# work. The asyncmap and escape will permit the PPP link to work with
# a telnet or rlogin connection. You are welcome to make any changes
# as desired. Don't use the 'defaultroute' option if you currently
# have a default route to an ethernet gateway.

exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS2 115200 \
	asyncmap 20A0000 escape FF kdebug 4 $LOCAL_IP:$REMOTE_IP \
	noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT

This is essentially the same file distributed with the pppd(8) package. At the bottom on the exec command line, I edited the device my modem resides on and the default speed I use for a 33.6 kbps modem. Next we may need to edit /etc/ppp/ppp-on-dialer, the script file which the chat(8) program uses.



# This is part 2 of the ppp-on script. It will perform the connection
# protocol for the desired connection.

exec chat -v					\
	TIMEOUT  3				\
	ABORT  '\nBUSY\r'			\
	ABORT  '\nNO ANSWER\r'			\
	ABORT  '\nRINGING\r\n\r\nRINGING\r'	\
	''	\rATZ1				\
	'OK-+++\c-OK' ATH0			\
	TIMEOUT  30				\
	CONNECT  ''				\
	sername:--sername: $ACCOUNT		\
	assword: $PASSWORD			\
	chita  'ppp default'

Again, there isn't much here you'll need to change. I show the last line in red as it demonstrates how additional prompts can be added to the chat script. My ISP would send a string "Wichita> " after the password at which point the string "ppp default" would need to be entered for the server to exit the login shell and begin the PPP link negotiation. The \ at the end of each line is a continuation character that causes chat(8) to process the commands as one string on the commandline. A tab is required at the beginning of each line.

The Slackware distribution typically has the files in the right places with the correct permissions. You may need to change permissions on your modem device, but I doubt it as pppd(8) runs suid root.


Scenario 2 -- It gets complicated

This collection of files is based on my experience back around January 21, 1998 with my current ISP after I could no longer log into the server through Linux but could through Windows 95. After a bit of head scratching, name calling, a call to the ISP's tech support (no help), muttering, questioning the ancestry of certain sysadmins, and just in general getting into a bad mood, I started looking through the system log files (and you wonder why they exist?). The key ended up being a couple of lines in the /var/log/debug file. Thanks to the way Slackware '96 has the syslogd(8) facility setup, the PPP link negotiation packets are recorded to this file each time PPP is started.


...: sent [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x20a0000> <magic 0x3fe1c95> <pcomp> <accomp>]
...: rcvd [LCP ConfReq id=0x49 <asyncmap 0xa0000> <auth pap> <magic 0x49a80151> <pcomp> <accomp>]

After finding the text in red to be new to the line sent by the server compared to the last time I logged in, I had to figure out how to configure pppd(8) to respond using Password Authentication Protocol (PAP). Going through the PPP-HOWTO pointed me in the right direction. I ended up creating two new files for this purpose, /etc/ppp/pap-secrets and /etc/ppp/options. The pap-secrets file is well documented in the PPP-HOWTO and is easy to write. Using the username and password from Scenario 1 above, here is how it would appear:


# Secrets for authentication using PAP
# client  server  secret   IP addresses
george    *    gracie

That's all there is to it! While the comments indicate an IP address can be placed on the line as well, for dynamic IP assignment it isn't used. Replace george with your username and gracie with your password. Root should own the file and the permissions should be set to read and write for root only (chmod 0700).


# Set the name of the local system for authentication purposes to <n>.
# This will probably have to be set to your ISP user name if you are
# using PAP/CHAP.
name george


This is simply a fragment of /etc/ppp/options as the complete file can be copied and pasted out of the PPP-HOWTO. Just using this fragment should allow you to use PAP.

After adding these two files I restarted pppd(8) and was rewarded with a working PPP link until...


Scenario 3 -- A curve ball!

The third chapter of my ongoing saga with my ISP's login authentication monkey business has been the most interesting (and frustrating). The whole thing manifested itself Wednesday evening, March 18, 1998. I had logged in early that morning, read mail, checked out a couple of web sites, etc. and went to work. Later that evening I came home tried to login and it failed. During prime time this wasn't uncommon to get busy signals, but I thought I'd heard a carrier from the modem. I tried again and again it failed. So, off to the log file I go expecting to see some other kind of authentication (there are at least three, probably more). Instead there was no line that came from the server. Thinking that things like that were rather odd, I called tech support (mistake #1) and was told a major crash had taken place and that the techs were in the process of restoring things. So I let it go.

Thursday morning nothing had changed, so Thursday eve when things still weren't working I tried Windows '95 and I logged right in. Something was amiss. More calls to tech support did nothing but raise my blood pressure for about 24 hours, so by Friday evening I decided it was probably time to upgrade pppd to version 2.3.3 as I was guessing the ISP may be using some Microsoft version of PPP authentication (there exists one, honest!). To make a long story short I compiled and installed pppd 2.3.3 with libdes encryption capability and tried a number of configurations by Saturday noon, all to no avail.

A couple of things were happening, after chat sent my password and was waiting for the Wichita> prompt, I noticed the server sending a string of "% Access denied". I talked to tech support Thursday evening and he couldn't explain that prompt as he could login as me. After talking to him I tried Windows '95 and it worked. I then tried using Procomm just see if I would receive the same error as I was under Linux, and I did.

So, I did have two positive things going for me. In researching the problem and watching the login sequence I noticed the Wichita> prompt had been removed. So I commented that line out in /etc/ppp/ppp-on-dialer and removed the \ from the end of the line above it so that the last two lines of the file now look like this:


	assword: $PASSWORD
#	chita  'ppp default'

The second positive thing was that Windows '95 Dialup Networking was able to login just fine. So I at least had 'Net access. However this was truly puzzling, since I was sure that anything Windows could do, Linux had probably already been made to do better. So Google Groups (DejaNews back in the day) to the rescue. Browsing the comp.protocols.ppp newsgroup in DejaNews revealed the following post from Tuesday March 17, 1998 (nice timing, huh?):

Subject:      solution of a Linux to Windows NT PPP problem
From:         Erik Rossen <rossen@dgcdec1.epfl.ch>
Date:         1998/03/17
Message-ID:   <350ED323.23265C60@dgcdec1.epfl.ch>
Newsgroups:   comp.protocols.ppp

[Subscribe to comp.protocols.ppp]
[More Headers]

To whom it may concern:

Have you been having trouble connecting to your Windows NT-based ISP
from your Linux box using the usual scripts that come with pppd?

Do you get the following symptoms?
1.  Chat script works and you get a proper serial connection.  Yes
2.  Many (about 8 to 10) LCPs sent from your Linux box to the ISP.  Yes
3.  No response AT ALL from the ISP.  Yes
4.  pppd aborts.  Yes
5.  Chats scripts, ppp-on, and pppd all worked with your previous(/current)ISP.  Yes

HERE IS A POSSIBLE FIX: remove any escape settings from your list of
pppd options and set asyncmap to 0.

In my new ppp-on script I start pppd with the following:

exec /usr/sbin/pppd name $ACCOUNT remotename $REMOTE debug lock modem crtscts \
	/dev/ttyS2 38400 asyncmap 0 kdebug 0 $LOCAL_IP:$REMOTE_IP \
	noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT

My old way to start pppd from ppp-on was something like the following.
This comes from the ppp-on provided with the pppd package and it worked
just fine with my last ISP, but I bet they were not NT-based.

exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS2 38400 \
	asyncmap 20A0000 escape FF kdebug 0 $LOCAL_IP:$REMOTE_IP \
	noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT

The most important difference is the asyncmap 0 and the total lack of
escape codes.  Another difference is that the new ppp-on script uses
CHAP or PAP directly and the old script had the login sequence built

Why does this work?  I have a theory but feel free to correct me if you
know it is wrong.  Some Windows NT/95 PPP programs (at least Shiva PPP)
can be set up to constantly have a PPP connection ready, you just simply
have to go through the auth procedure (PAP, CHAP, MSCHAP, whatever), BUT
CODES FOR ESCAPING.  When you start pppd, the very first LCP that it
sends has FF as its second byte.  If you have set escape FF, that byte
gets translated into a two-byte combination and the ISP can't recognize
recognize the rest of the packet as a LCP since it doesn't know that you
are using escape codes!

By the way, I found all of this out by null-modeming my usual modem port
to a another port where I had a TERMINAL.EXE session running (under
Windows 3.1) and looking at what my pre-configured dialer was sending to
the port.  The dialer was called IEDIAL.EXE and it had a connection
parameter file that worked perfectly for calling the ISP and using
Internet Explorer 3.01, but who wants to do that? :-)  It was necessary
to type modem responses like "OK" and "CONNECT" to get the dialer to go
through its paces.  I saw something bizarre and I am curious to know why
it was there.

The first LCP sent to the modem was something like the following:

~ÿ}#À!},} } 7} } } } ShivaPPP dial-in driver version 4.1M3 (960911)} Z½~

Why the hell was it necessary to send the name of the PPP software???

Below is a bit of mail from the first person I found who mentioned that
they had a problem similar to mine.

I hope this helps, Brian!


 > From: Charles Brian Hill
 > To: Erik Rossen
 > Subject: Re: Did you ever find your answer to the PPP problem?
 > Erik Rossen wrote:
 > >
 > > Hi, Brian,
 > > I am dying to know if you ever found a solution to your Linux-NT PPP problem
 > because I am going through EXACTLY the same thing with my new provider right
 > now.
 > Unfortunately, I have no good news to give you.  I am in a situation
 > where I don't have any access to the NT server's logs, so I can't tell
 > what's going on.  In addition, the people on the other end (the ones
 > with the NT box) are not extremely skilled and generally don't know what
 > they are doing.
 > The suggestion I have heard from others is "look at the logs on the NT
 > server."
 > If you find out what's happening, though, let me know!
 > -Brian
 > --
 > Charles Brian Hill
 > brian@hillman.org

So, with nothing else to lose and my Linux connectivity to gain (short of another ISP) I took Erik's suggestion and modified my /usr/sbin/ppp-on script as follows:


exec /usr/sbin/pppd debug lock modem crtscts /dev/cua2 115200 \
    asyncmap 0 kdebug 0 $LOCAL_IP:$REMOTE_IP \
    oipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT

If you compare this with my /usr/sbin/ppp-on example from Scenario 1, you'll see that I changed asyncmap to 0 and removed escape FF from the command line entirely. So I tried starting PPP one more time. Success!!! I once again had a working PPP connection from my Linux box.

What really made this an interesting problem was that two variables were changed at once, the removal of the Wichita> prompt and apparently the support of escaped characters. Wow!

BTW, tech support claimed that nothing had been changed with the login procedures. If you were running Windows '95, you'd agree...


Scenario 4 -- It gets weird

Well, for about three months all worked well with my PPP login. I guess I was getting complacent because I came home from work only to find that I was unable to login once more. A look through /var/log/syslog revealed the following lines:

linux modprobe: Can't locate module ppp-compress-21
linux modprobe: Can't locate module ppp-compress-24


I did some checking of my kernel compile options and found I was compiling PPP header compression as a module. A recompile of the kernel wouldn't have helped as PPP header compression will only work as a module. I opted to add the following lines to /etc/modules.conf:


alias ppp-compress-21 bsd_comp
alias ppp-compress-24 bsd_comp

Amazingly, I was once more able to login and my PPP connection seemed to run a bit faster now.


Scenario 5 -- Back to basics

After a few days out of town due to work, I get back in the evening of June 28, 1998 only to find that I can't login with Linux (is this starting to sound familiar?). I do a bit of tinkering around after looking in the various log files and nothing seems to work, so I restart into Windows '95 (yeah, I should have dumped it a loonnnngggg time ago, but it's handy now as an alternative login platform :-( ) and it works (no surprise). Monday, I decide to look a bit deeper and I look through the comp.protocols.ppp newsgroup in Google Groups (formerly DejaNews) looking for a hint. I do see one, a reminder that if pppd complains about the link not being 8 bit clean, then the remote server has not terminated the login shell and started its ppp process. So, I reboot into Linux and decide to play with /etc/ppp/ppp-on-dialer which controls the chat(8) dialing script. I added the line I had commented out back in Scenario 2 so that my last few lines looked like this:


	sername:--sername:  $ACCOUNT		\
	assword:  $PASSWORD			\
	chita  'ppp default'

I figured this would at least keep chat alive long enough so that maybe I could catch some clue as to what was happening. However, to my surprise I was greeted with a working PPP connection again. Go figure, this prompt was added in again. This is a bit amusing as my ISP's connection instructions for Trumpet Winsock and other PPP winsocks don't mention this extra prompt anymore...

In troubleshooting these problems I use a handy little utility called tail that I use in an alias I have setup in root's .bash_profile:

alias ppst='tail -f /var/log/messages'

This allows me to watch the output of chat as it runs the script.


Scenario 6 -- PAP only

Okay, one should not fight Fate, however, it has gotten to the point that I stick around just to see what'll happen next! Friday August 21, 1998, one of those long days with plans to get out of town for a couple of days. Well, work dictated that I work overtime and when I got home I was in a hurry and just wanted to get my email and get on the road. I started ppp as usual and this time the modem disconnected shortly after connecting. A quick look into /var/log/debug revealed the following cryptic line:

Aug 21 16:59:04 linux pppd[1110]: rcvd [PAP AuthNak id=0x1 "User: XXXXXXXX already logged onto system 1 time(s). \n\r"]

Huh? Well, I did recall the ppp link seemed to have terminated the link a bit weird that morning, so I put a call into the ISP's Tech Support (when will I learn?) thinking that somehow I was never logged out of the server. In about a half-hour a tech called and reported he couldn't see me as currently logged in to the system, so I thanked him and left for the weekend.

Sunday evening I returned and tried again only to get the same error again. Once again I boot into Windows '95 and tried logging in. You guessed it, worked the first time. So, I boot into Linux and start playing. I tried commenting out the name option in /etc/ppp/options and found that the modem hung up quicker than before! Examining /var/log/debug revealed the following:

Aug 23 20:00:18 linux pppd[119]: rcvd [LCP ConfReq id=0x90 <asyncmap 0xa0000> <auth pap> <magic 0x34d5ce48> <pcomp> <accomp>]
Aug 23 20:00:18 linux pppd[119]: sent [LCP ConfRej id=0x90 <auth pap>]

Most of this isn't too human readable, but the LCP ConfRej indicated that my machine was refusing to authenticate using PAP and after about 4 tries the server terminated the link. So I had the following clues:

Dang Catch 22!

So, I tried something really radical. I edited /etc/ppp/ppp-on-dialer to eliminate the shell login as so:


#	sername:--sername:  $ACCOUNT		\
#	assword:  $PASSWORD			\
#	chita  'ppp default'

So now, the text login is bypassed entirely and upon connect the ppp negotiation begins without a text login.

Sometime between 6 AM and 4 PM August 26th, the extra text prompts disappeared from from the login process. Apparently the login has been made PAP only.



As I write this it is nearly a year an a half since the last problem (One should understand I am risking the wrath of Murphy by writing this) has occurred. I have been running with a PAP only login on my main desktop since August 1998. I recently started using Debian 2.1 on another machine and have it configured for PAP login as well. Interestingly, I setup Trumpet Winsock for another person on the same ISP and had to configure it as PAP only even though their online guide makes no mention of this requirement. So long as everything is working I am happy. However, having to work through the above scenarios, while frustrating, did much to improve my understanding of PPP and how important the syslogd logging facility is to resolving problems. If nothing else, I hope this page provides some insight on effectively using the logs and various debugging options of Linux tools to troubleshoot and solve problems.

Stay tuned...


Take me back to the Index!

The Linux Webring:
[ Prev | Next | Random | List | Home | Stats ]

Original content Copyright © 1997-2024 Nate Bargmann NØNB n0nb@n0nb.us
any other content copyright by respective author(s).

This page last modified
February 12, 2005
Valid XHTML 1.0! Valid CSS! Built with WSMake!