386.10 on AC86U losing all 2.4Ghz devices (seemed to be fixed in 386.9.0)

[FLN]

Hello,

I've the pernicious problem off and on of losing all 2.4 ghz devices off my RT-AC86U router periodically, requiring a reboot. There was a period in the < 386.9 versions where this was happening weekly or so, for months. I assumed it was something in my setup/didn't report it.

Apparently this was fixed in 386.9.0 as I had no issues since installing that firmware 13-Jan-2023 and had no disconnected devices for the past two months - until recently (19-Mar-23) about four days after installing 386.10.0. I found at least one other thread about this issue (below) - don't know if it's related.

I haven't gone back to the previous 386.9.0 yet - I'll wait until a few more disconnects of all 2.4 devices (IoT stuff, mostly) and then do a full erase/reapply 386.10.0 and see what happens.

Anyone else seeing this?

Past Ref from 2022: https://www.snbforums.com/threads/386-4-ac86u-losing-2-4-ghz-devices.77018 /

 

[BliteKnight]

Hello,

I've the pernicious problem off and on of losing all 2.4 ghz devices off my RT-AC86U router periodically, requiring a reboot. There was a period in the < 386.9 versions where this was happening weekly or so, for months. I assumed it was something in my setup/didn't report it.

Apparently this was fixed in 386.9.0 as I had no issues since installing that firmware 13-Jan-2023 and had no disconnected devices for the past two months - until recently (19-Mar-23) about four days after installing 386.10.0. I found at least one other thread about this issue (below) - don't know if it's related.

I haven't gone back to the previous 386.9.0 yet - I'll wait until a few more disconnects of all 2.4 devices (IoT stuff, mostly) and then do a full erase/reapply 386.10.0 and see what happens.

Anyone else seeing this?

Past Ref from 2022: https://www.snbforums.com/threads/386-4-ac86u-losing-2-4-ghz-devices.77018 /

I posted in the 386.10 release thread - since I upgraded my two AC68P routers I had constant disconnects and sometimes no connection on the 5Ghz band, so I downgraded back to 386.9 and my connections have been stable all day. I have a webcam acting as a baby monitor viewed on a tablet in another room and the video feed has been constant since the downgrade. When I was on 386.10, the video feed would cut out ever 10-15 mins because the camera would lose internet connection.

If it is still happening I would go back to 386.9 which seems like a more stable build.

 

[torch]

Am on a different router (AX86U) & different verson (388.1), but noticed the only 2.4GHz device (a Brother printer) was causing continual "Disassociated due to inactivity" errors in the syslog. I was able to eliminate the errors by setting Wireless > General > Protected Management Frames to Disable.
A different device in the 5GHz band on an AP was causing "Class 3 frame received from nonassociated station" errors - that was solved by setting Wireless > General > Protected Management Frames to Required.

 

[RMerlin]

PMF is generally required for WPA3, but may have compatibility issues with older WPA2 devices (like your printer).

 

[BliteKnight]

PMF is generally required for WPA3, but may have compatibility issues with older WPA2 devices (like your printer).

Thanks for the firmware and all the great work you do.
Is there anyway for me to look at the logs for a specific node in an AiMesh config? I keep getting no internet and discconects when I bind certain devices to one of my nodes. On the AiMesh page the connection quality is great (hard wired to main router)...just the 2Ghz and 5Ghz connection is bad

 

[RMerlin]

Is there anyway for me to look at the logs for a specific node in an AiMesh config?

The router only logs itself. Maybe nodes may have their own logfile if you check over SSH, I don't know.

 

[BliteKnight]

Just giving an update to this. The 386.10 was fine, it was my main router in my AiMesh node that was causing the problem - it's an RT-AX68U on the 388.10 firmware that I had to downgrade to 386.7_2 to have no drops.

I might not be seeing the drops since mine are nodes in an AiMesh network, but they are all working fine since I downgraded my main router.

Edit: Looks like i spoke too soon going back to 386.9 as I'm still getting drops, hopefully it'll help

 

[FLN]

Following up to my original post, all 2.4 devices have dropped off after seven days with RT-AC86U_386.10_0. Reverting to RT-AC86U_386.9_0 for the time being.

 

[Languor245]

Following up to my original post, all 2.4 devices have dropped off after seven days with RT-AC86U_386.10_0. Reverting to RT-AC86U_386.9_0 for the time being.

I also had issues on a ac68u , sometimes wouldn’t connect to wifi and drops. Reverted back to 386.9 like everyone else. No biggie. Thanks merlin for the support !

 

[heywire]

If this is only a problem with Aimesh and not the main router, I'd recommend running stock firmware on those. This will also give you access to automatic (one-click) updates in the GUI, as opposed to having to manually update it with Merlin.

I run Merlin on the main router (mainly for CakeQOS) and stock firmware on the Aimesh nodes.

If you're having trouble with the main router (or want to eliminate it as a source of your problems), I'd highly recommend testing the latest stock firmware for a while to see if the problem also occurs there. If it does, it is VERY important that you do the following before downgrading to the last working Merlin firmware in wait for a fix, in order to improve the probabilities of such a fix:

-file a report to Asus in the webgui under "Administration/Feedback". In the free-text field; describe what you did and what the problem is. Remember to check "attach logs" so they can use them to problem-solve.

This is so important, because if the problem is not reported to Asus, the likeliness increases that this bug is passed on to both newer stock firmware and the derivative GPL+closed source binary from Asus that Merlin bases his future releases on. (which btw. usually lags behind, so you have to wait even longer for a fix, or no fix).

If this procedure was stapled to every new post form in this forum, I think we'd have a lot fewer firmware bugs, because of the state of Asus QA-procedures, or rather the evident complete lack of it.

 

[Languor245]

This is in wireless router mode. I don’t think stock has dns director ? Otherwise I would run stock for sure.

 

[BliteKnight]

If this is only a problem with Aimesh and not the main router, I'd recommend running stock firmware on those. This will also give you access to automatic (one-click) updates in the GUI, as opposed to having to manually update it with Merlin.

I run Merlin on the main router (mainly for CakeQOS) and stock firmware on the Aimesh nodes.

If you're having trouble with the main router (or want to eliminate it as a source of your problems), I'd highly recommend testing the latest stock firmware for a while to see if the problem also occurs there. If it does, it is VERY important that you do the following before downgrading to the last working Merlin firmware in wait for a fix, in order to improve the probabilities of such a fix:

-file a report to Asus in the webgui under "Administration/Feedback". In the free-text field; describe what you did and what the problem is. Remember to check "attach logs" so they can use them to problem-solve.

This is so important, because if the problem is not reported to Asus, the likeliness increases that this bug is passed on to both newer stock firmware and the derivative GPL+closed source binary from Asus that Merlin bases his future releases on. (which btw. usually lags behind, so you have to wait even longer for a fix, or no fix).

If this procedure was stapled to every new post form in this forum, I think we'd have a lot fewer firmware bugs, because of the state of Asus QA-procedures, or rather the evident complete lack of it.

Thanks for this and I'm going to try this. After taking out all my mesh nodes and swapping them with stock Zenwifi Ax Mini XD4 I was still getting drops - so I don't know now if it's firmware or if I have a failing router.

Hopefully going back to stock will shed some light on what's going on

 

[heywire]

Btw have you set the 2.4ghz band to 2.4mhz in Wireless-settings, or are you running the defaul Auto/40ghz?

I always set this at 20mhz, as 40ghz takes up twice as many channels (which is pretty limited on the 2.4ghz band), which is known to cause conflicts with other wifi's and connection drops. I believe this is common practice. Maybe 40mhz works if you live far away from other wifi networks, but not if you have several other wifi networks within throwing distance. I recommend trying it.

 

[BliteKnight]

ugh!!! this is why too many things happening at once can cloud the real culprit...

Switched to T-Mobile internet from Cox and updated my Asus routers firmware at the same time. (1 Main, 2 nodes)
However, I found out that T-Mobile blocked all ports on my network, causing DNS entries to my home server to be blocked on my new public IP.
So I hosted a VPN on an external server to tunnel into their home network - it partially worked and I went one with life.

Then I started getting the random disconnects.
I tried various solutions, including downgrading firmware, changing ISP back to Cox, and using different mesh nodes - but I still got the disconnects

I seriously thought someone in the neighborhood had a Wi-Fi killer and was messing with me...then I discovered that one of their VPN connections was causing the network disconnects.

I had tried to create a bridge on this server to the external VPN but this caused it to get the IP address of the router when it tried to do this and caused the disconnects.

It would periodically do this so I always thought it was a Wi-Fi issue.

Just posting this in case someone every experiences the same thing and might have a VPN connection setup, it could be wrecking your network.

 

[FLN]

The plot thickens. RT-AC86U_386.9_0 back on for 5-6 days and all 2.4 devices removed. Before rebooting, tailed the syslog.log via ssh and saw a device repeatedly storming the 2.4 network with an odd RFC1918 address - 192.168.101.x instead of 192.168.1.x (my CIDR) and repeatedly disconnecting/reconnecting/disconnecting/reconnecting, etc.

Shows up as TizenRT with an OUI of 88:57:1D and found out it is my Samsung refrigerator. You know how you see wierd stuff and get all paranoid? like a device is repeatedly requesting a DHCP reservation on a completely different subnet? well... it ended up that I had set up the fridge on my guest network (no intranet, but yes internet, access). So this is now the working theory that this bad boy might be messing with things.

I'm going back to RT-AC86U_386.10 and put the fridge on the normal 2.4 network. We'll see how this goes in a few days.

 

[Viktor Jaep]

The plot thickens. RT-AC86U_386.9_0 back on for 5-6 days and all 2.4 devices removed. Before rebooting, tailed the syslog.log via ssh and saw a device repeatedly storming the 2.4 network with an odd RFC1918 address - 192.168.101.x instead of 192.168.1.x (my CIDR) and repeatedly disconnecting/reconnecting/disconnecting/reconnecting, etc.

Shows up as TizenRT with an OUI of 88:57:1D and found out it is my Samsung refrigerator. You know how you see wierd stuff and get all paranoid? like a device is repeatedly requesting a DHCP reservation on a completely different subnet? well... it ended up that I had set up the fridge on my guest network (no intranet, but yes internet, access). So this is now the working theory that this bad boy might be messing with things.

I'm going back to RT-AC86U_386.10 and put the fridge on the normal 2.4 network. We'll see how this goes in a few days.

I remember when fridges were used to keep things cool. Now they attack your network! Lol!

 

[bukso]

Hello,

I've the pernicious problem off and on of losing all 2.4 ghz devices off my RT-AC86U router periodically, requiring a reboot. There was a period in the < 386.9 versions where this was happening weekly or so, for months. I assumed it was something in my setup/didn't report it.

Apparently this was fixed in 386.9.0 as I had no issues since installing that firmware 13-Jan-2023 and had no disconnected devices for the past two months - until recently (19-Mar-23) about four days after installing 386.10.0. I found at least one other thread about this issue (below) - don't know if it's related.

I haven't gone back to the previous 386.9.0 yet - I'll wait until a few more disconnects of all 2.4 devices (IoT stuff, mostly) and then do a full erase/reapply 386.10.0 and see what happens.

Anyone else seeing this?

Past Ref from 2022: https://www.snbforums.com/threads/386-4-ac86u-losing-2-4-ghz-devices.77018 /

Same here - I upgraded my RT-AC86U main router and RT-AC86U node to 386.10 and all looked OK first, but after couple hours I noticed that my all 2,4 GHz IoT devices are offline. The problem was that my 2,4 GHz Guest 1 network was not visible, as if it was turned off, but on the router it was enabled.
5Ghz guest network was working.
I did go back to 386.9 on router and node and 2,4 GHz Guest 1 network did come back for short time and then disappeared again. It seems that 2,4 GHz wifi does not work anymore, only 5GHz.

 

[donbru]

Same here - I upgraded my RT-AC86U main router and RT-AC86U node to 386.10 and all looked OK first, but after couple hours I noticed that my all 2,4 GHz IoT devices are offline. The problem was that my 2,4 GHz Guest 1 network was not visible, as if it was turned off, but on the router it was enabled.
5Ghz guest network was working.
I did go back to 386.9 on router and node and 2,4 GHz Guest 1 network did come back for short time and then disappeared again. It seems that 2,4 GHz wifi does not work anymore, only 5GHz.

I had a similar experience on a RT-AC1900P after loading 386.10. After reading other posts here I downgraded to 386.9 and things got worse. I even tried dropping back to 386.7.2. There were devices no matter what I did that would not connect to either the 2.4Ghz or the 2.4Ghz Guest 2 network and I was thinking the 2.4Ghz radio was going bad although some IOT devices still worked, I ended up reloading 386.10 and then resetting the router using the WPS method. All devices came back and have been working fine for the last three days.

 

[bukso]

In my case factory reset did restore the 2,4 GHz wireless network and then upgrade to 386.10 did work as expected.

 

[Clark Griswald]

Keeping in mind, that all wireless is Asus and NOT RMerlin, perhaps it's time to upgrade? We've experienced Zero Issues with our 4+ year-old AC86U on RMerlin fw! When hw issues arise in the AC86U, I will recycle it appropriately, and move my 6000 to the AP position, thus forcing me to buy a new RMerlin supported Main router.