PPPoE does not reconnect after upstream switch power loss (WAN link comes up, PPPoE doesn't)

Installing and Using OpenWrt Network and Wireless Configuration
1

OpenWrt (Xiaomi AX3200), WAN — PPPoE.

The issue occurs only after a power loss of the upstream ISP switch (located on the rooftop).
After power is restored:
the physical WAN link comes up
netifd considers the wan interface up
PPPoE does not establish
there are no automatic retry attempts
lcp-echo does not help, because the PPPoE session is never established in the first place.
After running ifdown wan && ifup wan manually, the Internet connection is restored immediately.
A canonical / proper solution is needed (without cron jobs or ping-based watchdog hacks) so that PPPoE reliably reconnects after an upstream power loss.

2

I have same hardware (AX3200) and my backup UPS lasts longer than that of my ISP. I never saw such problem.

3

Hi! From your post, it seems that the issue isn’t the PPPoE connection itself, but rather that after a blackout of the upstream ISP switch, the PPPoE session doesn’t start automatically, even though the WAN link is up.

To better understand if your configuration can handle this scenario, you should check these points in your /etc/config/network:

config interface 'wan'
	option device 'wan'
	option proto 'pppoe'
	option username '*****'
	option password '*****'
	option ipv6 'auto'
	option delegate '0'

If your configuration is exactly like this, then something is missing for the behavior you want. Specifically, to make PPPoE reconnect automatically after a blackout, you should at least add these options:

	option auto '1'          # forces netifd to attempt the connection even if the link is already up
	option keepalive '6 10'  # PPPoE will try to reestablish the connection if it fails
	option demand '0'        # disables on-demand mode

With these additions, the router should reconnect automatically without needing to run ifdown/ifup manually or use cron/ping scripts.

You can check this, and if you want, post your full configuration (masking username/password of course) so we can confirm everything is set up correctly.

ps: I extracted an old configuration of yours, in case it has changed it would be possible to see the current configuration

1 Like
4

config interface 'loopback'

option device 'lo'

option proto 'static'

option ipaddr '127.0.0.1'

option netmask '255.0.0.0'

config globals 'globals'

option ula_prefix 'fdb3:a6be:d110::/78'

config device

option name 'br-lan'

option type 'bridge'

list ports 'lan1'

list ports 'lan2'

list ports 'lan3'

config interface 'lan'

option device 'br-lan'

option proto 'static'

option ipaddr '192.168.1.1'

option netmask '255.255.255.0'

option delegate '0'

config device

option name 'wan'

option macaddr '5c:93:67:88:b9:7f'

config interface 'wan'

option device 'wan'

option proto 'pppoe'

option username '\*\*\*\*\*'

option password '\*\*\*\*\*'

option ipv6 'auto'

option delegate '0'

option keepalive '3 5'

option norelease '1'
5

you have the option or you can test if it solves by adding (on wan interface):

option auto '1'
option demand '0'

documentation:

https://openwrt.org/docs/guide-user/network/wan/wan_interface_protocols#protocol_pppoe_ppp_over_ethernet
2 Likes
6

Can the option norelease '1' in my wan config affect my issue? Should I delete it or leave?

Now my wan config is following:

config interface 'wan'
option device 'wan'
option proto 'pppoe'
option username '***'
option password '***'
option ipv6 'auto'
option delegate '0'
option keepalive '6 10'
option norelease '1'
option auto '1'
option demand '0'

7

I don't know all the details, so this explanation may be incomplete.

As far as I know, option norelease '1' is a netifd/DHCP option that tells the system not to send a release message to the server when the interface is brought down. In practice, it prevents the DHCP lease (v4 or v6) from being released immediately.

This option does not affect the establishment of a PPPoE connection or the behavior of reconnection attempts, because PPPoE messages such as PADT are handled separately by pppd.

Since norelease is not necessary in most configurations, it may be worth temporarily removing it to rule out any side effects on DHCP.

documentation (the option is present here):

https://openwrt.org/docs/guide-user/network/ipv6/configuration#protocol_dhcpv6

https://openwrt.org/docs/guide-user/network/ipv4/configuration?utm_source#protocol_dhcp

a case similar to yours (but without seeing the debug it is not possible to fully analyze):

https://github.com/ppp-project/ppp/issues/3?utm_source

PS: To reduce disconnections after power outages or upstream interruptions, it is recommended to connect both the ISP modem and the OpenWrt router to a small UPS. This way, the WAN link remains stable even during short outages, preventing PPPoE from failing to reconnect automatically.

8

If you still experience strange behavior, you can enable debug mode with:

option debug '1'

I also suggest trying these PPPoE options:

option persist '1'
option maxfail '0'
option holdoff '5'

These options make pppd persistent and automatically attempt to reconnect after a failure, even if the link remains up.

documentation:

https://github.com/search?q=repo%3Aopenwrt%2Fopenwrt%20proto_config_add_int%20maxfail&type=code

https://lists.infradead.org/pipermail/lede-commits/2025-November/027833.html