|
|
|
|---|
| PPTP Client Diagnosis HOWTO
by James Cameron 10th September 2002 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 in two parts; common problems and a fault tree. The common problems part has error messages along with solutions. The fault tree part is a list of things to check in 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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||
| |||
| |||
| |||
| |||
|
| pptp-command: command not found |
Diagnosis: the pptp-command program is not in your PATH, because pptp requires root to be able to create a raw socket for GRE packet transmission.
Solution: Use the new activation technique. This causes pppd to start pptp attached to a psuedo-tty, rather than the old technique which was to have pptp start pppd. Since pppd is already designed to be started by non-root users, it is better to use this new technique.
| pty "pptp x.x.x.x --nolaunchpppd" |
where tunnel is the name of the tunnel configuration you created, and x.x.x.x is the IP address or host name of the PPTP Server.
| # chmod u+s `which pptp` |
| # 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.
| # pon tunnel |
| error: failed dependencies: ppp <= 2.3.15 conflicts with kernel-2.4.7-10 |
On Red Hat 7.3, the kernel version is usually 2.4.18-3.
Diagnosis: the 2.4.0-4 ppp-mppe package provides a ppp package without a version. The newer Red Hat kernel packages require a specific version, and so the conflict occurs. Since pptp-linux 1.1.0 there is no longer a dependency on ppp-mppe, as many people don't need to interoperate with a Microsoft VPN Server.
Solution: Install the package with --nodeps.
| rpm -Uvh --nodeps ppp-mppe-2.4.0-4.i386.rpm |
The installation script should tell you that you will have to build the kernel module yourself. Follow the instructions provided with the notice to build the kernel module, then follow the instructions provided from the kernel module build to install the new module. Note that the kernel-sources package for your kernel needs to be installed to complete the build.
On Red Hat 7.3, edit /etc/modules.conf and add these lines:
| alias char-major-108 ppp_generic alias ppp-compress-18 mppe |
| modprobe: modprobe: Can't locate module char-major-108 /usr/sbin/pppd: This system lacks kernel support for PPP. This could be because the PPP kernel module could not be loaded, or because PPP was not included in the kernel configuration. |
Diagnosis: the 2.4.0-4 ppp-mppe package adds entries to /etc/modules.conf that work only for Red Hat 6.2.
Solution: Edit the /etc/modules.conf file and change the alias char-major-108 ppp to alias char-major-108 ppp_generic.
| warn[open_inetsock:pptp_callmgr.c:305]: connect: Connection refused fatal[callmgr_main:pptp_callmgr.c:128]: Could not open control connection to x.x.x.x fatal[open_callmgr:pptp.c:278]: Call manager exited with error 256 |
Diagnosis: the host that you provided on the command line has refused connection.
Solution: check the IP address or name of the PPTP Server, and check that the PPTP Server is running properly. Work through the Fault Tree from the top.
| warn[open_inetsock:pptp_callmgr.c:305]: connect: Network is unreachable fatal[callmgr_main:pptp_callmgr.c:128]: Could not open control connection to x.x.x.x fatal[open_callmgr:pptp.c:278]: Call manager exited with error 256 |
Diagnosis: the host that you provided on the command line cannot be reached via the network. This is usually caused by not having an active internet connection at all.
Solution: check the IP address or name of the PPTP Server, and check that the PPTP Server is running properly. Work through the Fault Tree from the top.
| warn[open_inetsock:pptp_callmgr.c:305]: connect: No route to host fatal[callmgr_main:pptp_callmgr.c:128]: Could not open control connection to x.x.x.x fatal[open_callmgr:pptp.c:278]: Call manager exited with error 256 |
Diagnosis: the host that you provided on the command line cannot be reached via the network.
Solution: check the IP address or name of the PPTP Server, and check that the PPTP Server is running properly. Work through the Fault Tree from the top.
| log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:580]: Client connection established. log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:708]: Outgoing call established (call ID 0, peer's call ID 0). log[decaps_hdlc:pptp_gre.c:129]: short read (4294967295): Input/output error log[callmgr_main:pptp_callmgr.c:245]: Closing connection log[pptp_conn_close:pptp_ctrl.c:307]: Closing PPTP connection log[call_callback:pptp_callmgr.c:88]: Closing connection |
Diagnosis: pppd was started by pptp but was unable to operate, and so terminated quickly. pptp 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.
Solution: Enable debug logging and check to see why pppd failed. Search this HOWTO for those messages.
| log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:580]: Client connection established. log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:708]: Outgoing call established (call ID 0, peer's call ID 0). log[decaps_gre:pptp_gre.c:215]: short read (4294967295): Protocol not available log[callmgr_main:pptp_callmgr.c:245]: Closing connection log[pptp_conn_close:pptp_ctrl.c:307]: Closing PPTP connection log[call_callback:pptp_callmgr.c:88]: Closing connection |
Diagnosis: cause unknown.
Solution: load the ip_gre module.
| # modprobe ip_gre |
Ravi noted that this problem may also be fixed by adopting the recent change in CVS that binds the GRE socket prior to calling the server. He says loading the ip_gre module should not be needed. [2002-08-07]
Diagnosis: iptables rules (such as for a firewall configuration) do not allow the interface to emit GRE packets.
Solution: locate the rule that prevents the write, or add a rule to cover it, and retry the tunnel.
| write: warning: Input/output error (5) Modem hangup |
Diagnosis: pptp is not running at the time pppd writes to the psuedo-tty. This may be because you have no pptp program, or it may have failed. Enabling debug logging would show just one message, an LCP write, being sent prior to the write warning.
Solution: check that the pptp program is present, check that the --nolaunchpppd option is being used, and check the messages log for messages emitted by pptp.
| sent [CHAP Response id=0x0 <...>, name = "domain\\\\username"] rcvd [LCP EchoRep id=0x0 magic=0x15973814] rcvd [CHAP Failure id=0x0 "E=691 R=1 C=... V=3"] Remote message: E=691 R=1 C=... V=3 CHAP authentication failed sent [LCP TermReq id=0x3 "Failed to authenticate ourselves to peer"] rcvd [LCP TermAck id=0x3 "Failed to authenticate ourselves to peer"] |
Diagnosis: four slashes have been used instead of two between the domain name and the username. This is a common error, due to the escaping and quoting rules of the shell versus the pppd options file.
Solution: remove two of the slashes.
| The remote system is required to authenticate itself but I couldn't find any suitable secret (password) for it to use to do so. (None of the available passwords would let it use an IP address.) |
There are two known causes for this symptom.
Diagnosis 1: While normally the PPTP Server will require authentication from your client, your pppd configuration files can tell your client to require authentication from the PPTP Server. The message shows there is insufficient information to achieve this, and so pppd stops.
Solution 1: Usually it is not necessary to have the PPTP Server authenticate in this way. Make sure that that noauth option is in the options file, or given to pppd via the command line.
Diagnosis 2: You may have rebuilt the kernel after installing the modules for the PPTP Client. During "make modules_install", you will have overwritten the misc/mppe.o and kernel/drivers/net/ppp_generic.o modules.
Solution 2: reinstall the two modules.
We believe there may be other causes of this error. Please write to the mailing list if this solution does not fix your problem, so that we can work together to improve this HOWTO.
There are a number of possible reasons for the timeout error;
Diagnosis: PPTP servers will not allow a connection to start from the same IP address that they perceive an active connection on already.
Solution: use alternate PPTP server IP addresses.
Diagnosis: you may be running pppd with the pty option and the debug option but not the logfd 2 option. This can cause pppd to send the debug messages out the psuedo-tty file descriptor to the GRE-to-PPP gateway process, and then to the PPTP Server. The server refuses to respond once it sees random traffic like this.
Solution: Add the logfd 2 option.
Symptom: tcpdump shows no GRE packets are being transmitted by the client. strace shows no write() on the GRE socket by the GRE-to-PPP gateway process.
Diagnosis: you may be running pppd with the sync option, which prevents the GRE-to-PPP gateway from forwarding the packets.
Solution: turn off sync and try again.
Symptom: tcpdump shows no GRE packets are being transmitted by the client. However, strace shows a successful write() on the GRE socket by the GRE-to-PPP gateway process.
Diagnosis: your system may have iptables or ipchains rules that prevent GRE transmission. The GRE-to-PPP gateway sends the packets, but they are dropped by the packet filter before being transferred to the interface.
Solution: check the firewall rules, remove or add replacements, and try again. The following iptables rules may be added to allow GRE through eth0. Change eth0 to the name of the interface through which the PPTP Server is contacted.
| iptables --insert OUTPUT 1 \ --source 0.0.0.0/0.0.0.0 \ --destination 0.0.0.0/0.0.0.0 \ --jump ACCEPT --protocol gre \ --out-interface eth0 iptables --insert INPUT 1 \ --source 0.0.0.0/0.0.0.0 \ --destination 0.0.0.0/0.0.0.0 \ --jump ACCEPT --protocol gre \ --in-interface eth0 |
These rules can be refined further to constrain the GRE traffic.
| rcvd [LCP ConfReq id=0x0 <auth chap 81> <magic 0x7a73> <pcomp> <accomp>] sent [LCP ConfRej id=0x0 <auth chap 81> rcvd [LCP TermReq id=0x1 00 00 02 dc] sent [LCP TermAck id=0x1] |
Diagnosis: your pppd is refusing to perform MSCHAP 81 authentication. The PPTP Server requires it, and so it terminates the connection.
Solution 1: make sure your pppd has MPPE support. Prove this using the MPPE step in the Fault Tree.
Solution 2: make sure the domain and username specified in the pppd options has an entry in the /etc/ppp/chap-secrets file. The message sequence also appears if the domain or username is not present.
See below for the most likely cause.
| sent [CCP ConfReq id=0x5] rcvd [CCP ConfNak id=0x5 <mppe 0 0 0 0>] sent [CCP ConfReq id=0x6] rcvd [CCP ConfNak id=0x6 <mppe 0 0 0 0>] sent [CCP ConfReq id=0xa] rcvd [CCP TermReq id=0x3 00 00 02 dc] sent [CCP TermAck id=0x3] sent [LCP EchoReq id=0x1 CCP: timeout sending Config-Requests sent [LCP EchoReq id=0x2 No response to 4 echo-requests Serial link appears to be disconnected. sent [LCP TermReq id=0x3 "Peer not responding"] |
Diagnosis: your pppd is refusing to accept MPPE encryption, despite passing through MSCHAP authentication. The PPTP Server requires MPPE, and so it terminates the connection.
Solution: make sure the MPPE module loads successfully. Prove this using the MPPE step in the Fault Tree.
See below for the most likely cause.
| sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>] sent [CCP ConfReq id=0x1 <mppe 1 0 0 60>] rcvd [CCP ConfReq id=0x3 <mppe 1 0 0 e1>] sent [CCP ConfNak id=0x3 <mppe 1 0 0 60>] rcvd [CCP ConfNak id=0x1 <mppe 1 0 0 40>] sent [CCP ConfReq id=0x2] rcvd [CCP ConfReq id=0x5 <mppe 1 0 0 40>] sent [CCP ConfRej id=0x5 <mppe 1 0 0 40>] rcvd [CCP ConfNak id=0x2 <mppe 1 0 0 40>] sent [CCP ConfReq id=0x3] rcvd [LCP TermReq id=0x6 "#\37777777776U\37777777621\000<..."] LCP terminated by peer (#M-~UM-^Q^@<M-Mt^@^@^BM-f) sent [LCP TermAck id=0x6] |
Diagnosis 1: your pppd is refusing to accept the level of MPPE encryption required by the PPTP Server. The PPTP Server insists on that level, and so it terminates the connection.
Solution 1: make sure the mppe-40, mppe-128 and mppe-stateless options are provided to the pppd command, such as in the options file.
Make sure the MPPE module loads successfully. Prove this using the MPPE step in the Fault Tree.
Diagnosis 2: You may have rebuilt the kernel after installing the modules for the PPTP Client. During "make modules_install", you will have overwritten the misc/mppe.o and kernel/drivers/net/ppp_generic.o modules.
Solution 2: reinstall the two modules.
| sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [CCP ConfReq id=0x2] sent [CCP ConfReq id=0x2] rcvd [CCP TermAck id=0x2] sent [CCP TermReq id=0x3"No compression negotiated"] rcvd [CCP TermAck id=0x3] |
Diagnosis: your pppd is suggesting only deflate and bsdcomp compression options, and not MPPE. The PPTP Server rejects the suggestions and disconnects.
Solution: make sure the mppe-40, mppe-128 and mppe-stateless options are provided to the pppd command, such as in the options file. Make sure the nobsdcomp and nodeflate options are provided, so that pppd does not suggest them.
MPPC is a patent-encumbered compression method for which an open source implementation is unfortunately unavailable.
References:
| Compression methods. ******************** This package supports two packet compression methods: Deflate and BSD-Compress. Other compression methods which are in common use include Predictor, LZS, and MPPC. These methods are not supported for two reasons - they are patent-encumbered, and they cause some packets to expand slightly, which pppd doesn't currently allow for. BSD-Compress is also patent-encumbered (its inclusion in this package can be considered a historical anomaly :-) but it doesn't ever expand packets. Neither does Deflate, which uses the same algorithm as gzip. |
| rcvd [LCP ProtRej id=0x70 59 ae 22 41 d5 15 51 fc 50 3a 4b 21 ...] rcvd [LCP ProtRej id=0x71 b5 a7 dc 7d 99 fd eb ec 92 5e 0b b6 ...] rcvd [LCP ProtRej id=0x72 e9 62 fb 15 c1 b5 e0 b3 92 22 46 1e ...] rcvd [LCP ProtRej id=0x73 19 3d 51 49 25 4f 25 f9 98 0d 1f 70 ...] rcvd [LCP ProtRej id=0x74 cc 09 4e a5 62 59 92 cf 88 8d 4b 99 ...] |
The important pattern appears to be the incrementing first byte.
Diagnosis: the PPTP Server has negotiated mppe-40, but the client has negotiated mppe-128. The protocol reject messages are triggered by the pppd reading the improperly decoded data stream. Cause of this situation is not known, but it may be due to the PPTP Server being configured for 40-bit encryption only.
Solution: remove mppe-128 from the options given to pppd.
| bad bytes thrown away Outgoing call established [60 second delay] Closing PPTP connection |
Diagnosis: the PPTP Server is not conforming to RFC2637, which states that the reserved0 field in the header MUST be zero. It was fixed in 1.1.0-1, thanks to Rein Klazes.
Solution: upgrade to pptp-linux-1.1.0-1 or later.
| rcvd [LCP EchoReq id=0x1 sent [LCP EchoRep id=0x1 sent [LCP EchoReq id=0x1 rcvd [LCP EchoReq id=0x2 sent [LCP EchoRep id=0x2 sent [LCP EchoReq id=0x2 |
which indicates that echo requests from the server are being received by the client, which issues an echo reply, but that echo requests from the client are not generating echo replies from the server.
Diagnosis: the route to the PPTP Server has changed to include the tunnel itself, and packets are being looped. Packets sent through the VPN are being encapsulated in PPP over GRE, and then sent through the same interface again.
See our diagram showing this situation.
Solution: Examine the routing table using netstat -rn before and after the tunnel becomes active. Determine why the route to the PPTP Server is via the tunnel interface. The reasons may be:
If scripts are adding or changing routes, fix them.
If the PPTP Server is providing an incorrect IP address, force a more appropriate address by adding an option such as :10.0.1.1, where 10.0.1.1 is the address to be adopted. It would be better to fix the PPTP Server.
| Not enough space to encrypt packet: 1004<1004+4! |
Solution: patch ppp_generic.c using the patches in this project's CVS repository.
| The patches are in mppe/kernel/kernel, and are
ppp_generic.ccp_max_option_length.patch and
ppp_generic.header_length.patch. Carsten Grammes found that the SuSE 8 kernel (2.4.18-4GB) has MPPE support, but shows this problem. The patches above solved the problem. [2002-08-23]
|
Problem: TCP connections via the tunnel freeze once they attempt to transfer large amounts of data.
Diagnosis: MTU in use may exceed capability of the tunnel.
Solution: verify that the MTU and MRU parameters are given as options to the pppd program, either in the peers file for the tunnel, in the options file, or on the command line. The parameters known to work are:
| mtu 1000 mru 1000 |
(However recent tests have shown an MTU of 1500 also seems to work fine, on Linux 2.4.18.)
Problem: TCP connections using the PPTP Client host as a hop in the route (such as via normal routing, NAT or IP masquerading) freeze once they attempt to transfer large amounts of data.
Diagnosis: Path MTU Discovery may not be working, due to hosts on the route refusing to forward ICMP responses.
Solution: if using Linux 2.2, reduce the MTU on all hosts using the PPTP Client host as their route. If using Linux 2.4, add the following iptables rule:
| iptables --append FORWARD --protocol tcp \ --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu |
For more information, see section 15.7, Circumventing Path MTU Discovery issues with MSS Clamping (for ADSL, cable, PPPoE & PPtP users) in the Linux Advanced Routing & Traffic Control HOWTO.
| WARNING: the line: # whatever contains unsafe characters! |
Solution: check for carriage return characters in the drop-in configuration file and remove them.
| % od -c /tmp/config|grep "\n" % tr --delete '\r' < /tmp/config > /tmp/config.new |
| # ping pptpserver |
| # traceroute pptpserver |
| # telnet pptpserver 1723 |
Gordon Chaffee and Neale Banks have contributed a patch to traceroute to provide an option to use GRE packets. This may prove useful to identify the cause of a GRE blockage.
Common GRE blockages are as follows:
Hosts between your client and the server through which GRE must pass may be configured to block GRE. Using the GRE traceroute above you may be able to identify the host that is causing the block.
The client may be configured to block GRE packets as they arrive, or before they depart. Check your iptables or ipchains configuration.
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.
Both of the following tests must pass for MPPE to function.
| # modprobe mppe |
Note: the kernel module name may be either mppe or ppp_mppe. Generally we have found that Red Hat based distributions using kernel version 2.4.x use mppe, and some other distributions such as Debian use ppp_mppe. The change of name may be due to the ppp-mppe source package, but we're not sure. If you have /etc/modules.conf aliases they must match the module name.
There are numerous causes of a failure to load. Some of the causes are;
| # strings `which pppd`|grep -i mppe|wc --lines |
For a pppd without MPPE support, the number displayed is zero. For a MPPE capable pppd, the number is about 38, but may vary.
| 0x01000000 | MPPE_STATELESS - use stateless encryption. |
|---|---|
| 0x00000080 | MPPE_57BIT - use 57-bit key lengths for encryption. |
| 0x00000040 | MPPE_128BIT - use 128-bit key lengths for encryption. |
| 0x00000020 | MPPE_40BIT - use 40-bit key lengths for encryption. |
| 0x00000001 | MPPC - use compression, see more about MPPC. |
The values must be logically ORed. So, if you see a message <mppe 1 0 0 e1> which 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 show that it will not support MPPC, or 57-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.
| # tcpdump -i ppp0 # pppd call tunnel |
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.
If you get:
| 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.
| Usernames and passwords from your chap-secrets file are included in the debug log. If you do not want to give away this information, remove it before sending the log to someone else. |
For example:
| # script test.log # pppd call tunnel debug 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.
If you see binary data, you may have configured your peer file for the older style activation, and so you should try that instead:
| # script test.log # pptp 10.0.0.1 call tunnel debug logfd 2 nodetach |
Under some circumstances, it may be necessary to ensure that the PPTP Client itself also logs to the same place as pppd. Rein Klazes wrote:
| I think there is a problem with how Debian packages ppp and the pptp
log their messages. pppd uses facility LOG_LOCAL2 to log debug
messages and pptp uses LOG_DAEMON. With the default /etc/syslog.conf,
these messages will be logged to different files. I think the easiest way is to add a line like: local2.* -/var/log/daemon.log to /etc/syslog.conf, do a "killall -HUP syslogd" and try to connect again. This time post the lines from /var/log/daemon.log Rein. |
| # 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 10.0.0.1> <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 168.192.232.31>] sent [IPCP ConfAck id=0x2 <addr 168.192.232.31>] rcvd [CHAP Success id=0xf4 "S=B8C96D7EC7960C2EC2C096D5C5256C711D435C67"] rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] sent [IPCP ConfReq id=0x2 <addr 10.0.0.1>] 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 168.192.232.42>] sent [IPCP ConfReq id=0x3 <addr 168.192.232.42>] rcvd [CCP ConfAck id=0x2 <mppe 1 0 0 40>] MPPE 128 bit, stateless compression enabled rcvd [IPCP ConfAck id=0x3 <addr 168.192.232.42>] Cannot determine ethernet address for proxy ARP local IP address 168.192.232.42 remote IP address 168.192.232.31 Script /etc/ppp/ip-up started (pid 14084) Script /etc/ppp/ip-up finished (pid 14084), status = 0x0 |
| Date | Change | ||
|---|---|---|---|
| 2002-09-10 |
| ||
| 2002-08-20 |
| ||
| 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-10 | Add protocol reject due to mppe-40 being forced on at the PPTP Server. | ||
| 2002-05-07 | Add network is unreachable, remove mail addresses. | ||
| 2002-05-02 | Fix ambiguity on which interface to use when using tcpdump. | ||
| 2002-05-01 | Add note about char-major-108. Clarify logging to stderr. | ||
| 2002-04-30 | Add 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-15 | Add Jes Sorensen's problem when pppd is set to use sync option. Rework section titles and introduction. Add table of contents, conventions and ChangeLog. |
