What's new

[384.14_Alpha - builds] Testing all variants.

  • 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.
Mine are still there. examine the amount of NVRAM you are using.
Code:
size: 59593 bytes (5943 left)
940 custom_clientlist
810 nc_setting_conf
603 dhcp_staticlist
516 rc_support
514 dhcp_hostnames
337 vpn_client1_clientlist
334 vpn_client3_cust2
334 vpn_client1_cust2
333 vpn_client_cust2
287 vpn_client_custom2
275 sshd_authkeys
213 cfg_relist
205 wl1_chansps
164 asus_device_list
143 vpn_client3_clientlist
142 vpn_client_clientlist
138 vpn_client2_cust2
129 wps_env_buf
120 qos_rulelist
106 vpn_server2_cust2
 
My main curiosity was about if there was a possibility that it would silence the contrak errors about the table being full, I was looking for an alternative to the script by ram guy.

That's unrelated.

So that I understand correctly, the time it takes to set up the rules may have a minor boost to the time it takes to set them up?

Yes. The way bwdpi sets up the Adaptive QoS rules is that the firmware sets up the rules, and it periodically polls the Linux traffic control tables to see if a certain number of rules have been configured, if not after a while it will complain in the log that "QoS failed to setup" (I forgot the exact message) and might restart the process again. The previous script made this happen more frequently (especially on slower models), it should happen less often now since creating those traffic rules will be slightly faster than before.

But in the end, it will have zero impact on router performance itself, it's only tied to the small period of time where the rules are being configured either at boot time, or after changing QoS settings.
 
I have used Alpha 1 for a while now and seems that "Manually Assigned IP around the DHCP list" have disappeared.
Someone else seen this?

Open the browser console and look for Javascript errors.
 
That's unrelated.



Yes. The way bwdpi sets up the Adaptive QoS rules is that the firmware sets up the rules, and it periodically polls the Linux traffic control tables to see if a certain number of rules have been configured, if not after a while it will complain in the log that "QoS failed to setup" (I forgot the exact message) and might restart the process again. The previous script made this happen more frequently (especially on slower models), it should happen less often now since creating those traffic rules will be slightly faster than before.

But in the end, it will have zero impact on router performance itself, it's only tied to the small period of time where the rules are being configured either at boot time, or after changing QoS settings.
That sounds like a familiar error, I think I've seen it happen after any changes that restarted QoS, well still that's good to hear in my books that that issue will get fixed.
 
I’m having zero WiFi issues on Merlin, based on 81049. I don’t run AiMesh.
I started having WiFi issues and not Merlin related, because I’ve seen this log event mentioned in the stock firmware thread for 81049. I’m seeing this WiFi event in my log periodically with disconnects:
class 3 frame received from nonassociated station (7)

I rolled back to Merlin based on 45717 and haven’t experienced the issue since.

Edit: (Going to try a factory default reset and test some more).
 
Last edited:
I get a buch of them, this was red.
SyntaxError: expected expression, got '<'

Not really useful, would also need to know the content of the line with that error.
 
That sounds like a familiar error, I think I've seen it happen after any changes that restarted QoS, well still that's good to hear in my books that that issue will get fixed.

I said it would happen less often, not that it will be entirely fixed. It's basically a bad design decision from Asus, and the only real fix would be for them to change that behaviour.
 
All I can see in this log are warnings about css from Firefox, and connection failures to its telemetry server.
Sent from my SM-T720 using Tapatalk

okay maybe it was temporarily. I have load alpha build again we have to wait and see it it happen again. o_O
 
Updated to Alpha 2, working fine!!!!
Uptime 0 days 0 hour(s) 19 minute(s) 35 seconds
 
Updated RT-AC86U to Alpha 2, all is running fine


Sent from my iPad using Tapatalk
 
Me too :)
Updated RT-AX88U 384.14_alpha2 over 384.13, Looks OK so far, Thanks :)
 
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