RT-AC86U dropping 2.4Ghz devices

[xulian]

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

 

[L&LD]

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]

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]

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]

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]

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.

 

[maus73]

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]

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:

 

[kjoshj]

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]

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.

 

[L&LD]

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).

 

[xulian]

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:

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)

 

[Neil62]

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?

 

[xulian]

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

 

[L&LD]

@xulian, location, location, location!

 

[Ahurasim]

Hey just thought I'd post this here to help anyone with this router who doesn't want to buy another router due to the 2.4GHz issue but still needs the 2.4GHz connection to connect certain devices to their network.

So basically what you can do is buy a cheap wireless repeater that also works in AP mode and then connect that to one of your routers LAN ports (Make sure the device is set to AP mode and has its channel set to auto), This way you are creating the 2.4GHz network through the repeater device while having the 5GHz come through the router.

Personally I have had to do this for a smart home device that only worked on 2.4GHz, It seems an obvious solution but when I was originally having this problem it did not cross my mind once.

Here's a link to an example device like the one I have used :
https://www.ebay.com.au/itm/1751501...dpM6QL/Id14YibWFDq23N3Uw==|tkp:BlBMUOK0tIWVYg

Also if the link no longer works here is the title of the ad for the device I have used : "300Mbps Wifi Extender Repeater Range Booster AP Router AU Wireless-N 802.11"

Also you may want to disable the 2.4GHz network by going to the router settings : Wireless>Professional>(Select band 2.4GHz) & (Set enable radio to 'No') , I run merlin firmware but I think it is probably the same on stock firmware.

P.S. Also unrelated to the above - F*** eBay.

 

[Tech9]

Here's a link to an example device like the one I have used :
https://www.ebay.com.au/itm/1751501...dpM6QL/Id14YibWFDq23N3Uw==|tkp:BlBMUOK0tIWVYg

This particular example device is one of the worst fake ones you can get.

Better get the one below from a better known manufacturer and at least known to work well and with good range:

300Mbps Universal Wi-Fi Range Extender

The 300Mbps TL-WA850RE Universal WiFi Range Extender boosts WiFi signals to reach your router can't while reducing interference for reliable WiFi throughout your home or office.

www.tp-link.com

It has Web UI with AP Mode option.

 

[sfx2000]

Here's a link to an example device like the one I have used :
https://www.ebay.com.au/itm/1751501...dpM6QL/Id14YibWFDq23N3Uw==|tkp:BlBMUOK0tIWVYg

Also if the link no longer works here is the title of the ad for the device I have used : "300Mbps Wifi Extender Repeater Range Booster AP Router AU Wireless-N 802.11"

OMG - they still make these?

These are ancient - Realtek chipset, and while sold under a lot of names, they're basically all the same...

Winstars WS-WN518N2

For a list of all currently documented Realtek chipsets with specifications, see Realtek. Wirepess Repeater Product page "2158-V2.2" and "2011-08-10" is silkscreened...

wikidevi.wi-cat.ru