Bug 620625
| Summary: | pptp stopped working | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | yyetim | ||||
| Component: | pptp | Assignee: | Paul Howarth <paul> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 13 | CC: | jskala, jwboyer, paul | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-06-29 12:37:57 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
What has changed since this last worked for you? When you say the same settings work on a different distro, is that on the same machine on the same network? You may want to look at the PPTP problem diagnostic page: http://pptpclient.sourceforge.net/howto-diagnosis.phtml#lcp_timeout Yes, same machine with dual boot. I am posting a longer output below: Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'... Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 3308 Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> VPN service 'org.freedesktop.NetworkManager.pptp' appeared, activating connections Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> VPN plugin state changed: 3 Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> VPN connection 'VPN connection 1' (Connect) reply received. Aug 16 08:20:53 yyetim-laptop pppd[3310]: Warning: can't open options file /root/.ppprc: Permission denied Aug 16 08:20:53 yyetim-laptop pppd[3310]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded. Aug 16 08:20:53 yyetim-laptop pppd[3310]: pppd 2.4.5 started by root, uid 0 Aug 16 08:20:53 yyetim-laptop pppd[3310]: Using interface ppp0 Aug 16 08:20:53 yyetim-laptop pppd[3310]: Connect: ppp0 <--> /dev/pts/1 Aug 16 08:20:53 yyetim-laptop pptp[3312]: nm-pptp-service-3308 log[main:pptp.c:314]: The synchronous pptp option is NOT activated Aug 16 08:20:53 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_rep:pptp_ctrl.c:254]: Sent control packet type is 1 'Start-Control-Connection-Request' Aug 16 08:20:53 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_disp:pptp_ctrl.c:754]: Received Start Control Connection Reply Aug 16 08:20:53 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_disp:pptp_ctrl.c:788]: Client connection established. Aug 16 08:20:54 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_rep:pptp_ctrl.c:254]: Sent control packet type is 7 'Outgoing-Call-Request' Aug 16 08:20:54 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_disp:pptp_ctrl.c:873]: Received Outgoing Call Reply. Aug 16 08:20:54 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_disp:pptp_ctrl.c:912]: Outgoing call established (call ID 0, peer's call ID 15620). Aug 16 08:21:24 yyetim-laptop pppd[3310]: LCP: timeout sending Config-Requests Aug 16 08:21:24 yyetim-laptop pppd[3310]: Connection terminated. Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <warn> VPN plugin failed: 1 Aug 16 08:21:24 yyetim-laptop pppd[3310]: Modem hangup Aug 16 08:21:24 yyetim-laptop pptp[3312]: nm-pptp-service-3308 warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error Aug 16 08:21:24 yyetim-laptop pptp[3312]: nm-pptp-service-3308 warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log Aug 16 08:21:24 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[callmgr_main:pptp_callmgr.c:235]: Closing connection (unhandled) Aug 16 08:21:24 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_rep:pptp_ctrl.c:254]: Sent control packet type is 12 'Call-Clear-Request' Aug 16 08:21:24 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[call_callback:pptp_callmgr.c:79]: Closing connection (call state) Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <warn> VPN plugin failed: 1 Aug 16 08:21:24 yyetim-laptop pppd[3310]: Exit. Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <warn> VPN plugin failed: 1 Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <info> VPN plugin state changed: 6 Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <info> VPN plugin state change reason: 0 Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <warn> error disconnecting VPN: Could not process the request because no VPN connection was active. Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS. Nothing has changed since it last worked. But I think Fedora 13 updated the pptp package, that might be the problem. If you revert to an older version of pptp, does it work? You might try "yum downgrade pptp", or if that doesn't help, you can find older versions of pptp here: http://koji.fedoraproject.org/koji/packageinfo?packageID=3515 I tried downgrading. It still doesn't work. I updated it again, and tried the manual debug commands as explained on the ptppclient sourceforge page but it doesn't give me any additional information. It keeps sending LCP requests, then gives up. Below is the output (changed personal stuff to my_...): pppd options in effect: debug # (from command line) nodetach # (from command line) logfd 2 # (from command line) dump # (from command line) noauth # (from /etc/ppp/options.pptp) refuse-pap # (from /etc/ppp/options.pptp) refuse-chap # (from /etc/ppp/options.pptp) refuse-mschap # (from /etc/ppp/options.pptp) refuse-eap # (from /etc/ppp/options.pptp) name There\\my_username # (from /etc/ppp/peers/there) remotename PPTP # (from /etc/ppp/peers/there) # (from /etc/ppp/options.pptp) pty pptp my_server --nolaunchpppd # (from /etc/ppp/peers/there) ipparam there # (from /etc/ppp/peers/there) nobsdcomp # (from /etc/ppp/options.pptp) nodeflate # (from /etc/ppp/options.pptp) require-mppe-128 # (from /etc/ppp/peers/there) using channel 9 Using interface ppp0 Connect: ppp0 <--> /dev/pts/1 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>] LCP: timeout sending Config-Requests Connection terminated. Modem hangup Waiting for 1 child processes... script pptp my_server --nolaunchpppd, pid 2852 Script pptp my_server --nolaunchpppd finished (pid 2852), status = 0x0 vpn2.Princeton.EDU > ool-457ea4a2.dyn.optonline.net: GREv1, Flags [key present, sequence# present, ack present], call 0, seq 2, ack 1, length 26 LCP, Conf-Reject (0x04), id 1, length 8 encoded length 6 (=Option(s) length 2) 0x0000: c021 0401 0006 ACFC Option (0x08), length 2: 18:46:44.189072 IP (tos 0x0, ttl 64, id 16407, offset 0, flags [DF], proto GRE (47), length 56) This is the tcpdump package I found the problem. When I create a wireless connection using "Create New Wireless Network" in the network manager, PPTP stops working. If I remove the connection I created and reboot, PPTP starts working again. It's probably a routing problem then. See what your routes look like before/after creating your wireless connection: $ netstat -rn It's possible that the wireless connection is replacing the route that you use to communicate with the PPTP server. Here are some steps and outputs: 1) Connect to existing wireless network -- Successful 2) Connect to PPTP server -- Successful 3) Disconnect from the PPTP server -- Successful 4) Create "New Wireless Connection" from Network manager -- Successful 5) Remove "New Wireless Connection" from Network Manager -- Successful Output of `netstat -rn`: [yyetim@yyetim-laptop ~]$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 6) Connect to existing wireless network -- Successful Output of `netstat -rn`: [yyetim@yyetim-laptop ~]$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 140.180.0.0 0.0.0.0 255.255.192.0 U 0 0 0 wlan0 0.0.0.0 140.180.0.1 0.0.0.0 UG 0 0 0 wlan0 7) Connect to PPTP server -- UNSUCCESSFUL Output of `netstat -rn`: [yyetim@yyetim-laptop ~]$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 128.112.64.210 140.180.0.1 255.255.255.255 UGH 0 0 0 wlan0 140.180.0.0 0.0.0.0 255.255.192.0 U 0 0 0 wlan0 0.0.0.0 140.180.0.1 0.0.0.0 UG 0 0 0 wlan0 Even if I connect to the internet using ethernet, it still fails at the same step. What can be the remnants of a deleted "New Wireless Connection"?? (In reply to comment #9) > Here are some steps and outputs: > > 1) Connect to existing wireless network -- Successful What did "netstat -rn" look like at this point? > 2) Connect to PPTP server -- Successful What did "netstat -rn" look like at this point? > 3) Disconnect from the PPTP server -- Successful What did "netstat -rn" look like at this point? > 4) Create "New Wireless Connection" from Network manager -- Successful What did "netstat -rn" look like at this point? > 5) Remove "New Wireless Connection" from Network Manager -- Successful > Output of `netstat -rn`: > [yyetim@yyetim-laptop ~]$ netstat -rn > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 6) Connect to existing wireless network -- Successful > Output of `netstat -rn`: > [yyetim@yyetim-laptop ~]$ netstat -rn > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 140.180.0.0 0.0.0.0 255.255.192.0 U 0 0 0 wlan0 > 0.0.0.0 140.180.0.1 0.0.0.0 UG 0 0 0 wlan0 Can you ping 128.112.64.210 at this point? > 7) Connect to PPTP server -- UNSUCCESSFUL > Output of `netstat -rn`: > [yyetim@yyetim-laptop ~]$ netstat -rn > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 128.112.64.210 140.180.0.1 255.255.255.255 UGH 0 0 0 wlan0 > 140.180.0.0 0.0.0.0 255.255.192.0 U 0 0 0 wlan0 > 0.0.0.0 140.180.0.1 0.0.0.0 UG 0 0 0 wlan0 Can you ping 128.112.64.210 at this point? > Even if I connect to the internet using ethernet, it still fails at the same > step. What can be the remnants of a deleted "New Wireless Connection"?? There is still a host route to the PPTP server set up at this point (the additional line in the netstat output). You might try deleting it and seeing if that helps (need to be root for that): # ip route del 128.112.64.210/32 via 140.180.0.1 dev wlan0 ;; This buffer is for notes you don't want to save, and for Lisp evaluation. ;; If you want to create a file, visit that file with C-x C-f, ;; then enter the text in that file's own buffer. 1) Connected to eth0: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 2) Connected to PPTP: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 128.112.64.210 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 3) Disconnected from PPTP Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 4) Reconnected/disconnected to/from PPTP (same as 2 and 3) 5) Created New Wireless Network: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 10.42.43.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 6) Disconnected from New Wireless Network Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 7) Tried to connect to PTPP -- UNSUCCESSFUL: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 8) Executed ip route del 128.112.64.210/32 via 69.126.164.1 dev eth0: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 9) Tried to connect to PPTP -- UNSUCCESSFUL: 128.112.64.56 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 (In reply to comment #11) > ;; This buffer is for notes you don't want to save, and for Lisp evaluation. > ;; If you want to create a file, visit that file with C-x C-f, > ;; then enter the text in that file's own buffer. > 1) Connected to eth0: > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 > 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 OK, standard set up with default route via 69.126.164.1 on eth0. > 2) Connected to PPTP: > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 > 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 > 128.112.64.210 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 > 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 As before, but with host route to PPTP server 128.112.64.210 (via eth0) added twice and default route switched to the tunnel. pptp will have added one of these host routes (new in 1.7.2) and NetworkManager-pptp probably added the other. > 3) Disconnected from PPTP > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 > 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 > 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 Back to original state, except that one of the host routes has remained. This will be the one that pptp added. > 4) Reconnected/disconnected to/from PPTP (same as 2 and 3) > 5) Created New Wireless Network: > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 > 10.42.43.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 > 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 > 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 No difference here except that you've added a new route to 10.42.43.0/24 via wlan0. > 6) Disconnected from New Wireless Network > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 > 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 > 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 Back to same state as (3). > 7) Tried to connect to PTPP -- UNSUCCESSFUL: > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 128.112.64.210 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 > 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 > 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 No change. > 8) Executed ip route del 128.112.64.210/32 via 69.126.164.1 dev eth0: > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 > 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 Back to same state as (1). > 9) Tried to connect to PPTP -- UNSUCCESSFUL: > 128.112.64.56 69.126.164.1 255.255.255.255 UGH 0 0 0 eth0 > 69.126.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 > 0.0.0.0 69.126.164.1 0.0.0.0 UG 0 0 0 eth0 Hmm, doesn't look like a routing problem then. Perhaps a firewall issue? If you disable the firewall ("service ipstables stop") prior to trying to connect, does that help? I'll try that too but I don't think that's the problem. Why would the vpn server be sending me LCP-Reject packages if the problem is the iptables? Ah yes, I missed that in comment #6 although I'd have expected to see it in comment #5 too. I was trying to think of something that might have been changed as a result of adding/removing a connection in NM... This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 436184 [details] Settings for failed connection Description of problem: Version-Release number of selected component (if applicable): pptp-1.7.2-9.fc13.i686 NetworkManager-pptp-0.8.0-1.git20100411.fc13.i686 How reproducible: Always Steps to Reproduce: 1. Create new vpn connection with pptp 2. Enter similar settings as in the attachment: 3. Reboot, try connecting from network-manager-applet by clicking the connection. Actual results: Waits and /var/log/messages has: LCP: timeout sending Config-Requests Connection terminated. VPN plugin failed: 1 short read (-1): Input/output error Expected results: Connected Additional info: Same settings work on a different distro (and used to work on Fedora)