Make sure that you did rebuild the kernel and that
you are running it.
<p>
Make sure that you don't have an old copy of pppd on your disk and you
are running that version. The previous version of pppd was stored on
/usr/lib/ppp. Many people objected to this location. The 2.2 code has
moved the <em>pppd</em>, <em>chat</em>, and <em>pppstats</em> to the
/usr/sbin directory. If your scripts still reference
<bf>/usr/lib/ppp</bf> then you will probably run the old code.
<sect1>pppd wont run unless you are root
<p>
The pppd process needs to make changes to the networking
system and this can only be done if you are the root user. If
you wish to run <em>pppd</em> from other than
the root user then the pppd program needs to be secured `suid
to root`.
<p>
<tscreen><verb>
chown root /usr/sbin/pppd
chmod 4755 /usr/sbin/pppd
</verb></tscreen>
<p>
If you wish to control the pppd access to a select
group of people, then make the <em>pppd</em>
process owned by the group and do not permit all others to run
the program.
<sect1>unable to create pid file: no such file or directory
<p>
You need to create the directory <em>/var/run</em>.
On earlier Slackware distributions, this was a symbolic link to
the <em>/etc</em> directory.
<p>
This is a warning. The PPP software will work normally
in spite of this message. However, the <em>ppp-off</em>
script depends upon this file. It is a good idea to create the
directory or make the link to the appropriate location.
<p>
The posix header, <em>paths.h</em>,
defines the location for the pid file under the name `<em>_VAR_RUN</em>`.
If you wish to use a different directory for PPP and others, change
the value for this define and rebuild the software.
<sect1>/etc/ppp/options: no such file or directory
<p>
You must create the directory <em>/etc/ppp</em>
and have a file called `<em>options</em>`
in that directory. It needs to be readable by the <em>pppd</em>
process (root).
<p>
The file may be empty. To make an empty file use
the `<em>touch</em>` command.
<p>
See the <em>pppd</em> man page, <em>pppd.8</em>, for a description of
this file.
<sect1>Could not determine local IP address
<p>
This happens with many configurations of the Telebit
Netblazer. The problem is not the terminal server, but the site
which has not configured the terminal server with a set of IP
addresses.
<p>
The Netblazer does not have your IP address. You
do not have your IP address. The link will not work unless both
IP addresses are known.
<itemize>
<item>The Netblazer does not have your IP address and you do not
have your IP address.
<item>The Netblazer does know its IP address and you do not have
its IP address.
</itemize>
<p>
The link will not work unless both IP addresses are known.
<p>
You must tell the Netblazer the IP addresses to be
used. Use the local IP address and the remote IP address as a
parameter to the pppd process.
<p>
Use the pppd option format of:
<p>
<verb>local_ip:remote_ip</verb>
<p>
(That is the local IP address, a colon, and the remote IP address.)
<sect1>Could not determine remote IP address
<p>
See the previous answer.
<sect1>I keep getting the message to the effect that the magic number is always NAKed. The system will not connect.
<p>
There is a one in over four billion chance that the
two systems have chosen the same magic number. If you get a continual
failure about the magic number, the chances that this is a fluke
will geometrically reduce.
<p>
The two most common reasons for this failure are:
<itemize>
<item>The remote PPP software is not running when you think it is. Is
the remote system configured to run PPP? Did you use the proper
account? Did you use the proper password for this account? If you are
using a scripting tool such as chat, then did you miss a prompt and
are really talking to the logon process and not the PPP code? Is the
PPP process in the expected location? Is the privileges suitable so
that you may run it?
<p>
This would indicate that the shell is doing the local echo of
the data. This is the more common reason.
<item>The modem has disconnected immediately upon making the connection
and logging you on to the remote. Most modems are configured to
echo the data sent to them and you are seeing the local echo from
the modem.
</itemize>
<p>
In either case, the Linux system is sending data to the remote which
is being fed immediately back into the serial receiver. This is not an
acceptable condition. You have what is called a
`<em>loop</em>`.
<sect1>protocol reject for protocol fffb
<p>
This usually occurs when you are trying to connect
to a Xyplex terminal server. Version 5.1 of the Xyplex terminal
server software, according to Xyplex, has numerous problems with
PPP. It is strongly recommended that you update the Xyplex software
to at least version 5.3.
<p>
If you must use Xyplex version 5.1, then use the pppd option
`<em>vj-max-slots 3</em>` to limit the number of slots to
three. The problem on the Xyplex server is that it will accept the
request for the default 16 slots, but fail to operate beyond the third
slot. It should have return a NAK frame with the limit, but it does
not.
<p>
Alternately, you can disable the Van Jacobson header compression with
the option `<em>-vj</em>`.
<sect1>The PPP software connects, sends quite a few frames, but still does not seem to connect. Why is that?
<p>
Linux does not support RPI modems. If your modem is RPI then you will
have to find a different modem. This is not likely to change in the
future given the statements made by Rockwell`s management.
<p>
Examine the system log when you use the `<em>debug</em>`
option. (You will need the system log data anyway if you are going to
ask for help.) If the trace shows that it is sending the
<em>LCP</em>-request frame over and over again and the id number is
not incrementing then you are not exchanging frames with the remote
PPP software.
<p>
The common reasons for this for this are:
<itemize>
<item>You don't have the PPP software running on the other end.
You are sending the PPP frames to some other program which is
probably saying `What is this #$%percent;ˆ ?`
<item>Please make sure that you have the PPP software started on
the other end before you enter the PPP protocol sequence. Try
to use a normal modem program and go through the logon sequence
that you would normally do. Do you see the PPP frames being sent
to you?
<p>
The PPP frames are fairly distinctive. They will be about 40 characters
in length and contain several <em>{</em> characters. They should
not have a carriage return character after them and are sent out
in a burst with a pause between the bursts.
<item>The line is not `eight bit clean`. This means that
you need to have eight data bits, no parity, and one stop bit.
The PPP link absolutely requires eight data bits.
<p>
The pppd software will automatically put the line into eight data
bits, no parity, and one stop bit. The remote must match this
configuration or framing and parity errors may occur.
<p>
PPP will escape characters. It is not possible for it to escape
bits as kermit does. PPP will <em>not</em> work with a seven bit
communications link.
<item>The remote is configured to require authentication such as
<em>PAP</em> or <em>CHAP</em>. You have not configured the local
system to use this feature. Therefore, the remote is discarding
all of your frames until it sees a valid authentication frame
from you. Since you are not configured to generate the frames,
the <em>IPCP</em> frames which you send are being ignored.
<p>
In this case, either configure the remote to not expect authentication
or configure the local system to do authentication and supply
the proper secrets.
<p>
Examine the receipt of the LCP configure frame. If it shows an
`auth` type, then the remote is configured for authentication.
</itemize>
<sect1>The /etc/ppp/ip-up scripts won't work.
<p>
The pppd process launches the program at the location
/etc/ppp/ip-up when the IP layer goes up. It gives it parameters
which define the line status. Such things include the device name,
communications speed, and IP addresses.
<p>
However, what may not be clear is that it treats
this file as a <em>program</em>. It is not
a script. The program is started by using the exec() function
of Linux.
<p>
What this means is that if you wish to use a script
for these programs, then you must do two things.
<itemize>
<item>You need to have the file marked as executable with chmod.
The proper mode for the file should be mode 100. Mode 500 is acceptable
if you wish to read the file and mode 700 is acceptable if you
wish to write to the file. The file should be owned by the root
user.
<item>The file must have as the first line the sequence:
<p>
<tscreen><verb>
#!/bin/sh
</verb></tscreen>
<p>
The # character must be in the first character position
of the very first line of the file. The interpreter program, /bin/sh
in this case, may be any program which is expected to run the
script. Most people will use the Bourne shell for this purpose.
It is commonly stored in the location /bin/sh. Other commonly
used interpreters are perl and csh. What is important is that
the first two characters of the file be the # and ! characters
respectively.
</itemize>
<p>
<sect1>I can't execute /etc/ppp/ip-up: Exec format error
<p>
Please refer to the answer to the previous question.
<sect1>How do I use PPP with a system which uses dynamic IP assignments? It assigns a different IP address to me with each call.
<p>
The assignment of the local IP address is a function
of the options given to pppd and the IPCP protocol. You should
use the `magic` IP address of 0.0.0.0 if you must specify the
local IP address. Most people simply leave the local IP address
out of the option list.
<p>
The other option which is closely tied to this is
called `noipdefault`. The noipdefault option instructs the pppd
process to not attempt to guess the local IP address from your
hostname and the IP addresses in the /etc/hosts file. Most people
use this option when the IP address is dynamically assigned. However,
this option does not mean `use dynamic IP addresses`. The use
of dynamic IP addresses is automatic when the local IP address
is not given.
<sect1>How do I know what IP address was given to me when it is dynamically assigned?
<p>
Use the /etc/ppp/ip-up hook. The local IP address
is the fourth parameter. This will be executed when pppd knows
the IP address for the local system. The fifth parameter is the
remote IP address if you should wish to know this value as well.
<p>
If you are curious about the value assigned then
you may use the <em>ifconfig</em> program
to display the current settings. It will show you the current
values for both the local IP address and the IP address assigned
to the remote under the P-t-P heading.
<sect1>I just upgraded my system and now pppd reports that the option -v is not supported. Why?
<p>
Did you just upgrade to Linux `96 from Walnut Creek CDROM? It
is also known as the Slackware 3.1 package. The problem is that the pppd
executable in the /usr/sbin directory was renamed in that distribution
and a script was installed in its place. This script was to find
the version of the operating system and then either run the 2.2
or 2.1 version of pppd.
<p>
Unfortunately, the script does not work properly with the pppd
process when you use the connect option.
<p>
So, to correct the problem, remove the script and replace it with
the proper pppd executable.
<sect1>The pppd process reports that it won't replace the existing default route. How do I get it to use the default route?
<p>
This is another Slackware `enhancement`. The Slackware package
added a default route to the ethernet controller during the startup
sequence in the /etc/rc.init1 script. This statement is:
<p>
<tscreen><verb>
/usr/bin/route add default dev eth0
</verb></tscreen>
<p>
The problem is that the statement has absolutely no functionality
with the proper routing. A default route is designed to be sent
to a router, not just dumped on the ethernet controller.
<p>
The pppd process is configured to not replace a default route
if a default route is currently used before it starts. It does
this for security reasons. Since Slackware uses the default route
incorrectly, the pppd process is unable to install a new default
route.
<p>
To correct the problem you need to replace the default route statement
in the /etc/rc.init1 script with a proper network route. See the
Net-2-HOWTO for the instructions on what should be used.
<sect1>When I run pppd it says that support is not in the kernel.
<p>
There are a few reasons for this to be generated.
<itemize>
<item>You are running the pppd process from an account other than
the root account and the pppd process is not secured as being
setuid to root. To correct for this, issue the command `chmod
4555 /usr/sbin/pppd` while you are signed on as the root
user.
<item>You are using modules and have not loaded the ppp.o module.
This may require that you first load the slhc.o module to provide
for the VJ header compression logic.
<item>You are not running the proper pppd process. If you are using
the 2.x series kernels then you must use at least the 2.2.0 version
of the pppd process. The 2.1 version is not supported with the
2.x series kernels.
<item>Likewise, if you are running the 1.2.13 kernel and have built
the 2.1 version of the drivers into the kernel then you must run
the 2.1.2d version of pppd.
<item>The pppd process as moved from /usr/lib/ppp/pppd used in the
2.1 version of the pppd process, to the `new` home of /usr/sbin/pppd.
It is expected that all future versions of pppd will be stored
in this location. The change was in response to the FSSTND document
for Linux. This change may require that you rebuild the dip or
diald programs to reflect the new location of pppd.
</itemize>
<sect1>How do I use PPP and a local network at the same time?
<p>
Break the problem into two parts. The first part
is to get the ethernet network working properly. See the question
about the default route concerning a problem with the Slackware
`96 package.
<p>
Once you have the ethernet network working, then
get the PPP link between the one system running pppd and the internet
provider working. Do not concern yourself with the local network
at this time. Just get the PPP link working.
<p>
Then, once you have the two pieces working, you can
get the two of them working together. Use either a firewall system
on the computer with the PPP link or use the IP masquerading software.
<p>
For more instructions on the firewall code, see the Firewall-HOWTO.
<p>
For more instructions on the masquerading code, see the Net-2-HOWTO.
<sect1>Can I use the same local IP address for each line of a PPP server?
<p>
Yes, you may use the same IP address for all of the
local addresses on each of your PPP devices. You may even use
the same IP address as one of your ethernet or token ring controllers.
<p>
However, you must use a unique IP address for each
of your remote IP addresses.
<p>
The routing for a point-to-point link is to the remote
IP address, not to the local IP address.
<sect1>How do I find my local IP address??
<p>
The local IP address is one of the parameters given
to the /etc/ppp/ip-up program. It is the 4th (counting
from the first) argument. The easiest method is to simply save
the value at the time that the ip-up program is executed.
<p>
If you don't wish to do this then you can use the
ifconfig program to display the parameters for the specific PPP
device. One of the values is the IP address.
<p>
If you don't wish to do this then you can obtain
the information from the system log. This is the least desirable
method as parsing the standard log file is much more complicated
than parsing the output from ifconfig.
<p>
The easiest solution is to simply store the value
during the ip-up program in some specific file which you may access
at a later date.
<sect1>I can't connect to the merit network.
<p>
Some users of the merit network have indicated that
it needs PAP. Did you try PAP authentication?
<sect>DIP
<p>
<sect1>DIP does not have support for PPP`s mode
<p>
The current version of dip-uri supports PPP in that
it will execute the pppd process when you execute `mode PPP`.
However, there are many options which are needed for the proper
operation of pppd. Since dip does not pass these to the program,
they must be stored in the /etc/ppp/options file.
<p>
The dip program controls the establishment of the
SLIP link. It controls the SLIP link with the aid of slattach,
ifconfig, and route. These programs may be used to establish a
SLIP link. They are not useful for the establishment of a PPP
link.
<p>
The dip program may be used to dial the telephone
and start the <em>PPP</em> software on the
remote system. It is best used in this mode as the parameter to
the `<em>connect</em>` option. However, you
have the option to use dip to control the link. It
is not important how pppd be executed to run the PPP link. It
is only important that it be executed as it is a mandatory program
for the PPP protocol.
<p>
While this is not a FAQ for dip, there is a common
problem with dip and pppd. The dip process has the absolute pathname
to the pppd process embedded within it. Until recently, the location
for pppd was /usr/lib/ppp/pppd. It has moved to the /usr/sbin/pppd
location. So, if you are unable to get dip to start pppd then
check the pathnames in dip.
<p>
Additional information about the dip process is in
the Net-2-HOWTO document.
<sect1>DIP dies immediately when I do `mode ppp`
<p>
The location of the pppd program file is stored within dip.
<p>
The 2.1 version of pppd was stored in /usr/lib/ppp/pppd. The 2.2
version has moved to the more `standard` location of
/usr/sbin/pppd. That is well and good. However, the problem is that
now dip has the wrong location for pppd. When it attempts to run the
pppd process as you do `mode ppp&grave, the dip program attempts
to run the pppd program and it can`t because it isn`
there.
<p>
You can temporarily make a symbolic link from the /usr/lib/ppp/pppd
location to the /usr/sbin/pppd file. However, a better solution is to
rebuild the dip program so that it knows that pppd is at
/usr/sbin/pppd.
<sect>Process termination
<p>
<sect1>Is there a `dip -k` for PPP?
<p>
No. There is no `<em>dip -k</em>`.
<p>
However, if you run dip -k, and have properly built
the dip process so that it knows that the lock file directory
is /var/locks, then you may use the command to terminate the pppd
process. The reason that this works is that dip will terminate
any process which owns the tty device, not just the one which
it started. This may be a security concern for some (perhaps many)
people. However, it is just the way that the program works. If
you are concerned about dip doing this action then either secure
dip so that it is executable by only specific people or remove
it from your system and use slattach, route, ifconfig, and arp
to do the dial-in functions of SLIP.
<p>
In the chat directory, there is a `<em>PPP-off</em>`
script. This will stop the PPP link in the same manner as the
`<em>dip -k`</em>.
<p>
I have included it below. (Cut it out. Store it in its own file.
<p>
Make the file executable with chmod.)
<tscreen><verb>
#!/bin/sh
DEVICE=ppp0
#
# If the ppp0 pid file is present then the program is running. Stop it.
if [ -r /var/run/$DEVICE.pid ]; then
kill -INT `head -1 /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
</verb></tscreen>
<p>
In addition, you may still use `dip -k` to terminate the
pppd link. The reason is that dip does not care if it started the
program which is using the serial device. It sends a SIGTERM to any
process which owns the serial device. (This is not a great idea,
however, that is the way that dip works.)
<sect1>PPP does not hangup the modem when it terminates
<p>
There are several reasons for this.
<itemize>
<item>Did you use the pppd `<em>modem</em>` parameter? This parameter
controls whether or not the <em>pppd</em> process is to control
and honor the signals reflecting the modem status. This parameter
is explained in the man page for <em>pppd</em>.
<item>Do you have the modem presenting the DCD signal and honoring
DTR? The Hayes sequence for this is usually `&C1`.
If you reset the modem during the connection sequence with `ATZ`
then ensure that your modem is configured correctly.
<item>The DTR signal is generated by the computer and instructs
the modem to disconnect. Hayes sequence for this is usually `&D1`
or `&D2` with `&D2` being the preferred
setting for PPP. Many manufacturers will ignore the DTR condition
in their `factory defaults` setting.
<item>Did you use a cheap cable which does not pass the DCD signal?
Macintosh `Classic` cables are notorious for this problem. The
Macintosh Classic does not use this signal.
<item>For dial-in connections, did you exec the pppd process properly?
The pppd process should be `exec`ed from the script rather than
simply executed. If you attempt to simply run the pppd process
then it will be the shell which will receive the SIGHUP hangup
signal and not the pppd process.
<p>
The `shell` script should have a format similar to the following:
<p>
<tscreen><verb>
#!/bin/sh
exec pppd -detach modem ...
</verb></tscreen>
<item>The use of <bf>dip</bf> and <bf>diald</bf> has, on occasion, interfered
with the ability of pppd to sense the loss of the carrier. In
this case, you should use the lcp-echo-request and lcp-echo-failure
options to detect the loss of the connection in-band.
<p>
[Ed: Sorry for the technical terminology. `in-band`
refers to the use of the protocol itself to detect a condition. It is
similar to using XON and XOFF as flow control characters. These
characters are sent along with the data and perform the flow control
operations. The `in-band` is the opposite of
`out-of-band`. They both refer to `band` as being
short for `bandwidth`. When something is
`in-band`, it is within the bandwidth of the signals. That
is, it takes some of the bandwidth to perform the additional
function. `out-of-band` would be the equivalent of using the
RTS and CTS signal lines to do flow control. These do not take a
character. These are not sent with the data. The signals are just
additional lines that happen to do the required function.]
<p>
</itemize>
<sect>Data Transfer related issues
<p>
<sect1>The ftp transfers seems to die when I do a `put` operation. They will work correctly if I `get` a file. Why?
<p>
Do you have the flow control enabled?
<p>
Flow control is set by the pppd option <em>crtscts</em> for RTS/CTS
and <em>xonxoff</em> for XON/XOFF. If you don't enable the flow
control then you will probably overrun the modem`s buffers and this
will prove to be disastrous with vj header compression.
<p>
It is important that the modem, not just the computer, have the proper
setting for flow control. If the modem does not do flow control and
the computer is expecting that the modem will tell it when the buffer
overruns, then the buffer will overrun because the modem is not
configured to tell the computer that it is full.
<p>
Likewise if the modem is configured to use RTS/CTS and your computer
is configured to use XON/XOFF then you will not be able to recognize
the modem`s request to suspend transmission.
<p>
The modern modems are configured with the use of a command code to do
flow control. Check in your manual for the appropriate command code and
include it along with the modem initialization.
<p>
Do not fall into the "well, the modem does this by default so I don't
have to configure the modem before I use it." trap. Do the
configuration. Do it explicitly. If the manual says that &H1 sets
RTS and CTS flow control (what is also commonly called
`hardware` flow control) then send the modem AT&H1 to
set the flow control. Do it before you dial the number. Don't expect
that just giving the modem ATZ will enable the flow control
properly.
<sect1>How do I use XON/XOFF for flow control?
<p>
The better flow control is CTS/RTS. However, if you
can not do the hardware flow control with the signals CTS and
RTS, then use XON/XOFF. The following three steps need to be performed.
<itemize>
<item>You need to specify the pppd option <em>xonxoff</em>. This
tells the pppd process to configure the serial device for XON/XOFF
flow control and to load the two characters into the tty driver.
<item>You need to specify the XON and XOFF characters in the pppd
parameter <em>asyncmap</em>. This tells the remote system that
is should quote the XON and XOFF characters when it wishes to
send them to you. It is normally specified as the pppd parameter
`<bf>asyncmap a0000</bf>`.
<item>Of course, don't forget to tell the modem to use XON/XOFF flow
control. My <em>ZyXEL</em> modem uses a sequence
`&R1&H4` to do this.
</itemize>
<sect1>The modem seems to always connect at a strange rate. When I use minicom, the modem will always use 14400. However, PPP is using 9600 or 7200 or even 2400. How do I fix this?
<p>
Put the desired rate as an option to the pppd process.
If you don't put the rate, then pppd process will use whatever
rate is set currently at the time. Not all programs will restore
all of the parameters to the previous settings properly upon exit.
This may lead to strange rates configured for the serial device.
<p>
Linux does not support modems which use the RPI (<bf>R</bf>ockwell
<bf>P</bf>rotocol <bf>I</bf>nterface) proprietary specification. Given
the proprietary nature of the specification (even if you signed
a NDA Rockwell will not release the code needed to interface to
the modem) it is <bf>extremely</bf> unlikely that Linux will <bf>ever</bf>
support this modem. The only solution, should you have a RPI modem,
is to take it back to the dealer and get one which does not use
RPI.
<p>
Some of the catch phrases to avoid are modems which
are marked as having error correction in software, `windows`
compatible, or `requiring a special driver` for full
operation. These usually indicate that the modem uses RPI.
<sect1>The ftp transfers seems to be very slow when I do a `get` operation. The `put` operation is much faster. Why?
<p>
Did you specify the option:
<p>
<verb>asyncmap 0</verb>
<p>
when you ran pppd? If you forgot the option, the
peer must quote (double) all of the control characters in the
range from 00 to 1F (hex). This will result in a statistical loss
of about 12.5% in speed for all of the data which you receive.
<p>
Did you configure the remote system? If so, did you
forget flow control on its modem?
<sect1>The proxyarp function fails to find the hardware address.
<p>
Use the <em>ppp-2.1.2d.tar.gz</em>
package. The <em>pppd</em> process was erroneously
compiled with the 1.1.8 kernel and it used <em>Net-3</em>
rather than <em>Net-2</em> definitions.
<p>
Additionally, you should refer to the proxy-ARP mini-HOWTO
about the requirements for using proxy-ARP.
<p>
The 2.1 package had a limit of 64 network devices.
be a very likely limit as most people had one or two ethernet
controllers. This is no longer the case when we consider that
some systems routinely have 128 network devices.
<p>
The 2.2 package has raised the limit to 5000 network devices. That
limit is excessive. However, it means that in all practial purposes,
there is no limit. It is a compile-time define in the sys-linux.c
module.
<sect>Routing and other problems
<p>
<sect1>My route to the remote keeps disappearing! It last for about 3 minutes and then the route just goes away. Help!
<p>
This is not a question for PPP.
<p>
Hint: <bf>DON'T RUN <em>routed</em>!</bf>
<p>
If you need to send RIP frames to the peer for its routing purposes
then use the bcastd program. The bcastd program is on sunsite.unc.edu.
<sect1>I would like to attach my other computers on my network to the Internet through my PPP connection. I have only the one IP address which is assigned to me from my service provider. (It may even have been dynamically assigned.) How may I do this?
<p>
You may not. At least, you can't do it in the manner
that you would normally want to do it. The problem is that your
provider would not know about the IP addresses of your local network
and therefore wont route the frames to your local system.
<p>
There are other solutions, however.
<itemize>
<item>You may telnet to your one computer running pppd and then
use telnet or ftp to reach out to the rest of the Internet. This
is not really much better then just using the computer directly,
but it does work for simple things.
<item>You may run a 2.x series kernel and use the `IP
Masquerade` option. For instructions on how to use this facility
you should refer to the Net-2-HOWTO document.
<item>You may run the <em>socks</em> program on your PPP system. This
will perform the same facility as the IP Masquerade but it will take
modified clients or a replacement run-time library. The advantage is
that the socks program has been around for some years and many clients
will understand the concept of a `proxy` server which is
needed to work with socks.
</itemize>
<sect1>I can reach the remote server, but I can not get anywhere else.
<p>
Did you forget the `<em>defaultroute</em>`
parameter to pppd? This parameter adds a default route into your
routing system so that frames to all other IP addresses will be
sent to the PPP device.
<p>
The PPP software will not replace the default route
if you have one already set when you run pppd. This is done to
prevent people from destroying their default route to the ethernet
routers by accident. A warning message is written to the system
log if the defaultroute parameter is not performed for this reason.
<sect1>I have a default route and I still can't get anywhere else! Now what?
<p>
The problem then is not with the local Linux system.
It most likely is routing problem on the remote end.
<p>
The remote system is not configured for `<em>IP
forwarding</em>`. It is an RFC requirement that this
option <bf>NOT</bf> be enabled by default. You must enable the option.
For Linux systems, you will need to build the kernel and specify
that you want IP forwarding/gatewaying.
<p>
The remote computers need a route back to you just
as you need a route to them. This may be accomplished by one of
four methods. Each has advantages and limitations. You need to
do one and only one of these.
<itemize>
<item>Use a host route. At each host on the remote system, add a
host route to your Linux IP address with the gateway being the
terminal server that you use for your local access. This will
work if you have a small number of host systems and a simple network
without bridges, routers, gateways, etc.
<item>Use a network route. Subdivide the remote IP addresses so
that your local Linux IP address and the remote terminal server
address and the remote terminal server`s ethernet address is on
the same IP network. This will work if you have the IP addresses
to spare. It will work very well if you have a Class-B IP network
and can afford to put the all of the remote addresses on the same
IP network. Then add a network route on each of the gateways and
routers so that any address of the remote network is sent to the
terminal server. Most configurations have many hosts but few routers.
(At <em>sii.com</em>, we have over 300 active host systems with
only 3 routers.)
<item>Use <em>gated</em> on all of the gateways and on the terminal
server. This will cause the terminal server to broadcast to the
gateways that it can accept the frames for your IP address. Since
the hosts will have a default route to one of the gateways, the
gateways will generate the ICMP re-direct frame and the specific
host will automatically add its host route.
<item>Use proxy ARP on the terminal server. This will only work
if your remote IP address is in the same IP domain as one of the
domains for the network cards.
</itemize>
<p>
There is no clear solution. You must choose one of these.
<p>
If your remote router requires to receive RIP frames
in order to update the route to your system then you should use
the <em>bcastd</em> program on sunsite.unc.edu.
This will generate the RIP frames without actually running gated.
<sect1>I can not ping my local IP address
<p>
You are not able to do this because you wont normally
have a route to the address. This is the normal operating environment.
<p>
If you wish to ping your own system then use the
loopback address of 127.0.0.1.
<p>
You may be able to ping the remote address. However,
some terminal servers may not allow this as the address may be
`phony` to them. It depends upon their environment.
<p>
In general, don't try to ping either address. Choose
a third address which is well known to be available on the remote
network such as one of your name server IP address.
<p>
While the PPP software will not perform this task,
you may add the route table entry yourself once the link has been
established. The syntax for the route statement is:
<p>
<tscreen><verb>
route add -host 192.187.163.32 lo
</verb></tscreen>
<p>
where the local IP address is represented as 192.187.163.32
in this example. This will tell the network software to route
all frames destined to your local IP address to the loopback adapter.
Once you add the appropriate route to the local IP address then
you may use this address as the target to IP frames.
<p>
You will be responsible for deleting the route when the link goes down.
<sect>Interactions with other PPP implementations
<sect1>How do I connect to a Windows NT server?
<p>
This question is becomming one of the most frequently asked questions
about PPP. The Microsoft Windows NT platform is making substantial
inroads into the corporate and commerial service organizations and the
use of it's RAS services is seen as one of the reasons. It is just so
easy to fill a few items in a form and have your Windows 95 system
connect to the Windows NT platform that it is extremely tempting for
many companies to offer Windows NT as their method of connection to
either the corporate intranet or the Internet.
<p>
Yet, there are some difficulties with the use of Linux PPP and
Microsoft Windows NT. There are a few different things with Windows NT
as opposed to a UNIX platform.
<p>
There is no special script for connecting to Windows NT servers. If
you are using chat (a UUCP expect-reply scripting tool), the script is
nothing more than:
<p>
<tscreen><verb>
chat "" ATDT5551212 CONNECT
</verb></tscreen>
<p>
since it only needs to dial the Windows NT server and get the
telephone to return a connected status. You can embelish it to look
for things such as BUSY or VOICE or other errors from the modem, but
those are not required. The only thing is to not expect "login:" or
any other form of textual login sequence. Also, Windows NT server is
`quiet`. It does not send anything until you do. It will
just answer the telephone and then wait.
<p>
There is nothing special about using PAP or MSCHAP with Windows NT and
Linux PPP. The Linux PPP process supports the MSCHAP protocol if you
apply the patches which are included with the source package and get
the D.E.S. library from ftp.funet.fi. (The DES library was originally
developed in Australia. That country has the same restrictions on
export of cryptography as do the countries of NORAD. So, since it has
leaked to Finland, people should get it from there. I do not know who
broke Australian law and that does not matter as long as it was not
I.)
<p>
If you require to interface to a server which is configured to accept
only encrypted authentication then you must use MSCHAP. If you can
open up the server and accept "any authentication, including clear
text" then you are best using PAP.
<p>
If you use PAP, then edit the /etc/ppp/pap-secrets file and put the
entry which corresponds to:
<p>
<tscreen><verb>
account remote password
</verb></tscreen>
<p>
This is three words, seperated by one or more spaces, on the same
line. I have left out the IP addresses as they are used more for the
`dial-in server` side of the pppd process. There is no limit
to the line length. If your password or account name has spaces in it
then use "password" or "account" (put quotes around it.) If the
password has special characters which are not glyphs (printable
characters such as a, b, c, etc.) then you may use \nnn for octal or
\xNN for hexadecimal to enter the raw data as needed.
<p>
The field marked account is the name of the account on the Windows NT
server, remote is either an "*" to mean that it is not used or it
corresponds to the value used with the `remotename` option
to pppd and password is, obviously, the password.
<p>
Then you need to add either "user account" or "name account" where
"account" is the matching item to your user name on the Windows NT
server and matches the entry in the pap-secrets file.
<p>
Do not use the "+chap", "+pap", or "auth" options since these require
that the remote system (Windows NT) authenticate itself with
you. Normally the administrator won`t put in your codes so this will
fail and you will not be able to communicate.
<p>
The entry for the chap-secrets file is basically the same. The MSCHAP
code will convert the ASCII code to UNICODE that Windows NT requires
since it is a simple mapping function from ASCII to UNICODE for the
first 128 characters.
<p>
The double entry in the chap-secrets file is because the CHAP
authentication is assumed to work both ways. In fact, since the MSCHAP
sequence only works in one direction at the present time (because the
Windows NT server does not authenticate itself with the client because
Microsoft chose not to do that section of the code) the second entry
is just noise. However, the parser for the option in pppd will require
that you have it to make MSCHAP an acceptable authentication protocol
when requested by the Windows NT peer. The "secret" for this item can
be anything but an empty string.
<p>
The difference between "name", "remotename", and "user" is:
<p>
user : Used for PAP authentication. It will default to the value
assigned to "name" if you do not specify the "user" option directly.
<p>
name : The name of the local system. It is used by the CHAP and MSCHAP
code to select the secret from the chap-secrets file. It will default
to name of the local IP address if you don't specify it.
<p>
remotename : The name of the remote (peer) system. It is used by PAP,
CHAP, and MSCHAP to select the item from the file. It will default to
the name of the peer's IP address if you don't specify it.
<p>
The Microsoft authentication sequence is a CHAP style
authentication with their DES encryption algorithm for the passwords.
<p>
So why didn`t Microsoft just use CHAP with MD5 encryption then?
CHAP does not send the clear text password across the
`wire`. The answer is that in order to use CHAP protocol, you
need the clear text for the password to be used with the encryption
algorithm. You would need to store this clear text on your disk
file. (The pppd process stores it in the /etc/ppp/chap-secrets file.)
Storing a password in clear text on the disk also violates the
requirements for C2 registration.
<p>
The only real difference between CHAP and MSCHAP is that MSCHAP does
not store the clear text for the secret (password). They are both as
vulnerable for middle-man imposter threats. They are both just as
secure. Yet, MSCHAP can be used on a C2 registered system; CHAP can
not.
<sect1>I tried to use MSCHAP or PAP with Windows NT and it fails with "E=691". Now what?
<p>
The error condition identified as 691 is Windows NT way of telling you
"invalid user name or password". Cute, isn`t it? It would have
been better if they had included just a little more text with the
message such as 'E=691 R="invalid user name or password"',
but I guess that they had to save some memory some place and that was
the place that they chose to do it. So, they left it as just this
cryptic code number.
<p>
(There are about five other errors which may occur. Each is just a
code number as well. For a list of the code numbers and their textual
translation, you will have to query Microsoft's knowledge base on
http://www.microsoft.com.)
<p>
Aside from the obvious reason of really not giving it a valid user
name and password, the other reason is that it can not validate the
entry that you did give it.
<p>
If your RAS server is a member or a secondary domain controller of a
domain then you need to prefix the user name with the domain name. The
reason that you must specify the domain name is that the RAS server
must ask some other server to validate your account, it needs to know
the domain name which corresponds to your account.
<p>
The domain name is pre-pended to the user name with a \ character
separator.
<p>
However, since \ is special to pppd as it has the normal "C"
language meanings then you need to use an entry in the pap-secrets or
chap-secrets file which looks like:
<p>
<tscreen><verb>
domain\\account remote password
</verb></tscreen>
<p>
and use name "domain\\account" or user
"domain\\account" as the option for pppd.
<p>
Then, you need to be careful about putting the \ character on the
runline or as an un-quoted parameter to the connect option. The shell
also uses \ for special purposes. This may mean that you would
have to use name domain\\\\account just so that
the pppd process sees name domain\\account so that it can
give to Windows NT the sequence domain\account.
<sect1>How do I support Windows 95?
<p>
Windows 95 PPP support is designed to work with Windows NT and similar
servers which do not use a login and password prompt. For this to
work, you would need to use a getty process which will recognize the
LCP configure-request.
<sect1>I am using a Trumpet (for MSDOS) and the connection simply terminates. Why is this happening?
<p>
<em>Trumpet</em> does not like any VJ header compression.
Use the pppd option `<em>-vj</em>`
to turn it off.
<sect1>I am using dp-3.1.2 (with SunOS) and the system will not allow me to use anything but ping, or nslookup. Why is this happening?
<p>
There is a bug in the <bf>3.1.2</bf> version of dp.
Please get the <bf>3.1.2a</bf> or later file from the dp ftp home
site <em>harbor.ecn.purdue.ecu</em>. Until
you can put the patch into dp, disable the vj header compression.
<sect1>My provider wants to use a dynamic DNS address which is not the same with every connection. Yet, Linux wants just one address in the /etc/resolv.conf file. This works with Microsoft Windows 95, but how do I make it work with Linux?
<p>
Run a local `cache-only` nameserver on your own Linux
system.
<p>
Instructions on running the nameserver are in the
Named-HOWTO. The only file which you need to obtain from the internet
to enable the nameserver is the named.boot file. This is available
from the ftp site at ds.internic.net. Then, use the address 127.1
as the address of the nameserver.
<p>
You will need to create a named.boot file as well
as a primary for a dummy domain which will hold your localhost
name and a primary domain for the 127 IP network. Again, instructions
on how to do this are in the Named-HOWTO file.
<sect>Other messages written to the system log
<p>
<sect1>Alarm
<p>
This is not a problem. It means that a timer has
expired. Timers are a necessary part of the protocol establishment
phase. This is a message to help the authors debug the program.
<sect1>SIGHUP
<p>
The pppd process has received a HUP signal. The HUP signal is
generated by the tty software when the remote system has disconnected
the modem link. It means that the modem has put the `telephone
receiver back on the hook`, or, `Hung UP` the
connection.
<p>
The kill program may also be used to send this signal
to the pppd process.
<p>
The pppd process will terminate the link in an orderly
fashion when it receives this signal.
<sect1>SIGINT
<p>
The pppd process has received an INT signal. The
INT signal is generated by the console software when you press
the Ctrl-C key combination and pppd is the foreground process.
<p>
The kill program may also be used to send this signal
to the pppd process. In fact, the recommended method to terminate
the pppd link is to send the process an INT. See the question
relating to `dip -k` for a script which will perform
this task. The pppd process will terminate the link in an orderly
fashion when it receives this signal.
<sect1>Unknown protocol (c025) received!.
<p>
The remote wishes to exchange Link Quality Reporting
protocol with the Linux system. This protocol is presently not
supported. This is not an error. It is merely saying that it has
received the request and will tell the remote that `I can't
do this now. Don't bother me with this!`
<p>
The Morning Star PPP package will always try to do
LQR protocol. This is normal.
<sect1>Unknown protocol (80fd) received!.
<p>
The remote wishes to exchange Compression Control
Protocol with the Linux system. This type of protocol is layered
upon the basic data protocol and will, if successfully negotiated,
result in a fewer number of bytes transmitted for the frame. This
means that the transfer will be quicker.
<p>
However, there are many types of compressors which
are used under the general `umbrella` of a Compression Control
Protocol. The 2.2 PPP package understands only one; the BSD compressor.
This compressor works very similar to the Unix `compress` program
and uses a LZW compressor. Depending upon the size of the code,
there can be a significant amount of kernel space needed to hold
the compression and decompression dictionaries. This should not
be used if you have a limited memory space and should not even
be contemplated if you have 8Meg or less real (RAM) memory. In
those cases you should invest in a decent modem which support
compression.
<p>
Unless both sides can agree upon the type of compression
the compression will not be used.
<p>
Another common compressor is called Predictor-1.
This will take less memory and run faster. However, its compression
is not as good in that it will send a little more data than the
equivalent frame given to the BSD compressor.
<p>
Many commercial terminal servers will employ a compressor
called `Stacker(TM) LZW` or LZS protocol. This is a
commercial compression agent. Apparently Stacker will give you
a license for no charge. However, a specific license is required
and that will usually prevent it being included with the pppd
process.
<p>
The 2.3 package will additionally include the compressor
known as `deflate`. It is a variation of the common package called
`gzip`.
<sect1>The connection fails with errors `ioctl(TIOCGETD): I/O error` or `ioctl(PPPIOCSINPSIG): I/O error`. What now?
<p>
Look at the boot messages when you boot the kernel.
If it says `<em>PPP version 0.1.2</em>`
then you have an old version of the <em>ppp.c</em>
driver.
<p>
If it says `<em>PPP version 0.2.7</em>`
then you have the current driver, for the 2.1.2 package however,
it was not built with the same set of defines for the ioctl numbers.
Ensure that you have only one file called `<em>if_ppp.h</em>`.
It should be located in the kernel`s <em>include/linux</em>
directory. Once you have done this, rebuild the kernel and the
pppd process.
<p>
If it says `<em>PPP version 2.2.0</em>`
then you are using the driver for the 2.2.0 package. This version
of the driver will only work with the 2.2 series of the pppd package.
The 2.2 pppd program will only work with this version of the driver.
<sect1>Sometimes the messages `ioctl(PPPIOCGDEBUG): I/O error`, `ioctl(TIOCSETD): I/O error` and `ioctl(TIOCNXCL): I/O error` occur. Why?
<p>
The remote system has disconnected the telephone.
The tty drivers will re-establish the proper tty discipline and
these errors are the result of the <em>pppd</em>
process trying to do the same thing. These are to be expected.
<sect1>My ifconfig has strange output for PPP.
<p>
Usually the ifconfig program reports information
similar to the following. You will have different IP addresses.
