Modify

Opened 6 years ago

Closed 5 years ago

Last modified 4 years ago

#11681 closed defect (fixed)

pppoe seems not retried after CHAP authentication failure

Reported by: hato Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

I'm running self-compiled OpenWrt Attitude Adjustment on a WNDR3700 v1. In recent releases (now r32343), I noticed that sometimes after restarting the router, the pppoe connection was not brought up, but it should since the pppoe connection was set as thefollowing:

config interface 'wan'
        option auto '1'
        option ifname 'eth1'
        option defaultroute '1'
        option proto 'pppoe'
        option keepalive '10'
        option demand '0'
        option peerdns '0'
        option username 'xxx'
        option password 'xxxxxx'

When the connection was brought up successfully, the pppd related log was like this:

Jun 15 17:36:07 WNDR3700 daemon.info pppd[740]: Plugin rp-pppoe.so loaded.
Jun 15 17:36:07 WNDR3700 daemon.info pppd[740]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
Jun 15 17:36:07 WNDR3700 daemon.notice pppd[740]: pppd 2.4.5 started by root, uid 0
Jun 15 17:36:12 WNDR3700 daemon.info pppd[740]: PPP session is 1939
Jun 15 17:36:12 WNDR3700 daemon.warn pppd[740]: Connected to xx:xx:xx:xx:xx:xx via interface eth1
Jun 15 17:36:12 WNDR3700 daemon.info pppd[740]: Using interface pppoe-wan
Jun 15 17:36:12 WNDR3700 daemon.notice pppd[740]: Connect: pppoe-wan <--> eth1
Jun 15 17:36:13 WNDR3700 daemon.info pppd[740]: CHAP authentication succeeded: CHAP authentication success, unit 4597
Jun 15 17:36:13 WNDR3700 daemon.notice pppd[740]: CHAP authentication succeeded
Jun 15 17:36:13 WNDR3700 daemon.notice pppd[740]: peer from calling number xx:xx:xx:xx:xx:xx authorized
Jun 15 17:36:13 WNDR3700 daemon.notice pppd[740]: local  IP address xxx.xxx.xxx.xxx
Jun 15 17:36:13 WNDR3700 daemon.notice pppd[740]: remote IP address xxx.xxx.xxx.xxx

When failed, the log was like this:

Jun 15 17:40:07 WNDR3700 daemon.info pppd[748]: Plugin rp-pppoe.so loaded.
Jun 15 17:40:07 WNDR3700 daemon.info pppd[748]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
Jun 15 17:40:07 WNDR3700 daemon.notice pppd[748]: pppd 2.4.5 started by root, uid 0
Jun 15 17:40:12 WNDR3700 daemon.info pppd[748]: PPP session is 2802
Jun 15 17:40:12 WNDR3700 daemon.warn pppd[748]: Connected to xx:xx:xx:xx:xx:xx via interface eth1
Jun 15 17:40:12 WNDR3700 daemon.info pppd[748]: Using interface pppoe-wan
Jun 15 17:40:12 WNDR3700 daemon.notice pppd[748]: Connect: pppoe-wan <--> eth1
Jun 15 17:40:13 WNDR3700 daemon.info pppd[748]: CHAP authentication failed: 4|82|M-UM-KM-:M-EM-RM-QM-TM-ZM-OM-_M-!M-#
Jun 15 17:40:13 WNDR3700 daemon.err pppd[748]: CHAP authentication failed
Jun 15 17:40:13 WNDR3700 daemon.notice pppd[748]: Connection terminated.
Jun 15 17:40:13 WNDR3700 daemon.info pppd[748]: Exit.

Note that the second log actually came from a reboot right after the first one without touch any setting.
When it failed, manually reconnecting the interface works fine.
I don't know why the authentication failed at first place but I always saw such failure, even back in the time of using manufacturer's firmware (and this would made the connection establishment very slow some time), but the connection would always be retried till it succeeded.

Attachments (0)

Change History (14)

comment:1 Changed 6 years ago by jow

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

The scripts a deliberately designed to *not* redial if an authentication failure is detected, since that is an unrecoverable error.

I don't think we're going to change this to accomodate for fundamentally broken peer implementations, but you can fix it locally by editing /lib/netifd/ppp.sh; find the "case "$ERROR" in" switch and remove the branch handling the AUTH_FAILED condition.

comment:2 Changed 6 years ago by hato

Thanks Jow. That's good enough for me.

comment:3 Changed 6 years ago by wwenigma@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Some authentication errors is need redial - like when router restarted and cant log out from network and need to wait until timeout occured.

comment:4 Changed 6 years ago by anonymous

SOLVE:
nano /lib/netifd/proto/ppp.sh in PUTTY

Change from:

case "$ERROR" in
11|19)
proto_notify_error "$interface" AUTH_FAILED
proto_block_restart "$interface"
;;
2)
proto_notify_error "$interface" INVALID_OPTIONS
proto_block_restart "$interface"
;;
esac

TO:

case "$ERROR" in
11|19)
proto_notify_error "$interface" AUTH_FAILED
#proto_block_restart "$interface"
;;
2)
proto_notify_error "$interface" INVALID_OPTIONS
proto_block_restart "$interface"
;;
esac

Thx to Vargalex, Hungary.

comment:5 Changed 6 years ago by vargalex@…

Hi!

I have a log from an another user (after a reboot):

Jul 8 07:46:06 DD daemon.notice netifd: Interface 'wan' is now down
Jul 8 07:46:06 DD daemon.info pppd[2414]: Plugin rp-pppoe.so loaded.
Jul 8 07:46:06 DD daemon.info pppd[2414]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
Jul 8 07:46:06 DD daemon.notice pppd[2414]: pppd 2.4.5 started by root, uid 0
Jul 8 07:46:06 DD daemon.info pppd[2414]: PPP session is 45965
Jul 8 07:46:06 DD daemon.warn pppd[2414]: Connected to 64:00:f1:49:0e:51 via interface eth0.2
Jul 8 07:46:06 DD daemon.info pppd[2414]: Using interface pppoe-wan
Jul 8 07:46:06 DD daemon.notice pppd[2414]: Connect: pppoe-wan <--> eth0.2
Jul 8 07:46:11 DD daemon.info pppd[2414]: Remote message: ^M^JYou are already logged in - access denied^M^J^J
Jul 8 07:46:11 DD daemon.err pppd[2414]: PAP authentication failed
Jul 8 07:46:11 DD daemon.notice pppd[2414]: Connection terminated.
Jul 8 07:46:11 DD daemon.info pppd[2414]: Exit.

Usually the ISP-s allows 2 concurrent connections to such problems (it seems this ISP not). But, when no, you must wait for the timeout. This can we make with comment out the

proto_block_restart "$interface"

line (then the pppd daemon repeats the login).

But it is possible, that by a reboot the router not closes the connection? When yes, than I think, this is a bug.

vargalex

comment:6 Changed 6 years ago by duvi

I'm seeing the same thing, most probably since the switch to netifd.

Scenario: the pppoe wan connection is working fine, I need to restart the router for a different reason. I enter the command 'reboot' in ssh, the router reboots, but the pppoe connection does never come up after the reboot. The only solution is to restart the router again.

This has happened several times already. If I need to restart, I have to restart twice.
This is very bad, since I'm managing most devices remotely, and because the pppoe interface does not come back after the first restart, I have to drive to the location every time to manually restart the second time...

comment:7 Changed 6 years ago by duvi

When this happens:

Jan  1 01:00:25 OpenWrt daemon.info pppd[642]: Plugin rp-pppoe.so loaded.
Jan  1 01:00:25 OpenWrt daemon.info pppd[642]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
Jan  1 01:00:25 OpenWrt daemon.notice pppd[642]: pppd 2.4.5 started by root, uid 0
Jan  1 01:00:30 OpenWrt daemon.info pppd[642]: PPP session is 549
Jan  1 01:00:30 OpenWrt daemon.warn pppd[642]: Connected to 00:1b:21:7b:38:93 via interface eth0
Jan  1 01:00:30 OpenWrt daemon.info pppd[642]: Using interface pppoe-wan
Jan  1 01:00:30 OpenWrt daemon.notice pppd[642]: Connect: pppoe-wan <--> eth0
Jan  1 01:00:34 OpenWrt daemon.info pppd[642]: Remote message: Too many sessions^J
Jan  1 01:00:34 OpenWrt daemon.err pppd[642]: PAP authentication failed
Jan  1 01:00:34 OpenWrt daemon.notice pppd[642]: Connection terminated.
Jan  1 01:00:34 OpenWrt daemon.info pppd[642]: Exit.

For me the problem is "Too many sessions", probably because on reboot the pppoe connection is not terminated normally.
My ISP allows only one connection, and since the first time connection hangs because of too many sessions, it never tries to redial again.

Vargalex's solution is however fixing the problem.

comment:8 Changed 6 years ago by Damian Kaczkowski <damian.kaczkowski@…>

I am experiencing the same problem. jows solution works but its not ideal. There indeed isn't a perfect solution for this problem but could you please give us the possibility of forcing a redial on AUTH_FAILED by e.g. adding appropriate setting in UCI (/etc/confing/network)? It would be disabled by default but leaves us the possibility to enable it (keeping in mind that we broke peer implementations by doing that). That would be better solution imo.

comment:9 follow-up: Changed 6 years ago by anonymous

The ideal fix here is to ifdown before rebooting or manually ifdown you're pppoe first before you power cycle your router.

comment:10 in reply to: ↑ 9 Changed 5 years ago by el_goretto

Replying to anonymous:

The ideal fix here is to ifdown before rebooting or manually ifdown you're pppoe first before you power cycle your router.

Which is totally impossible if you are to reboot the router remotely...
I think that if this error is not to be handle specifically, at least an option should be available like "always redial" even on errors.
It happens sometimes that my ISP is failing, but in that case I'm really happy when I see my router poping in again after trying for 1 or 2 hours to reconnect (with original firmware).

comment:11 Changed 5 years ago by Sabidabi

I also have this issue. See here:
https://forum.openwrt.org/viewtopic.php?id=38929

comment:12 Changed 5 years ago by Damian Kaczkowski <damian.kaczkowski@…>

Fixed in r33291. Thanks jow.

comment:13 Changed 5 years ago by nbd

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

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.