What's new

[Preview 384/NG] Asuswrt-Merlin 384.5 early test builds

  • 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!

I have a problem with the last build using a vpn client this not show a public ip, and then make a DDOS request until browser is blocked.

znum7jS.png
 

Attachments

  • build.png
    build.png
    334.9 KB · Views: 424
Flashed the alpha 3 over 384.4. Did no restart. Everything running smooth on AC68U for two days now.
Thank you for the hard work RMerlin !
 
Sorry, I know bad language I can not find answer :)
It's a known issue that has been present for months, and will have to be resolved by Asus.

Sent from my P027 using Tapatalk
 
I have a problem with the last build using a vpn client this not show a public ip, and then make a DDOS request until browser is blocked.

znum7jS.png

Those requests are perfectly normal. The page queries the router for any change every two seconds so it can refresh the displayed information.
 
Hmmm..your issue sounds similar to what I thought was going on with my own RT-AC-68P, but is now resolved in a completely different manner. To explain: around the same time the Merlin NG branch (everything post-380.xx) started, I started seeing terrible bufferbloat results on the DSLReports speed test. I tried all sorts of things on the router to solve this, different alphas and betas, only to ultimately discover that what was causing my poor result was having the latest generation of Malwarebytes active and running on my system when doing these tests. It is strictly coincidence that these updates (in both Malwarebytes and the Merlin NG branch) occurred at around the same time: by disabling Malwarebytes temporarily on my test computer, I get perfect A or A+ scores across the board on the DSLReports speed test site. Yes, I am aware that the speed test site points this possibility of some security software interfering, but since it had never affected me previously, I went along for a very long time looking elsewhere.

I just wanted to point out that it might not be a true failure of the QOS system on your router that can sometimes skew the results of tests like these. Perhaps you have other signs of QOS not starting up correctly: system logs, etc...? Also, I think I did read somewhere in this forum that in order for the QOS setup to work correctly, you do have to accept the terms of the Trend Micro AI Protection, as it uses parts of that (closed source) setup to classify the types of traffic.

Good Luck

I tried your suggestion @jsbeddow, but unfortunately without success. QoS is still not running. So I decided to roll back to stock firmware (latest release: 3.0.0.4.384_20648) only to find out that the same issue applies indeed to stock firmware as well. I have provided ASUS with feedback, hopefully they'll be able to fix it.

One I thing I did find out (actually to my surprise) is that dslreport reports higher speeds, lower latency and much less bufferbloat on stock firmware:

32613168.png


versus Asuswrt-Merlin 384.x

31918356.png


Not sure what causes this... Both speedtests where done on the same machine with an USB3.0 Gigabit Adapter.

Well, I'll probably stick with stock firmware for now, awaiting reply from ASUS (and closely monitor the developments related to Asuswrt-Merlin, as I'm going back for sure as I can't see myself living without Skynet, AB-Solution and all these other goodies...)
 
Last edited by a moderator:
I tried your suggestion @jsbeddow, but unfortunately without success. QoS is still not running. So I decided to roll back to stock firmware (latest release: ) only to find out that the same issue applies indeed to stock firmware as well. I have provided ASUS with feedback, hopefully they'll be able to fix it.

One I thing I did find out (actually to my surprise) is that dslreport reports higher speeds, lower latency and much less bufferbloat on stock firmware:

32613168.png


versus Asuswrt-Merlin 384.x

31918356.png


Not sure what causes this... Both speedtests where done on the same machine with an USB3.0 Gigabit Adapter.

Well, I'll probably stick with stock firmware for now, awaiting reply from ASUS (and closely monitor the developments related to Asuswrt-Merlin, as I'm going back for sure as I can't see myself living without Skynet, AB-Solution and all these other goodies...)
Have you tried fresh Jr script to help with the bufferbloat?
 
@RMerlin You recently made some improvements to the textareas for keys/certs. Another improvement would be to add a spellcheck="false" attribute to the textarea tags. That would prevent the red wavy lines from appearing (and also improve performance by avoiding unnecessary spelling checks in up to seven of those 7999 character textareas on a page).

The default for textareas is spellcheck="true" in all browsers:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/spellcheck

This affects these pages:
Advanced_OpenVPNClient_Content.asp
Advanced_System_Content.asp
Advanced_VPN_OpenVPN.asp

Most textareas on other pages are not affected because they have a readonly attribute.
 
Have you tried fresh Jr script to help with the bufferbloat?

As long as QoS doesn't work (it doesn't even start on either stock or on Merlin), FreshJR's script doesn't do anything either...
 
Running Alpha 3 on RT-AC1900P. Just noticed my home automation outlets are no longer accessible if I am not on wifi/LAN. Tried rebooting. They still say offline, but they are not. Was there a change in the firewall that might affect this? Thank you.
 

At least someone else is experiencing issues, glad I'm not the only one. But still, my issue is that Adaptive QoS isn't working at all anymore since 382 and up, and rolling back to stock confirms that is an ASUS issue and not related to @RMerlin's builds, as it doesn't work in stock either. At least for me. It's like my hardware revision (E1) isn't fully supported all of a sudden, but that's something ASUS needs to look at. 380.x is not an option anymore, I loved it, but as it's basically EOL (even though Eric has said he will release security fixes if anything critical surfaces) I'd rather keep up to date to make sure I'm (relatively) safe. Which is the main reason I'm actually quite uncomfortable running stock now... :confused:
 
Whenever I reboot my RT-AC86U I get the following error. I'm running Alpha 3. I have qos running.

Apr 25 11:01:08 kernel: ERR[qos_start:3356] qos_ops is not registered!
Apr 25 11:01:08 kernel: ioctl_iqos_op_switch(1) fail!

If this is a known issue, I'm sorry for the post.
 
Running Alpha 3 on RT-AC1900P. Just noticed my home automation outlets are no longer accessible if I am not on wifi/LAN. Tried rebooting. They still say offline, but they are not. Was there a change in the firewall that might affect this? Thank you.

I am getting the same problem with my Nest thermostat. It goes offline everyone in awhile, but then again all my wifi connected devices. Hardwired connection work just fine. Definitely a firewall interruption.
 
Whenever I reboot my RT-AC86U I get the following error. I'm running Alpha 3. I have qos running.

Apr 25 11:01:08 kernel: ERR[qos_start:3356] qos_ops is not registered!
Apr 25 11:01:08 kernel: ioctl_iqos_op_switch(1) fail!

If this is a known issue, I'm sorry for the post.
This is normal right now. It is Asus's baby @RMerlin has no control. QOS works fine in adaptive mode.
 
Running Alpha 3 ... my home automation outlets are no longer accessible if I am not on wifi/LAN. Tried rebooting. They still say offline, but they are not.

I noticed similar behavior from my iDevices on my RT-AC5300 but only after they received a firmware upgrade to v 3.9.4 . I am planning on doing a clean slate this weekend, I'll post back if it helps out. As usual I am traveling and well all home repair things happen on the weekend. :)

The mrs has been without her automation for a week now, I had to leave last weekend with it off line.
 
Last edited:
Those requests are perfectly normal. The page queries the router for any change every two seconds so it can refresh the displayed information.

Yes when vpn client is not connected request is made each 2 seconds but in this case when vpn client is connected then start to make request each 2 seconds but then 1 request fail and then make 2 request at the same time then from 2 request 1 fail and start 2 new reques then make infinite request that was caused when 1 request fail. Maybe the problem is in the javascript request when 1 request fail start 2 new request and continue the same bucle until make a ddos attack.

I get ~ 9000 request in 60 seconds and then continue infinite until browser crash. Is just using vpn client and seeing vpn status connection.-
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top