How to migrate RT-AC86U to RT-AX86U-PRO?

[BosseSwede]

Configuration problem somewhere?
I have now replaced the old router with the new RT-AX86U Pro and checked it out.
Mostly it does work Ok including the connection via VPN back to the home LAN.
But I have found a few items that are non-working:

1) Front status LED:s black
The row of LED indicators on the front of the router are all dark so I cannot read the current state of the system. Is there a setting to switch off the LED:s that I might have accidentally activated?

2) NFS shares back to home LAN not working
I have two RPi4 devices running OSMC Kodi here and they use the main video store on my home server via NFS.
I had set up autofs on the RPi4 devices and it worked just fine before the router switch. But now the RPi4 cannot connect NFS to the ubuntu server back home using autofs, so I switched it to a connection managed in /etc fstab instead.
I had used connections via fstab earlier so I activated the line there which used before I discovered autofs.
But when I ran this I received an error message:

$ sudo mount -a
mount.nfs: access denied by server while mounting 192.168.119.251:/home/bosse/www/VIDEO

This has worked just fine on all of my earlier Kodi setups, just not now...
In fact it seems like all my nfs connections back home fail with this router....

NOTE:
I also have a video source on my home LAN which uses Samba for sharing. It is located on a Synology NAS on my home LAN and that works just fine.
So there must be something about the networking change that has caused my home ubuntu server to start refusing connections.
What can it be and how can I fix it?

 

[bennor]

1) Front status LED:s black
The row of LED indicators on the front of the router are all dark so I cannot read the current state of the system. Is there a setting to switch off the LED:s that I might have accidentally activated?

Yes the firmware has an option to turn off the LED's. You may have inadvertently hit the button on the right side of the RT-AX86U Pro router to disable the LED's.
[Wireless Router] How to turn ON/OFF LED light of ASUS router?

In the router GUI go to AiMesh > Topology > Management > LED
If using Asus-Merlin firmware there is also an option to turn off the LED's under Administration > System > Enable LEDs.

Personally the LED's are so ridiculously bright on the RT-AX86U Pro that I have them disabled on mine.

Edit to add: I may have missed it but what firmware are you running on the RT-AX86U Pro?
On the NFS issue, first step is to ensure all IP address used for mounting are correct and that you can ping each of the clients you are trying to mount.

 

[BosseSwede]

FINALIZING
Today I switched on the new router and managed to get "almost" everything checked out OK.
But these items occurred:

1) No LED light
For some reason all of the indicator LED:s on the front of the router have been switched off so I cannot see the state of the router by looking at them. What could have done this?
The router seems to work OK apart from this and the LED:s were shining before I carried the router to the living room..
Is there a setting I might have touched which disabled the LED indicators and if so where is it?
Edit:
STUPID ME (with old eyes too): There was a button on the side of the case which read LED OFF/ON or similar hard to read in dark gray on light black...
/Edit

2) No access to NFS shares on the remote server
I have several devices (media players etc) which use data from the server in my home LAN.
So I have used the router built-in OpenVPN client to connect the summer cottage LAN to my home LAN (the OpenVPN server is running on my main Ubuntu server at home). This has been running fine with the old RT-AC86U router's built-in OpenVPN client.
So I did not expect what would happen...
The config was completely transferred to the new router and an OVPN file uploaded to handle the VPN connection.
But the VPN connections on all of my devices here failed.
After 6 hours of troubleshooting with the help of ChatGPT we finally found what was the problem and it was that the ASUS was running ASUSWRT 3.0.0.6 (the “Next Gen” firmware line) where they have introduced NAT translation through the VPN client without any way to switch that off!
So I had to add an extra client IP range to the server side exports file with the ASUS set IP value.
This took the better part of today to figure out once I had started the new router7 hours ago.
Everything else seems to be A-OK and VPN is now also running.

PS: And I am running the stock ASUS f/w updated a few days ago.DS

 

[BosseSwede]

So I had to add an extra client IP range to the server side exports file with the ASUS set IP value.
This took the better part of today to figure out once I had started the new router 7 hours ago.
Everything else seems to be A-OK and VPN is now also running.

Talked too early regarding LAN-LAN integration
Now back home where the main server is located and to which the remote summer home site connects via OpenVPN using the VPN client functionality in the new router to merge the two LAN:s.
When I was in the cottage I managed to get it working as seen from there, but now home I discovered that it does not work the other way at all!

I cannot connect to any device on the other side of the VPN tunnel from here, so the integration of the LAN:s is a one-way street.

I have tried to troubleshoot this and the end result is that it is impossible to use the RT-AX86U PRO router's VPN client in the same way as I could on the RT-AC86U router.
The reason is that ASUS in its wisdom has decided that the client tunnel should be NAT-ed to prohibit backwards traffic!!!
So noone on the server side can get a connection to the client, only remote clients can connect to main LAN devices!
This is a feature in the latest firmware and it cannot be overridden!

So now I have to redesign the whole LAN-LAN integration by setting up a separate Linux device on the remote LAN to use stock openvpn to connect to main LAN and then tweak routing and what not to allow server side clients to route back to the client side LAN.
If ASUS had only put an on/off switch in the f/w for activation of NAT over the VPN tunnel, then I would have been done and only needed to set that to OFF.
But there is no such switch in stock f/w!!!!!

 

[BosseSwede]

Finally solved the LAN-LAN integration without using the ASUS RT-AX86U PRO router VPN functions.
I had to configure an Ubuntu machine on the remote LAN as an OpenVPN client which auto-connects to the home LAN.
This client then had to be configured for IP forwarding.
Then I had to set up routing on both LAN routers such that they channel the requests for the other LAN via the OpenVPN server on the home LAN and the new OpenVPN client on the remote LAN.
And of course I had to switch off the new remote router's built-in VPN client since it did not work properly.

All of this was only possible because I have previously configured a Raspberry Pi running as an OpenVPN server on the remote LAN in order to be able to reach it from my Windows PC anywhere to manage settings there etc. It came in handy to clean up the mess with the new RT-AX86U PRO router at the cottage.

Another note on the ASUS VPN NAT:
The NAT-ing they have done uses the 10.8.0.x LAN which is doubly stupid because that is the default out of the box of most OpenVPN installations and guides so there is a high likelihood of hitting two such connections at the same time. And this causes LAN confusion when two tunnels use the same network address.
ASUS could at least have selected an obscure other VPN address range in my view.
Like 10.139.76.x or similar.

 

[BosseSwede]

UPDATE/NEW QUESTION
The router has been taken off the VPN duties and a Linux box on the remote network is instead handling the connection to the main LAN at home.
This is now working well and the LAN-LAN integration works both ways.

New issue
I have now discovered a new issue, this time regarding WiFi connectivity on the remote network.
I have an ESP8266 based IoT device there which monitors the electricity meter and it is located in a box on the pole where the incoming electricity is connected. The meter and the IoT is inside that box.
The IoT device connects to the electricity meter and it powered from it.
It has a separate antenna mounted on the outside of the box.

The f/w of the device is designed to connect via WiFi to the main router and send incoming meter messages via WiFi to an MQTT broker running on a Linux box on the remote LAN. It also reports temperature and WiFi level via MQTT.

I have written a monitoring system which stores the incoming MQTT meter data etc into a database on my web server and there I have a php script which displays the data.

That display also shows the WiFi signal level, which is reported by the IoT device twice hourly.
The WiFi level part of the webpage shows this roundabout when I switched from the old to the new ASUS router on Aug 19:

Notice the drastic change of behavior on August 19, when I switched routers!
QUESTION:
Why is the WiFi signal level behaving like this on the new router when it was only really affected by rain on the old router?
Before the change the signal never dropped below -80 dBm but now it is even reaching below -90 dBm sometimes....
This is a totally unexpected result of the router switch.

 

[degrub]

Different radio chipset, different drivers, settings, etc. looks like the average signal level rose above -80 dBm starting late 21st/early 22nd. Is there some optimization/control channel/band width adjustment going on ?
Maybe you can help the situation by using a directional external AP with line of sight to the ESP instead of the using the router omnidirectional ? Ubiquity has and others have offerings. Same for the antenna on the ESP box - higher gain, directional antenna ?

 

[BosseSwede]

I have two installations looking almost the same, one at home and the other at my summer cottage.
The home installation was upgraded to the RT-AX86U Pro in June 2024 following a lightning strike close by which killed the WAN Ethernet input of the RT-AC86U router I used before.
On that installation I do not see the strange variations up/down of the WiFi signal strength (the ESP8266 device use the same f/w on both installations so no difference there).

Concerning the antenna of the ESP8266 IoT device, it is made as a dipole antenna using a 100 mm long coaxial cable with a micro-connector that plugs into the ESP-07 wifi connector. This antenna is fed through a 3 mm hole drilled in the side of the metal box containing the electric meter to get a reasonable signal strength. Same on both installations.
On the home install I think that the IoT actually connects to an AP closer to it than the main router so that might be the reason it does not show the same strength variations. In order to verify that I might need to move it closer to the main router, but then it will not be connected to the meter anymore, so that is kind of difficult...

Anyway these short-term variations should not really be there unless there is a router config problem or the like.
Is there some new WiFi feature on the router which I can switch off to make it more "backwards" compatible?
I do not need any new functionality that might be provided by the new router.

This is how it looks like on my home installation right now:

 

[degrub]

Assuming 2.4GHz band the devices are using, set a fixed control channel, 20 MHz width, unless you need higher bandwidth.
Which wifi std are the ESP compliant with ? G, N, AC, AX ? Fix the wifi protocol type to the highest required that gives enough bandwidth.

Do you have neighbors at the cottage that may be causing interference or channel hopping ?
If so, what are the signal strengths of those other SSIDs relative to yours ?

 

[OzarkEdge]

I have two installations looking almost the same, one at home and the other at my summer cottage.
The home installation was upgraded to the RT-AX86U Pro in June 2024 following a lightning strike close by which killed the WAN Ethernet input of the RT-AC86U router I used before.
On that installation I do not see the strange variations up/down of the WiFi signal strength (the ESP8266 device use the same f/w on both installations so no difference there).

Concerning the antenna of the ESP8266 IoT device, it is made as a dipole antenna using a 100 mm long coaxial cable with a micro-connector that plugs into the ESP-07 wifi connector. This antenna is fed through a 3 mm hole drilled in the side of the metal box containing the electric meter to get a reasonable signal strength. Same on both installations.
On the home install I think that the IoT actually connects to an AP closer to it than the main router so that might be the reason it does not show the same strength variations. In order to verify that I might need to move it closer to the main router, but then it will not be connected to the meter anymore, so that is kind of difficult...

Anyway these short-term variations should not really be there unless there is a router config problem or the like.
Is there some new WiFi feature on the router which I can switch off to make it more "backwards" compatible?
I do not need any new functionality that might be provided by the new router.

This is how it looks like on my home installation right now:
View attachment 67786

All things being equal(?) except ambient radio conditions in the 2.4 band... I tend to doubt that it is a router config issue. The IoT signal strengths appear to be roughly the same, -70 to -80dBm, except the remote IoT signal has a steady disturbance that began(?) with the Aug 19 installation of the remote AX86U Pro router. I notice a similar signal disturbance on Aug 17... was that with the old AC86U router?

Router USB3.0 Mode connected devices can cause 2.4 band interference, which is more noticeable at distance/weaker signal levels... -80dBm is weak/susceptible. Bluetooth and other 2.4 band cordless periperal-type devices can also interfere with a weak 2.4 WiFi signal. From my experience, this presents to the user as the client connectivity/streaming going in and out... analogous to a weak, received signal level going up and down like in your graph... not noticeable at close range with a strong signal, but very noticeable at far range with a weak signal.

Operating at -60 to -70dBm signal level instead (an order more power) might be good enough, but often easier said than done.

I would also want to inspect the remote IoT antenna/cable for damage like a critter bite that might let water in until it dries up.

Is there any odd 2.4 client activity in the remote router log? I wonder if another 2.4 client is struggling with the new router settings and upsetting the 2.4 WLAN.

OE

 

[BosseSwede]

1) The earlier signal drop might actually have been caused by a heavy rain downpour. But it did not drop as far down as I had earlier with a poorer antenna going down towards -88 dBm...

2) I forgot to mention distances, the IoT is about 25 m from the router but outside the house obviously. The router is on a shelf in the living room. All wood house construction.

3) The WiFi environment on the home site is loaded with other routers/access points whereas the cottage is not having any neighbours to deal with. About 80-100 m to the closest other house. And most are not occupied this time of year.

4) I did replace the antenna with an improved one where I have protected the exposed dipole with shrink tubing. That was done some weeks before the router replacement when I was searching for another problem.

5) I don't think the log contains anything useful, but it is hard to tell. I have no experience looking at the logs.

 

[degrub]

look for repeated client association/deassociation/deauth messages as a start. Maybe from the MAC address of that client. You can post a relevant section in a text file to the thread and knowledgeable folks can have a peek.

If your cottage router is facing a window and has direction line of sight to the ESP device, that would be next best to an outdoor AP under the eave or on the wall. Narrow beam may be better if there are no neighbors in that direction.

 

[OzarkEdge]

4) I did replace the antenna with an improved one where I have protected the exposed dipole with shrink tubing. That was done some weeks before the router replacement when I was searching for another problem.

I asked AI about heat shrink tubing and RF and got this interesting tidbit:

'Some black heat shrinks contain carbon to increase UV resistance, and this could potentially have a minor impact on RF signals.'

Carbon increases conductivity which can block RF.

I'm not suggesting this is an issue... just found it tangentially interesting.

OE

 

[BosseSwede]

My heatshrink is 2 mm yellow, so I think I am good.

It covers the pulled back shield tied to ground and makes it harder for water to get in when raining.