Solution: see the command not found entry below, as it covers the same problem but from a different error message.

Solution 2: upgrade to 1.2.0 or later of pptp-linux. If the problem continues, upgrade to the latest pptp-command from CVS.

Diagnosis: the program is not in your PATH, or you are not running the program as the root user. This is a normal security feature of most systems.

The solutions depend on which program you are running.

pptpconfig

The pptpconfig program needs access to your X-Windows display, write access to /etc/ppp/peers, /etc/pptpconfig, and also needs to start pppd and pptp which themselves need root. Choose one of these methods:

1. configure sudo to allow a user to run pptpconfig as root without any password prompt, for example:

   # echo ALL ALL=NOPASSWD: /usr/sbin/pptpconfig >> /etc/sudoers

   add a desktop launcher item which runs this:

   % sudo /usr/sbin/pptpconfig

   and since pptpconfig presumes both pptp and ip are in the PATH, either create symlinks:

   % ln -s /usr/sbin/pptp /usr/bin/pptp % ln -s /sbin/ip /bin/ip

   or augment PATH in the usual fashion.

2. use kdesu if it is installed; type kdesu pptpconfig and press enter. You may be prompted for the root password, and then the pptpconfig window should appear.
3. use gksu if it is installed; type gksu pptpconfig and press enter. You may be prompted for the root password, and then the pptpconfig window should appear.
4. use gnomesu if it is installed; type gnomesu pptpconfig and press enter. You may be prompted for the root password, and then the pptpconfig window should appear.
5. use ssh to forward the X11 connection; type ssh -X [email protected] pptpconfig and press enter. You may be prompted for the root password. The sshmethod may not work if your /etc/ssh/sshd_config file has X11Forwarding set to no. Another security feature.
6. log in as root to begin with. On some distributions, you can configure the connection using pptpconfig as root, and then start the tunnel using pon tunnelname as an ordinary user.
7. adjust the definition of the menu option for pptpconfig by adding whichever wrapper above worked for you.

The pptpsetup program needs write access to /etc/ppp/peers, /etc/pptpconfig, and also needs to start pppd and pptp. Choose one of these methods:

1. configure sudo to allow you to start pptpsetup, as described in the section above,
2. use ssh; type ssh [email protected] pptpsetup and press enter. You may be prompted for the root password.
3. log in as root to begin with. On some distributions, you can configure the connection using pptpsetup as root, and then start the tunnel using pon tunnelname as an ordinary user.
4. configure pptpsetup to be setuid root:

   # chmod u+s `which pptpsetup`

pptp requires root privilege to create a raw socket for GRE packet transmission. pptp is in /usr/sbin, which is in the PATH for the root user. pptp is started bypppd. Follow this sequence:

1. make sure you are using pptp-client 1.1.0 or later,
2. as root, configure the tunnel with pptpconfig or pptpsetup, and test it, but then stop using pptpconfig or pptpsetup as the way to start it,
3. make pptp setuid root:

   # chmod u+s `which pptp`

4. test that a pppd command can be used to start the tunnel:

   # pppd call tunnel

   where tunnel is the name of the tunnel configuration file. pppd knows to look in /etc/ppp/peers for the file.

   If the tunnel does not start, enable debug logging, and try the pppd command again.

5. return to non-root user mode, and then use a normal GUI or console utilities (e.g. pon and poff) to start or stop the pppd connection named 'tunnel'.

   # pon tunnel

6. you may need to add a host route to the PPTP server first, which is something that pptpconfig does for PPTP Client 1.7.1 and earlier,
7. if you used any special routing in pptpconfig then you will need to duplicate this at the command line. Enable debug logging in pptpconfig to see exactly what commands it is executing and when.

Diagnosis: pppd was started by pptpd but was unable to operate, and so terminated quickly. pptpd tried to read data from pppd but found none. There are many reasons why pppd could have failed, but the most likely are configuration file errors.

pptpd incorrectly hides all pppd error output. This is a defect and should be fixed. It apparently doesn't even wait for and report the pppd exit status.

Solution: check the configuration files. A simple typo will cause this error. It is easy to have pppd tell you where the typo is. Here is how:

Try running pppd against the configuration files in the same way that pptpd would run it. If you strace the pptpd, you can detect the command line given topppd (just after it says "launching pppd"), and then you can run that command manually in a shell to see what objections pppd has to the options.

When we did an strace just now, we got this line that was valuable;

This tells us that pptpd is trying to execute the following command to accept the tunnel connection from the client (we have speed 50 in our options file);

Running this command in a shell starts pppd negotiating with the keyboard and screen. After a while it times out. Adding the dryrun option allow us to test the syntax only. We added the word bogus to our pptpd-options file (your file name may differ), and the result was as follows:

pppd had returned an exit status of 2, which according to the manual page means "An error was detected in processing the options given, such as two mutually exclusive options being used."

Removing the word bogus caused pppd to exit with a status of 0. We used the shell command echo $? to check the exit status.

As to why the error messages from pppd are being ignored, the running pppd on our test server has file descriptor 2 (stderr) bound to a deleted pty. We presume this is a code fault in pptpd.

Diagnosis: this is a normal situation. Many network links drop or re-order packets as a normal part of their operation. This message informs you that a packet was lost or re-ordered. The TCP network infrastructure above this level will retransmit the lost data.

(out-of-order in this context relates to the sequence of the packets, and should not be confused with the use of the phrase in some locales to warn that public equipment is not operating.)

Solution: if the loss is higher than the physical layer should provide, check the physical layer for problems.

You can also use the link statistics feature of pptp, see the man page for how to obtain and understand the statistics.

Diagnosis: pppd has failed to change the pty over to run it in PPP mode. This may be because you have no ppp_async module built for your kernel. Most kernels are built with this already, but if you have customised your kernel you may not have built it.

Solution: rebuild your kernel with CONFIG_PPP_ASYNC set. While you are at it, you should set CONFIG_PPP as well, and both should be set to "m" so that they are built as modules. We've found they don't work compiled statically.

1. specifying the wrong domain (E=691),
2. restrictions on logon hours (E=646),
3. account is disabled (E=647),
4. account password expired (E=648),
5. specifying the wrong password (E=691), (e.g. by not quoting special characters),
6. using spaces or blanks as part of your password (E=691), (our tests show this doesn't work).

Diagnosis: error code 649 is ERROR_NO_DIALIN_PERMISSION, the account does not have dialin permission.

Solution: ask the server administrator to give your account dialin permission.

Diagnosis: pppd has completed IPCP negotiation with the peer (e.g. the PPTP server) and was about to raise the new network interface, but found that neither the peer, the command line, or the hostname gave a valid IP address.

Usually, the peer provides the IP address during IPCP negotiation. You can examine the debug log to determine how this negotiation proceeded.

Solution: choose one:

1. provide an IP address on the command line, (see man pppd in the section marked OPTIONS, or just add the IP address followed by a colon, e.g. 10.0.0.1:),
2. change the peer configuration to suggest a local IP address,
3. ensure that the noipdefault option is not being used, and that the system hostname translates to an IP address.

pppd tries to determine your local IP address using the host name. On systems installed without a hostname, this may fail. So set a hostname using thehostname command, and add the IP address to /etc/hosts. This change may require the restart of other processes.

Diagnosis: your pppd is refusing to perform MS-CHAP-V2 authentication. The PPTP Server requires it, and so it terminates the connection. The known causes are:

• pppd could not find a matching entry in the chap-secrets file, (see below for causes)
• pppd was built without MS-CHAP-V2 support (quite uncommon).

The search in the chap-secrets file uses the name and remotename options given to pppd. The name is usually the authentication domain and username. Theremotename is usually PPTP, or the name of the tunnel.

The chap-secrets file is a series of lines with blank separated fields. The file is searched for a line where:

• the first field matches the local name option value (e.g. domain\\username),
• the second field matches the remotename option value (e.g. tunnelname or PPTP), and
• the fourth field contains a valid IP address or asterisk.

Any spaces or special characters in the local name, password, or remote name must be properly quoted. The hash character (#) in a password is a definite cause of this; add quotes around the password to fix it. See man pppd section AUTHENTICATION for more details.

Solution: fix the chap-secrets file or the pppd options so that they match.

Diagnosis: this may be an indication that EAP authentication failed.

Solution: either correct the cause of the authentication failure, or direct the client to refuse EAP authentication by adding refuse-eap to the list of pppdoptions.

If that doesn't fix it, enable debug logging, try the connection again, and look for rejection packets just prior to this message. Decide what to do based on the rejection packets.

Diagnosis: you have given pppd the option require-mppe which forces the use of encryption, but the authentication phase did not use MS-CHAP[v2], it used something else. MPPE requires the use of MS-CHAP[v2] for establishing initial encryption keys. pppd terminates once it detects this conflict.

Solution: either fix the authentication or remove require-mppe.

To find out how authentication happens, enable debug logging, try the connection again to determine what method the peer is offering for authentication. Then configure pppd to refuse that method.

Or, add the following pppd options:

• refuse-eap
• refuse-pap
• refuse-chap
• refuse-mschap

These options configure pppd to refuse to authenticate using certain protocols. As a result, the peer will attempt other protocols, hopefully MS-CHAP[v2]. Do not use require-mschap-v2 because this asks pppd to authenticate the peer, a reversal of what is normally done.

or

Symptom 2: debug logs contain this sequence:

Diagnosis: the local pppd is refusing to accept the level of MPPE encryption required by the peer. The peer insists on that level, and so it terminates the connection.

In the case above, the local pppd has proposed no encryption or compression, but the peer has requested stateless 128-bit encryption. The local pppd rejects the proposal from the peer.

Solution: if you are using the GUI, select the tunnel, click on on the Encryption tab, turn on Require Microsoft Point-to-Point Encryption (MPPE), and Update, and try to Start the tunnel again.

Otherwise, make sure the require-mppe option is provided to the pppd command, such as in the options file or the command line.

with the essential component being the immediate termination by the local host on receipt of a CCP ConfReq that has the encryption bits turned off (-M -S -L).

Diagnosis: this is a defect of pppd on your system. It is terminating the connection on the basis that the peer started to suggest no encryption. Your pppd is not first negotiating to achieve encryption. The version of pppd you are using takes the require-mppe-128 option pedantically; refusing to connect if the peer is configured to allow no encryption, even if the peer may allow encryption after negotiation.