This document describes some of the common problems which users may
encounter with their first use of PPP. It is a condensation of the
development mail list problems and their corresponding solutions. Of
course, your problem may not be listed. If you have a problem, then I
usually frequent the usenet news groups, but I would prefer that you
ask it on the mail list.

Instructions for joining the mail list are in the README.linux file.

--------

Q: I can't seem to leave that bloody mail list!

A: This question is one of the most frequent problems. I realize that
you would tend to get frustrated, but posting this type of message to
the list will only make more enemies than friends.

The instructions on how to quit are included if you ask the mail list
-request address for 'help'. The major problem that most people find
is that they send the leave request from one account and expect that
the system will match their user name and quit them from a different
account.

This does not work. You must use exactly the same account, host name,
and domain name. If you sent your subscription request from one host,
such as plato, and you have now switched to a different host, cicero,
then you must send the leave request from plato. The mail list
software matches the From: name. It could care less about
Reply-To:. It could care less about Sender:.  It only matches the
From: address.

If this does not work, then the only human being in the world who can
do anything about manually removing your address is
arl@joker.cs.hut.fi. There is no one on the mail list who will be able
to remove you. Repeated requests to the list will only get people mad
at you. Send your requests to Arl.

------------

Q: I can reach the remote server, but I can not get anywhere else.

A: Did you forget the 'defaultroute' parameter? 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.

-------------

Q: I have a default route and I still can't get anywhere else! Now what?

A: The problem then is not with the local Linux system. It most likely
is routing problem on the remote end. (The remote end is also called
the 'peer' system.)

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.

1. 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.

2. 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
domain. This will work if you have the IP addresses to spare. It will
work very well if you have a Class-B IP domain and can afford to put
the all of the remote addresses on the same IP domain. 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. (We have over 300 host
systems with only 3 routers.)

3. Use gated 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.

4. Use proxy ARP on the terminal server. This will only work if your
Linux IP address matches the one of the IP domains of the network
cards.

There is no clear solution. You must choose one of these.

--------------------

Q: I keep getting the message to the effect that the magic number is
always NAKed. The system will not connect.

A: 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.

The most common reason for this failure is one of two conditions:

1. 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.

2. The remote ppp software is not running when you think it is. Is the
remote system configured to run PPP? Is the ppp process in the
expected location? Is the privileges suitable so that you may run it?

This would indicate that the shell is doing the local echo of the data.

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 "loop".

--------------------

Q: I am trying to connect to a Netblazer and it terminates with a
message "Could not determine local IP address".

A: The Netblazer does not have your IP address. You do not have your
IP address. You must have been given a piece of paper with your IP
address written upon it. Use the local IP address and the remote IP
address as a parameter to the pppd process.

Use the pppd option format of:

local_ip:remote_ip

(That is the local IP address, a colon, and the remote IP address.)

--------------------

Q: I am trying to connect to a Netblazer and it terminates with a
message "Could not determine remote IP address".

A: See above.

--------------------

Q: I can not ping my local IP address

A: You are not able to do this because you don't have a route to the
address. This is the normal operating environment. Don't try to ping
the local IP address.

If you wish to ping your own system then use the loopback address of
127.0.0.1.

--------------------

Q: Can I use the same local IP address for all of the lines of my PPP
server?

A: Yes. The local address is not significant to the local system. You
must have a unique _remote_ IP address. The routing is performed based
upon the remote IP address and not the local IP address.

--------------------

Q: I am using a Xyplex terminal server and pppd complains about
receiving a protocol reject for protocol fffb. What is this?

A: The Xyplex terminal server is confused about Van Jacobson header
compression. Use the pppd option "-vj" to disable the header
compression.

--------------------

Q: The connection fails with errors "ioctl(TIOCGETD): I/O error" or
"ioctl(PPPIOCSINPSIG): I/O error". What now?

A: Look at the boot messages when you boot the kernel. If it says
"PPP version 0.1.2" then you have an old version of the ppp.c driver.

If it says "PPP version 0.2.7" then you have the current driver,
however, it was not built with the same set of defines for the ioctl
numbers. Ensure that you have only one file called "ppp.h". It should
be located in the kernel's include/linux directory. Once you have done
this, rebuild the kernel and the pppd process.

--------------------

Q: Sometimes the messages "ioctl(PPPIOCGDEBUG): I/O error",
"ioctl(TIOCSETD): I/O error" and "ioctl(TIOCNXCL): I/O error"
occur. Why?

A: The remote system has disconnected the telephone. The tty drivers
will re-establish the proper tty dicipline and these errors are the
result of the pppd process trying to do the same thing. These are to
be expected.

--------------------

Q: I am trying to use the merit network. Why does this not connect?

A: Some users of the merit network have indicated that it needs PAP.
Did you try PAP authentication?

--------------------

Q: My netstat says something other than the following. It may report
the ppp device as "unknown" and show a strange hardware address. Is
this important?

ppp0      Link encap Point-Point Protocol
          inet addr 192.76.32.2  P-t-P 129.67.1.165  Mask 255.255.255.0

A: No. The information is for display purposes only. If you are using
a recient 1.1 kernel then update the nettools package with the current
one on sunacm.swan.ac.uk in the directory /pub/Linux/networking/nettools.

--------------------

End.

