Update for Look Communications

(Linux Kernel version 2.2.14 and pppd version 2.3.11)

[Back]

There have been some changes to the Internet Direct service since they have been bought out by Look Communications. Phone numbers have changed, and so has the PPP service. It appears that it is all in an effort to get customers on their satellite service. Since they do not offer tech support to Linux users (they never have in the past, but at least Charles Pham had his web page, which was helpful), they are pretty much left in the dark as to whether satellite service is really ready for Linux. Apart from that, if you are like me, you are a kind of luddite to whom speed is not really a concern.

In one of my web contracts, it became necessary to configure PPP at my home in order to do my work. I found that once again I had to go up the proverbial learning curve with PAP authentication, something I never bothered myself with before (maybe I should have), and new chat scripts and so on. In addition, I have this strange machine that was pre-configured for me, so diddling with network protocols on a machine that is otherwise functioning fine was not my idea of fun, since it was paramount that nothing be broken on it. But there was work to do, and it wasn't going to be done if PPP wasn't up and running. So...

While pppd has always been kernel version-dependent, there have also been changes in the way ISPs handle logins. PAP authentication (less common is CHAP), or "Password Authentication Protocol" is a secure means by which a password is sent over to your ISP, since your password is kept in a "secrets" file that is only readable and writeable by root. Internet Direct still allows for a text based login, depending on how your pppd command was entered.

Changes to files

I was stuck with a RedHat 6.2 system (which actually isn't that bad). There are a number of files I had to change besides /usr/local/bin/ppp-on and /etc/ppp/options and the like. There was also:
/etc/resolv.conf
/etc/syslog.conf
/usr/local/bin/ppp-on
/usr/local/bin/ppp-off
/etc/ppp/pap-secrets
/etc/ppp/options

/etc/resolv.conf
resolv.conf was changed to:

domain idirect.com
search idirect.com
#HOOBER
# search hoober.com
nameserver 207.136.65.24
nameserver 199.166.254.254
nameserver 199.166.254.9
#HOOBER
# nameserver 204.121.251.1
Note what was done to commenting out the nameservers from where I worked. "hoober.com" is a fictitious name, but you get the point. All nameservers at my home (since I am not sure how you could have much of a name server over a ppp line on a local machine) point to idirect.com, including the "domain" statement and the "search" statement. Since I run four network devices on my local machine (vmware/vmnet, ppp0, eth0, and loopback) I was a little nervous as to how this would pan out. But it was fine, and right now I am editing this web page from my vmnet connection (Windows NT4 in a sandbox over Linux) with PPP up and full net access. Hell, even my database still works.

Debugging PPP

Here is a change I made to syslog.conf:
*.info;mail.none;news.none;authpriv.none;daemon.debug;local2.debug 
      /var/log/messages
Note that this is all supposed to be on the same line of text. The text is divided here into two lines for readability. The change I made to that line in syslog.conf was to add "daemon.debug;local2.debug". The effect of this statement was to redirect all ppp debugging messages to /var/log/messages. As I have said elsewhere on these pages, it is important to keep track of debugging information while testing your ppp connection. Linux has a command called tail that can track messages sent to a log file in real time. A log file is a plain text file where messages are sent which bears a transcript of all messages from a process like pppd. Now, readers of earlier versions of my document may recall (it is still up on one of my webpages) the statement
tail -f /var/log/messages
which I was so much a fan of. Back then I was using a clunky 486 which made the use of tty's more feasible. Now that I am using a Dell Pentium III 700 MHz computer, I make much more use of X-Windows than in the past :-)

Since I am a frequent user and a fan of FVWM2, I have a Button Bar (FvwmButtons) with the system log (/var/log/messages) constantly running, no matter what I am doing. So it is convenient for me to simply chuck all the ppp stuff in the same file so I can monitor it in real time. If you are also running fvwm2, the command that "swallows" an xterm (or an rxvt terminal in this case) would be something like:
 

*FvwmButtons(8x1, Title "System Messages", Swallow(UseOld) "messages" \
     'Exec rxvt -T messages -n messages -fn fixed -e tail -f /var/log/messages &')
... in the section where there would be information on FvwmButtons. This statement would be found either in you home .fvwm2rc file or on the system.fvwm2rc file. Besides this there are other window managers that have button bars that can swallow applications.

And if you don't know what any of this is about, then not to worry. Just go to an xterm window and issue this command, and you can also have a constant monitor:

tail -f /var/log/messages

Keeping books: Another aid to debugging:

There are some software engineers out there that swear by (and sometimes at) keeping good notes. On the one hand you would like to keep notes detailed enough so that when you screw up, you can backtrack. On the other hand, detailed notes are also a good thing to have if something goes right, and you would like to reproduce the same situation another time on another computer. All computers are different, and you never know what it is you did that makes something work and something else not work. However, your effectiveness as a configurator is only going to be as good as the quality of your notes.

And finally, the source code:

Please take note that they are not by any means to be considered model scripts. ppp-on, for instance, does not make use of ppp-on-dialer. This can be seen as better efficiency, or as the breaking of conventions. The chat command, as you can see is included in the pppd command in its entirety. It is so short that I thought I may include it right here:

/usr/local/bin/ppp-on

These scripts are generated by GNU enscript 1.6.1.


#! /bin/bash

# A *real* makeshilft ppp-on script -- but it works!
# This script *requires* PAP authentication from the ISP.
# This script does not make use of /etc/ppp/ppp-on-dialer.
#
# By Paul King

# DEBUG='debug'
DEBUG=''
USERPPP=pking


# Get rid of the ethernet gateway (it is reset in ppp-off)
/sbin/route del default 2>> /dev/null

# set up the ppp connection
/usr/sbin/pppd connect          \
    '/usr/sbin/chat TIMEOUT 45 "" ATDT4166400481 CONNECT "\c"'  \
    /dev/ttyS1 115200 $DEBUG user $USERPPP &

/usr/local/bin/ppp-off

The only change I made to this file was to add the text
route add default gw 192.168.1.1 eth0
to the file listed here. It stands out, because it is one of the few lines not coloured.
#!/bin/sh
######################################################################
#
# Determine the device to be terminated.
#
if [ "$1" = "" ]; then
        DEVICE=ppp0
else
        DEVICE=$1
fi

######################################################################
#
# If the ppp0 pid file is present then the program is running. Stop it.
if [ -r /var/run/$DEVICE.pid ]; then
        kill -INT `cat /var/run/$DEVICE.pid`
#
# If the kill did not work then there is no process running for this
# pid. It may also mean that the lock file will be left. You may wish
# to delete the lock file at the same time.
        if [ ! "$?" = "0" ]; then
                rm -f /var/run/$DEVICE.pid
                echo "ERROR: Removed stale pid file"
                exit 1
        fi
#
# Success. Let pppd clean up its own junk.
        echo "PPP link to $DEVICE terminated."
        route add default gw 192.168.1.1 eth0
        exit 0
fi
#
# The ppp process is not running for ppp0
echo "ERROR: PPP link is not active on $DEVICE"
exit 1

/etc/ppp/pap-secrets

As I had said, ppp-on relies on a file called "pap-secrets", located under /etc/ppp. This is a "secrets" file which contains information about usernames and passwords, as well as the server names of the machines they can log into. The 4-column format goes something like:  

clientusername servername secret IP_address
iampedantic snoopy pork_rules 172.16.195.8
idontcare * kalium19 *
clientusername is the username on the ISP's account.
servername is the name of the ISP's server.
secret is the password you give to your ISP to log on to it.
IP_address is the IP address that you'll be assigned by the remote system. You are likely not to know what this is ahead of time.

The second row of the above table assigns the server "snoopy" to the username "iampedantic". When iampedantic logs in, he does so with the password "pork_rules", and expects his machine to be assigned the IP number 172.16.195.8, thereby identifying it to the internet.

The third row of the table allows the ISP to assign any server to user idontcare, who logs in with username kalium19. idontcare then waits for any IP address to be assigned to him. This will lead to the same outcome, his ability to be seen in the internet.

The entire content of pap-secrets consists of lines as written above. If you only have one ISP account, then it is likely your file will only consist of a single entry.


lock
crtscts
noauth
defaultroute
asyncmap 0xa0000

So here, we not only want the modem locked, but we want to assume no authentication (having already pre-determined the authentication method already in our setups and scripts), and also wanting pppd to set up its own default route without my having to type it in each time I log on.

Colophon/Acknowledgements for this update

This is about 95% of what I had to do ti get this thing going. This is not without many sources of information available to me. You would do good to take advantage of these sources. First, there is the HOWTO offered freely by W. G. Unruh at the University of British Columbia. He had also helped me out with some of my connection problems on the newsgroup comp.protocols.ppp, as had James Carlson. Some help was provided by Roderick W. Smith from his book Linux: Networking for Your Office (SAMS Publishing, ISBN 0-672-31792-3). It is also my understanding that he, too, frequents the newsgroups, and you just might find him answering a question of yours.

since Apr 1 2007