[ppp] duplicate maxfail process option

[anon27813507]

• 19.07.3
• WAN dual-stack with PPPoE authentication
• setting in /etc/config/network

config interface 'wan'
	option pppd_options 'passive maxfail 0'

---

ps -aux | grep pppd producing

/usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan lcp-echo-interval 10 lcp-echo-failure 6 lcp-echo-adaptive +ipv6 set AUTOIPV6=1 set PEERDNS=0 nodefaultroute usepeerdns maxfail 1 user *** password *** ip-up-script /lib/netifd/ppp-up ipv6-up-script /lib/netifd/ppp6-up ip-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down mtu 1492 mru 1492 plugin rp-pppoe.so nic-eth2 passive maxfail 0

maxfail is applied twice and with different values. (unwanted) maxfail 1 might be produced from https://github.com/openwrt/openwrt/blob/678ee30ee4c2a7d727d1b8a055faa5d274dd73ec/package/network/services/ppp/files/ppp.sh#L110

[jow]

Yes, since netifd is supervising pppd, we don't want pppd to continue trying on connection failures. We want to notify netifd and terminate pppd so that netifd can restart the process as needed.

If you want to override maxfail for debugging purposes or whatever, you have to adjust ppp.sh

[anon27813507]

@jow

If you want to override maxfail for debugging purposes or whatever, you have to adjust ppp.sh

That does not seem to be necessary, least my understanding is that the ppp process arguments are read/applied from left to right and the last value wins.

---

@jow

we don't want pppd to continue trying on connection failures. We want to notify netifd and terminate pppd so that netifd can restart the process as needed.

That seems to be counteracted then by https://github.com/openwrt/openwrt/blob/master/package/network/services/ppp/files/etc/ppp/options#L8

---

Then there is https://www.tldp.org/HOWTO/Leased-Line/pppd.html

`maxfail 0' may be necessary with newer PPPDs. After the connection is lost, PPPD will wait for a while before reconnecting.

---

@jow

Yes, since netifd is supervising pppd

Could you elaborate how or point to the code?

What seems to be happening is that /lib/netifd/ppp-up is being called way too early during the node's boot phase, leading to repeated PPPoE discovery attempts (and times producing a SIGTERM signal) regardless of whether the carrier link state of the WAN port (ethX) is up already.

In this context I asked PPPoE packet egress depending on netifd's link_state and/or firewall status?, particularly noticing that with option force_link '1' the number of PPPoE discovery attempts is less (and neither SIGTERM signal are observed)

[anon27813507]

@anon27813507

@jow

we don't want pppd to continue trying on connection failures. We want to notify netifd and terminate pppd so that netifd can restart the process as needed.

That seems to be counteracted then by https://github.com/openwrt/openwrt/blob/master/package/network/services/ppp/files/etc/ppp/options#L8

Looks like maxfail 0 in /etc/ppp/options is being discarded at least for WAN PPPoE. Bit of confusing that is being a vanilla argument in /etc/ppp/options.

[anon27813507]

@anon27813507

option force_link '1' [...] (and neither SIGTERM signal are observed)

Not sure how that option remedies that issue. On the other hand there appears to be bug in the ppp code where handling of signals is broken when rp-pppoe.so plugin (used for PPPoE) is loaded https://github.com/paulusmack/ppp/pull/148

Plus

@jow

netifd is supervising pppd

would seem to derive pppd process state assumption from the existence of its related /proc//exec* file instead of monitoring its signal pipe.

[anon27813507]

@anon27813507

there appears to be bug in the ppp code where handling of signals is broken when rp-pppoe.so plugin (used for PPPoE) is loaded https://github.com/paulusmack/ppp/pull/148

Master branch commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=8d2c031f21d48505a58807bcafae13f2f6cf628f incorporates the source patch, hopefully it will be cherry-picked for the stable branch soon too.