From: James C. <jam...@hp...> - 2007-10-16 23:33:00
|
I agree, using "strings" it looks like your pppd does not have MPPE support, yet the log you have shows it accepted an MPPE option, so I suspect that the "strings" test may no longer be a valid method. But your actual problem was easy to detect, since I'm familiar with it ... the connection was closed and the critical evidence is: On Tue, Oct 16, 2007 at 10:14:59AM -0400, d spos wrote: > sent [LCP EchoReq id=0x1 magic=0x7cd90286] > rcvd [LCP EchoReq id=0x6 magic=0xc5f4e260] > sent [LCP EchoRep id=0x6 magic=0x7cd90286] > rcvd [LCP EchoReq id=0x7 magic=0xc5f4e260] > sent [LCP EchoRep id=0x7 magic=0x7cd90286] > rcvd [LCP EchoReq id=0x8 magic=0xc5f4e260] > sent [LCP EchoRep id=0x8 magic=0x7cd90286] > rcvd [LCP EchoReq id=0x9 magic=0xc5f4e260] > sent [LCP EchoRep id=0x9 magic=0x7cd90286] Despite sending an echo request (id=0x1), there was no reply from the other end. The other end is regularly sending echo requests and your end is sending replies. > rcvd [LCP TermReq id=0x2 "MPPE disabled"] > LCP terminated by peer (MPPE disabled) The other end disconnects. > Connect time 1.1 minutes. > Sent 454199808 bytes, received 7781 bytes. And your end thinks it has sent 454Mb of data. This is usually caused by routing recursion. Proposed solution: add a route to the PPTP server before you start the tunnel. Reference: http://pptpclient.sourceforge.net/howto-diagnosis.phtml#lots_of_data -- James Cameron http://ftp.hp.com.au/sigs/jc/ |