|
|
| Line 1: |
Line 1: |
| {{stub}}
| | #redirect [[Some_explanation_to_some_errors_and_warnings#LCP:_timeout_sending_Config-Requests]] |
| | |
| In a direct sense, this means that pppd did not receive any LCP configuration requests from the peer, or was unable to agree on LCP parameters.
| |
| Which doesn't mean much to me either.
| |
| | |
| | |
| If there is something else failing, say, you see "cannot stat() /dev/pts/1" in your logs, you have some other problem on the server end.
| |
| | |
| If not, it's likely to be pppd negotiation.
| |
| | |
| | |
| <!--
| |
| Possibilities:
| |
| * authentication problems (e.g. requiring MSCHAP2 on one end and the other not doing it)
| |
| | |
| * disagreement on features, e.g.
| |
| ** requiring unsupported features
| |
| ** client demands compression when the server has it forced disabled
| |
| | |
| * If you're setting up pptpd:
| |
| ** GRE traffic not getting through one directon or the other (perhaps use tcpdump to check?)
| |
| ** to check
| |
| | |
| | |
| | |
| Enable any logging verbosity and look for errors before this one.
| |
| Note that sometimes the server end is more informative, sometimes the client end is.
| |
| | |
| Without verbose logging you get something like
| |
| Aug 11 13:57:26 hostname pppd[14797]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
| |
| Aug 11 13:57:26 hostname pppd[14797]: pppd 2.4.5 started by root, uid 0
| |
| Aug 11 13:57:26 hostname pppd[14797]: Using interface ppp0
| |
| Aug 11 13:57:26 hostname pppd[14797]: Connect: ppp0 <--> /dev/pts/17
| |
| Aug 11 13:57:56 hostname pppd[14797]: LCP: timeout sending Config-Requests
| |
| Aug 11 13:57:56 hostname pppd[14797]: Connection terminated.
| |
| Aug 11 13:57:56 hostname pppd[14797]: Modem hangup
| |
| Aug 11 13:57:56 hostname pppd[14797]: Exit.
| |
| | |
| | |
| Since I was using pptpd-style VPN, I edited options.pptpd to mention {{inlinecode|debug}} and got a few sequences like:
| |
| Aug 11 14:34:35 tokeh pppd[19619]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x4a8258f3> <pcomp> <accomp>]
| |
| Aug 11 14:34:35 tokeh pppd[19619]: rcvd [LCP ConfReq id=0x0 <mru 1400> <magic 0x629a766d> <pcomp> <accomp> <callback CBCP>]
| |
| Aug 11 14:34:35 tokeh pppd[19619]: sent [LCP ConfRej id=0x0 <callback CBCP>]
| |
| | |
| You want to see a ConfAck, not a ConfRej,
| |
| and also see it move beyond LCP.
| |
| | |
| ConfRej basically means a a requested option is not supported,
| |
| and it is complaining about CBCP. That was solved by disabling LCP extensions on the windows client,
| |
| but was not the real problem.
| |
| -->
| |
| | |
| | |
| Another example:
| |
| I had a problem connecting to my ISP with a USB ADSL modem. This was not likely to be modem driver trouble, more likely to be something while the connection is established.
| |
| Fiddle with your ppp <tt>peers</tt> files. Chances are you're using a stock one that doesn't work with your ISP without some tweaking. In my case the VPI and VCI were incorrect.
| |
| | |
| | |
| | |
| See also:
| |
| * http://pptpclient.sourceforge.net/howto-diagnosis.phtml#lcp_timeout
| |
| | |
| * http://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-ppp/25440-debug-ppp-negotiation.html
| |
| | |
| | |
| [[Category:Unices]]
| |
| [[Category:Networking]]
| |
| [[Category:Warnings and errors]]
| |