PPPoE packet egress depending on netifd's link_state and/or firewall status?

[anon27813507]

Noticed that with PPPoE authentication in ISP connectivity there is a difference in the number of repeated PPPoE connectivity attempts during boot time, i.e. with option force_link '1' there are less attempts than without that option set.

Is upstream packet egress prevented until link_state actually becomes true (or is forced by the aforementioned setting) and/or netfilter (firewall) rules are loaded?

[anon27813507]

@jow with the highest debug level for netifd the log exhibits some ominous

netifd: wan Command failed: Not found

each time ppp.sh is invoked. How to find out what it is that is not found?

---

Having added some addition logging to ppp.sh there is some bit of inconsistency with /sys/class/net/eth2/operstate, shows mostly down, e.g.

kernel info on eth2 -> operstate = down | -> carrier = 1 | -> flags = 0x1003

but on some call showing

kernel info on eth2 -> operstate = up | -> carrier = 1 | -> flags = 0x1003

According to https://www.kernel.org/doc/Documentation/networking/operstates.txt

IF_OPER_DOWN (2):
Interface is unable to transfer data on L1, f.e. ethernet is not plugged or interface is ADMIN down

And logging with each ppp.sh invocation ubus status is showing:

ubus info on wan "up": false, "pending": true, "device": "eth2"

[anon27813507]

Since there is no mechanism for netifd to discover the DSL line status of an external modem those repeatedly futile PPPoE discovery attempts are likely happening during the time the modem initiates DSL line sync with the ISP and until completed PPPoE discovery will fail.

Getting the DSL line status from an external modem is probably not possible without knowing how to access/extract the information from the modem.

[anon27813507]

For some curious reason option padi_timeout is neither exposed in LuCI or could it be traced in the documentation. However, having discovered https://github.com/openwrt/openwrt/commit/678ee30ee4c2a7d727d1b8a055faa5d274dd73ec

and accordingly edited /etc/config/network

+ config interface 'wan'
++	option padi_timeout '20'

solved the futile PADI discovery attempts; in this case (external xDSL modem) it takes 20 seconds for the first discovery packet being received from the ISP. No more futile discovery attempts since then.