Menu
▾
▴
Re: [pptp-devel] LCP: timeout sending Config-Requests
|
From: Richard G. <go...@ya...> - 2004-10-18 01:43:26
|
I use wlan0 to get on the internet. The following are the tcpdump messages. Seems there is no return from the server, how come? ------------------------------------------------------ 20:34:03.737865 00:30:2d:87:16:42 IPX > bf:79:94:fe:ff:ff sap 23 83/F len=38 20:34:03.824606 IP 192.168.1.101.32773 > ns1.lu.dl.cox.net.domain: 34517+ A? vpn.ttu.edu. (29) 20:34:03.825841 IP 192.168.1.101.32774 > ns1.lu.dl.cox.net.domain: 33703+ PTR? 245.208.1.68.in-addr.arpa. (43) 20:34:03.837842 IP ns1.lu.dl.cox.net.domain > 192.168.1.101.32773: 34517 2/3/3 CNAME[|domain] 20:34:03.839238 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: S 3400812221:3400812221(0) win 5840 <mss 1460,sackOK,timestamp 1912623 0,nop,wscale 0> 20:34:03.844823 IP ns1.lu.dl.cox.net.domain > 192.168.1.101.32774: 33703 1/3/3 (183) 20:34:03.845250 IP 192.168.1.101.32774 > ns1.lu.dl.cox.net.domain: 33704+ PTR? 101.1.168.192.in-addr.arpa. (44) 20:34:03.860819 IP ns1.lu.dl.cox.net.domain > 192.168.1.101.32774: 33704 NXDomain 0/1/0 (121) 20:34:03.861168 IP 192.168.1.101.32774 > ns1.lu.dl.cox.net.domain: 33705+ PTR? 114.4.118.129.in-addr.arpa. (44) 20:34:03.876812 IP ns1.lu.dl.cox.net.domain > 192.168.1.101.32774: 33705 1/3/3 (209) 20:34:03.880825 IP acvp01-public.ttu.edu.1723 > 192.168.1.101.32838: S 1818216606:1818216606(0) ack 3400812222 win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 8640336 1912623> 20:34:03.880875 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: . ack 1 win 5840 <nop,nop,timestamp 1912664 8640336> 20:34:03.881823 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: P 1:157(156) ack 1 win 5840 <nop,nop,timestamp 1912665 8640336>: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) [|pptp] 20:34:03.924819 IP acvp01-public.ttu.edu.1723 > 192.168.1.101.32838: P 1:157(156) ack 157 win 8192 <nop,nop,timestamp 8640336 1912665>: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(S) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(774) [|pptp] 20:34:03.924866 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: . ack 157 win 6432 <nop,nop,timestamp 1912708 8640336> 20:34:04.883955 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: P 157:325(168) ack 157 win 6432 <nop,nop,timestamp 1913668 8640336>: pptp CTRL_MSGTYPE=OCRQ CALL_ID(0) CALL_SER_NUM(0) MIN_BPS(2400) MAX_BPS(10000000) BEARER_TYPE(Any) [|pptp] 20:34:04.920648 IP acvp01-public.ttu.edu.1723 > 192.168.1.101.32838: P 157:189(32) ack 325 win 8192 <nop,nop,timestamp 8640338 1913668>: pptp CTRL_MSGTYPE=OCRP CALL_ID(14657) PEER_CALL_ID(0) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(10000000) RECV_WIN(16) PROC_DELAY(1) [|pptp] 20:34:04.920691 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: . ack 189 win 6432 <nop,nop,timestamp 1913704 8640338> 20:34:04.921646 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 1 gre-ppp-payload 20:34:07.820627 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 2 gre-ppp-payload 20:34:09.676852 00:30:bd:ec:ca:42 sap 80 > 78:1b:a7:ff:ff:ff proway-nm I (s=119,r=47,R) len=37 20:34:10.821194 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 3 gre-ppp-payload 20:34:13.821732 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 4 gre-ppp-payload 20:34:16.822219 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 5 gre-ppp-payload 20:34:19.822755 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 6 gre-ppp-payload 20:34:22.823320 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 7 gre-ppp-payload 20:34:25.823858 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 8 gre-ppp-payload 20:34:28.824387 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 9 gre-ppp-payload 20:34:31.824980 IP 192.168.1.101 > acvp01-public.ttu.edu: call 14657 seq 10 gre-ppp-payload 20:34:32.716010 80:5a:bc:c6:16:42 sap 76 > 9f:c9:ff:ff:ff:ff sap f6 I (s=7,r=39,F) len=37 20:34:33.637864 a0:62:60:a6:02:43 sap 68 > 95:fe:ff:77:01:d7 sap a3 I (s=62,r=57,R) len=37 20:34:34.251762 00:30:bd:13:14:42 sap 80 > Broadcast sap 23 rnr (r=48,R) len=37 20:34:34.885039 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: P 325:341(16) ack 189 win 6432 <nop,nop,timestamp 1943673 8640338>: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0) 20:34:34.922658 IP acvp01-public.ttu.edu.1723 > 192.168.1.101.32838: P 189:337(148) ack 341 win 8192 <nop,nop,timestamp 8640398 1943673>: pptp CTRL_MSGTYPE=CDN CALL_ID(14657) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) [|pptp] 20:34:34.922715 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: . ack 337 win 7504 <nop,nop,timestamp 1943711 8640398> 20:34:34.923638 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: P 341:357(16) ack 337 win 7504 <nop,nop,timestamp 1943711 8640398>: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0) 20:34:35.151610 IP acvp01-public.ttu.edu.1723 > 192.168.1.101.32838: . ack 357 win 8192 <nop,nop,timestamp 8640399 1943711> 20:34:35.151647 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: P 357:373(16) ack 337 win 7504 <nop,nop,timestamp 1943940 8640399>: pptp CTRL_MSGTYPE=StopCCRQ REASON(3) 20:34:35.189594 IP acvp01-public.ttu.edu.1723 > 192.168.1.101.32838: P 337:353(16) ack 373 win 8192 <nop,nop,timestamp 8640399 1943940>: pptp CTRL_MSGTYPE=StopCCRP RESULT_CODE(1) ERR_CODE(0) 20:34:35.189785 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: F 373:373(0) ack 353 win 7504 <nop,nop,timestamp 1943978 8640399> 20:34:35.193596 IP acvp01-public.ttu.edu.1723 > 192.168.1.101.32838: F 353:353(0) ack 373 win 8192 <nop,nop,timestamp 8640399 1943940> 20:34:35.193616 IP 192.168.1.101.32838 > acvp01-public.ttu.edu.1723: . ack 354 win 7504 <nop,nop,timestamp 1943982 8640399> 20:34:35.224586 IP acvp01-public.ttu.edu.1723 > 192.168.1.101.32838: . ack 374 win 8192 <nop,nop,timestamp 8640399 1943978> ------------------------------------------------------ --- James Cameron <jam...@hp...> wrote: > On Sat, Oct 16, 2004 at 08:52:59PM -0700, Richard > Gong wrote: > > I can't get the pptp client work. It has the > following > > error: > > sent [LCP ConfReq id=0x1 <asyncmap 0x0 <magic > > 0x8d2b2758> <pcomp> <accomp>] > > After trying several times, it terminated by > timeout. > > This shows an inability to send GRE packets to the > server, or for the > GRE packets from the server to arrive back at the > client. > http://pptpclient.sourceforge.net/howto-diagnosis.phtml#lcp_timeout > > > The error is got when I run tcpdump -i ppp0 > > ioctl: No such device > > At this stage, there is no ppp0 because the tunnel > is not established. > To check the GRE data flow, run tcpdump against eth0 > instead. > http://pptpclient.sourceforge.net/howto-diagnosis.phtml#tcpdump > says > this "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." > > We cannot make an assumption as to what it would be > for you, so I don't > see that I need to change this. > > On Sun, Oct 17, 2004 at 10:42:22AM -0700, Richard > Gong wrote: > > I'm using Debian sid and have upgraded the kernel > to > > the newest 2.6.8 with the mppe patch also. I do > need > > the mppe to connect to the server. > > By the way, the problem you reported above (LCP > timeout) has nothing to > do with MPPE. It would happen regardless of whether > the server or the > client required or didn't need MPPE support. LCP is > the link control > protocol. MPPE is negotiated in the compression > control protocol (CCP) > which occurs after LCP is successfully started. > Your error so far shows > that LCP is not working. > > > Now the problem is like the pptp client doesn't > emulate a ppp0 > > interface I think. > > No, I don't think this is the problem. > > > I checked the config file in /etc/ppp/peers/{VPN}, > and > > it seems there's no problem. The pppd is 2.4.2; > the > > noauth parameter is being used. > > Any idea? > > I would use tcpdump to prove that GRE packets are > being emitted by the > client in the direction of the server. I would also > check to see if any > are coming back. If none are coming back, then the > possible causes are; > > a) GRE packets are not reaching the server, because > they are being > dropped by intervening equipment, such as ADSL > modems (which are > routers), > > b) GRE packets from the server are not reaching the > client, because they > are being dropped by other equipment, or because the > client's firewall > rules are preventing them from being accepted. > > See > http://pptpclient.sourceforge.net/howto-diagnosis.phtml#gre > > -- > James Cameron > http://quozl.netrek.org/ > HP Open Source, Volunteer > http://opensource.hp.com/ > PPTP Client Project, Release Engineer > http://pptpclient.sourceforge.net/ > _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com |
