7 Problems running pppd

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 pppd from other than the root user then the pppd program needs to be secured 'suid to root'.

   chown root pppd
   chmod 4755 pppd

If you wish to control the pppd access to a select group of people, then make the pppd process owned by the group and do not permit all others to run the program.

Sorry, I goofed. You will have to forego the binaries and re-compile the code yourself. It is easy. Go to the pppd directory, delete the bad binary, and issue the command `make'. Go to the chat directory and do the same if you want a corrected chat program.

You must have the C language compiler and GNU make installed to rebuild the PPP software.

It turns out that when I compiled the ppp-2.1.2d package, while I used the proper definitions, I used the 4.6 libraries. One of these days, Al may finally get his act together . . . .

Or, you can get binaries from the Slackware 2.0.2 (or later) package. They are in the PPP.tgz file in the `n' series of disks.

Please use the source in the ppp-2.1.2d to compile the code. The source has been corrected over the `a' package.

You need to create the directory /var/run. On earlier Slackware distributions, this was a symbolic link to the /etc directory.

This is a warning. The PPP software will work normally in spite of this message. However, the PPP-off script depends upon this file. It is a good idea to create the directory or make the link to the appropriate location.

The posix header, paths.h, defines the location for the pid file under the name "_VAR_RUN". If you wish to use a different directory for PPP and others, change the value for this define and rebuild the software.

You need to create the directory /etc/PPP and have a file called 'options' in that directory. It needs to be readable by the pppd process (root).

The file may be empty. To make an empty file use the `touch' command.

See the pppd man page, pppd.8, for a description of this file.

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.

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.

• The Netblazer does not have your IP address and you do not have your IP address.
• The Netblazer does know its IP address and you do not have its IP address.

The link will not work unless both IP addresses are known.

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.

Use the pppd option format of:

local_ip:remote_ip

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

See the previous answer.

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 two most common reasons for this failure are:

• 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. This is the more common reason.

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

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

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.

If you must use version 5.1, then use the pppd option "vj-max-slots 3" 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.

Alternately, you can disable the Van Jacobson header compression with the option "-vj".

Examine the system log when you use the "debug" 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 LCP-request frame over and over again and the id number is not incrementing then you are not exchanging frames with the remote PPP software.

Three common reasons for this are:

• 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 #$%ˆ ?"

  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?

  The PPP frames are fairly distinctive. They will be about 16 characters in length and contain several { characters. They should not have a carriage return character after them and are sent out in a burst with a pause between the bursts.

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

  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.

  PPP will escape characters. It is not possible for it to escape bits as kermit does. PPP will not work with a seven bit communications link.

  There is a compile option in the PPP.c driver (part of the kernel) called CHECK_CHARACTERS which will include additional code in the driver to provide additional checking on the input characters. It will be able to tell you if the parity was enabled or if the remote system always sent the characters as seven bits.

• The remote is configured to require authentication such as PAP or CHAP. 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 IPCP frames which you send are being ignored.

  In this case, either configure the remote to not expect authentication or configure the local system to do authentication and supply the proper secrets.

  Examine the receipt of the LCP configure frame. If it shows an 'auth' type, then the remote is configured for authentication.

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