 |
Software Interest Group
The UA Math Department Software Interest Group (SWIG)
is a self-organized informal group, consisting of faculty members,
visitors, staff, and graduate students, whose goal is to promote and
advance computer and software literacy among the members of the department
through meetings, talks, and discussions.
|
 |
For more details, and talks in past semesters, consult the full schedule of talks.
Past topics can (and should) be repeated occasionally. In addition, here are some topics people might like to hear about:
To give a talk, please contact swig@math.arizona.edu.
This page describes a simple Linux PPP setup using Slirp on the remote end. Once you have PPP working, you can say goodbye to kermit, seyon, and minicom forever. You won't miss them, I promise. You can forget about sz and rz because you'll be able to ftp. You won't be doing ASCII graphics with gnuplot because you'll have X-Windows at home. You will also have netscape, allowing you to browse the 'net instead of watching a Beverly Hillbillies rerun. In fact, you will be able to do all of these things simultaneously over a single modem connection. Pretty fancy!
This dicussion is by no means complete; it is based on sources like:
In addition, the Linux PPP-FAQ and the Linux Network Administrator's Guide (NAG) can be quite helpful. Finally, the PPP scripts presented here are virtually identical to the ones in /usr/doc/ppp-2.2.0f-2.
The full set of scripts (tarred and gzipped) is available
To unpack the scripts (into a subdirectory called "slirp"), type
linux$ gzip -dc slirp.tgz | tar xvf -
This HTML file is included in slirp.tgz.
Once you have configured your software and hardware for PPP, using it is simple. Simply type:
ppp-on
This script will dial up CCIT, log in on a machine of your
choice, and start up Slirp. You will then be able to use netscape,
telnet, and ftp, etc. It takes less than a minute to establish a
PPP connection.
To terminate your PPP connection, issue the command
ppp-off
This will shut down networking and hang up your modem.
You should be aware that PPP is inherently slower, throughput-wise, than using dedicated communications software, which is why I recommend a 28.8 modem as a minimal configuration. The advantage is the ability to use the standard FTP/TELNET/etc programs simultaneously.
If you have a Unix account at the Math Department, you are all set on the remote side: slirp is installed on the departmental systems. If you intend to run slirp somewhere else, you will either have to compile it yourself or obtain precompiled binaries from the Slirp distribution sites. Slirp needs to have been compiled with PPP support (this is the default).
If you don't want to go through CCIT, you need to be aware that PPP requires that the link be 8 bit clean end to end. This means that both your modem and the remote modem must use 8 data bits. Any intermediate terminal hardware/software must be set to pass 8 bit data.
The configuration I will describe is based on the sample scripts supplied with the PPP distribution and instructions contained in the PPP-HOWTO, the Linux NAG, and the Serial-HOWTO.
I assume that you are trying to set up PPP on your Linux PC that lives at home (not connected to any other network), with only yourself, close friends, and family members using it. If this is your situation, then this setup may be appropriate.
This setup is not secure! The authors of the sample scripts state it, and so do I. You should not use this configuration unless you trust all local users of your Linux machine.
The HOWTOs describe more secure setups; however, their configuration can become considerably more complex than the one described here.
In order to use the PPP scripts described here, you must have a modem that uses the Hayes "AT" command set. If you do not have such a modem, you will have to roll your own scripts.
| NOTE: | If you have a modem advertised as supporting Rockwell's "RPI" protocol, or if you have a "WinModem", you're out of luck. Linux doesn't support RPI- or Win- modems and probably never will. |
You must have your modem set up as follows:
The easiest way to configure your Hayes-compatible modem is to start up kermit, minicom, seyon, or whatever and issue the appropriate commands. To check that command echo and verbal responses are working, issue the hangup command "ATH". If the command is echoed (i.e., you can see that you typed "ATH") and the modem responds with "OK", this part is all set.
Besides flow control, you must also configure your modem to make use of the RS-232 DTR and DCD signals. Instructions for setting all of this up should be in your modem's manual. The Linux Serial-HOWTO may also be of assistance.
| NOTE: | Do not assume that your modem's factory settings or hardware flow control templates will work. For many modems, this is not the case. If your modem manual says that "AT&C1" enables DCD, then issue the command by hand. |
Remember to save your modem settings into its non-volatile RAM and configure it to load these settings on power-up.
The main parameter you need to determine is the speed at which your modem and computer communicate. This is dictated by both your modem and your computer's serial hardware. To determine your computer's peak serial speed, have a look at your system's boot messages (usually in /var/adm/messages ot /var/log/messages). Look for a line like
tty00 at 0x03f8 (irq = 4) is a 16550A
The "16550A" is the important part: it means that you have a
high speed UART chip capable of 115200 bps. If you have an internal
modem, it should have the appropriate UART built in. If you have an
external modem, you will be using your computer's built-in serial
hardware. If you have a 16450 or 8250 UART, you need to upgrade to
a 16550A (or use an internal modem with a 16550A) before you can
get peak performance from your 28.8, 33.6, or 56k modem.
| NOTE: | In your boot messages, "tty00" corresponds to DOS' COM1:, "tty01" corresponds to COM2:, etc. |
To test the operation of various UART speeds, simply change the speed from within your communication software and issue the modem hangup command "ATH". As long as the command is echoed and you get the usual "OK" response, everything is working. Choose the highest speed that works.
| NOTE: | If your communications software does not have a 57600 or 115200 bps options, see the manpage for the setserial command. You'll probably want to use the spd_hi or spd_vhi option -- these options give you 57600 and 115200 respectively when you request 38400 bps. |
The simplest way to set up your serial port is with the stty command. Below is the command I use to set up my modem:
stty hupcl -clocal </dev/modem >/dev/null
This tells linux to hang up the modem when the last process
closes the modem device; it also sets up the port to use the
hardware modem control lines. The PPP daemon automatically takes
care of many other serial port parameters such as baud rate, number
of data bits, etc.
RedHat users can put this command in /etc/rc.d/rc.local; this way, every time your machine boots, your serial port will be properly configured. If you aren't running RedHat, you'll need to figure out where your rc.local lives.
If you are using a recent RedHat linux (4.0 or newer), this step should not be necessary: RedHat comes shipped with PPP enabled. PPP can either be compiled into the kernel or can be dynamically loaded as a kernel module. To check for a statically compiled PPP driver, have a look at your boot messages. If you don't see anything about a PPP driver, you need to look for a dynamic kernel module.
To check for a dynamically loaded module, issue the command:
ls /lib/modules/<kernel version>/net
Your kernel version is the output of the command
uname -r
You should see slhc.o and ppp.o (and probably a whole bunch of other .o files). If so, you're all set.
If you don't fall into either of these categories, you have some thinking and/or work to do. If you have the PPP daemon installed, you may just need to recompile your kernel with PPP support turned on. If this isn't the case, your best bet may be to get a recent set of Linux kernel sources and compile a new kernel (see the Kernel-HOWTO for details on the procedure). You will probably also need to obtain sources for and compile the PPP daemon pppd. If you are currently running kernel 1.2.x or 1.3.x, switching to 2.x may break a number of programs, including ps. You might consider upgrading your whole setup in such a case.
| NOTE: | If you are running Walnut Creek Linux '96 AKA Slackware 3.1, see the PPP-Linux FAQ. Linux '96 has a number of "features" that adversely affect PPP. |
| NOTE: |
If you are not running pppd version 2.2.0 or
better, you probably won't be able to get Van Jacobson IP
header compression. You can determine what version you
are running by typing:
linux$ /usr/sbin/pppd -xyzzy
VJ header compression can reduce the 40 byte IP packet header
down to 7 bytes. When you consider that every character you type in
a telnet session gets sent as an IP packet, it is clear that VJ
header compression is a big win.
|
Before setting up the ppp-on and ppp-off scripts, you need to configure the PPP daemon. In addition, you must decide which users are allowed to establish and terminate PPP connections.
The PPP daemon looks for a configuration file (usually /etc/ppp/options). The setup I am describing does not make use of this file; however, the file must exist or pppd will complain. Therefore, we will set up an empty options file:
linux$ su
Password:
linux# cd /etc/ppp
linux# mv options options.old
linux# touch options
linux# chmod 600 options
If you are running RedHat 4.2 or newer, you'll also want to disable RedHat's /etc/ppp/ip-up script:
linux$ mv /etc/ppp/ip-up /etc/ppp/ip-up.old
Now you must decide who is allowed to establish PPP connections.
| NOTE: | Once a PPP connection is established, any local user can make use of it with telnet, ftp, netscape, etc. |
If you only use the root account, you can skip this step. If you only want to allow certain users to establish PPP connections, see the PPP-HOWTO. You might want to consider such a setup if, for example, you want to control your children's use of the Internet.
In what follows, I assume that you want all local users to be able to establish and terminate PPP connections.
The PPP daemon, pppd, needs to make changes to your kernel's IP routing tables. Normal users are not allowed to do this, so you need to make pppd run as root. To do this, log in as (or su to) root and issue the following commands:
linux# cd /usr/sbin
linux# chown root pppd
linux# chmod 4755 pppd
Next, you need to grant all users access to your modem. To do
this, become root and
linux# chmod 666 /dev/modem
Once your PPP link is estabished, you will certainly want Domain Name Service (DNS). This service lets you do things like "telnet ame2" instead of the harder-to-remember "telnet 128.196.224.60". If you are going to use netscape from home, you must set up DNS. To configure DNS, add the following to your /etc/resolv.conf file:
search math.arizona.edu
nameserver 128.196.224.2
The first line says to append math.arizona.edu to every query. Without this line, "telnet ame2" won't work, but "telnet ame2.math.arizona.edu" will. The second line is the most important one: it tells your machine which machine knows how to resolve non-numerical addresses.
| NOTE: | If you find that you can telnet to machines by IP address but not name, /etc/resolv.conf is the place to look. |
| NOTE: |
If you are running RedHat 4.2 or later, you will want to
turn off named with:
linux$ rm -i /etc/rc.d/rc[35].d/S55named*
and reboot.
|
Finally, you need to set up the PPP scripts themselves. There are three scripts in all, but you will hopefully only need to modify one of them.
The flow among the scripts is as follows: the ppp-on script simply starts up the PPP daemon, pppd, with a bunch of options. One of these options gives the path to a script, ppp-on-dialer, that does the dialing, logs you in, and starts up Slirp.
The ppp-off script simply kills pppd. This causes pppd to shut down the connection, remove the IP routing entries, and hang up the modem.
Below is the ppp-on script. There are a number of parameters near the top of the script that you'll need to edit. Note that your departmental Unix password is stored in plaintext in this script. When the dialer script runs, your password is visible from the ps command. Anyone allowed to run this script can simply read it and determine your password. These are the primary reasons that this setup is not secure.
The first parameter to change is BAUDRATE -- set it to the UART speed you found above. The second parameter is HOST. This is the host you telnet to from the CCIT terminal server. ACCOUNT and PASSWORD are your username and password on HOST. The connect script will use these to log you in on HOST after the telnet command is sent.
| NOTE: | The default HOST ame2 is fine for departmental Sun system users. If you are on the undergraduate Linux system, you need to change HOST to lehi.math.arizona.edu. |
Finally, the connect script needs to be able to recognize your Unix prompt on HOST so that it will know when to start up slirp. The PROMPT parameter should contain some recognizable part of your shell prompt. For example, my initial prompt on ame2 is "ame2(1)$", so I set
PROMPT='$'
On another system, my initial prompt is "hays> ", and I
set
PROMPT='>'
Using a hostname is not a good idea because it may appear
during the login process before your prompt is issued. You should
be careful of characters that are interpreted by the shell in
special ways (parentheses, brackets, etc.). It is a good idea to
enclose PASSWORD and PROMPT in single (not double) quotes.
#!/bin/sh
########################################################################
# ppp-on:
#
# Script to initiate a ppp connection. This is the first part of
# a 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.
BAUDRATE=115200 # Serial port speed
HOST=ame2.math.arizona.edu # Host to connect to from CCIT
ACCOUNT='george' # The account name for logon (as in 'George Burns')
PASSWORD='gracie' # The password for this account (and 'Gracie Allen')
PROMPT='$' # Part of your shell prompt
MTU=296 # Maximum Transmission Unit -- tune for max throughput
MRU=296 # Maximum Receive Unit -- tune for max throughput
#
# Other parameters -- shouldn't need to change
MODEMDEV=/dev/modem # Modem device
TELEPHONE=6219600 # The telephone number for the connection
NETMASK=255.255.255.0 # The proper netmask if needed
#
# Export them so that they will be available at 'ppp-on-dialer' time.
export BAUDRATE TELEPHONE HOST PROMPT ACCOUNT PASSWORD
#
# 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.)
#
DIALER_SCRIPT=/etc/ppp/ppp-on-dialer
#
# 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. 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 \
$MODEMDEV \
$BAUDRATE \
asyncmap 0 \
connect $DIALER_SCRIPT \
crtscts \
defaultroute \
lock \
modem \
mru $MRU \
mtu $MTU \
netmask $NETMASK \
noipdefault
# EOF ppp-on
| NOTE: | If, for some reason, you cannot enable command echo and verbal responses on your modem, you will have to modify this chat script accordingly. You should read the PPP-HOWTO and the chat manpage. |
#!/bin/sh
########################################################################
# ppp-on-dialer:
#
# This is part 2 of the ppp-on script. It will perform the connection
# protocol for the desired connection.
#
PR=$PROMPT
exec /usr/sbin/chat \
TIMEOUT 3 \
ABORT '\nBUSY\r' \
ABORT '\nNO ANSWER\r' \
ABORT '\nRINGING\r\n\r\nRINGING\r' \
'' '\rAT' \
'OK-+++\c-OK' ATH0 \
TIMEOUT 60 \
OK ATDT$TELEPHONE \
CONNECT '' \
TIMEOUT 20 \
: "telnet $HOST" \
ogin:--ogin: $ACCOUNT \
assword: "$PASSWORD" \
"$PR--$PR" "exec slirplogin -P -b $BAUDRATE -as 0x0"
# EOF ppp-on-dialer
I can't think of any reason you'd need to modify this one.
#!/bin/sh
######################################################################
# ppp-off:
#
# This script terminates a PPP link
#
#
# 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."
exit 0
fi
#
# The ppp process is not running for ppp0
echo "ERROR: PPP link is not active on $DEVICE"
exit 1
# EOF ppp-off
Copy ppp-on and ppp-off into /usr/sbin or someplace else in your PATH (like /usr/bin). Copy ppp-on-dialer into /etc/ppp/. Make sure that all three scripts have execute permission set:
linux# chmod 755 /etc/ppp/ppp-on-dialer
linux# chmod 755 /usr/sbin/ppp-on
linux# chmod 755 /usr/sbin/ppp-off
If you do not install ppp-on and ppp-off in /usr/sbin, you
might want to remove or rename any existing /usr/sbin/ppp-on and
/usr/sbin/ppp-off scripts.
OK, now that everything is installed, it is time to try it out. To facilitiate debugging, we'll configure the syslog daemon to print pppd's diagnostic output to the console. This way, you can see what pppd is doing while dialing. Become root and add the following line to /etc/syslog.conf:
daemon.* /dev/console
| NOTE: | Those are tabs, not spaces. |
| NOTE: | Some older versions of pppd will require that you change "daemon.*" to "local2.*". |
Now you must restart syslogd with:
linux# kill -1 `cat /var/run/syslog.pid`
| NOTE: | Those are backquotes. |
Now start up X-Windows (as yourself, not root). Make sure you have an xconsole running so you can see PPP's startup messages. If you haven't rebooted, be sure and run the stty command to configure your serial port. Open a window and initiate a PPP conneciton:
linux$ ppp-on
You should immediately see some messages from pppd. If
everything works as planned, you should eventually see something
like "Connect: ppp0 <--> /dev/modem" followed by "local IP
address 10.0.2.15". If this is what you see, things are looking
good. Skip to the next section to test your DNS setup.
It is more common that it doesn't work the first time. If you get a "connect script failed" error, edit /etc/ppp/ppp-on-dialer and add a -v argument after "exec /usr/sbin/chat". This will cause the dialer script to emit detailed information (via syslog) about what it is sending and receiving. Hopefully this data will help you track down the problem.
| NOTE: | When you use "chat -v", your departmental password may end up in /var/log/messages, depending on your syslog setup! |
If the connection simply hangs, possible causes are that the connection is not 8 bit clean, or that software flow control is turned on somewhere. There are many other things that can go wrong -- the PPP-HOWTO covers these in detail. It is often helpful to simply watch your modem's Carrier Detect, Send Data, and Receive Data LEDs.
If you want to see what Slirp is up to, log in to your math account with minicom/seyon/whatever and create a .slirprc file (in your home directory) containing the following line:
log start
Then retry ppp-on. Log back in to math with minicom; slirp's
startup messages will be in the file .slirp_start. A healthy
.slirp_start looks something like:
Log started to /disk1/people/hays/.slirp_start
Setting VJ compression
Setting baudrate to 115200
IP address of Slirp host: 128.196.224.60
IP address of your DNS(s): 128.196.224.2, 192.12.69.5
Your address is 10.0.2.15
(or anything else you want)
Type five zeroes (0) to exit.
[talking PPP, 115200 baud]
SLiRP Ready ...
End log.
Once your PPP connection is up and running, you should test your DNS setup. First, try:
linux$ telnet ame2
If you get a login prompt, everything is ready to go. If not,
try:
linux$ telnet ame2.math.arizona.edu
If this works, check out the "search" line in your
/etc/resolv.conf. If not, try:
linux$ telnet 128.196.224.60
If you get a login prompt, something is amiss with your DNS
configuration -- have another look at your /etc/resolv.conf. If you
do not get a login prompt, something else is wrong -- see the
troubleshooting section of the PPP-HOWTO for more suggestions.
At this point, you should be able to start netscape up on your Linux machine (after downloading it via FTP and installing it, of course) and point it to the departmental home page, or anywhere else on the 'net, for that matter. You can also telnet and ftp to your favorite sites.
| NOTE: | The programs rsh and rlogin will not work over a slirp link. Telnet works fine, though. |
Once you are satisfied that everything is working, run ppp-off and verify that pppd terminates properly and hangs up the modem. If the modem does not hang up when pppd terminates, have another look at the stty command you used.
Running X-Windows applications over the phone is easy with PPP/Slirp. Once your PPP link is set up, simply telnet to Slirp's "magic address" 10.0.2.8 (you need to do this once -- every time you run ppp-on):
linux$ telnet 10.0.2.8
Slirp> redir X
[message telling you where to set your DISPLAY]
Slirp> quit
linux$
If you want an xterm from ame2, for example, do the following
(just like you'd do it here and assuming that your login shell is
ksh):
linux$ xhost +ame2
ame2 being added to access control list
linux$ telnet ame2
[log in]
ame2$ typeset -x DISPLAY=<display from redir X>
ame2$ xterm &
ame2$ exit
linux$
In a few seconds, an xterm should pop up on your screen. You
can run many X applications over the phone. I regularly run emacs
and xterm over PPP with no problems. You will find that some
applications are too slow to be useful when run over the phone.
Remember: today's standard "fast" modem (33600 bps) is about 300
times slower than our departmental 10 megabit ethernet.
The PPP software comes with a program called pppstats. This program periodically displays the number of bytes sent and received over your PPP link. See the manpage for more details. If you are running an older version of Linux (kernel 1.x), you probably won't have the pppstats program (you can use "netstat -i" to see packet counts, though).
On a 28.8 modem, I get about 3 kilobytes/sec when ftp'ing compressed files and up to 12 kilobytes/sec for text files.
If you are not going to run slirp on the Math Department systems, you will also want to install the following script someplace in your PATH. Make sure it has execute permission set.
Basically, this script turns off terminal echo (which can make PPP go bonkers). It also turns off write and wall messages, as well as talk requests for Slirp's tty.
#!/bin/sh ######################################################################## # slirplogin: # # This script sets up a couple of things and runs slirp for you # mesg n >/dev/null 2>&1 stty -echo >/dev/null 2>&1 exec slirp $* echo "Cannot start Slirp" # EOF slirplogin
Here are some experimental scripts to facilitate running X applications with slirp. You will need TCL 7.6 or better or your Linux box, and PPP 2.2.0f or higher. I've only tested it on my setup at home, so... YMMV. This setup has 3 parts:
linux$ xslirp
linux$ xslirp hays@acoma.math.arizona.edu emacs
The first command will give you an xterm from the host on
which slirp is running. The second command opens an emacs window on
acoma (assuming that I have .rhosts privileges set up between my
slirp host and acoma).
For this to work, you need your .slirprc to look something like:
log start
add exec slirp-cmd:10.0.2.11:8000
redir X
You will also need to place two shell scripts someplace along
your PATH on your Unix account. The first is called "xrsh" -- it's
part of the X11R6 distribution. The second is called "slirp-cmd".
It sets your DISPLAY based on the contents of .slirp_start and runs
whatever program you tell it to.
The third part is the xslirp script. It basically opens a connection to slirp and sends a command to the slirp-cmd script. If you give a user@host argument, it uses xrsh to run the command. Note that it also does an "xhost +host" for the selected host (the host running slirp if user@host isn't specified).
These scripts make some severe assumptions about your connectivity and installed software -- if they don't work, hopefully you'll be able to hack them and get them to work with what you do have.
Good luck,
Mark
