pptp client
 getting started
 try it
 fedora core 1
 fedora core 2
 fedora core 3
 fedora core 4
 fedora core 5
 fedora core 6
 mandrake 9.0
 mandrake 10.0
 mandrake 10.1
 red hat 9
 red hat 8.0
 red hat 7.3
 suse 10.0
 suse 9.2
 suse 9.1
 suse 8.2
 support faq
 contact us

PPTP Client

Diagnosis HOWTO

by James Cameron
12th April 2006

You're probably here because you have a problem getting PPTP Client to work. There are many reasons why it can fail. Other people may have encountered the problem you have.

This HOWTO is a series of known problems in installation and running order. When the PPTP Client fails, it will display an error message. Search for the message in this page.

For some error messages, more detail will need to be gathered. This is done by enabling debug logging.

Near the end of the document, we also show a fault tree, and some additional documentation for using tools to determine what your problem is.

We thank the many contributors to this page. If you think you've found a solution to a common problem, please write it up in our problem, diagnosis, solution format, and submit it to the mailing list.



Conventions used in this document:

italic text, a program name or option keyword

monospaced text, a file name

blue background, error messages or log output

green background, commands to be entered

red background, quotation

yellow background with black vertical "change bar" on right hand side, text changed in this revision (or the last month)

Installing kernel modules

Installing pppd

Installing pptp

Installing pptpconfig

Running pptpconfig

Running pptp-command

Running pptp

Running pppd (before connection)

Running pppd (during connection)

Running pppd (after connection)

Loading kernel modules

Other Problems

Fault Tree

  1. Ping PPTP Server

    Prove that you can bounce ICMP echo request packets off the PPTP Server. If you can, this shows you have a network connection to it. If you can't, it doesn't prove anything, because it could be firewalled.

    # ping pptpserver

  2. Traceroute to PPTP Server

    Prove that you can trace the route to the PPTP Server. If you can, this shows you have a network connection to it. If you can't, again it doesn't prove anything, because it could be firewalled. However, only you can tell, given your knowledge of the network near you.

    # traceroute pptpserver

  3. Connect to port 1723 on PPTP Server

    Prove that you can connect to the PPTP Server on the TCP/IP port used for call management. If you can, this shows you have half the network connectivity you need. If you can't, you must fix the problem.

    # telnet pptpserver 1723

  4. Check GRE Works

    Prove that you can exchange GRE packets between the PPTP Server and the client. To do this, run a packet tracing tool such as tcpdump at the client while starting the tunnel. You should see a connection to port 1723, followed by GRE packets in both directions. If you are new to tcpdump, we have instructions.

    For diagnosing the point at which GRE is lost in a network path;

    Note: these days with the profusion of cheap consumer-grade NAT routers and gateways, hping2 and GRE traceroute do not work as well as one would like. This is because most NAT routers use stateful inspection of the PPTP control connection to determine how and when to forward the GRE packets. Concentrate on block-box analysis using tcpdump at the end points you have access to.


    Common GRE blockages are as follows:

    • Firewalls and Gateways

      Hosts between your client and the server through which GRE must pass may be configured to block GRE. Using the GRE traceroute programs above you may be able to identify the host that is causing the block.

    • Local Filtering Rules

      The client may be configured to block GRE packets as they arrive, or before they depart. Check your iptables or ipchains configuration.

    • Simultaneous Tunnels via NAT Gateway

      If you have a NAT gateway, such as a DSL router, that presents one IP address to the network on which the PPTP Server is contacted, then only one PPTP connection can be active at once. The PPTP Server will only accept one.

      Attempting to start a second tunnel to another IP address may also fail if the NAT software cannot differentiate the two connections. This may cause the first connection to fail.

    • PPTP Server Misconfiguration

      If the PPTP Server fails to start pppd because of a syntax error in the options file or command line, the effect mimics a total loss of GRE packets from the server end. Check the server logs carefully. Start pppd manually at the server to test the options.

  5. Check MPPE Support

    MPPE support is required if you wish to connect to a PPTP Server such as Microsoft Windows VPN Server. MPPE is built as a Linux kernel module, as part of PPP 2.4.2 or later, and as a patch to the PPP 2.4.0.

    Both of the following tests must pass for MPPE support to function.

  6. Check MPPE in kernel Support

    Make sure the MPPE module can be loaded:

    # modprobe ppp-compress-18

    If this module loads without error, then all is well with it. If errors are generated, you must find the cause and fix it. There are numerous causes of a failure to load. Some of the causes are;

    1. depmod -a was not run after loading a kernel-mppe rpm,
    2. the MPPE module cannot be found in the appropriate /lib/modules directory,
    3. the MPPE module that was found cannot be loaded because of version conflicts,

    1. an old mppe.o file was left around after an upgrade that provided an ppp_mppe.o file (which results in "init_module: File exists" error if the mppe.o module is loaded somehow),

    1. the ppp_generic module cannot activate the MPPE module when it finds it needs it, because you are using PPP-MPPE 2.4.0 and the /etc/modules.conf file does not have an entry for alias ppp-compress-18 mppe,
    2. the PPP modules were compiled into the kernel statically (they must be modules for MPPE to work as a module),
    3. the ppp_async module cannot be loaded (although pptp does not use a serial port, the ppp_async module is required for data transfer with the psuedo-tty device).

  7. Check MPPE in pppd Support

    Make sure the pppd program contains MPPE support by checking for option keywords in the file. If it contains MPPE options, then it has MPPE support. If it has no MPPE options, you must obtain or build an MPPE capable version.

    # strings `which pppd`|grep -i mppe|wc --lines

    For a pppd without MPPE support, the number displayed is zero. For an MPPE capable pppd, the number is about 38, but may vary.

Why are the pppd options different?

PPTP Client depends on PPP. See our diagrams for why. PPP needs MPPE support to interoperate with certain PPTP servers.

There are three PPP MPPE versions, and their history is shown in the graph below:

PPP History Graph

There are two parts to the PPP MPPE support, for each version. One part is in the kernel, and the other part is in the pppd program. These two parts must be the same general version. If they are mixed, the result can be that the pppd program reports the kernel has no support.

Comparing the two versions in detail:

PPP-MPPE 2.4.0

  • no further development?
  • no response to problems
  • has known problems such as kernel panics
  • OpenSSL license directly conflicts with kernel license
  • when loaded, does not indicate a license conflict
  • requires /etc/modules.conf changes
  • module file name mppe.o (or ppp_mppe.o)
  • +mppe-128 (inconsistent with existing option names)
  • mppe-stateless
  • require-chapms-v2 (incorrect protocol name)
PPP 2.4.2 and later

  • ongoing development by PPP project
  • active response to problems by developers
  • has no known problems at this time (stay tuned)
  • BSD license does not conflict (as much) with kernel license
  • when loaded, indicates a license conflict
  • requires no /etc/modules.conf changes
  • module file name ppp_mppe.o
  • require-mppe-128
  • nomppe-stateful
  • require-mschap-v2
The two versions of pppd have different command line options.

If you are upgrading from the old PPP-MPPE 2.4.0 package, change /etc/ppp/options.pptp, and any existing tunnels in /etc/ppp/peers, to adopt correct naming for pppd options relating to MPPE support.

The following table compares the options between the versions.

PPP-MPPE 2.4.0 option PPP 2.4.2 option Explanation
mppe-40 require-mppe require-mppe requires the use of MPPE, disabling all other compression types, and enabling both 40-bit and 128-bit encryption. It is then up to the server what level of encryption is adopted. require-mppe-40 and require-mppe-128 are like require-mppe but use 40-bit and 128-bit encryption respectively, rather than allowing the server to choose.
mppe-128 require-mppe
mppe-stateless nomppe-stateful Stateless is now the default, you'd have to use mppe-stateful to turn it off.
require-chapms-v2 refuse-pap refuse-chap refuse-mschap refuse-eap A client cannot require a method of authentication of itself, but it can refuse a method offered. The "require" forms of these options are intended for use by servers, and if used on a client will force authentication of the server by the client, which will generally fail.

The option naming used previously on the PPTP Client project was for an unofficial MPPE patch to PPP. Since then, the PPP project has derived their own naming that is consistent with other pppd options.

What are those CCP MPPE bitmasks?

PPP negotiates MPPE with the PPTP Server using the Compression Control Protocol (CCP). When using debug logs, pppd decodes the CCP packets. How this is done depends on the version:

The following table describes the bits and their meanings:

PPP-MPPE 2.4.0PPP 2.4.2MeaningExplanation
0x01000000 +H Stateless use stateless encryption (less vulnerable to packet loss).
0x00000080 +M 56-bit use 56-bit key lengths for encryption (not supported).
0x00000040 +S 128-bit use 128-bit key lengths for encryption (less easy to decrypt than 40-bit).
0x00000020 +L 40-bit use 40-bit key lengths for encryption (more easy to decrypt than 128-bit).
0x00000010 +D Obsolete obsolete, usage unknown.
0x00000001 +C Compression use compression, see more about MPPC.

The values in the PPP-MPPE 2.4.0 column must be logically ORed. So, if you see a message <mppe 1 0 0 e1> this shows that the PPTP Server is prepared to support any of the above encryption types. Your system running pppd will likely respond with <mppe 1 0 0 60> which shows that it will not support MPPC, or 56-bit keys, but will support stateless 128-bit or 40-bit encryption.

Wanted: what the various PPTP Servers out there initially propose or will settle on given specific configuration options. We plan to build a list, to make it easier to understand why certain PPTP Servers are giving trouble.

What does ConfReq, ConfAck, ConfNak, and ConfRej mean?

These options and values are desired.
These options and values are acceptable. The ConfAck reply will contain the options and values.
All the options are recognised by the peer, but some of the values in the options are unacceptable. The ConfNak reply will contain the options that were unacceptable, but with values that are acceptable.
The options are not recognised or not acceptable for negotiation by the peer (e.g. because the remote system is configured to not allow negotiation). The ConfRej reply will contain only the options that are unacceptable.

On receipt of a ConfRej, the local system must not include the options in any following ConfReq.

As James Carlson wrote to the linux-ppp mailing list:

    Note that the *only* time you can send Configure-Nak is when you actually recognize all of the options (i.e., you *could* have sent Configure-Ack), but some of the values embedded in the options are themselves unacceptable. Configure-Nak says "yes, I like this option, but if you would please just say you want two slots instead of three, I'd be happy." Configure-Reject says "no, I've never even heard of this option; please don't ask me anything else about it."

See also the PPP RFC 1661.


How to use tcpdump?

tcpdump can be used to capture the packets exchanged between the PPTP Client and the PPTP Server. By comparing the packets with what should be happening, you may determine what the cause of a problem might be.

Give to tcpdump the name of the network interface that connects to the PPTP Server, which for dial-up users would be ppp0, and for ADSL users eth0. Then, in another window or console, start the tunnel.

Start tcpdump in one window: Then run pppd in the other window:
# tcpdump -i eth0

# pppd call tunnel

The tcpdump command should show you the packets as they are received or transmitted. Press Control/C when you do not need to capture any more packets.

You should see a connection to port 1723, followed by GRE packets in both directions. If you can see this, then you have full network connectivity. If you can't, you must find the problem.

Note: if you get an error:

tcpdump: pcap_loop: read: Network is down

then you may be using tcpdump on the wrong interface. Use ifconfig to list the available interfaces and choose the one through which your client must contact the server. See our diagrams if you're still confused.

The above technique is useful for quick checking, but for detailed analysis a binary tcpdump is required.

Security Warning
Internet addresses of your client and server, usernames and passwords are included in a binary tcpdump. This information may allow someone to gain equivalent access to protected networks. If you do not want to give away this information, convert it to text and remove it before sending the log to someone else.

If you have been asked to capture a complete tcpdump packet trace, for analysis by someone else, you should:

  • add -w file to tell it to save the packets to the file file,
  • add -s 0 to capture all of each packet,
  • and add tcp port 1723 or proto 47 to keep only the PPTP packets, if the client is performing other network traffic at the time.
For example:

# tcpdump -i eth0 -w my.tcpdump -s 0 tcp port 1723 or proto 47

Again, once the packets have been collected, use Control/C to stop the tcpdump process. The file containing the packets can then be e-mailed or analysed.

You may analyse it using ethereal.

# ethereal my.tcpdump

Note: when using ethereal, clicking on a byte in the hex dump will highlight the field name of the data in the packet, and vice versa. You may also analyse it using tcpdump:

# tcpdump -n -r my.tcpdump > my.tcpdump.txt

This converts it to text, saving the output into a file my.tcpdump.txt. This often hides the username and password. You may wish to globally substitute the IP addresses. Check your results to ensure your security.


How to enable debug logging?

Add the options debug dump to the pppd command line or options file, then retry the connection. Further information is below. Enabling debug logging is necessary to determine the cause of certain problems. It also gives more information as to why an event happened.

Security Warning
Usernames and passwords from your chap-secrets file may be included in the debug log if you are using the old ppp-mppe package. If you do not want to give away this information, remove it before sending the log to someone else.

How you enable debug logging depends on the method you use to start the tunnel.

usual commandenabling debug logging
pptpconfig click on the tunnel, click on Miscellaneous, click on Enable connection debugging facilities, click on Update, click on Start, examine the output.

Or, if the problem is occuring after a successful connection report:

pppd call tunnel logfd 2 nodetach debug dump

where tunnel is the name of the tunnel you created using the GUI. This command is similar to what the GUI uses to start the tunnel, except for the change to the logfd and nodetach.

pptp-command start start the tunnel manually by typing:

pppd pty 'pptp server --nolaunchpppd' call tunnel debug dump logfd 2 nodetach

Where server is the IP address or host name of the PPTP Server, and tunnel is the name of the /etc/ppp/peers entry that pptp-command created for you.

pon tunnel add
debug dump logfd 2 nodetach

to the end of the command

pptp ip call tunnel
pppd pty 'pptp ip --nolaunchpppd' call tunnel

The dump phrase includes in the debug log each option given to pppd. This is very useful for others who are trying to help you with a problem.

The logfd 2 nodetach phrase is necessary to prevent debug messages from being sent to the PPTP Server, which may confuse it.

To ease collection of the debug log, use the script command to record the output. For example:

# script test.log
# pon tunnel debug dump logfd 2 nodetach

After the command exits, type Control/D or exit and the test.log file will contain a complete log of the session since the script command.

How to enable pptpd debug logging via syslogd?

For users of pptpd, the PPTP server program:
  1. add the keywords debug dump to the /etc/ppp/options.pptpd or /etc/ppp/pptpd-options file, (this is an option for pppd, so there is no need to restart pptpd, the next connection will use the new keywords),

  2. test that syslogd is reporting debug class messages, using the logger command:

    # logger -p daemon.debug some unique test message

    You should see some unique test message added to a log file in the /var/log directory. If no output appears edit /etc/syslogd.conf and add a debug entry, such as:

    1. add the debug entry:

      # PPTP debug logging
      *.debug;mail.none /var/log/debug

    2. touch /var/log/debug

    3. restart syslogd:

      /etc/init.d/sysklogd reload

    Note: this is usually needed on Red Hat derived distributions, because debug logging is disabled.

  3. retry the tunnel, and examine the debug log file,

  4. remove debug once you've fixed the problem, as the logs may cost a lot of disk space and performance.
Derived from a post by Peter Mueller.

How to start a tunnel on demand?

The tunnel can be started in a way that will wait for the first packet to be sent before it establishes the connection to the server. This is called "demand" mode. See our diagram for how it works.

Demand mode is handled by PPP, not by PPTP Client. You must start the tunnel using the pppd command rather than pptp. To enable demand mode, add the demand option to the pppd command, or the /etc/ppp/peers/tunnel file.

If PPP complains that a connect script is required (versions prior to about 2003-07-01 do this) then add the option connect /bin/true.

If you normally have to define specific routes to have the tunnel work to your satisfaction, you will have to define these routes once the PPP interface for the tunnel is created, even though the tunnel is not yet connected. Otherwise, packets that should start the tunnel will be sent out the normal interface instead of the tunnel interface.

The persist option can also be used. This causes the tunnel to be retried if it disconnects. Also check the maxfail option, as the default (10) usually causes the tunnel to eventually stop. Use 0 to say that it should never give up, but remember that this could cause huge amounts of data flow over a long time if the tunnel ever fails in a way that causes PPP to keep trying.

The pptpconfig GUI cannot be used for demand mode, as of 2003-07-30, because it does not set up the routes before starting the pppd process, and it does not show the log of the connection attempt until it succeeds. However, despite these restrictions, if you wish to try it, type demand in the Options for pppd field on the Miscellanous tab, then start the tunnel.


Known Working Log

The following log shows what might normally be expected to appear for a successful connection from a Debian GNU/Linux (potato) client to a Microsoft Windows NT VPN Server. Use this for comparison against your log. The debug option has been supplied to pppd.

Note: this was last updated for PPP-MPPE 2.4.1, which had debugging code for determining where the username and password information was obtained from, and used the old style of MPPE option reporting. PPP 2.4.2 and later generates slightly different output.

# pon tunnel
Using interface ppp1
Connect: ppp1 <--> /dev/pts/1
Looking for secret in /etc/ppp/chap-secrets for client domain\username server PPTP
Got client domain\username
Got server PPTP
Got secret PPTP
Got client password
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x5d4790f> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <auth chap 81> <magic 0x6fe7> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <auth chap 81> <magic 0x6fe7> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x1 <mru 1500>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x5d4790f> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0x5d4790f> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x5d4790f]
rcvd [CHAP Challenge id=0xf4 <13b0a50a64cb40e5e2afbb47186f8255>, name = ""]
Looking for secret in /etc/ppp/chap-secrets for client domain\username server PPTP
Got client domain\username
Got server PPTP
Got secret PPTP
Got client password
sent [CHAP Response id=0xf4 <b6 ... 00>, name = "domain\\username"]
rcvd [LCP EchoRep id=0x0 magic=0x6fe7]
sent [CHAP Response id=0xf4 <b6 ... 00>, name = "domain\\username"]
rcvd [CHAP Success id=0xf4 "S=B8C96D7EC7960C2EC2C096D5C5256C711D435C67"]
Remote message: S=B8C96D7EC7960C2EC2C096D5C5256C711D435C67
sent [IPCP ConfReq id=0x1 <addr> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1 <mppe 1 0 0 60>]
rcvd [CCP ConfReq id=0x1 <mppe 1 0 0 61>]
sent [CCP ConfNak id=0x1 <mppe 1 0 0 60>]
rcvd [IPCP ConfReq id=0x2 <addr>]
sent [IPCP ConfAck id=0x2 <addr>]
rcvd [CHAP Success id=0xf4 "S=B8C96D7EC7960C2EC2C096D5C5256C711D435C67"]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr>]
rcvd [CCP ConfNak id=0x1 <mppe 1 0 0 40>]
sent [CCP ConfReq id=0x2 <mppe 1 0 0 40>]
rcvd [CCP ConfReq id=0x3 <mppe 1 0 0 40>]
sent [CCP ConfAck id=0x3 <mppe 1 0 0 40>]
rcvd [IPCP ConfNak id=0x2 <addr>]
sent [IPCP ConfReq id=0x3 <addr>]
rcvd [CCP ConfAck id=0x2 <mppe 1 0 0 40>]
MPPE 128 bit, stateless compression enabled
rcvd [IPCP ConfAck id=0x3 <addr>]
Cannot determine ethernet address for proxy ARP
local IP address
remote IP address
Script /etc/ppp/ip-up started (pid 14084)
Script /etc/ppp/ip-up finished (pid 14084), status = 0x0


If you have comments on this document, please send them to the author at james.cameron at hp.com.


Reworked root privilege advice following mail from Peter Young.

2006-04-12 Added note about hping2 and GRE traceroute to the section on GRE diagnosis.
2006-03-27 Added explanation for MPPE required, but MS-CHAP[v2] auth not performed..
2006-03-23 Added method ot test debug logging for pptpd.
2006-03-09 Added new solution for MPPE required but peer negotiation failed involving a recent patch to pppd.
2006-01-24 Added explanation of R=0 and R=1 to the CHAP authentication failure section, thanks to a suggestion from Brian Takita.
2006-01-23 Added known problem protocol reject with kernel 2.6.15 and Gentoo, thanks to a report from Carl Michal.
2006-01-20 Minor fix to connection freeze recommendations regarding kernel version, thanks to a report from Charlie Brady.
2005-10-12 Add another way to solve routing loop due to same IP.
2005-09-05 Fix pointer to Jan Dubiec's page.
2005-06-02 Add a section for No auth is possible thanks to a report from Jason Roysdon.
2005-01-19 Added a better explanation for X display access problems, thanks to Brock Steiner for confirming the solutions.
2004-12-09 Reworked for PPP 2.4.3 release.
2004-12-07 Added comment about syslog configuration to debug logging section.
2004-09-02 Noted that embedded blanks in a password cause a CHAP authentication failure.
2004-04-19 Listed authentication options to avoid for remote system is required to authenticate itself.
2004-03-11 Added a solution to Terminating on signal 2 explanation.
2004-03-08 Added Could not determine local IP address explanation, thanks to Onno Zweers for his debug log.
2004-02-27 Added Terminating on signal 2 explanation.
2004-02-18 Added ConfReq, ConfAck, ConfNak, and ConfRej explanation section.
2004-02-16 Revised buffering out-of-order packets explanation following the Chris Wilson's explanation on the mailing list.
2004-02-09 Changed the connections via tunnel freeze section to account for the effect of MTU on MSS, and that MRU doesn't normally need to be changed at all.
2004-02-05 Added a new cause of a routing loop, when interface created has same IP address as host, thanks to MzOzD.
2004-02-02 Added buffering out-of-order packets explanation. Added two new GRE traceroute links to the GRE section, thanks to Chris Wilson.
2004-02-02 Resorted the problems according to when they occur.
2004-02-02 Add explanation for cause of EINVAL on setting PPP discipline. Thanks to Moe on IRC.
2003-12-15 Add a list of alternates to CHAP authentication failed and a write up of E=691 that points at no dialin permission as the caused, contributed by Per Hamnqvist.

2003-10-24 Add hint for init_module: File exists derived from contribution by Martin Ward.

2003-10-21 Add hint about root's PATH contributed by John BouAntoun. Rewrote tcpdump section following feedback from John.

2003-10-14 Add an alternate solution to LCP ProtRej contributed by Leon Brooks.

2003-10-13 Add a Microsoft Windows 2000 client side solution to MPPE required but peer negotiation failed, contributed by Andrew Cilia.

2003-09-04 Add a potential cause for error 629, contributed by Nerijus Baliunas.

2003-09-02 Add more on Input/output error for the server.

2003-08-12 Add more on MPPE required but peer negotiation failed contributed by Rob Gamble.

2003-08-04 Add a link to diagrams in the demand section.

2003-08-01 Add obscure possible return error from modprobe, contributed by Martin Ward.

2003-07-30 Add a "How to start a tunnel on demand?" section, requested by Chris Wilson.

2003-07-09 Add a "bad configure-ack" and an odd "LCP ConfNak MRU" reported by Andrew Lumsdaine.

2003-06-17 Add "MPPE required but peer refused."

2003-06-16 Add "MPPE required but peer negotiation failed."

2003-06-05 Add "MPPE required, but kernel has no support." Reordered the PPP comparison section. Added automatic dates to the end of each change-bar section.

2003-05-30 Add "LCP ConfRej <auth chap MS-v2>" for new PPP version, and remove text that used to say MPPE was required for MS-CHAP-V2 to work. Thanks to Gail Songer.

2003-05-29 Add "EAP Response" thanks to Doug Langille.

2003-05-26 Add "CCP terminated by peer".

2003-05-14 Suggest dump in addition to debug.

2003-05-02 Changed MPPE module test to use ppp-compress-18. Total review of document, added additional solutions in light of recent release of pptp-linux 1.2.0, the pptpconfig GUI, and the kernelmod instructions.

2003-04-14 Add nopcomp as a solution to unsupported protocol 0x2145 received. Suggested by Peter Wilsmore, with confirmation from Bart Coninckx, Duncan Gibb and Abel Lucano.

2003-04-08 Clarify require-mppe option naming. Suggested by Chris King.

2003-04-01 Add another two paths to the IP loop section. Contributed by Frederick C. Druseikis and Sascha Scholz.

2003-03-24 Changes for PPP 2.4.2. Change MPPE option names. Add section explaining option differences. Change MPPE bitmasks section.

2003-03-21 Add special comments for enabling debug logging with pptpconfig when the problem occurs after successful connection.

2003-03-20 Add a new error message reported by pptp-command.

2003-03-17 Add another reason for GRE loss, thanks to Manuel Clos.

2003-02-06 Add pptp-command timeout error, and simplify debug logging section.

2002-12-30 Add contributed (and far simpler) solution to the same-ip problem from Markus Gaugusch.

2002-12-24 Fix incorrect 57-bit reference.

2002-12-23 Include reference to MPPC work by Jan Dubiec.

2002-12-20 Mentioned passwords that contain hash characters, thanks to Chad Beattie.

2002-11-21 Described why ip_gre module acts as a workaround for the protocol not available error.

2002-11-13 Added Eric Stanley's iptables and ip solution to the same IP address dilemma. We met on the #pptp IRC channel, he had the same problem others had, but had the knowledge and experience required to fix it.

2002-11-11 Asked for more information on insecure dependency errors.

2002-10-31 Added another cause for "remote system is required to authenticate". Added routing problems. Added the old insecure dependency error.

2002-10-25 Added another cause for LCP timeout; client transmits sync packets but the server returns asynchronous. Thanks to Ernst via the support tracker.

2002-09-10 Greeno on irc.openprojects.net found that the write to a GRE socket could fail with Operation not permitted if iptables rules were set to prevent GRE traffic.

2002-08-20 Added pointer to ppp_generic.c patches in CVS, and comment about SuSE 8 kernel not including them. Thanks to Carsten Grammes.

2002-08-07 Barvaz encountered a ClarkConnect firewall rule set that stopped all GRE traffic; another cause for no GRE packets being transmitted. Ravi found that the EPROTO error can be fixed by binding the GRE socket early. James documented the use of --clamp-mss-to-pmtu for connections that freeze.
2002-07-17 Mike Machado found a solution for the "short read Protocol not available" problem. Added a CHAP authentication failure due to excessive slashes between domain and username. Noted that the module name may be either ppp_mppe or mppe, thanks to Joona Palaste and Mike Machado.
2002-06-11 Frank Kelbe found a new cause for the authentication required problem, which was caused by overwriting modules after initial installation of MPPE capability.
2002-05-29 Add short read caused by noauth missing. Add remote system required to authenticate. Add explanation of CCP MPPE bitmasks and link log references to the section. Note results of Frank's investigation into FreeBSD MPPC support. Improve conflicts with kernel solution.
2002-05-15 Further clarify the possible causes for MPPE failures, fix links to Fault Tree section, and add a section on 'command not found'. Remove a few HTML structure faults found using weblint. Break out from the page content table to better use the screen space.
2002-05-10Add protocol reject due to mppe-40 being forced on at the PPTP Server.
2002-05-07Add network is unreachable, remove mail addresses.
2002-05-02Fix ambiguity on which interface to use when using tcpdump.
2002-05-01Add note about char-major-108. Clarify logging to stderr.
2002-04-30Add Huelbe Arizon Garcia's IP loop problem as discussed on pptpclient-devel mailing list. Add Mary Deck, James Kenworthy and Farrell Woods problem with carriage returns in pptp-command drop-in configuration files as discussed on an internal Compaq mailing list. Moved to site links.
2002-04-15Add Jes Sorensen's problem when pppd is set to use sync option. Rework section titles and introduction. Add table of contents, conventions and ChangeLog.