What's new

[BETA] Asuswrt-Merlin 380.59 Beta 1 is now available

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

"New Device" is a description, not a hostname. To change the description, you have to go through the Network Client List, not through the DHCP page.

I was able to change all my other DHCP reservation "Description"s through the DHCP page by clicking on the icon and then editing the Name field. This then shows up as the description rather than the host name. Please see the attached screen clip. I do see how you can change these through the network client list, but here too, changes I make are not applied to the DHCP reservation descriptions and for some entries, nothing happens when I click on the icon.
 

Attachments

  • Capture.PNG
    Capture.PNG
    198.1 KB · Views: 470
BTW, I was able to spend some time testing Traditional QoS + my new QoS code last night, with an RT-AC68U. As I thought, Traditional QoS is still working fine with the RT-AC68U (and so it should also be fine on the RT-AC56U). The issue lies only with newer models.

So I was able to do a couple of tests involving SFQ versus fq_codel versus OpenWRT's SQM implementation. The results were not entirely what I expected... I'll need to digest the data first before deciding what to do with these results. But the first thing I noticed, and which didn't really surprise me: from purely a bufferbloat point of view, using DSLReports's bufferbloat tests? I get similar, even slightly better results with... Asus's SFQ implementation. Switching it to fq_codel gave me slightly HIGHER latency.

But that's not the only piece of data I've collected. I'll need to analyze the rest before deciding what to do with it.

But in the meantime, feel free to switch to 380.59 - your T-QoS should still work properly on your RT-AC56U.
This is good news. I'm doing my own experiments with fq_codel today, I'm not sure yet what's the deal but I suspect it may not be as good as you also discovered. I'll know more soon when I access my server remotely from work, my wife complained today that the streaming was choppy. Coincidence? Hmm...
 
[Edit]
Sorry Merlin, I thought it was in topic
I open a dedicated topic.
Thank You for reply :)
 
Last edited:
@RMerlin I did some remote tests to check the upload and the Plex streaming, turns out it's not fq_codel thats causing the issues I encountered today but something with the streaming content itself. So I will need to wait for more conclusive tests before I can say fq_codel is useless.

For now, I will attempt to compile a test build for my RT-AC56U with your latest git and the QoS patches on top of it.
 
These MAC addresses or clients name, have the characteristic of having the first 4 suffixes equal 40:00:3F:06: and the other two variables with a series of combinations...

What are they and who are these mutants MAC addresses?

Why are there? Who creates them?

Does anyone know what is this or what it might be?

You have an Miracast or DirectLink devices on your network?
 
Still looking for more user feedback about this updated page. Please test editing, adding and removing entries.

Also, more feedback related to SMB sharing would be appreciated, especially in these areas:

- People who previously had trouble accessing using a username/password, does it work more reliably now that spnego has been enabled?
- Benchmark numbers showing throughout of 380.58 vs 380.59 for the RT-AC68U and RT-AC87U (performance settings were changed for these model's SMB configuration)

If nothing else is reported, there will be at least a second beta release in the coming days.

Thanks!
Adding and removing a device, changing static DHCP and device description seems to work ok on my RT-AC87U.
 
That's correct. I need to ensure that people can still safely remove, add, or edit entries in that list.

On an AC88u, I have done 2 edits and 1 remove. Worked fine, no issues.

I also like the ability to add a custom icon/photo in the Client Status view. I have added 6+ photos of different sizes and the firmware happily handles them.
 
@RMerlin I did some remote tests to check the upload and the Plex streaming, turns out it's not fq_codel thats causing the issues I encountered today but something with the streaming content itself. So I will need to wait for more conclusive tests before I can say fq_codel is useless.

For now, I will attempt to compile a test build for my RT-AC56U with your latest git and the QoS patches on top of it.

The one scenario where it might have made a positive difference (I need to do more tests) was on latency while running a Speedtest.net test. I think that site opens multiple parallel streams, which would explain why it impacts latency far more than the DSLReports test. With DSLReports, there was barely an increase in latency with both sfq and fq_codel, with sfq being still slightly better. However with Speedtest.net, latency shot to 130-150 ms using sfq, but with fq_codel it remained within the 30-50 ms observed with DSLReports.

That's the scenario that will need more testing: having multiple simultaneous data streams while monitoring latency, to see if fq_codel brings any concrete improvement over sfq.
 
I also like the ability to add a custom icon/photo in the Client Status view. I have added 6+ photos of different sizes and the firmware happily handles them.

That part is Asus's own code. The tricky bit for me was to integrate their code on top of my highly customized DHCP code.

The same integration was also done to the DNSFilter page (it was the first one I did, as a proof-of-concept).
 
Last edited:
In my log web history adaptive QoS, I find about a fifty pages of this series of unknown MAC Address to me and they does not belonging to any network device.

These MAC addresses or clients name, have the characteristic of having the first 4 suffixes equal 40:00:3F:06: and the other two variables with a series of combinations...

What are they and who are these mutants MAC addresses?

Why are there? Who creates them?

This is unrelated to this beta build.

To track down a MAC, check the content of the router's arp table. Over SSH:

Code:
arp -a
.
 
The one scenario where it might have made a positive difference (I need to do more tests) was on latency while running a Speedtest.net test. I think that site opens multiple parallel streams, which would explain why it impacts latency far more than the DSLReports test. With DSLReports, there was barely an increase in latency with both sfq and fq_codel, with sfq being still slightly better. However with Speedtest.net, latency shot to 130-150 ms using sfq, but with fq_codel it remained within the 30-50 ms observed with DSLReports.

That's the scenario that will need more testing: having multiple simultaneous data streams while monitoring latency, to see if fq_codel brings any concrete improvement over sfq.
Actually I did some reading on how codel is supposed to work and you're right on the spot, it won't make a difference when only one stream is used but it will make a big difference when multiple streams are used. That's what it was designed for after all.

Anyway, I prepared already a new build from your latest git with the QoS commits on top, I now have to wait until I get home to install it.
 
Actually I did some reading on how codel is supposed to work and you're right on the spot, it won't make a difference when only one stream is used but it will make a big difference when multiple streams are used. That's what it was designed for after all.

Anyway, I prepared already a new build from your latest git with the QoS commits on top, I now have to wait until I get home to install it.

Keep me informed. If you could also test Asus's Traditional QoS using SFQ versus fq_codel, I'd like to get your feedback. With the custom build having the qos patches applied, you can select the packet scheduler with this nvram value:

qos_sched=0 (Asus's original SFQ)
qos_sched=1 (codel)
qos_sched=2 (fq_codel)

You can easily switch this way:

1) Make sure you enable Traditional QoS on the webui
2) Switch scheduler like this:

Code:
nvram set qos_sched=2
service restart_qos
 
Sure thing, I can just deactivate temporarily the part of my script that changes the qdiscs and the classes and the rest of my modifications (mangle entries to match my various server services) will still be working.
 
The one scenario where it might have made a positive difference (I need to do more tests) was on latency while running a Speedtest.net test. I think that site opens multiple parallel streams, which would explain why it impacts latency far more than the DSLReports test. With DSLReports, there was barely an increase in latency with both sfq and fq_codel, with sfq being still slightly better. However with Speedtest.net, latency shot to 130-150 ms using sfq, but with fq_codel it remained within the 30-50 ms observed with DSLReports.

That's the scenario that will need more testing: having multiple simultaneous data streams while monitoring latency, to see if fq_codel brings any concrete improvement over sfq.


With no qos and speedtest.net on my 88U (Flash Speedtest)

ping bbc.co.uk -n 100

10ms at idle
19-24ms during downstream test
25-36ms during upstream test

I presume im getting better results than you using qos
down to a better connection?
 
Installed 380.59 git with QoS patches last night. Everything works fine on my RT-AC56U except one annoying thing, all the LEDs turned off except the power LED. After some tinkering I found that a simple "service restart_wireless" brought all the LEDs back to life so I put that command to the services_start user script to be executed in every boot. No other complaints for now, my usage case is rather simple after all with the sole exception of the QoS customizations I absolutely need (or the wife would kill me if her Skype work calls would hick up).
 
Installed 380.59 beta 1 on my RT-AC88U and it didn't go well.

First thing I noticed was that NTP was making a lot of entries in the system log and then I noticed that I wasn't getting any internet data from my ISP. My internet status was telling me that the router was connected, but I wasn't getting any data. My IPTV was working though.

So I reverted back to 380.58. I was happy that I made a backup of the settings and JFFS partition, because none of the services I was running under 380.58 were working.
 
Hi!

My 5GHZ radio on my RT-AC88U acts very strange, get sometimes very low speeds, family members think it´s not working at all.
I even reboot my router each night, did a factory reset before installing beta 1.
Anyone else?

//KD
 
Last edited:
I have a weird issue with traffic monitor in this beta which was also in 380.57 but never happened in .58.. My modem, which is plugged into wan port shows GBs of uploaded data each day in the traffic monitor and in adaptive qos screen can see it apparently uploading ~8-9mbps at random times for extended periods. o_O
 

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