Modify

Opened 3 years ago

Last modified 2 years ago

#18026 reopened defect

pppoe auto reconnect does not work

Reported by: anonymous Owned by: developers
Priority: high Milestone:
Component: base system Version: Barrier Breaker 14.07
Keywords: Cc:

Description

after executing /etc/init.d/network reload
the pppd process starting for few seconds and then die/killed and never executed again.
When the device is booting or when i click the manual connect button (i have to wait few seconds or everything is the same) the pppd process get started and everything works.

Its also happen when the wan interface went down.

The log of the problem:
Sat Oct 4 04:39:34 2014 daemon.notice netifd: Network device 'eth1' link is down
Sat Oct 4 04:39:34 2014 daemon.notice netifd: Interface 'wan' has link connectivity loss
Sat Oct 4 04:39:34 2014 kern.info kernel: [28077.230000] eth1: link down
Sat Oct 4 04:39:34 2014 daemon.notice netifd: Interface 'modem_wan' has link connectivity loss
Sat Oct 4 04:39:34 2014 daemon.info pppd[9945]: Terminating on signal 15
Sat Oct 4 04:39:34 2014 daemon.info pppd[9945]: Connect time 23.1 minutes.
Sat Oct 4 04:39:34 2014 daemon.info pppd[9945]: Sent 58588591 bytes, received 4938236 bytes.
Sat Oct 4 04:39:34 2014 daemon.notice netifd: Network device 'pppoe-wan' link is down
Sat Oct 4 04:39:36 2014 kern.debug kernel: [28079.230000] ar71xx: pll_reg 0xb8050018: 0x13000a44
Sat Oct 4 04:39:36 2014 kern.info kernel: [28079.230000] eth1: link up (100Mbps/Full duplex)
Sat Oct 4 04:39:36 2014 daemon.notice netifd: Network device 'eth1' link is up
Sat Oct 4 04:39:36 2014 daemon.notice netifd: Interface 'wan' has link connectivity
Sat Oct 4 04:39:36 2014 daemon.notice netifd: Interface 'wan' is setting up now
Sat Oct 4 04:39:36 2014 daemon.notice netifd: Interface 'modem_wan' has link connectivity
Sat Oct 4 04:39:36 2014 daemon.info pppd[10760]: Plugin rp-pppoe.so loaded.
Sat Oct 4 04:39:36 2014 daemon.info pppd[10760]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Sat Oct 4 04:39:36 2014 daemon.notice pppd[10760]: pppd 2.4.7 started by root, uid 0

And the log when i click the connect button:
Sat Oct 4 04:42:42 2014 daemon.warn dnsmasq[9097]: no servers found in /tmp/resolv.conf.auto, will retry
Sat Oct 4 04:42:42 2014 daemon.notice netifd: Interface 'wan' is now down
Sat Oct 4 04:42:42 2014 daemon.notice netifd: Interface 'wan' is setting up now
Sat Oct 4 04:42:42 2014 daemon.info pppd[11019]: Plugin rp-pppoe.so loaded.
Sat Oct 4 04:42:42 2014 daemon.info pppd[11019]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Sat Oct 4 04:42:42 2014 daemon.notice pppd[11019]: pppd 2.4.7 started by root, uid 0
Sat Oct 4 04:42:42 2014 daemon.info pppd[11019]: PPP session is 1
Sat Oct 4 04:42:42 2014 daemon.warn pppd[11019]: Connected to 00:11:22:33:44:55 via interface eth1

Attachments (0)

Change History (16)

comment:1 Changed 3 years ago by anonymous

me too

comment:2 Changed 3 years ago by anonymous

I can confirm that automatic reconnecting of PPPoE is not reliable. My provider provides a wireless bridge that interrupts the LAN connection to my WRT160NL briefly every night. I must reactivate the PPPoE connection manually (e.g. by clicking Connect in LuCI) afterwards, which is really annoying.


Log of connection loss and unsuccessful reconnection:

Mon Nov  3 03:59:42 2014 daemon.notice netifd: Network device 'eth1' link is down
Mon Nov  3 03:59:42 2014 daemon.notice netifd: Interface 'wan' has link connectivity loss
Mon Nov  3 03:59:42 2014 kern.info kernel: [57457.940000] eth1: link down
Mon Nov  3 03:59:42 2014 daemon.info pppd[982]: Terminating on signal 15
Mon Nov  3 03:59:42 2014 daemon.info pppd[982]: Connect time 957.3 minutes.
Mon Nov  3 03:59:42 2014 daemon.info pppd[982]: Sent 128682542 bytes, received 3243082994 bytes.
Mon Nov  3 03:59:42 2014 daemon.notice odhcp6c[1018]: carrier => 0 event on pppoe-wan
Mon Nov  3 03:59:42 2014 daemon.notice odhcp6c[1018]: (re)starting transaction on pppoe-wan
Mon Nov  3 03:59:42 2014 daemon.notice netifd: Network device 'pppoe-wan' link is down
Mon Nov  3 03:59:42 2014 daemon.notice netifd: Network alias 'pppoe-wan' link is down
Mon Nov  3 03:59:42 2014 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Mon Nov  3 03:59:42 2014 daemon.notice odhcp6c[1018]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)
Mon Nov  3 03:59:42 2014 daemon.notice netifd: Interface 'wan6' is now down
Mon Nov  3 03:59:42 2014 daemon.notice netifd: Interface 'wan6' is disabled
Mon Nov  3 03:59:43 2014 kern.debug kernel: [57458.940000] ar71xx: pll_reg 0xb8050018: 0x13000a44
Mon Nov  3 03:59:43 2014 kern.info kernel: [57458.940000] eth1: link up (100Mbps/Full duplex)
Mon Nov  3 03:59:43 2014 daemon.notice netifd: Network device 'eth1' link is up
Mon Nov  3 03:59:43 2014 daemon.notice netifd: Interface 'wan' has link connectivity 
Mon Nov  3 03:59:43 2014 daemon.notice netifd: Interface 'wan' is setting up now
Mon Nov  3 03:59:43 2014 daemon.info pppd[18609]: Plugin rp-pppoe.so loaded.
Mon Nov  3 03:59:43 2014 daemon.info pppd[18609]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Mon Nov  3 03:59:43 2014 daemon.notice pppd[18609]: pppd 2.4.7 started by root, uid 0
Mon Nov  3 03:59:57 2014 daemon.notice netifd: Network device 'eth1' link is down
Mon Nov  3 03:59:57 2014 daemon.notice netifd: Interface 'wan' has link connectivity loss
Mon Nov  3 03:59:57 2014 kern.info kernel: [57472.940000] eth1: link down
Mon Nov  3 03:59:58 2014 kern.debug kernel: [57473.940000] ar71xx: pll_reg 0xb8050018: 0x13000a44
Mon Nov  3 03:59:58 2014 kern.info kernel: [57473.940000] eth1: link up (100Mbps/Full duplex)
Mon Nov  3 03:59:58 2014 daemon.notice netifd: Network device 'eth1' link is up
Mon Nov  3 03:59:58 2014 daemon.notice netifd: Interface 'wan' has link connectivity 
Mon Nov  3 04:00:29 2014 daemon.warn dnsmasq[1089]: no servers found in /tmp/resolv.conf.auto, will retry

comment:3 Changed 3 years ago by anonymous

same on current trunk r43236

comment:4 Changed 3 years ago by anonymous

I have same problem TP-Link TL-WR842N/ND v2, i am use ipv6

Mon Nov 17 21:30:01 2014 daemon.notice odhcp6c[1299]: Starting RENEW transaction (timeout 1080s, max rc 0)
Mon Nov 17 21:30:01 2014 daemon.notice odhcp6c[1299]: Send RENEW message (elapsed 0ms, rc 0)
Mon Nov 17 21:30:01 2014 daemon.notice odhcp6c[1299]: Got a valid reply after 3ms
Mon Nov 17 21:30:01 2014 daemon.notice odhcp6c[1299]: Starting <POLL> transaction (timeout 1800s, max rc 0)
Mon Nov 17 21:37:58 2014 daemon.notice netifd: Network device 'eth0' link is down
Mon Nov 17 21:37:58 2014 daemon.notice netifd: Interface 'wan' has link connectivity loss
Mon Nov 17 21:37:58 2014 kern.info kernel: [1217349.130000] eth0: link down
Mon Nov 17 21:37:58 2014 daemon.notice odhcp6c[1299]: Starting RELEASE transaction (timeout 4294967295s, max rc 5)
Mon Nov 17 21:37:58 2014 daemon.notice odhcp6c[1299]: Send RELEASE message (elapsed 0ms, rc 0)
Mon Nov 17 21:37:58 2014 daemon.notice netifd: Interface 'wan6' is now down
Mon Nov 17 21:37:58 2014 daemon.notice netifd: Interface 'wan6' is disabled
Mon Nov 17 21:37:58 2014 daemon.info pppd[1001]: Terminating on signal 15
Mon Nov 17 21:37:58 2014 daemon.info pppd[1001]: Connect time 20288.1 minutes.
Mon Nov 17 21:37:58 2014 daemon.info pppd[1001]: Sent 604368715 bytes, received 2219851544 bytes.
Mon Nov 17 21:37:58 2014 daemon.err miniupnpd[1499]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Mon Nov 17 21:37:58 2014 daemon.err miniupnpd[1499]: Failed to get IP for interface pppoe-wan
Mon Nov 17 21:37:58 2014 daemon.warn miniupnpd[1499]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mon Nov 17 21:37:58 2014 daemon.notice netifd: Network device 'pppoe-wan' link is down
Mon Nov 17 21:38:00 2014 daemon.warn dnsmasq[1364]: no servers found in /tmp/resolv.conf.auto, will retry
Mon Nov 17 21:38:00 2014 daemon.notice netifd: Network device 'eth0' link is up
Mon Nov 17 21:38:00 2014 daemon.notice netifd: Interface 'wan' has link connectivity
Mon Nov 17 21:38:00 2014 daemon.notice netifd: Interface 'wan' is setting up now
Mon Nov 17 21:38:00 2014 kern.info kernel: [1217351.130000] eth0: link up (100Mbps/Full duplex)
Mon Nov 17 21:38:00 2014 daemon.info pppd[20843]: Plugin rp-pppoe.so loaded.
Mon Nov 17 21:38:00 2014 daemon.info pppd[20843]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Mon Nov 17 21:38:00 2014 daemon.notice pppd[20843]: pppd 2.4.7 started by root, uid 0
Mon Nov 17 21:39:11 2014 daemon.err miniupnpd[1499]: Failed to get ip address for interface pppoe-wan
Mon Nov 17 21:39:12 2014 daemon.err miniupnpd[1499]: Failed to get ip address for interface pppoe-wan
Mon Nov 17 21:39:14 2014 daemon.err miniupnpd[1499]: Failed to get ip address for interface pppoe-wan
Mon Nov 17 21:39:18 2014 daemon.err miniupnpd[1499]: Failed to get ip address for interface pppoe-wan
Mon Nov 17 21:39:26 2014 daemon.err miniupnpd[1499]: Failed to get ip address for interface pppoe-wan
Mon Nov 17 21:39:42 2014 daemon.err miniupnpd[1499]: Failed to get ip address for interface pppoe-wan
Mon Nov 17 21:41:37 2014 daemon.notice miniupnpd[1499]: remove port mapping 56162 UDP because it has expired
Mon Nov 17 21:41:37 2014 daemon.notice miniupnpd[1499]: remove port mapping 56162 TCP because it has expired
Mon Nov 17 21:45:25 2014 daemon.notice miniupnpd[1499]: remove port mapping 46889 UDP because it has expired
Mon Nov 17 21:45:27 2014 daemon.notice miniupnpd[1499]: remove port mapping 46889 TCP because it has expired
Mon Nov 17 21:45:43 2014 daemon.err miniupnpd[1499]: Failed to get ip address for interface pppoe-wan
Mon Nov 17 21:52:12 2014 daemon.err miniupnpd[1499]: Failed to get IP for interface pppoe-wan
Mon Nov 17 21:57:39 2014 daemon.notice netifd: Interface 'wan' is now down
Mon Nov 17 21:57:39 2014 kern.info kernel: [1218530.350000] eth0: link down
Mon Nov 17 21:57:39 2014 daemon.notice netifd: Interface 'wan' is disabled
Mon Nov 17 21:57:39 2014 daemon.notice netifd: Interface 'wan' is enabled
Mon Nov 17 21:57:39 2014 daemon.notice netifd: Interface 'wan' is setting up now
Mon Nov 17 21:57:39 2014 daemon.notice netifd: Network device 'eth0' link is down
Mon Nov 17 21:57:39 2014 kern.info kernel: [1218530.370000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Mon Nov 17 21:57:39 2014 daemon.notice netifd: Interface 'wan' has link connectivity loss
Mon Nov 17 21:57:39 2014 daemon.info pppd[20958]: Plugin rp-pppoe.so loaded.
Mon Nov 17 21:57:39 2014 daemon.info pppd[20958]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Mon Nov 17 21:57:39 2014 daemon.notice pppd[20958]: pppd 2.4.7 started by root, uid 0
Mon Nov 17 21:57:40 2014 kern.info kernel: [1218531.290000] eth0: link up (100Mbps/Full duplex)
Mon Nov 17 21:57:40 2014 kern.info kernel: [1218531.290000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Mon Nov 17 21:57:40 2014 daemon.notice netifd: Network device 'eth0' link is up
Mon Nov 17 21:57:40 2014 daemon.notice netifd: Interface 'wan' has link connectivity
Mon Nov 17 21:57:44 2014 daemon.info pppd[20958]: PPP session is 1011

comment:5 follow-up: Changed 3 years ago by dermoth

I have a similar issue. I'm still trying to find out what's happening, but the signs I see is pppd being killed by netifd for no apparent reason (not even on ubus messages) and not being properly restarted, and unfortunately I cannot find any logs for netifd.

Oddly I upgraded to Barrier Breaker about a month ago and 2-3 events aside where a restart or two worked the connection was stable.

I wrote a script to restart pppd for now as I couldn't even use the net without it - sometimes pppd gets killed less than a minute after being started, but it can also stay on for a while, maybe an hour or so. Under normal conditions the ppp session can remain on for days. My syslog is very similar to the one already posted here, but here's a log of ubus messages along with my script running ifup as needed (unfortunately no timestamp; when I tried to capture them I realized buffering in ubud prevented form printing them properly).

root@OpenWrt:~# ubus -v listen
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...

And it goes on and on and on...

Last edited 3 years ago by dermoth (previous) (diff)

comment:6 Changed 3 years ago by dermoth

Added date to the reconnect info:

{ "network.interface": {"action":"ifdown","interface":"wan"} }
Fri Feb  6 06:45:32 EST 2015: ifupd.sh[28556]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
Fri Feb  6 06:45:49 EST 2015: ifupd.sh[28556]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
Fri Feb  6 06:48:06 EST 2015: ifupd.sh[28556]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
Fri Feb  6 06:48:23 EST 2015: ifupd.sh[28556]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
Fri Feb  6 06:50:28 EST 2015: ifupd.sh[28556]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
Fri Feb  6 06:53:52 EST 2015: ifupd.sh[28556]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
Fri Feb  6 06:55:02 EST 2015: ifupd.sh[28556]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
Fri Feb  6 06:57:37 EST 2015: ifupd.sh[28556]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }

The net is functional as soon as it reconnects, so it's not that the connection fails. Some time after the PPPoE session is established netifd kills (SIGTERM) pppd, which gracefully tear down the PPP session.

comment:7 Changed 3 years ago by dermoth

Ok I just found out the source of the problem... Should've checked the kernel log (I got used to see that in syslog anyway)... So the wan port (eth1) was flapping and this is what triggered the shutdown of pppd (this is pretty stupid IMHO as PPPoE can definitively survive a flap of the wan network port... I'd love to have an option to disable that behavior!)

So there's still the issue of netifd not reconnecting PPPoE when the port is going back up... That's what this bug is about, so I may add a feature request to disable the auto-bounce of pppoe if there's no option already.

Regards,

comment:8 Changed 3 years ago by dermoth

Err, changed the cable, still the same...

It turns out it's netifd that resets eth1 when pppoe fails, not the other way around (!!).

Anyway I changed the maxfail option as explained in the unfortunately closed bug #14144 and the connection has been stable for now. It doesn't make sense to me since pppd was clearly being killed, not failing (from an strace I could see the kill signal coming from netifd).

I'll see how long it remains stable now...

comment:9 Changed 3 years ago by anonymous

I see that interface is HANG. Like io wait state. The new pppd instance can not use the name attach to old instance.

Sat Feb 7 19:22:12 2015 daemon.info pppd[7639]: Plugin rp-pppoe.so loaded.
Sat Feb 7 19:22:12 2015 daemon.info pppd[7639]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Sat Feb 7 19:22:12 2015 daemon.notice pppd[7639]: pppd 2.4.7 started by root, uid 0
Sat Feb 7 19:22:12 2015 daemon.info pppd[7639]: PPP session is 7503
Sat Feb 7 19:22:12 2015 daemon.warn pppd[7639]: Connected to 00:90:1a:42:68:70 via interface eth0.2
Sat Feb 7 19:22:12 2015 daemon.debug pppd[7639]: using channel 160054
Sat Feb 7 19:22:12 2015 daemon.err pppd[7639]: Couldn't rename ppp1 to pppoe-p2
Sat Feb 7 19:22:12 2015 daemon.info pppd[7639]: Exit.

comment:10 in reply to: ↑ 5 Changed 3 years ago by anonymous

Dermoth,

Could you share the script to check the WAN?

Replying to dermoth:

I have a similar issue. I'm still trying to find out what's happening, but the signs I see is pppd being killed by netifd for no apparent reason (not even on ubus messages) and not being properly restarted, and unfortunately I cannot find any logs for netifd.

Oddly I upgraded to Barrier Breaker about a month ago and 2-3 events aside where a restart or two worked the connection was stable.

I wrote a script to restart pppd for now as I couldn't even use the net without it - sometimes pppd gets killed less than a minute after being started, but it can also stay on for a while, maybe an hour or so. Under normal conditions the ppp session can remain on for days. My syslog is very similar to the one already posted here, but here's a log of ubus messages along with my script running ifup as needed (unfortunately no timestamp; when I tried to capture them I realized buffering in ubud prevented form printing them properly).

root@OpenWrt:~# ubus -v listen
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"6rd"} }
{ "network.interface": {"action":"ifdown","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"wan"} }
{ "network.interface": {"action":"ifup","interface":"6rd"} }
ifupd.sh[22211]: WARN: pppd down, bringing wan back up...

And it goes on and on and on...

comment:11 Changed 3 years ago by bittorf@…

i have seen this today with r46197. a simple 'ifup wan' fixed it.

comment:12 Changed 3 years ago by dermoth

@anonymous, I'm sorry I never got any email follow up on your reply.

Here's the "ifupd" script - that was a temporary solution to troubleshoot the issue only; the fix setting maxfail 0 in /lib/netifd/proto/ppp.sh - the line I changed now looks like this:

  $demand maxfail 0 holdoff 2 \

ifupd.sh:

#!/bin/sh

name="$(basename $0)"

while sleep 1
do
        pgrep pppd >/dev/null && continue
        # Sleep trice before restarting ifup
        sleep 1
        pgrep pppd >/dev/null && continue
        sleep 1
        pgrep pppd >/dev/null && continue
        echo "$(date): $name[$$]: WARN: pppd down, bringing wan back up..."
        ifup wan
done

On a side note, another related bug: #12245. Closed as wontfix; that one was merely about the fact maxfail couldn't be overridden in pppd options, no mention of failures like in this bug and #14144.

comment:13 Changed 2 years ago by anonymous

Is the problem still present on Chaos Calmer 15.05?

comment:14 Changed 2 years ago by nbd

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

tested and working in current trunk / CC

comment:15 Changed 2 years ago by jsdaf@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

The bug is still present in chaos calmer release.
My interface goes crazy up and down until i manually ifdown wan followed by ifup wan.

comment:16 Changed 2 years ago by zhoupeng@…

Hi, everybody

I have the same issue in 14.07/openwrt.git.And I have a clue for you, when I add usleep(500000) after netifd_start_process when call proto_shell_handler function in proto-shell.c, the ppp reconnect not working issue happened much less times when pppoe reconnect compare to before.

Add Comment

Modify Ticket

Action
as reopened .
Author


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

 
Note: See TracTickets for help on using tickets.