What's new

[Alpha] Pre-release test builds available (both 380 and 382 branches)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Forgive me if this is an ignorant question.....I have an EA6900 running solidly on 380.69. I was wondering if the 382 alpha builds would be compatible to test on the router.

Thanks
 
Forgive me if this is an ignorant question.....I have an EA6900 running solidly on 380.69. I was wondering if the 382 alpha builds would be compatible to test on the router.

Thanks
This firmware is for specific Asus routers.
 
.I have an EA6900 running solidly on 380.69. I was wondering if the 382 alpha builds would be compatible to test on the router.

This firmware is for Asus routers, if there is a hack version for the EA6900 then find support there.
 
Last edited by a moderator:
I still have a problem with my wireless devices showing up as wired in both the Client Status and View List areas of the GUI.

Been answered many times already. The issue is in the networkmap service, and that service is now closed source and therefore outside of my control. Nothing will change until Asus addressed the issue on their end.
 
QoS is not enabled, neither is any Ai-stuff. I have one Port Forwarding active and one VPN client with policy rules routing, if that matters.

Only Asus would know what can cause runner to get disabled.
 
Been answered many times already. The issue is in the networkmap service, and that service is now closed source and therefore outside of my control. Nothing will change until Asus addressed the issue on their end.
Ah, okay. I thought it was just the friendly naming that was at issue, I missed that the actual connection type was also problematic. Sorry for asking an already answered question.
 
Probably when it‘s ready :)

No, seriously, the A2 is quite stable already. Have been running it for 1 day now and no issues so far.
Is it really?
Merlin said this last Monday.
"It's nothing short of frustrating. The latest stumble block is at boot time Adaptive QoS will fail to setup itself like 90% of the time, requiring to manually restart QoS. So far I've been unable to track down the cause."
 
Is it really?
Merlin said this last Monday.
"It's nothing short of frustrating. The latest stumble block is at boot time Adaptive QoS will fail to setup itself like 90% of the time, requiring to manually restart QoS. So far I've been unable to track down the cause."
The core functions of the build may be rock solid, but extras like Adaptive QoS may have issues. If one does not use any of those problematic extras, stable is an appropriate description.
 
Only Asus would know what can cause runner to get disabled.
Well, the source of AdaptiveQoS_Bandwidth_Monitor.asp is readable of course, so I looked into it:

The page contains a function update_device_tarffic() that makes a request to /getTraffic.asp every second to update the bandwidth gauges.

getTraffic.asp contains just this:
Code:
var array_traffic = new Array();
var router_traffic = new Array();
array_traffic = <% bwdpi_status("traffic", "", "realtime", ""); %>;

router_traffic = <% bwdpi_status("traffic_wan", "", "realtime", ""); %>;

That bwdpi_status causes the runner to get disabled. I have confirmed this by blocking requests to /getTraffic.asp in the adblocker in my browser, which solves the issue.

Would it be an idea to put something like
Code:
if ("<% nvram_get("qos_enable"); %>" == 1) {
}
around those two lines with the bwdpi_status tags in getTraffic.asp?

PS: I do realise that the gauges on that page will no longer function if you have QoS disabled then, but I think that is better than inadvertently disabling HW acceleration and having to reboot to solve that.
 
Last edited:
Is it really?
Merlin said this last Monday.
"It's nothing short of frustrating. The latest stumble block is at boot time Adaptive QoS will fail to setup itself like 90% of the time, requiring to manually restart QoS. So far I've been unable to track down the cause."

So far I have only observed that issue on my RT-AC88U, and to make things worse, it only happens when the router is facing my Internet connection. That means I can't put a temporary router on my Internet connection while attempting to track the issue down. I might eventually have to give up, and wait for Asus to come up with a fix with a future release.
 
Well, the source of AdaptiveQoS_Bandwidth_Monitor.asp is readable of course, so I looked into it:

The issue lies deeper than that. If I disable QoS and I issue a service restart to the QoS system, it will still force qrunner to be disabled even if QoS isn't enabled. It seems that one of the closed source functions within libbwdpi sets qrunner_disable to 1 even if QoS is not enabled, and I cannot change that.

Basically, I can trigger that without even touching the webui. The root issue isn't in the webui code, it's in libbwdpi.

PS: I do realise that the gauges on that page will no longer function if you have QoS disabled then, but I think that is better than inadvertently disabling HW acceleration and having to reboot to solve that.

I disagree. You don't improve performance for a very small subset of users (you don't need runner unless you had a gigabit connection, the CPU is more than able to hit well over 700 Mbps on its own) by breaking other functionality for everyone else. It's making things worse, not better. Stability will always win over performance - it's part of this project's rationale.
 
The issue lies deeper than that. If I disable QoS and I issue a service restart to the QoS system, it will still force qrunner to be disabled even if QoS isn't enabled. It seems that one of the closed source functions within libbwdpi sets qrunner_disable to 1 even if QoS is not enabled, and I cannot change that.

Basically, I can trigger that without even touching the webui. The root issue isn't in the webui code, it's in libbwdpi.
Thanks for the info. Hope that you have enough details to report the bug to Asus.

I disagree. You don't improve performance for a very small subset of users (you don't need runner unless you had a gigabit connection, the CPU is more than able to hit well over 700 Mbps on its own) by breaking other functionality for everyone else. It's making things worse, not better. Stability will always win over performance - it's part of this project's rationale.
Understood, it needs to be fixed elsewhere. For now I have added these rules to my ad blocker:
Code:
@@||192.168.1.1^
||192.168.1.1/getTraffic.asp^$important
 
An early test build for the RT-AC56U is now available as well.
 
Hi there,

I am after the same answer, please RMerlin make us a Xmas gift
Read his answer. He doesn't know and please respect the fact that this is a hobby project.

And besides that, your internet connection and performance will be the same as with 380.69. It's just a new code base.

Verstuurd vanaf mijn SM-G935F met Tapatalk
 
No probs. I read he will release when it’s ready. I must have missed his answer. I will keep checking the forums. No bad feelings people, its Xmas
 
Running the currently latest alpha on my RT-AC68U (RT-AC68U_382.2_alpha2-gdef3266), with QoS enabled (Adaptive / Automatic / fq_codel / WAN Packet overhead = 0 / Web Surfing mode), no issues whatsoever in the past 24 hours since I uploaded it. Did a factory reset beforehand, a power cycle afterwards after it had been up for a while, restored dhcp_staticlist and configured some minor things, no complaints here. Thanks @RMerlin and happy holidays!
 
Status
Not open for further replies.

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