Beta Asuswrt-Merlin 386.1 Beta is now available

[John Fitzgerald]

There are now 3 of us so far that can confirm that rapidly clicking through the menu system (for example to check your settings) on 386 Beta 1 causes the RT-AX58U to crash and reboot.

There are now "4" that can confirm that this happens.

 

[JWoo]

Yes confirmed i can also confirm the issue is not present in the latest stock firmware.

At least 4 of us with RT-AX58U routers have now confirmed that rapidly navigating through the menu in the GUI (for example checking your settings) causes the router to crash and reboot. Hopefully @RMerlin can also confirm as he has an RT-AX58U. The issue is not present in stock or Merlin 384 based firmware. The bug appears to be present in all the 386 Alpha and Beta builds.

 

[AntonK]

At least 3 of us with RT-AX58U routers have now confirmed that rapidly navigating through the menu in the GUI (for example checking your settings) causes the router to crash and reboot. Hopefully @RMerlin can also confirm as he has an RT-AX58U. The issue is not present in stock or Merlin 384 based firmware. The bug appears to be present in all the 386 Alpha and Beta builds.

Brings to mind this old lesson:

“The patient says, "Doctor, it hurts when I do this."
The doctor says, "Then don't do that!”​

Anton

 

[JWoo]

Brings to mind this old lesson:

“The patient says, "Doctor, it hurts when I do this."
The doctor says, "Then don't do that!”​

Anton

Definitely a funny and good medical saying. For troubleshooting software though, the opposite is true. Keep doing it until you can replicate it.

 

[shabbs]

I've done a "dirty upgrade" from 384.19 Release to the 386.1 Beta 1 on two of my four devices. Both RT-AC86U's. Will let these ride for a bit before going further. So far everything is fine. Have given them the usual round of reboots following the upgrade and settle. Will not do a factory reset though.

Will likely keep my main router on 384.19 Release until 386.1 Release hits. Unless I get that upgrade itch. Heh.

 

[dave14305]

At least 4 of us with RT-AX58U routers have now confirmed that rapidly navigating through the menu in the GUI (for example checking your settings) causes the router to crash and reboot. Hopefully @RMerlin can also confirm as he has an RT-AX58U. The issue is not present in stock or Merlin 384 based firmware. The bug appears to be present in all the 386 Alpha and Beta builds.

The Adaptive QoS tab will trigger some bwdpi activity just by clicking on the Bandwidth Monitor page if QoS is not enabled. Can you narrow down which tab seems to be the one triggering the crash? Just switch between Adaptive QoS and any other tab repeatedly to see if it is the reason? I'd be most suspect of this because the bwdpi components now require secret sauce for Merlin to include them in his builds, compared to the general public who can't build them anymore.

 

[rlj2]

hm. looks like asus have a custom config and license etc.
i probably can't re-use their binary in spdmerlin

does running /usr/sbin/ookla work without any arguments?

Im not having any luck, it only wants to get a config file from a server.

 

[vrapp]

After the upgrade of AC68P from 384.19 without any resets, in WebUI there's flashing warning "Your router is running low on free NVRAM", which was not the case before the upgrade. From the system page: NVRAM usage : 63437 / 65536 bytes

 

[hifiwifi]

I'm getting a LOT of "kernel: TCP: time wait bucket table overflow" entries in the log. And a curious "possible DNS-rebind attack detected: sinkhole.netmng.com" entry.

Dec  6 10:42:44 kernel: net_ratelimit: 237 callbacks suppressed
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:44 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: net_ratelimit: 60 callbacks suppressed
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:55 kernel: TCP: time wait bucket table overflow
Dec  6 10:42:56 kernel: TCP: time wait bucket table overflow
Dec  6 10:43:00 dnsmasq[759]: possible DNS-rebind attack detected: sinkhole.netmng.com

 

[Theliel]

Thanks as always Eric for your great work.

RT-AX58U in my case, dirty flash. In general everything seems to work correctly, only two minor issues that for now I have found:

-Once updated, my custom certificate would not load. After several checks it seems that now ECC keys are not supported, only RSA certs. In the previous version there was no problem with using an ECC certificate.

-QoS Class page does not show any graphs or rates. It does appear perfectly below the classifications made to traffic, but not graph or rates. Tested with several browsers, and nothing to highlight in their console or log. Maybe related to FlexQoS or dirty Flash?

On the other hand, my OpenVPN setup seems to work fine, and my own ipset scripts too.

 

[Mutzli]

Thanks as always Eric for your great work.

RT-AX58U in my case, dirty flash. In general everything seems to work correctly, only two minor issues that for now I have found:

-Once updated, my custom certificate would not load. After several checks it seems that now ECC keys are not supported, only RSA certs. In the previous version there was no problem with using an ECC certificate.

-QoS Class page does not show any graphs or rates. It does appear perfectly below the classifications made to traffic, but not graph or rates. Tested with several browsers, and nothing to highlight in their console or log. Maybe related to FlexQoS or dirty Flash?

On the other hand, my OpenVPN setup seems to work fine, and my own ipset scripts too.

It's not recommended to to a dirty flash. See also this post.

 

[Elmer]

Still having Aimesh problems with an AX88 using beta1 meshed to an AC88 and an AC1750_B1. Just like alpha1/2, the AC88 rejoins without problems, but the AC1750_b1 refuses to join. Both the AC88 and AC1750 are using the latest Asus firmware. Both work fine with 384.19. Maybe the 1750 is no longer going to be supported? Going back to 384.19.

 

[Theliel]

It's not recommended to to a dirty flash. See also this post.

I was on 384.19, not alpha, and anyway I am aware that hypothetically it could be of it, that is why I have pointed it out

 

[MNoisy]

Still unable to connect my mesh nodes (5300 and 68) to my ac88 when running this beta. I had to switch the nodes to the official asus beta in order to find them like the alphas. (Found at https://www.snbforums.com/threads/asuswrt-386-rc2-public-beta-with-full-functions-aimesh-2-0.65235/)

 

[rlj2]

Still having Aimesh problems with an AX88 using beta1 meshed to an AC88 and an AC1750_B1. Just like alpha1/2, the AC88 rejoins without problems, but the AC1750_b1 refuses to join. Both the AC88 and AC1750 are using the latest Asus firmware. Both work fine with 384.19. Maybe the 1750 is no longer going to be supported? Going back to 384.19.

If your talking a 66u-b1 (using 68u firmware) 2 of them are working fine in aimesh mode here with the alphas and beta1

 

[ecantona9]

I did a clean install on the AC86U and left the stock Asus RC2-9 on the AC3100 as the node. Working great so far. Traffic Monitor still not working but other than that everything is great. Thanks again Eric.

 

[JWoo]

The Adaptive QoS tab will trigger some bwdpi activity just by clicking on the Bandwidth Monitor page if QoS is not enabled. Can you narrow down which tab seems to be the one triggering the crash? Just switch between Adaptive QoS and any other tab repeatedly to see if it is the reason? I'd be most suspect of this because the bwdpi components now require secret sauce for Merlin to include them in his builds, compared to the general public who can't build them anymore.

@dave14305 you are a smart dude. Running 386.1 Beta 1 on the RT-AX58U, I clicked through the menus without selecting Adaptive QoS and the router appears stable. I then clicked on but did not change the menu options for Adaptive QoS and noticed these new processes running

2944 admin 12688 S < dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/
2957 admin 14964 S wred -B
2966 admin 9872 S bwdpi_wred_alive

The router then crashed and rebooted. So yes, it appears the Adaptive QoS is the stinker. @RMerlin it looks like the culprit is the Adaptive QoS causing the router crashes. Thanks @dave14305 for the great idea.

 

[Yooshaw]

Does your WAN stay up if you stop/start a client? I'm experiencing that right now.

I'm getting this too on my AX-88U. Running one VPN Client on #1 no problem. When I add another client on VPN 2, WAN connection drops. I then have to remove Client #2, then reboot to get WAN back.

 

[gburlingame]

If you know VLAN configurations, I’m hoping to get someone’s thoughts on an observation I made earlier. I posted in a new thread: http://www.snbforums.com/threads/vlan-question-on-386-1-beta-1.68225/

Thanks!

 

[Deleted member 22229]

@dave14305 you are a smart dude. Running 386.1 Beta 1 on the RT-AX58U, I clicked through the menus without selecting Adaptive QoS and the router appears stable.

I just reflashed 386.1 B1. I dont need or use QOS so will just avoid that tab. Other then that the AX58U is working as expected with the new build.