[Beta 384/NG] Asuswrt-Merlin 384.5 Beta is now available

[Grisu]

5G on 86U just stopped working, could not connect any more, but have seen my 5G-SSID.
stop and activate 5G solved it, but at least it is not stable.

 

[brummygit]

I've previously reported the same issues on earlier 384 versions but I've had latency issues this morning and discovered that CPU is stuck at 100% utilisation again on my RT-AC68U.

Last time it was reported RMerlin suggested it could be due to my USB drive, which has been disconnected for weeks now. I'm using QoS and AiProtection and have a hunch that this might be related to checks for new Trend Micro signature files.

Output of a Top command is attached

 

[Vexira]

I've previously reported the same issues on earlier 384 versions but I've had latency issues this morning and discovered that CPU is stuck at 100% utilisation again.

Last time it was reported RMerlin suggested it could be due to my USB drive, which has been disconnected for weeks now. I'm using QoS and AiProtection and have a hunch that this might be related to checks for new Trend Micro signature files.

Output of a Top command is attached

Have you set a reboot schedule I do to prevent issues my 88u glitches out with upnp and slow down untill I did, every morning at 4 am it's set to Automatically reboot

 

[brummygit]

Have you set a reboot schedule I do to prevent issues my 88u glitches out with upnp and slow down untill I did, every morning at 4 am it's set to Automatically reboot

Not as a general rule as IT kit should be able to run without needing frequent reboots, however I guess I'll reluctantly need to until this can be fixed.

 

[Vexira]

Not as a general rule as IT kit should be able to run without needing frequent reboots, however I guess I'll reluctantly need to until this can be fixed.

Technically a weekly reboot should be fine, but I do agree a reboot shouldnt be needed.

 

[brummygit]

Technically a weekly reboot should be fine, but I do agree a reboot shouldnt be needed.

Having been in the IT industry for over 30 years with kit up times in years for many devices, I see the need for frequent reboots as a mask for poor coding. Written well, it shouldn't be necessary but I'm going to have to accept it. This is not a pop at RMerlin who gives his time freely and is human, however he also has the errors of Asus to try to solve in addition to his own typos etc. And that's only if the problems are in open source components rather than closed.

 

[Vexira]

Having been in the IT industry for over 30 years with kit up times in years for many devices, I see the need for frequent reboots as a mask for poor coding. Written well, it shouldn't be necessary but I'm going to have to accept it. This is not a pop at RMerlin who gives his time freely and is human, however he also has the errors of Asus to try to solve in addition to his own typos etc. And that's only if the problems are in open source components rather than closed.

One of the biggest issues is the ancient kernel that Asus uses for most of its units that's why there is so many issues.

 

[Blacklistedcard]

One of the biggest issues is the ancient kernel that Asus uses for most of its units that's why there is so many issues.

+1.... The kernel is really old. But I bet the people involved in the firmware development do not want to touch the kernel. My 86u has kernel 4.1.27, which if fine. My 87U has kernel 2.6.36. wow...

 

[Deleted member 48827]

Yeah, there's another weird thing I'm seeing while watching Twitch.. the router registers a massive upload spike every 90 minutes or so; however, the Network properties on the PC do not register this data transfer. I changed the Traffic Monitor back to RAM and will see what it does over the rest of the night.

I've been seeing those spikes on the upstream side. Shows huge momentary data transfer ( 100 times faster than my upstream bandwidth ). For me this happens when streaming video on either my Roku or a PC. The traffic spikes are only shown under traffic analyzer->traffic monitor, and not under traffic analyzer->statistic from what I can tell.

Sorry to hear this is still happening when set to RAM. Mine is still set to RAM for now; I'll keep an eye on it.

 

[Deleted member 48827]

Confirms this is still happening when saving traffic to RAM. These spikes and unrealistic bandwidth do not get recorded under Traffic Analyzer->Statistic.

 

[skeal]

View attachment 12945
Confirms this is still happening when saving traffic to RAM. These spikes and unrealistic bandwidth do not get recorded under Traffic Analyzer->Statistic.

I can validate this. It happened to me last night. It usually happens when I leave Traffic Analyzer running for a extended amount of time. I've seen it a few times now.

 

[RMerlin]

I've previously reported the same issues on earlier 384 versions but I've had latency issues this morning and discovered that CPU is stuck at 100% utilisation again on my RT-AC68U.

Last time it was reported RMerlin suggested it could be due to my USB drive, which has been disconnected for weeks now. I'm using QoS and AiProtection and have a hunch that this might be related to checks for new Trend Micro signature files.

Output of a Top command is attached

CPU usage still registers as I/O. No idea what else could be classified as such, in any case it's not caused by any of the running programs.

+1.... The kernel is really old. But I bet the people involved in the firmware development do not want to touch the kernel. My 86u has kernel 4.1.27, which if fine. My 87U has kernel 2.6.36. wow...

Broadcom decides which kernel to use for their chip with the SDK they provided to manufacturers. Manufacturers cannot change that in any radical way.

 

[RMerlin]

Random spikes in the traffic monitor has been present for years, and it also affects Tomato. Tomato devs have tried to alleviate the issue about two years ago with a few tweaks, and Asus has also made a few tweaks of their own over the years. The final conclusion the Tomato devs had reached is that due to how this is implemented, you have to chose between how frequent those spikes will be versus global traffic accuracy.

In a nutshell, it's a design limitation where the computed data eventually hits a "rollover" value. That's when those spikes are registered. Nobody could figure out a perfect solution, short of scrapping the whole rstats implementation and redesigning it from scratch.

The most important part is that the currently recorded data (as stored in the data file for historical reports) is as accurate as possible.

 

[Odkrys]

RT-AC86U, the latest commit firmware.

Test SSH idle timeout feature, plz.
It does not work to me.

 

[Deleted member 48827]

The most important part is that the currently recorded data (as stored in the data file for historical reports) is as accurate as possible.

Thanks for the info regarding the Traffic Monitor.

As a long-time Tomato firmware user and more recently Merlin firmware, I have seen anomolies in the traffic monitor, but they were not significant enough to render the recorded data useless. The problem has gotten much worse with the upgrade to the 384 code base. One upstream spike, as shown in the graph previously posted, causes the upstream recorded bandwidth to be inflated by 4 Gigabytes and this IS reflected in the historical reports. This is happening one or more times daily now where it used to be once a month at most with older firmware versions.

So, are you saying that the problem is in the open-source code, but there's nothing that can be done about it? Why does Traffic Analyzer->Static record the past 24-hr bandwidth correctly while Traffic Analyzer->Traffic Monitor record the erroneous bandwidth spikes? Am I right that one is the open-source code you speak of (rstats), and the other is Trend Micro closed source? Thanks!

 

[RMerlin]

RT-AC86U, the latest commit firmware.

Test SSH idle timeout feature, plz.
It does not work to me.

Make sure your client isn't sending keep-alive packets.

So, are you saying that the problem is in the open-source code, but there's nothing that can be done about it?

It's a design limitation. Tomato devs and Asus both tried to alleviate the problem, but the only real solution would be to scrap the design and implement it differently.

Traffic Analyzer uses a completely different design, it's actually implemented through a closed-source kernel driver developed by Trend Micro.

 

[Odkrys]

Make sure your client isn't sending keep-alive packets.

I am using putty, keepalive is disabled as default.

dropbear is executed without -I option.
(dropbear -p 192.168.50.1:22 -j -k)
How dropbear handle the timeout now ?

If I execute dropbear with -I 60 in shell manually, it kick me after 60s.
(dropbear -p 192.168.50.1:23 -j -k -I 60)

 

[MarkRH]

Random spikes in the traffic monitor has been present for years

I have only seen these upload spikes in the 24hour data (which also gets saved into the daily stats) since 384.5 beta 2. It thinks I've uploaded like 80GB in the past few days. No previous version of your firmware has shown this while watching Twitch nor has the stock firmware shown it yet (I watched over 4 hours last night without a spike.) Anyway, I've enabled the Statistics and will keep the stock firmware on for tonight and see what happens during the 8 or so hours I watch to see if I can make it happen. Tomorrow I'll put the beta back on to see if it starts again. I'll also change the frequency it saves to the USB drive to see if it affects the timing of these spikes.

 

[RMerlin]

I am using putty, keepalive is disabled as default.

dropbear is executed without -I option.
(dropbear -p 192.168.50.1:22 -j -k)
How dropbear handle the timeout now ?

If I execute dropbear with -I 60 in shell manually, it kick me after 60s.
(dropbear -p 192.168.50.1:23 -j -k -I 60)

I stopped keeping track of things because Asus changed that behaviour like three times over a few months. At one point the timeout wasn't handled by dropbear but by Busybox (ash) itself. I don't know which method they are using nowadays, and to be honest I don't really care either, because anything I change might get reverted a fourth time...

 

[mustafa803]

When using 384.4_2 on 2.4GHZ, channels 1,6 or 11 are selected automatically.

When I upgraded to 384.5 Beta 2, the other channels are selected instead..Now I have to pick channels 1, 6 and 11 manually...

Using Asus RT-AC1900P