Modify

Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#11545 closed defect (too_vague)

PPTP problem ar71xx

Reported by: r0xmachine@… Owned by: developers
Priority: highest Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

Hi,
since lastest 2 weeks snapshot pptp wont work.
The same configuration and the same pptp server but always the
same error :

peer refused to authenticate

root@OpenWrt:/etc/ppp# ls
chap-secrets filter options options.pptp resolv.conf

Best Regards

Attachments (0)

Change History (14)

comment:1 follow-up: Changed 6 years ago by jow

http://pptpclient.sourceforge.net/howto-diagnosis.phtml

Also paste some logs, your report is far too vague to act upon.

comment:2 in reply to: ↑ 1 Changed 6 years ago by anonymous

Replying to jow:

http://pptpclient.sourceforge.net/howto-diagnosis.phtml

Also paste some logs, your report is far too vague to act upon.


I used since 1 year always the same configuration on tp-link mr3220 with mikrotik pptp server. But Since two week the lastest snapshow the pptp client wont work.

This is my normal installation :

opkg update
opkg install luci
opkg install luci-proto-pptp

My option.pptp file:
lock
noauth
nobsdcomp
nodeflate
idle 0
nomppe
maxfail 0
In the last working snapshot was present this option : defaultroute
but also adding wont work

the /etc/ppp dir :
root@OpenWrt:/etc/ppp# ls
chap-secrets filter options options.pptp resolv.conf

the /etc/config/network :

config interface 'loopback'

option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config interface 'lan'

option ifname 'eth0'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.0.1'
option netmask '255.255.255.0'

#config interface 'wan'
# option ifname 'eth1'
# option proto 'dhcp'

config 'interface' 'wan'

option 'ifname' 'eth1'
option 'proto' 'static'
option 'ipaddr' '172.16.20.100'
option 'netmask' '255.255.0.0'

config 'interface' 'ppp0'

option 'proto' 'pptp'
option 'server' '172.16.0.254'
option 'keepalive' '10'
option 'username' 'test'
option 'password' 'test'

config switch

option name 'eth0'
option reset '1'
option enable_vlan '1'

config switch_vlan

option device 'eth0'
option vlan '1'
option ports '0 1 2 3 4'

this is the log:
May 28 12:56:27 OpenWrt daemon.notice pppd[30232]: Connect: pptp-ppp0 <--> /dev/pts/1
May 28 12:56:27 OpenWrt daemon.notice pptp[31487]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
May 28 12:56:27 OpenWrt daemon.notice pptp[31489]: anon log[main:pptp.c:279]: The synchronous pptp option is NOT activated
May 28 12:56:27 OpenWrt daemon.notice pptp[31487]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
May 28 12:56:27 OpenWrt daemon.notice pptp[31487]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
May 28 12:56:27 OpenWrt daemon.notice pptp[31487]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
May 28 12:56:27 OpenWrt daemon.notice pptp[31487]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.
May 28 12:56:27 OpenWrt daemon.notice pptp[31487]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 3754).
May 28 12:56:28 OpenWrt daemon.info pppd[30232]: LCP terminated by peer (peer refused to authenticate@)
May 28 12:56:28 OpenWrt daemon.notice pptp[31487]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed
May 28 12:56:28 OpenWrt daemon.notice pptp[31487]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown)
May 28 12:56:28 OpenWrt daemon.notice pptp[31487]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
May 28 12:56:28 OpenWrt daemon.notice pptp[31487]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed
May 28 12:56:28 OpenWrt daemon.notice pptp[31487]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)
May 28 12:56:28 OpenWrt daemon.notice pppd[30232]: Modem hangup

Best Regards

comment:3 Changed 6 years ago by anonymous

I confirm that issue.

comment:4 Changed 6 years ago by anonymous

I also confirm this. exactly the same problem. peer refused to authenticate.

comment:5 Changed 6 years ago by anonymous

ok, so I have some more information ( I'm the guy that posted the message just above this one ). Promise I'll create an account later.

So for me this is a two stage problem.
With a standard firewall enabled, I get the "lcp terminated by peer ( peer refused to authenticate ).
if I disable the firewall, then the story is different, and I get:
Jun 1 01:55:47 gateway daemon.info pppd[21813]: Using interface pptp-iPortal
Jun 1 01:55:47 gateway daemon.notice pppd[21813]: Connect: pptp-iPortal <--> /dev/pts/0
Jun 1 01:55:47 gateway daemon.notice pptp[22512]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Jun 1 01:55:47 gateway daemon.notice pptp[22514]: anon log[main:pptp.c:279]: The synchronous pptp option is NOT activated
Jun 1 01:55:47 gateway daemon.notice pptp[22512]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Jun 1 01:55:47 gateway daemon.notice pptp[22512]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Jun 1 01:55:47 gateway daemon.notice pptp[22512]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Jun 1 01:55:47 gateway daemon.notice pptp[22512]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.
Jun 1 01:55:47 gateway daemon.notice pptp[22512]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 23040).
Jun 1 01:55:50 gateway daemon.err pppd[21813]: MPPE required, but MS-CHAP[v2] auth not performed.
Jun 1 01:55:50 gateway daemon.err pppd[21813]: MPPE required, but MS-CHAP[v2] auth not performed.
Jun 1 01:55:50 gateway daemon.notice pppd[21813]: Connection terminated.
Jun 1 01:55:50 gateway daemon.warn pptp[22514]: anon warn[decaps_hdlc:pptp_gre.c:197]: short read (-1): Input/output error
Jun 1 01:55:50 gateway daemon.warn pptp[22514]: anon warn[decaps_hdlc:pptp_gre.c:209]: pppd may have shutdown, see pppd log
Jun 1 01:55:50 gateway daemon.notice pptp[22512]: anon log[callmgr_main:pptp_callmgr.c:231]: Closing connection (unhandled)
Jun 1 01:55:50 gateway daemon.notice pptp[22512]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Jun 1 01:55:50 gateway daemon.notice pptp[22512]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)

this means that we made the auth with pap or chap. I actually know that this server requires mppe encryptation but accepts any kind of auth, meaning that if we try pap or chap we end up being autheticated but not able to use the tunnel as mppe requires mschapv2.

how can I force to use mschapv2 on my side ( pptp client side ) ? there is no option on luci to select the auth type.

comment:6 Changed 6 years ago by reflexing@…

I can confirm this bug. My provider doesn't need MPPE. It doesn't work with MSCHAP v2 as described here and in Ticket #11570 which looks like duplicate.

comment:7 Changed 6 years ago by anonymous

From memory LUCI used to read / display an additional 'options' field (basically whats in the PPTP.options file) - but that is missing from the UI too. Not sure if this implies the whole options string is being omitted from the connection (and its just using the raw PAP/CHAP info you can enter in LUCI)

comment:8 Changed 6 years ago by anonymous

11570 seems to have fixed the problem with me. PPTP now appears to be connecting ok with the same configuration parameters. Suggesting this is now fixed?

comment:9 Changed 6 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

Fixed with r32035

comment:10 Changed 6 years ago by hugolopesousa@…

I seem to have the same problem with the last stable release on my tplink 1043 , what was changed exactly?

comment:11 Changed 4 years ago by kaefert

I've upgraded my TP-Link WR1043ND from backfire 10.03 to attitude adjustment 12.09
http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-sysupgrade.bin (03-Apr-2013 08:15)

With Backfire I couldn't get the router to fake it's MAC-Adress, this now works with Attitude Adjustment. But the pptp tunnel still won't start. I know my Connection-Infos are correct because it works with my Ubuntu laptop and also with my old Netgear Router.

comment:12 Changed 4 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

update to my comment above:
I've now flashed DD-WRT v24 preSP2 (Build 21061) (date: 2013-04-25) to my TP-Link WR1043ND Router - With this firmware I managed to configure a working PPTP client on my router. So the problem was not my devices fault, but OpenWRT's --> This bug doesn't look like fixed to me.

comment:13 Changed 4 years ago by jow

  • Resolution set to too_vague
  • Status changed from reopened to closed

"This bug" has been fixed and your reopened ticket provides zero details. Please open a new ticket and attach logread output and used configuration to it.

comment:14 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.