RT-AC86U dropping 2.4Ghz devices

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

xulian

Regular Contributor
Hi,

I have been testing latest firmwares and found that after a time 2.4ghz devices are being dropped, keeping 5ghz devices connected. This happens with latest 384.16 final, but comes from previous releases too.

My configuration has a main RT-AX88U and 2 Aimesh nodes, one of them this AC86U and another one is an AC68U which works perfectly.

Current tests I've done are:

- tested with 384.15, 384.14_2 and 384.13, devices are being dropped after a time
- tested with latest ASUS official firmware (RT-AC86U_3.0.0.4_384_81352) and devices are also dropped.
- tested with 384.12 and devices aren't dropped

I see main change regarding Aimesh support started within 384.13 which has this note below. There's no other modification at least AC86U related.

384.13 (31-July-2019)
- NEW: AiMesh Router and node support. Note that automatic live
update of Merlin-based nodes is not supported, you will have
to manually update any Merlin-based nodes when a new firmware
is available. Asus-based nodes (which is recommended) will be
able to make use of the automatic live update.
Within 384.14 the only addition regarding 384.14 AC86U is this one:

384.14 (14-Dec-2019)
- UPDATED: RT-AC68U, RT-AC86U to GPL 384_81351​

I think codebase that works is this one

384.12 (22-June-2019)
- UPDATED: Merged GPL 384_45717 (except for RT-AX88U)​

So question is, thinking the problem is firmware related and not Merlin's only issue (as it also happens with original firmware) what update can have been done after 384.12 with 384_45717 that breaks aimesh (apparently only with RT-AC86U)

Thanks
 
Last edited:

L&LD

Part of the Furniture
What are you doing to ensure the router is in a good/known state with each firmware you are testing?

2x RT-AC86U's in AiMesh mode has been working flawlessly since RMerlin 384.15_0 for several months now, including being 'dirty' updated to 384.16_0 a few days ago for a customer.

Note that the RT-AX88U has updated drivers in the current firmware (I believe since 384.15_0). That in itself may require a full reset/Initialize all settings to ensure the firmware is properly installed/configured internally and with client devices.
 

OzarkEdge

Part of the Furniture
Hi,

I have been testing latest firmwares and found that after a time 2.4ghz devices are being dropped, keeping 5ghz devices connected. This happens with latest 384.16 final, but comes from previous releases too.

My configuration has a main RT-AX88U and 2 Aimesh nodes, one of them this AC86U and another one is an AC68U which works perfectly.

Current tests I've done are:

- tested with 384.15, 384.14_2 and 384.13, devices are being dropped after a time
- tested with latest ASUS official firmware (RT-AC86U_3.0.0.4_384_81352) and devices are also dropped.
- tested with 384.12 and devices aren't dropped

I see main change regarding Aimesh support started within 384.13 which has this note below. There's no other modification at least AC86U related.

384.13 (31-July-2019)
- NEW: AiMesh Router and node support. Note that automatic live
update of Merlin-based nodes is not supported, you will have
to manually update any Merlin-based nodes when a new firmware
is available. Asus-based nodes (which is recommended) will be
able to make use of the automatic live update.
Within 384.14 the only addition regarding 384.14 is this one:

384.14 (14-Dec-2019)
- UPDATED: RT-AC68U, RT-AC86U to GPL 384_81351​

I think codebase that works is this one

384.12 (22-June-2019)
- UPDATED: Merged GPL 384_45717 (except for RT-AX88U)​

So question is, thinking the problem is firmware related and not Merlin's only issue (as it also happens with original firmware) what update can have been done after 384.12 with 384_45717 that breaks aimesh (apparently only with RT-AC86U)

Thanks
Stock firmware has been working for me.

Maybe the 86U is failing.

Are you using USB 3.0 Mode on the router?

OE
 

xulian

Regular Contributor
Hi,

What are you doing to ensure the router is in a good/known state with each firmware you are testing?
I made a full reset after 384.16 firmware upgrade. After verified the problem I went back to older firmwares until 384.12. Now it's already working with that version.

Stock firmware has been working for me.

Maybe the 86U is failing.

Are you using USB 3.0 Mode on the router?
It works with 384.12 and no, I stopped using any dongle for discarding other problems.

Thanks
 

L&LD

Part of the Furniture
A full reset isn't enough. Did you use a saved backup config file on the newly reset router? Did you 'blindly' copy your old settings from the old firmware into the new one (even manually)?

Were you testing at each step of the freshly reset router to determine stability for a long enough time frame (at least a day, I would imagine)?

No picking on you. Just would like a complete picture as others are not reporting similar issues to the same extent. :)
 

xulian

Regular Contributor
A full reset isn't enough. Did you use a saved backup config file on the newly reset router? Did you 'blindly' copy your old settings from the old firmware into the new one (even manually)?
hi, there is no newly reset router, just the aimesh node (AC86U) and didn't copy anything, just added it again to the aimesh system.

I keep them working from one day to the other. At first the AC86U keep the devices on 2.4Ghz but at last they are all disconnected.

EDIT.

just to clarify, both the AX88U and the AC68U have devices in 2,4 and 5Ghz and they stay there until the roaming assistant moves them anywhere.

It's just the AC86U the one that drops all 2.4Ghz devices, and there are at least 3 of them very nearly to the AP.
 
Last edited:

maus73

New Around Here
Hi,

I have been testing latest firmwares and found that after a time 2.4ghz devices are being dropped, keeping 5ghz devices connected. This happens with latest 384.16 final, but comes from previous releases too.

My configuration has a main RT-AX88U and 2 Aimesh nodes, one of them this AC86U and another one is an AC68U which works perfectly.

Current tests I've done are:

- tested with 384.15, 384.14_2 and 384.13, devices are being dropped after a time
- tested with latest ASUS official firmware (RT-AC86U_3.0.0.4_384_81352) and devices are also dropped.
- tested with 384.12 and devices aren't dropped

I see main change regarding Aimesh support started within 384.13 which has this note below. There's no other modification at least AC86U related.

384.13 (31-July-2019)
- NEW: AiMesh Router and node support. Note that automatic live
update of Merlin-based nodes is not supported, you will have
to manually update any Merlin-based nodes when a new firmware
is available. Asus-based nodes (which is recommended) will be
able to make use of the automatic live update.
Within 384.14 the only addition regarding 384.14 is this one:

384.14 (14-Dec-2019)
- UPDATED: RT-AC68U, RT-AC86U to GPL 384_81351​

I think codebase that works is this one

384.12 (22-June-2019)
- UPDATED: Merged GPL 384_45717 (except for RT-AX88U)​

So question is, thinking the problem is firmware related and not Merlin's only issue (as it also happens with original firmware) what update can have been done after 384.12 with 384_45717 that breaks aimesh (apparently only with RT-AC86U)

Thanks
Have experienced the same and it's played havoc with IOT devices and home automation. Last full reset and manual re-config with 15, now running 16 and the only way devices remain connected is by disabling Smart Connect.

Does that work for you?

My understanding is that Merlin has not made changes that are likely to have influence here and Wifi is closed source so there is little he is able to do. Just wanted to acknowledge that this has been a problem for a while here too.
 

xulian

Regular Contributor
Have experienced the same and it's played havoc with IOT devices and home automation. Last full reset and manual re-config with 15, now running 16 and the only way devices remain connected is by disabling Smart Connect.

Does that work for you?
Hi, I have smart connect disabled:

upload_2020-4-11_0-42-48.png
 

kjoshj

New Around Here
I also experience an issue where my AC86u has dropped my Win 10 laptop from the 2.4 Ghz band. I have the 5 Ghz disabled, and the laptop stays aprox 6 ft from the router 24/7 just running BOINC. It's rare, but has happened probably 3 times in the past two months. I keep hoping that 'dirty' updates will resolve it, but since I just flashed 384.16 recently, it has not happened yet with the new firmware likely just due to how rarely it occurs.
 

Neil62

Senior Member
Hi,

I have been testing latest firmwares and found that after a time 2.4ghz devices are being dropped, keeping 5ghz devices connected. This happens with latest 384.16 final, but comes from previous releases too.

My configuration has a main RT-AX88U and 2 Aimesh nodes, one of them this AC86U and another one is an AC68U which works perfectly.

Current tests I've done are:

- tested with 384.15, 384.14_2 and 384.13, devices are being dropped after a time
- tested with latest ASUS official firmware (RT-AC86U_3.0.0.4_384_81352) and devices are also dropped.
- tested with 384.12 and devices aren't dropped

I see main change regarding Aimesh support started within 384.13 which has this note below. There's no other modification at least AC86U related.

384.13 (31-July-2019)
- NEW: AiMesh Router and node support. Note that automatic live
update of Merlin-based nodes is not supported, you will have
to manually update any Merlin-based nodes when a new firmware
is available. Asus-based nodes (which is recommended) will be
able to make use of the automatic live update.
Within 384.14 the only addition regarding 384.14 AC86U is this one:

384.14 (14-Dec-2019)
- UPDATED: RT-AC68U, RT-AC86U to GPL 384_81351​

I think codebase that works is this one

384.12 (22-June-2019)
- UPDATED: Merged GPL 384_45717 (except for RT-AX88U)​

So question is, thinking the problem is firmware related and not Merlin's only issue (as it also happens with original firmware) what update can have been done after 384.12 with 384_45717 that breaks aimesh (apparently only with RT-AC86U)

Thanks
If I am not mistaken here, the first merlin firmware to run AiMesh was 384.13. Is my assumption correct, correct me if I am wrong anyone? So by running Merlin 384.12 on the Main router, I can't see how Aimesh would work, even with 45717 and any other ASUS standard firmware running on the node.

If you look at the changelog for 384.13 you will notice other than the fixes, that the only GPL binary, merged into this version was for the AX88U. So 384.13 would be just as stable as 384.12, knowing that the GPL from Merlin 14 and above has the newer GPL also merged into them for the 86U, which, by your testing is causing your issues.

You may also notice from my signature that I am running 5 86U's in a mesh setup (using only a WIFI backhaul), that are all running Merlin 384.16 from its initial release and I, at least to date, are not noticing any drop outs of devices across both bands and or nodes, disconnecting from the main.

Looking at your screen dump above, post #8, have you tried using a fixed wireless node and control channel? A channel bandwidth of 20MHZ rather than a 40MGZ for the 2.4 band? These changes may help with stability issues. AUTO as an example, for scanning of channels will cause a moment of disconnection while this process is running.
 
Last edited:

L&LD

Part of the Furniture
You have 40MHz bandwidth and Auto Control Channel (using channel 5) showing as your current settings. This is easily a source of some of the issues you're seeing.

WiFi Agile Multiband is another setting I would test disabling (after putting the 2.4GHz bandwidth to 20 and manually selecting channels 1, 6 or 11. By using any in-between channels, you are introducing many times the chances of interference from other broadcasting AP's. Not to mention causing all in range to suffer for the worst for it. :)

Don't only pick the best channel (1, 6 or 11) manually (by actually testing it - forget any 'app' you may have access to), but also leave it on that channel for at least a day or two. This gives other AP's running on 'Auto' to migrate away from your selected channel and should give you even better networking results (in time).
 
  • Like
Reactions: a5m

xulian

Regular Contributor
If I am not mistaken here, the first merlin firmware to run AiMesh was 384.13. Is my assumption correct, correct me if I am wrong anyone? So by running Merlin 384.12 on the Main router, I can't see how Aimesh would work, even with 45717 and any other ASUS standard firmware running on the node.
You are right, I listed in my first message the firmware notes with that change included and was speaking there about it. And as I explained there, problem happens with .13 and not with .12. You can see below:

upload_2020-4-11_19-36-37.png


upload_2020-4-11_20-10-28.png


If you look at the changelog for 384.13 you will notice other than the fixes, that the only GPL binary, merged into this version was for the AX88U. So 384.13 would be just as stable as 384.12, knowing that the GPL from Merlin 14 and above has the newer GPL also merged into them for the 86U, which, by your testing is causing your issues.
Yes, that change was also included in my list of updates from all the firmware versions. Thing is this happens with .13 and not with .12.

You may also notice from my signature that I am running 5 86U's in a mesh setup (using only a WIFI backhaul), that are all running Merlin 384.16 from its initial release and I, at least to date, are not noticing any drop outs of devices across both bands and or nodes, disconnecting from the main.

Looking at your screen dump above, post #8, have you tried using a fixed wireless node and control channel? A channel bandwidth of 20MHZ rather than a 40MGZ for the 2.4 band? These changes may help with stability issues. AUTO as an example, for scanning of channels will cause a moment of disconnection while this process is running.
I don't have my AP's running in Wirless backhaul. Will test the other parameters together with the changes suggested by L&LD below, thanks for your answer.

You have 40MHz bandwidth and Auto Control Channel (using channel 5) showing as your current settings. This is easily a source of some of the issues you're seeing.

WiFi Agile Multiband is another setting I would test disabling (after putting the 2.4GHz bandwidth to 20 and manually selecting channels 1, 6 or 11. By using any in-between channels, you are introducing many times the chances of interference from other broadcasting AP's. Not to mention causing all in range to suffer for the worst for it. :)
Hi L&LD, thanks for your suggestions, I will test them. But, don't forget that I have another RT68U and that one works, it keeps many of the 2.4Ghz devices that usually (because they have better signal) belong to the AC86U (by proximity I mean)
 

Attachments

Last edited:

Neil62

Senior Member
You are right, I listed in my first message the firmware notes with that change included and was speaking there about it. And as I explained there, problem happens with .13 and not with .12.

Yes, that change was also included in my list of updates from all the firmware versions. Thing is this happens with .13 and not with .12.
I see from your screen dumps you have included, that you have a 86U running as a node with .12. I was not aware that would even work, I assumed with Merlin, it had to be .13 and above, nodes and main router. My mistake there. I am still learning then.

Another point maybe for consideration with older firmwares, is at what version of firmware did ASUS decide to use a dedicated 5GZ dedicated wireless backhaul for AiMesh?
 
Last edited:

xulian

Regular Contributor
Hello everyone,

after a time of testing I found the source of my problems. Thanks to people here, specially them in this post and also Merlin for his comment there:

Also, the 2.4 GHz band is overcrowded. That particular frequency see interference coming from wifi routers, wireless mices, baby monitors, microwave ovens, old cordless phones, Bluetooth devices, USB 3.0 devices, and the list goes on. You will have to start by isolating things.

So, after moving the AC-86U to another spot location it started working as expected.

Thanks.

P.D. edited as per @L&LD comments below :)
 
Last edited:

L&LD

Part of the Furniture
@xulian, location, location, location! :)
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top