Problem with 2.4GHz with both Asus and Merlin 384.x firmware.

[MachineX]

Hello everyone...

Hoping someone can help. Ever since the 384.x firmware has been out, I am having an issue with the 2.4GHz WiFi band on my RT-AC5300. I have been going back and forth with Asus support, and they have not be helpful so far. Yesterday after the release of Merlin 384.4, I decided to try that, since there are many more helpful screens for troubleshooting, etc...and the AIMesh stuff is not present (which I do not use anyway).

This is the problem I am having:

• Everything works great for anywhere from a few minutes to a few hours after reboot.
• Ping rates for 2.4Ghz clients starts fluctuating. From 1ms to over 4000ms (up and down) for typically 15-20 mins, and then eventually it just stops working all together.
• When everything stops, the client are still "associated", but no bandwidth info is listed on the wireless log, photo below (I edited out my SSID and BSSID).
• This only happens on the 2.4GHz band, everything else is fine.
• The clients are my HP printer, Nest Thermostat, Smoke Detectors, and Raspberry Pi's.

My 2.4GHz Settings are as follows: (pretty much default, except enabling IGMP snooping for Nest/Google Home to work, and I tried disabling MIMO, based on another post I read). I have also tried disabling explicit and universal beamforming, but that did not help either.

Appreciate any help.

Thanks,
Brian

 

[agilani]

Are you running repeaters? There are a few us running repeaters and have experienced high wireless latency and complete dropouts that you describe. It goes away after a reboot, but eventually reappears.

I also went through the steps you described, but it doesn't seem to be settings related and nothing shows in the logs.

I also have IGMP snooping enabled for my wireless cameras.

So far it looks like the only recourse for many of us was to downgrade back to 380.69 branch of code. Not sure that's an option for your ac5300 though.

 

[MachineX]

So, last reboot was around 1:30pm today, just checked my ping logs, and something happened around 4:08pm....as you can see below I went from 1-2ms to up to 2-3 seconds in some cases...snippet below.

Sat 03/17/2018 16:08:09.87 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:10.90 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:11.93 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:12.96 Reply from 192.168.1.90: bytes=32 time=2ms TTL=255
Sat 03/17/2018 16:08:14.00 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:15.03 Reply from 192.168.1.90: bytes=32 time=2ms TTL=255
Sat 03/17/2018 16:08:16.06 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:17.09 Reply from 192.168.1.90: bytes=32 time=2ms TTL=255
Sat 03/17/2018 16:08:21.70 Request timed out.
Sat 03/17/2018 16:08:22.78 Reply from 192.168.1.90: bytes=32 time=81ms TTL=255
Sat 03/17/2018 16:08:23.81 Reply from 192.168.1.90: bytes=32 time=68ms TTL=255
Sat 03/17/2018 16:08:24.84 Reply from 192.168.1.90: bytes=32 time=51ms TTL=255
Sat 03/17/2018 16:08:25.87 Reply from 192.168.1.90: bytes=32 time=45ms TTL=255
Sat 03/17/2018 16:08:26.93 Reply from 192.168.1.90: bytes=32 time=36ms TTL=255
Sat 03/17/2018 16:08:28.15 Reply from 192.168.1.90: bytes=32 time=25ms TTL=255
Sat 03/17/2018 16:08:29.18 Reply from 192.168.1.90: bytes=32 time=11ms TTL=255
Sat 03/17/2018 16:08:30.31 Reply from 192.168.1.90: bytes=32 time=3ms TTL=255
Sat 03/17/2018 16:08:31.54 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:32.76 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:33.82 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:34.86 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:36.14 Reply from 192.168.1.90: bytes=32 time=1ms TTL=255
Sat 03/17/2018 16:08:37.37 Reply from 192.168.1.90: bytes=32 time=151ms TTL=255
Sat 03/17/2018 16:08:38.61 Reply from 192.168.1.90: bytes=32 time=57ms TTL=255
Sat 03/17/2018 16:08:39.83 Reply from 192.168.1.90: bytes=32 time=286ms TTL=255
Sat 03/17/2018 16:08:40.86 Reply from 192.168.1.90: bytes=32 time=176ms TTL=255
Sat 03/17/2018 16:08:41.98 Reply from 192.168.1.90: bytes=32 time=82ms TTL=255
Sat 03/17/2018 16:08:43.22 Reply from 192.168.1.90: bytes=32 time=295ms TTL=255
Sat 03/17/2018 16:08:44.25 Reply from 192.168.1.90: bytes=32 time=114ms TTL=255
Sat 03/17/2018 16:08:45.36 Reply from 192.168.1.90: bytes=32 time=13ms TTL=255
Sat 03/17/2018 16:08:46.59 Reply from 192.168.1.90: bytes=32 time=226ms TTL=255
Sat 03/17/2018 16:08:47.83 Reply from 192.168.1.90: bytes=32 time=133ms TTL=255
Sat 03/17/2018 16:08:49.29 Reply from 192.168.1.90: bytes=32 time=37ms TTL=255
Sat 03/17/2018 16:08:51.92 Reply from 192.168.1.90: bytes=32 time=1795ms TTL=255

The only thing different in the system log for this time frame (besides dropped/allowed traffic) is this entry for IPV6

Mar 17 16:08:39 router.asus.com kernel: icmpv6_send: no reply to icmp error

 

[MachineX]

Are you running repeaters? There are a few us running repeaters and have experienced high wireless latency and complete dropouts that you describe. It goes away after a reboot, but eventually reappears.

I also went through the steps you described, but it doesn't seem to be settings related and nothing shows in the logs.

So far it looks like the only recourse for many of us was to downgrade back to 380.69 branch of code. Not sure that's an option for your ac5300 though.

Nope, no repeaters. The only AP/Router I have is the RT-AC5300

 

[MachineX]

Looks like I should be able to go back to 3.0.0.4.380.7743 (Asus official, released 6/15/17), which is the last version before 384.x was released. Or probably Merlin's 380.69_2 (from 28-Jan-2018).

But I really would like to get all the new fixes, etc....so hoping there might be a fix.

 

[agilani]

Interesting, i was pretty sure the problem was related to repeaters. I'm doing basically the same thing, but through my repeaters with more nodes.

I just upgrade the core hub/router to 384.4 and downgraded my repeaters to 380.69 and am letting it run to see if the instability shows up again.

I thought there was an issue with the ac5300 after upgrade to 384 that prevented downgrade to the 380.69 branch of code, but i may be mistaken.

 

[MachineX]

Maybe there is, but I haven't seen anything except the following, which suggests no issue, other that a factory reset (which I have done several times in the last few days...):

"Note that starting around firmware 3.0.0.4.380_3000 (and with Asuswrt-merlin 380.60), a new firmware format is used, which will reject flashing attempts of any older version than these two versions.

Also reverting from a 382.xx version to an older 380.xx release is not officially supported - you will need to do a factory default after flashing the older release, or restore a settings backup made while still running a 380.xx release."

Source: https://github.com/RMerl/asuswrt-merlin/wiki/Reverting

 

[Zirescu]

Have you tried using a different SSID?

 

[agilani]

Looks like i was mistaken, it was the ac3200 that had the problem with downgrading.

https://www.snbforums.com/threads/release-384-ng-asuswrt-merlin-384-3-is-now-available.44693/

 

[MachineX]

Have you tried using a different SSID?

No, why would you suggest that might make a difference? Been on the same SSID for a couple years, and the site survey does not suggest any conflicts...

 

[MachineX]

Looks like i was mistaken, it was the ac3200 that had the problem with downgrading.

https://www.snbforums.com/threads/release-384-ng-asuswrt-merlin-384-3-is-now-available.44693/

Cool, so looks like I may be ok to revert...but as I said, I am hopeful to fix it, and keep all the new features and fixes...not there quite yet (but getting close).

 

[Zirescu]

Client could be holding onto to some incompatible settings, setting up a new SSID should fix that up. Could use a new Guest SSID to see if the problem persists. How many neighbours do you have? Could be just interference on the 2.4GHz. Did you assign a fixed channel or using auto? If your devices support 5GHz you could switch them over to that.

 

[MachineX]

Client could be holding onto to some incompatible settings, setting up a new SSID should fix that up. Could use a new Guest SSID to see if the problem persists. How many neighbours do you have? Could be just interference on the 2.4GHz. Did you assign a fixed channel or using auto? If your devices support 5GHz you could switch them over to that.

I'm in a pretty rural location, I can pick up a few, but not what I would call a "lot" of other signals. Right now, using auto channel selection (per site survey I am the only one on channel 1 at the moment). Unfortunately several of these devices are b/g, so I am stuck with 2.4GHz for now...

 

[Zirescu]

Yeah, try using a new SSID than.

 

[MachineX]

So, I grabbed a new SD card for one of the pi's and downloaded the latest Raspbian Stretch image. Formatted and installed the image, and added it to the router. Few minutes later, same issue. So, it does not appear to be client side.

Any other ideas?

 

[Zirescu]

When you setup the router after doing the factory default reset did you manually enter the settings or restore from a backup? Do you have a USB key attached to the router?

 

[MachineX]

I was previously on the Asus build, so when I switched to Merlin's firmware, I did the following:

• Installed the Merlin FW
• Did a factory reset (x3) by manually using the reset button. (took about 15 mins with reboots, initialization, etc.)
  
• Logged in via a physically wired workstation, and completed the initial setup.
• All settings were via the web gui, no imports.
• no USB drives are attached, and am not using any of the services (Media Server, SMB, FTP, VPN, etc...all are disabled).

Other than setting the names, icons, etc. for wireless clients, everything is default with exception of enabling IGMP snooping.

 

[Zirescu]

Could try disabling the USB interference and then test again. If no improvement try disabling the beamforming. I've had some success with changing the TX power from Performance down to Power Saving. You probably will want to do a reboot after applying the settings to be on the safe side. Beyond that, might be just a bad wireless driver. Not sure if others with the AC5300 are experiencing similar issues.

 

[MachineX]

So, a quick update. I downgraded to 380.69_2,and the issue no longer happens. All the same settings, SSID, etc. which leads me to believe there is some issue in 384.x somewhere. I don't really know where to go from there. At least I am stable at the moment, but I would really like to get all the updates and features 384.x offers.

 

[cybernexus]

So, a quick update. I downgraded to 380.69_2,and the issue no longer happens. All the same settings, SSID, etc. which leads me to believe there is some issue in 384.x somewhere. I don't really know where to go from there. At least I am stable at the moment, but I would really like to get all the updates and features 384.x offers.

I think it is the new build that was just released. 2.4GHz SSID was having issues, 5GHz SSIDs no issues at all. My son kept complaining his XBOX One would not connect. I noticed other devices would not connect to the 2.4GHz SSID. I would reboot and would resolve for a period of time. I reinstalled the firmware and manually reboot the router and still would have issues of the 2.4GHz SSID unable to connect. I reverted back to 384.3 firmware build and have no issues with any of devices. I'm glad I found this forum and that I'm not the only one having issues with the latest firmware build.