Possible problem with MESH nodes using Firmware version 386.1

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

tessierp

Occasional Visitor
Recently I updated my RT-AX88U and RT-AX86U to firmware version 386.1. Everything apart from a few sync issues was fine (by sync issues I meant my AI MESH router, RT-AX86U, would lose connection and reconnect. That was until yesterday when I noticed the router would not be connected, the internet LED was RED. I turned it off and on again but it wouldn't connect. So I thought I would reset to the factory settings. It is the second time I have to do this with this firmware. Before installing the latest Merlin firmware on my MESH NODE (RT-AX86U), the ASUS firmware was installed and ran stable for months while on my main router the RT-AX86U I was using Merlin's firmware 384.19.

I had similar issues with my AC routers in the past. Somehow, Merlin's firmware leads to a unstable MESH network.
 

joe scian

Very Senior Member
Recently I updated my RT-AX88U and RT-AX86U to firmware version 386.1. Everything apart from a few sync issues was fine (by sync issues I meant my AI MESH router, RT-AX86U, would lose connection and reconnect. That was until yesterday when I noticed the router would not be connected, the internet LED was RED. I turned it off and on again but it wouldn't connect. So I thought I would reset to the factory settings. It is the second time I have to do this with this firmware. Before installing the latest Merlin firmware on my MESH NODE (RT-AX86U), the ASUS firmware was installed and ran stable for months while on my main router the RT-AX86U I was using Merlin's firmware 384.19.

I had similar issues with my AC routers in the past. Somehow, Merlin's firmware leads to a unstable MESH network.

Yes it does BUT ONLY ON YOUR ROUTER so its obviously NOT the firmware - so change your heading as its WRONG and misleading or add "On My Router " at the end. Have you tried a WPS Reset. That could be your next port of call.
 
Last edited:

Smokey613

Very Senior Member
I had some issues early on but once I got my wireless settings adjusted, my AiMesh setup is working great. BTW, 386.2_alpha1 is working better for me than 386.1 release did.
 

tessierp

Occasional Visitor
Yes it does BUT ONLY ON YOUR ROUTER so its obviously NOT the firmware - so change your heading as its WRONG and misleading or add "On My Router " at the end. Have you tried a WPS Reset. That could be your next port of call.
No, I am not changing the title, it is not misleading and it is what has been happening two times now while with the ASUS firmware on the Mesh node never dropped. So don't you come here and tell me what I should do. This is a bug I'm reporting, if you are going to be sentimental and illogical about it, that is your problem. The problem remains and I have over 6 months usage to prove it! And that also did happen in the past with an older firmware on my AC routers and same thing, installing the ASUS firmware on the mesh nodes would solve the issues.

I'm again reporting an issue that I had right after flashing that firmware. Again you have an issue, look the other way.
 

dosborne

Very Senior Member
Not to get too far into this "conflict", but the title is misleading. I read the thread in case it was a "major issue" that was important to me.

First, it may be an issue, but I would argue that something that has happened twice, may not necessarily be "major".

Second, I don't run mesh, so not an issue at all for me.

Third, I wouldn't personally jump to the conclusion that this is RMerlin's "fault", as seemingly indicated, as it could be something in the ASUS code that may or may not be accessible. Personally, I haven't bothered looking at the codebase, even though I've been a programmer since the early '80s, as I'd rather leave it up to those who have taken the time.

Posting that you have an issue and explaining the specifics is obviously the best approach, as you have done. But, I wish, in general, the majority of posts had titles that make it easier for all users to get information or for to offer help in areas where they can. Having well thought-out titles helps everyone.

In this specific case, I hope you might see where a title along the lines of "Possible AI Mesh issue with FW386.1" would not only serve well as more descriptive, but may attract those with more knowledge in that specific dates to try and help and possibly even RMerlin himself if he felt there was a)something he could actually say about this section of code or b) if he felt it warranted a "bug" label.

Both sides need to remember to stay calm. Everyone is just trying to help (report potential bugs, help of members resolve issues, etc).
 

tessierp

Occasional Visitor
Not to get too far into this "conflict", but the title is misleading. I read the thread in case it was a "major issue" that was important to me.

First, it may be an issue, but I would argue that something that has happened twice, may not necessarily be "major".

Second, I don't run mesh, so not an issue at all for me.

Third, I wouldn't personally jump to the conclusion that this is RMerlin's "fault", as seemingly indicated, as it could be something in the ASUS code that may or may not be accessible. Personally, I haven't bothered looking at the codebase, even though I've been a programmer since the early '80s, as I'd rather leave it up to those who have taken the time.

Posting that you have an issue and explaining the specifics is obviously the best approach, as you have done. But, I wish, in general, the majority of posts had titles that make it easier for all users to get information or for to offer help in areas where they can. Having well thought-out titles helps everyone.

In this specific case, I hope you might see where a title along the lines of "Possible AI Mesh issue with FW386.1" would not only serve well as more descriptive, but may attract those with more knowledge in that specific dates to try and help and possibly even RMerlin himself if he felt there was a)something he could actually say about this section of code or b) if he felt it warranted a "bug" label.

Both sides need to remember to stay calm. Everyone is just trying to help (report potential bugs, help of members resolve issues, etc).
Hey Dosbone.

I'm not saying it is your case but many people in the networking "considering themselves" elite communities take offense very easily. I'm, not attacking anyone. I'm bringing a possible problem to the attention of people. I don't know how many time I got bug reports on products I worked on. Doesn't matter if it was a problem in the procedure or really a problem in the code. At the very least it could help make the firmware better. And if really the issue is by some mistake I've done then I will have learned something. Either way, I'll know soon enough if I can reproduce this issues for the thirs time.
 

SheikhSheikha

Regular Contributor
As you are new around here maybe interesting for you to know that a lot of "problems" and "bugs" in the router firmware most of the time are caused by the Asus closed part of the code and not by the Merlin features. In that case Eric is bound by those limitations until Asus has sorted out their own stuff.
Further a lot of problems are solved by following installation and configuration settings and/or procedures that other users have found out over time. User L&LD has summarized all these in a nice page that can help you out and that you can find here: https://www.snbforums.com/members/l-ld.24423/#about

Perhaps good to keep in mind that most people here are very helpful to others who have problems and, indeed to draw attention to certain issues that MAY be caused by the firmware. (very often the cause is in the closed part of the Asus firmware that Merlin cannot change and where we all have to wait until Asus does its homework). When somehow an issue occurs that is specific to the Merlin firmware it will be addressed and solved swiftly without the need to push your case, to shout at people and last but not least by calling names.
 

tessierp

Occasional Visitor
As you are new around here maybe interesting for you to know that a lot of "problems" and "bugs" in the router firmware most of the time are caused by the Asus closed part of the code and not by the Merlin features. In that case Eric is bound by those limitations until Asus has sorted out their own stuff.
Further a lot of problems are solved by following installation and configuration settings and/or procedures that other users have found out over time. User L&LD has summarized all these in a nice page that can help you out and that you can find here: https://www.snbforums.com/members/l-ld.24423/#about

Perhaps good to keep in mind that most people here are very helpful to others who have problems and, indeed to draw attention to certain issues that MAY be caused by the firmware. (very often the cause is in the closed part of the Asus firmware that Merlin cannot change and where we all have to wait until Asus does its homework). When somehow an issue occurs that is specific to the Merlin firmware it will be addressed and solved swiftly without the need to push your case, to shout at people and last but not least by calling names.
I already realize all you are saying. And I wouldn't have posted this if, like I said, the problem is solved by installing ASUS's firmware on the MESH NODES (slaves), not the main. It happened three times already. Doesn't matter if I am new here or now. I am not new in the IT industry, I know how it works and again all I did is raise an issue, not attacking anyone.

I think I was pretty clear with all the information how I got these issues.
 

doublehd

Regular Contributor
Guys calm down abit,I could tell it's most likely caused by Asus themselves.I was having little bug thing with AIMESH sync before,(Main router(386.1) wl country on AUSTRALIA,and node couldn't sync itself as AU,it was on US,and it happened in differ verions of stock firmware).No matter I used either RMerlin or Asus stock.And the fact is AIMESH closed source,it's outta Merlin almighty control.Same hardwares always encountering differ buggy stuffs.Well be frank,I'm addicted with Rmerlin's firmware.
 

thiggins

Mr. Easy
Staff member
@noah way Your post was unhelpful.
@joe scian Suggesting a thread title change is ok. Telling someone to do it is not
@tessierp You have been here long enough that you know name calling is not tolerated. Do it again and you'll get a temporary ban.

Focus on the problem or I'll lock the thread.
 

tessierp

Occasional Visitor
Everything related to either AiMesh or wifi is closed source, and outside of my control.
I see. Would you have any idea why it would become more unstable when I install your firmware? Could it be just a coincidence that I had the issues a few days after installing 386.1 ?
 

brummygit

Very Senior Member
I see. Would you have any idea why it would become more unstable when I install your firmware? Could it be just a coincidence that I had the issues a few days after installing 386.1 ?
Merlin's 384.19 and older stock firmware are significantly different to anything which has a 386 code base. Asus has been working for some time on it's AiMesh 2.0 which is in this release, and most significantly there have been major updates to the WiFi drivers used in the AX series routers as the 386 (AiMesh 2.0) code has worked its way through Beta tests.

I would say that the very latest stock versions 386_41994 are getting quite stable, but Merlin 386.1 is based on a slightly earlier GPL code set 386_41700. You could try updating your nodes to the latest stock versions in case that helps, otherwise it might be a case of waiting for Asus to fix things and then for @RMerlin to subsequently move his own releases to the newer GPL and associated Wireless SDK / Drivers.
 

MarkyPancake

Senior Member
For what it's worth, I've run Merlin 384.13, .17, .18, and .19 on my AC86U router and AC68U node setup, always via wireless backhaul, without any issues at all. Currently have .19 on the router still and the node is now on 386.1 and all still solid. All dirty upgrades as well. Will update the router when there's a window of no one relying on it being up.

Edit: I forgot to mention, each time I've updated the AC68U node, it has been via the router's admin page and in turn the wireless connection between the router and the node. I've never removed the node to update it directly via a wired connection.

I usually do firmware updates by going wired to the router from a laptop, but the node update from 384.19 to 386.1 I did completely wirelessly from my phone's browser.
 
Last edited:

CaptnDanLKW

Regular Contributor
From what I read, this is the scenario:

Main Router: RT-AX88U - 386.1
Mesh Node: RT-AX86U - 384.19
No issues


Main Router: RT-AX88U - 386.1
Mesh Node: RT-AX86U - 386.1
Problem - Main Router internet drops (RED LAN LED)

That does seem Odd, since the Mesh node should NOT have anything to do with the WAN config on the main node. However, when a mesh node is added there is a lot of dynamic things (highly technical term, I know) happening - new interfaces added, services restarted, etc.. so there could be something odd happening.

Question - when you upgraded your AX86U to the new codebase, did you just upgrade it? or did you remove the mesh node and re-add it. If the AX86U was in-place upgraded and not removed/re-added them MAYBE (guess) that some AI Mesh 2.0 setting is causing a failure on the main router.

IMHO, it seems cleaner to remove it Mesh node, upgrade it independently, factory reset, then add it back. (That's how I upgrade my nodes) The goal for any mesh node is to be added in from a factory default configuration so that the state is known and only the settings the AI Mesh control are changed.

I don't own one, but I know the AX86U also has a 2.5Gb LAN port and I'm not sure if you are using it - if you are, try using a different port? (not sure how this might play a role here)

Finally, you may also want to try using the AX86U as your main router and the AX88U as you node for troubleshooting and see if you can reproduce the problem.

This is all guess and hypothetical since AI Mesh is closed source and the logs often fall short in useful info.
 

tessierp

Occasional Visitor
@brummygit Thanks that is very useful information.

@CaptnDanLKW To answer your question, I upgraded it without disconnecting it from the mesh network. And I agree with your that it is perhaps the best thing to do to remove it, factory reset and relink the router with the mesh network. I've done that last time and it seems to be more stable now but I'll give it another week.

Thanks everyone!
 

Dirk Osstyn

New Around Here
Strange. I have a situation where I have an AC88U as master en one AC68U as Aimesh Node + another AC68U as simple AP.
I sit at about 2 m from the AC88U, 4 meter from the AC68U Aimesh Node (one extra wall) and 10 m from the AC68U AP (3 to 4 walls inbetween).
I noticed I do not have WIFI on one of my devices (iphone), when I connect I get a connetion error. Then suddenly it connects to the very weak signal of the router that is the furthest away.
Why are the Aimesh router and node refusing this connection to leave me at a weak signal?
I also seem to experience drop-outs on the node.
I have tried all kinds of stuff but no success so far. A power cycle helps but this should not be needed if I read the above positive feedback of some.
 

L&LD

Part of the Furniture
How I normally fix issues like the above for my customers (and usually, right after updating to any of the 386.1 versions).
  • Reboot the System via the GUI in AiMesh, System Settings, System Reboot.
  • Wait 15 minutes after the reboot before I 'test' to see if the network is stable/working.
  • If not, I remove all AiMesh nodes via the GUI.
  • Wait at least 5 minutes after the last one has booted up (should be fully reset at this point) before proceeding.
  • Add each AiMesh node, in sequence. Wait 15 minutes or so after the last one is added then...
  • Perform a System Reboot as above, waiting 15 minutes afterward before testing once again.
If the above doesn't fix things (it does 99% of the time), the link below may be worth perusing to see what 'best practice' steps may have been skipped during any previous 'full/proper reset to factory defaults' and corrected.

Note that 'fixing' a single missed step is not a good approach, IME.

Doing a full reset with all the suggested steps is necessary to get the router and network to a good/known state and one where the router is using the expected defaults of the firmware currently installed.

 

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