ASUS setup for BT Full Fibre

Hi folks, I've got a ASUS TUF Gaming AX5400 Router which I'm trying to setup with BT Full Fibre.

Had a new Openreach Nokia modem installed today, which is working just fine with the BT-supplied Smart Hub 2.

I just can't get it working with this ASUS router though

Used the login details:
- Username: [email protected]
- Password: bt

I tried 2 different ethernet cables just in case. Then suspected a hardware fault, so connected the WAN of the ASUS to the SH2 and that connected fine (via DHCP). So it seems to be something with the ASUS config for PPoE.

Screenshots of config: https://drive.google.com/drive/folders/1kLpxJiyH39iG...

There are tons of settings, I've tried several different combinations but this is how it's configured after a factory reset. Any suggestions or tips appreciated!

Connect the router WAN port to the ONT. Power cycle the router and allow it time to settle and to connect/ or attempt to connect via PPPoE (about 3 minutes or so give or take)

Post the output from the System Log from the router, so we can see what (error) messages are being logged.

Thanks for the suggestion, here's the log output:

May 5 06:07:53 hour monitor: daemon is starting
May 5 06:07:53 hour monitor: daemon terminates
May 5 06:07:54 miniupnpd: it is advised to use network interface name instead of 192.168.50.1/255.255.255.0
May 5 06:07:54 miniupnpd[2218]: Cannot get IP address for ext interface . Network is down
May 5 06:07:54 miniupnpd[2218]: HTTP listening on port 55991
May 5 06:07:54 FTP Server: daemon is stopped
May 5 06:07:54 miniupnpd[2218]: Listening for NAT-PMP/PCP traffic on port 5351
May 5 06:07:54 Samba Server: smb daemon is stoped
May 5 05:07:54 rc_service: httpd 1305:notify_rc restart_firewall
May 5 05:07:55 rc_service: ledg 1228:notify_rc restart_ledg
May 5 05:07:55 rc_service: waitting "restart_firewall" via httpd ...
May 5 06:07:55 miniupnpd[2218]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May 5 06:07:55 lldpd[2272]: cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted
May 5 05:07:55 rc_service: httpd 1305:notify_rc restart_wan_if 0;chpass;restart_time;restart_wireless;restart_cfgsync
May 5 05:07:57 pppd[1996]: Unable to complete PPPoE Discovery
May 5 06:07:58 pppd[2300]: pppd 2.4.7 started by admin, uid 0
May 5 06:07:59 kernel: klogd started: BusyBox v1.24.1 (2022-01-05 20:25:40 CST)
May 5 06:07:59 miniupnpd[2218]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May 5 06:07:59 hour monitor: daemon is starting
May 5 06:07:59 hour monitor: daemon terminates
May 5 06:07:59 kernel: CSIMON: CSIMON[1.1.0] Initialization
May 5 06:07:59 kernel: CSIMON: M2M usr already registered ...
May 5 06:07:59 kernel: CSIMON: CSIMON[1.1.0] Initialization
May 5 06:07:59 kernel: CSIMON: M2M usr already registered ...
May 5 06:08:00 kernel: CSIMON: CSIMON[1.1.0] Initialization
May 5 06:08:00 kernel: CSIMON: M2M usr already registered ...
May 5 06:08:00 wlceventd: main(961): wlceventd Start...
May 5 06:08:00 acsd: eth5: Selecting 2g band ACS policy
May 5 06:08:04 acsd: eth5: selected channel spec: 0x1008 (8)
May 5 06:08:04 acsd: eth5: Adjusted channel spec: 0x1008 (8)
May 5 06:08:04 acsd: eth5: selected channel spec: 0x1008 (8)
May 5 06:08:04 acsd: acs_set_chspec: 0x1008 (8) for reason APCS_INIT
May 5 06:08:04 acsd: eth6: Selecting 5g band ACS policy
May 5 06:08:05 rc_service: ledg 2439:notify_rc restart_ledg
May 5 06:08:09 cfg_server: event: wl_chanspec_changed_action
May 5 06:08:09 cfg_server: skip event due no re
May 5 06:08:10 acsd: eth6: selected channel spec: 0xe06a (100/80)
May 5 06:08:10 acsd: eth6: Adjusted channel spec: 0xe06a (100/80)
May 5 06:08:10 acsd: eth6: selected channel spec: 0xe06a (100/80)
May 5 06:08:10 acsd: acs_set_chspec: 0xe06a (100/80) for reason APCS_INIT
May 5 06:08:11 roamast: ROAMING Start...
May 5 06:08:18 miniupnpd[2218]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May 5 06:08:18 zcip client: configured 169.254.72.117
May 5 06:08:33 pppd[2300]: Timeout waiting for PADO packets
May 5 06:08:54 wlceventd: wlceventd_proc_event(527): eth6: Auth **:**:**:**:**:**, status: Successful (0), rssi:0
May 5 06:08:54 wlceventd: wlceventd_proc_event(556): eth6: Assoc **:**:**:**:**:**, status: Successful (0), rssi:-67
May 5 06:09:49 pppd[2300]: Timeout waiting for PADO packets
May 5 06:11:04 pppd[2300]: Timeout waiting for PADO packets
May 5 06:12:19 pppd[2300]: Timeout waiting for PADO packets
May 5 06:13:34 pppd[2300]: Timeout waiting for PADO packets
May 5 06:14:49 pppd[2300]: Timeout waiting for PADO packets
May 5 06:16:04 pppd[2300]: Timeout waiting for PADO packets

"Timeout waiting for PADO packets" looks like it might be the issue, will investigate further tomorrow. I'm going to leave the router and ONT powered off overnight on the off chance it helps.

My login is: [email protected]

everything else is the same on my AX88

Edit: I believe either should work though.

Edited by BuckleZ (Wed 12-Jan-22 04:41:30)

Thanks BuckleZ, helpful to know I didn't miss something in the config.

Still no luck after leaving it powered off though, getting that same error: "Timeout waiting for PADO packets". Tried with both variations of the PPoE username just in case.

I've had to switch back to the SH2 so I can work today, will dig into this again this evening. Suggestions welcome though!

From a TP-Link forum around the same problem.
"I have a PPPoE connection with my ISP (static IP address), and often after restarting the router, or whenever the PPPoE connection is restarted, the PPPoE connection fails during the negotiation phase. The router sends the "PADI" request, but never receives the "PADO" response. System Logs show "Timeout waiting for PADO packet". I've determined with the ISP technical support that the PPPoE access concentrator in that case rejects my PADI request based in the MAC address provided. If I then go into my router settings and change the WAN MAC address by 1 digit, the connection succeeds. But if I then restart my router, the same thing
happens. If I change the WAN MAC back to the original MAC address, the connection succeeds again."

Maybe if you clone the supplied router's MAC address to the ASUS it might work?

Edited by Adduxi (Wed 12-Jan-22 10:29:50)

The only setting i would consider a suspect is near the end of the second screen ...

"Enable VPN + DHCP connection"

You are using a PPPoE connection and the VPN ID is handled by the ONT it does not get to the router.

Agreed. Missed that on the setup pages from OP.

It just wants DHCP on the WAN connection.

Thank you all. Here's what I've tried, but still no joy with connecting:

- Enable VPN + DHCP connection: I had previously set to 'No'. It must have re-enabled with the factory reset. I set back to 'No', but it hasn't fixed it.

- VLAN tagging: I've tried with and without tag for VLAN 101 - I know shouldn't be necessary anyway since the ONT handles it.

- MAC address: I cloned the SH2 one and also tried changing it by 1 digit. Sadly also didn't work.

I can try leaving the ASUS connected overnight tonight, in case that somehow negotiates a connection after a certain time. Seems unlikely, but running out of ideas tbh.

Timeout. Just do a sense check and see if you can connect laptop/PC directly to the ONT. You will need to setup a PPPoE client session. Not too hard really.

I know you already have proved connectivity using the SH2 - but this proves without doubt the issue is with the new router (and not say a credential issue), which for all you know may have a firmware issue or hardware fault.

I'd start here - it's saying that the external interface is down. Whilst that's down, you're always going to get PADO timeouts.

In reply to a post by shyslop:

May 5 06:07:54 miniupnpd[2218]: Cannot get IP address for ext interface . Network is down

That message is very early in the output though; so it could be a red herring - however there us no message saying that the network has come up, and with the interface taking a 169.254.y.z address it would seem to confirm the interface is down.

In reply to a post by JonRennie:

That message is very early in the output though; so it could be a red herring -

I think that is a red herring, the upnp daemon is trying to set itself up, but before the public IP has been obtained by PPPoE.

My ASUS is no longer using PPPoE (as I switched to cable) but I think miniupnpd gets restarted when a public IP arrives.

Could be cabling, but most likely authentication issue.

In reply to a post by JonRennie:

however there us no message saying that the network has come up, and with the interface taking a 169.254.y.z address it would seem to confirm the interface is down.

There should be a link/activity light for the WAN port somewhere on the router; OP could check to see if its solid/blinking i.e. the link has come up.

At the other end of the cable, there is the "Port 1" LED on the ONT to confirm that the physical link is OK.

What are the options in the PPP Authentication box (screenshot 2)?

On my AX88U I don't have this option (probably because I'm running Merlin f/w) although mine is running fine with an ONT on BT Residential.

I assume you are a BT residential customer not business? I have on the back of my mind you need a different username.password for business.

In reply to a post by adrenalize_:

On my AX88U I don't have this option (probably because I'm running Merlin f/w) although mine is running fine with an ONT on BT Residential.

I'm an AX88U with Merlin (386.4) although on Virgin Media, so not using PPPoE, but if I change the type to PPPoE that box appears and I can choose Auto, PAP or CHAP.

I can't recall which one is needed for BT authentication?

Hmm, it's CHAP in the logs when mine connects. I'm on an older build of Merlin - which would explain why I don't have the option.

Thinking a bit more about it I think the PPPoE negotiation is before the authentication in the following PPP negotiation - so the PAP/CHAP settings and username/password are irrelevant as its not getting to that stage.

I have seen a couple of suggestions that either the previous PPPoE session is still active and the Asus can't cope with that (the BT Hub may cope better, well it obviously does) or that the Asus implementation is poor - some details in this thread https://www.snbforums.com/threads/unable-to-establis...

Not sure why some people's connect OK unless we are all on older firmware.

Yes you are correct. It is failing in the Discovery stage (PADO message not received) and not getting to the latter Session stage (PPP negotiation).

Huawei summarise the PPPoE process steps quite well on their support page here.

Is it a stale session (that the Asus is failing to clear) or back to Jon's point above - is there a problem with the link (that the Asus perceives)?

Edited by Pheasant (Wed 12-Jan-22 23:47:54)

Thank you all for looking into this, really appreciate it! Delayed reply as I was running some tests.

Firstly, yes it’s BT residential.

As for the connection on Asus:
- WAN light on the router is solid red, LAN light on the ONT is green (occasional blinking)
- Asus web interface goes from ‘cable unplugged’ to ‘disconnected’, so seems to detect something
- Tried all 3 options in the ‘PPP Authentication box’ but no joy

Some further testing:
I remembered I have a RPi with Openwrt, so tried but it also didn’t connect and got the same PADO error in the logs. It also didn’t work connecting my Mac to the ONT (but no detailed error message there).

It seems very odd to have these issues, yet the SH2 is working just fine whenever I plug it back in.

In all honesty I’m tempted to return the Asus and see how I get on with the SH2 for now. Happy to do more tests though if you have theories. Thanks again!

So the issue isn’t necessarily with the Asus router - the fact that it’s not working with either of the other two other devices directly connected.

Shouldn’t really make a difference, but have you tried powering off the ONT, leaving it off for 10 minutes, then powering it on again and then trying to connect with a ‘new’ device (not the SH2).

Otherwise if the credentials are correct, then the only other possible explanation is the PPP server on BT’s side - so that would be my next port of call: raising a support case - as you should definitely be able to connect using your own kit.

Thanks for the suggestion.

Sadly powering off the ONT didn't help. I left it off for >20 mins. When I powered on and connected the Asus, it still had the same issue.

Indeed it seems it must be a PPP server issue on BT’s side. However I'm doing alright using the SH2 and would rather avoid contacting BT, so will stick with this setup for now.

Many thanks though to you and the others on the thread for your support!

No worries. Good luck. 👍

It’s a long shot but have you tried clicking the disconnect button in the SH2 UI to drop the PPPoE session before removing it from your line?

In reply to a post by jpm:

have you tried clicking the disconnect button in the SH2 UI to drop the PPPoE session before removing it from your line?

Yes I did wonder that and so already tried a few times, including before unplugging the ONT. Didn't make any difference, sadly. Was worth a go though!

With nothing to lose, you could try vlan = 0
101 is, ibelieve for copper data plus voice.
Forum says also add vlan after boot and do manual reboot.

In reply to a post by flippery:

With nothing to lose, you could try vlan = 0
101 is, ibelieve for copper data plus voice.
Forum says also add vlan after boot and do manual reboot.

Nothing to lose but definitely nothing to gain.

Vlan 101 is applied on all Openreach FTTC connections whether voice is used or not. On FTTC it is added on the modem.

On Openreach FTTP the VLAN is added by the ONT. There is no vlan required on the router. I used my Asus RT-AX86U on BT FTTP without issue.

Asus routers also have issues applying a vlan of 0.

Yes, on most devices a VLAN ID of 0 is generally reserved / system only and/or can’t actually be assigned.

On other devices it signifies no VLAN tagging for the port = tell the system assign/use the default untagged VLAN on that port.

Hi all, old thread, but I wanted to loop back with an update.

I experienced an outage last week, had an engineer visit and they ended up replacing my modem - with a new Nokia one, seems to be exact same model.

Fault is fixed, but more interestingly - I just tested and PPoE login from my Mac worked immediately. With the old modem this never worked. So it seems the previous modem (even though it was brand new) was the issue here.

That said, if it hadn't been for the total outage, BT were not interested in sending an engineer for an issue affecting own equipment - so if you experience similar, then good luck :/

I wanted to share this anyway, in case it helps someone in future. Thanks again to the folks who helped on this thread before!