Can't make PPPoE connection — TP-Link AX23

[OvO]

Hello.

My ISP provides the ZTE F609 v9.0 ONT. I've configured the device to bridge mode (VLAN is enabled and set to 2025). The LAN port is bound, DHCP is disabled, and the PPPoE profile has been deleted.

I then connect the LAN to the WAN port of my TP-Link AX23 running OpenWrt 23.05 stable. I delete every interface except br-lan, add a new interface with PPPoE protocol, WAN device, correct credential, and configure the MTU to 1492, mirroring the value on the ONT.

However, despite numerous reboots, interface restarts and waits, the PPPoE connection remains unsuccessful. The error message displayed is:

Error: Unknown error (USER_REQUEST)
Error: Connection attempt failed
Error: Unknown error (AUTH_TOPEER_FAILED)

Here's part of the logs (haven't set the timedate):

Wed Nov 15 02:57:23 2023 daemon.info pppd[12060]: Plugin pppoe.so loaded.
Wed Nov 15 02:57:23 2023 daemon.info pppd[12060]: PPPoE plugin from pppd 2.4.9
Wed Nov 15 02:57:23 2023 daemon.notice pppd[12060]: pppd 2.4.9 started by root, uid 0
Wed Nov 15 02:57:23 2023 daemon.err pppd[12060]: Interface wan has MTU of 1492 -- should be at least 1500.
Wed Nov 15 02:57:23 2023 daemon.err pppd[12060]: This may cause serious connection problems.
Wed Nov 15 02:57:24 2023 daemon.warn odhcpd[1546]: No default route present, overriding ra_lifetime!
Wed Nov 15 02:57:29 2023 daemon.notice hostapd: phy0-ap1: AP-STA-DISCONNECTED [MAC ADDRESS]
Wed Nov 15 02:57:29 2023 daemon.info hostapd: phy0-ap1: STA [MAC ADDRESS] IEEE 802.11: disassociated
Wed Nov 15 02:57:30 2023 daemon.info hostapd: phy0-ap1: STA [MAC ADDRESS] IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Nov 15 02:57:32 2023 daemon.info hostapd: phy0-ap1: STA  IEEE 802.11: authenticated
Wed Nov 15 02:57:32 2023 daemon.info hostapd: phy0-ap1: STA [MAC ADDRESS] IEEE 802.11: associated (aid 13)
Wed Nov 15 02:57:32 2023 daemon.notice hostapd: phy0-ap1: AP-STA-CONNECTED [MAC ADDRESS] auth_alg=open
Wed Nov 15 02:57:32 2023 daemon.info hostapd: phy0-ap1: STA [MAC ADDRESS] WPA: pairwise key handshake completed (RSN)
Wed Nov 15 02:57:32 2023 daemon.notice hostapd: phy0-ap1: EAPOL-4WAY-HS-COMPLETED [MAC ADDRESS]
Wed Nov 15 02:57:38 2023 daemon.warn pppd[12060]: Timeout waiting for PADO packets
Wed Nov 15 02:57:38 2023 daemon.err pppd[12060]: Unable to complete PPPoE Discovery

Tue Nov 14 19:58:03 2023 daemon.notice netifd: Interface 'wan' is now down
Tue Nov 14 19:58:03 2023 daemon.notice netifd: Interface 'wan' is setting up now
Tue Nov 14 19:58:04 2023 daemon.info pppd[12872]: Plugin pppoe.so loaded.
Tue Nov 14 19:58:04 2023 daemon.info pppd[12872]: PPPoE plugin from pppd 2.4.9
Tue Nov 14 19:58:04 2023 daemon.notice pppd[12872]: pppd 2.4.9 started by root, uid 0
Tue Nov 14 19:58:04 2023 daemon.err pppd[12872]: Interface wan has MTU of 1492 -- should be at least 1500.
Tue Nov 14 19:58:04 2023 daemon.err pppd[12872]: This may cause serious connection problems.
Tue Nov 14 19:58:04 2023 daemon.warn odhcpd[1546]: No default route present, overriding ra_lifetime!
Tue Nov 14 19:58:19 2023 daemon.warn pppd[12872]: Timeout waiting for PADO packets
Tue Nov 14 19:58:19 2023 daemon.err pppd[12872]: Unable to complete PPPoE Discovery
Tue Nov 14 19:58:19 2023 daemon.info pppd[12872]: Exit.

I also attempted to clone the MAC address of the ONT, but it didn't resolve the issue.

At this point, I'm wondering whether it's a configuration error, an ISP-related issue, or a hardware problem. It's worth noting that I reached out to the ISP several days ago, and they assured me that bridge connection is permitted.

[Cheddoleum]

This might not be the problem, but on at least two different consumer routers I've had difficulty getting a PPPoE interface to start. Eventually it became clear that it wasn't initializing the physical interface. To get around that, I have to create a kind of dummy interface (in luci) that also uses the physical wan interface. I just call it ZNULL (so that it shows up at the bottom of the sort) set it to unmanaged, no firewall. This has the effect of enabling that physical interface, and then my PPPoE interface works.

I've seen this on both IPQ4018 and mt7621-based routers. The same solution works for both. Hope this helps.

[Borromini]

You should share your /etc/config/network you're talking VLANs etc, but we're steering blind like this.

This usually points to a 'regular' PPPoE connection issue, not to credential issues:

Tue Nov 14 19:58:19 2023 daemon.warn pppd[12872]: Timeout waiting for PADO packets
Tue Nov 14 19:58:19 2023 daemon.err pppd[12872]: Unable to complete PPPoE Discovery

[bill888]

Try increasing the timeout if it is not a VLAN tag issue.

https://forum.openwrt.org/t/new-to-openwrt-need-help-configuring-pppoe/185720/8

[OvO]

@Borromini

You should share your /etc/config/network you're talking VLANs etc, but we're steering blind like this.

This usually points to a 'regular' PPPoE connection issue, not to credential issues:

Tue Nov 14 19:58:19 2023 daemon.warn pppd[12872]: Timeout waiting for PADO packets
Tue Nov 14 19:58:19 2023 daemon.err pppd[12872]: Unable to complete PPPoE Discovery

My apologies.

VLAN is enabled on the ONT as suggested by the ISP.

etc/config/network:

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 'fd4d:6416:3a51::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.0.2'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'ZNULL'
	option proto 'none'
	option device 'wan'

config device
	option name 'wan'
	option mtu '1492'

config interface 'wan'
	option proto 'pppoe'
	option device 'wan'
	option username 'xxxxxx'
	option password 'xxxxxx'
	option ipv6 'auto'
	option keepalive '15 1'
	option mtu '1492'

With VLAN on OpenWRT, disabled on the ONT. Removed identical codes to make it easier to read:

config device
	option type '8021q'
	option ifname 'wan'
	option vid '2025'
	option name 'wan.2025'

With cloned MAC:

config device
	option type '8021q'
	option ifname 'wan'
	option vid '2025'
	option name 'wan.2025'
	option macaddr 'ONT MAC'

Also tried using a different port:

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'

config device
	option name 'lan4'
	option mtu '1492'
	option macaddr 'xx:xx:xx:xx:xx:B5'

config interface 'pppoe'
	option proto 'pppoe'
	option device 'lan4'
	option username 'xxxxxx'
	option password 'xxxxxx'
	option ipv6 'auto'
	option keepalive '15 1'
	option mtu '1492'	

Still giving me errors.

Error: Unknown error (NEGOTIATION_FAILED) then Error: Unknown error (AUTH_TOPEER_FAILED)

Here's how the working config looks like on the ONT, just in case I missed something.

@Cheddoleum

This might not be the problem, but on at least two different consumer routers I've had difficulty getting a PPPoE interface to start. Eventually it became clear that it wasn't initializing the physical interface. To get around that, I have to create a kind of dummy interface (in luci) that also uses the physical wan interface. I just call it ZNULL (so that it shows up at the bottom of the sort) set it to unmanaged, no firewall. This has the effect of enabling that physical interface, and then my PPPoE interface works.

I've seen this on both IPQ4018 and mt7621-based routers. The same solution works for both. Hope this helps.

@bill888

Try increasing the timeout if it is not a VLAN tag issue.

https://forum.openwrt.org/t/new-to-openwrt-need-help-configuring-pppoe/185720/8

Tried them all, didn't work.

[Borromini]

Any reason you are setting the MTU manually?

[Alpha1096]

I think reason could be backend. Most ISP's bind user connection to device mac address, it could be the case here. Your ONT device was configured previously now that's being used in bridge mode, your different device is now being used to initiate connection, and ISP is refusing it due to an unauthorized device is trying to use your user/pass to log into the network.

Contact your ISP to reset your mac then try again. Once mac is reset, you should be able to initiate connection with new device. This has happened with me once.

[OvO]

@Borromini

Any reason you are setting the MTU manually?

I'm just following what's given by the ISP. 1492 is the default value when creating a PPPoE profile on the ONT.

@Alpha1096

I think reason could be backend. Most ISP's bind user connection to device mac address, it could be the case here. Your ONT device was configured previously now that's being used in bridge mode, your different device is now being used to initiate connection, and ISP is refusing it due to an unauthorized device is trying to use your user/pass to log into the network.

Contact your ISP to reset your mac then try again. Once mac is reset, you should be able to initiate connection with new device. This has happened with me once.

If that's the case, cloning the MAC should've bypassed this, shouldn't it? Or is there more to it than that?

Last time I contacted them, they kept telling me that it's done and I can just connect.
I'm still trying to reach out to them again today, but still haven't connected to the human customer service agent yet.

[Alpha1096]

Well, not every router/modem is compatible with certain ISP's. It's also possible that there's a bug in the build you're running. You can either try with latest snapshot or try with previous stable builds.