[Beta] Asuswrt-Merlin 380.59 Beta 2 is available

[___Lele___]

Working fine so far thanks.

I'm also recompiling this for source and playing around with the web interface, just for the fun of it. When I "make" do I need to "clean" the project each time (takes forever!) or can I just clean the www module?

Without any "clean" at all some files appear not to regenerate in the UI.

 

[deathnite]

Front LEDs on AC56U are off except for power, as charlie2alpha mentioned on beta 1 thread.
LEDs on the back are working.

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.

 

[jb68]

Edit: Fixed it, Disabling HW Acceleration will cause it to work again?

Having Issues with the Traffic Monitor:

Traffic Monitor Broken, it will not record and show stats. Will only show low amount of usage used when I have downloaded GB's of stuff.

On RT-AC3200

this doesn't work either

This Issue also appears on the latest Beta from Asus, have to revert back to the latest stable to get the Traffic Monitor Stats and this to work

 

[dirtyclyde]

380.59 beta2 AC56U going from default mode (router) to AP mode the front LEDs except power LED not work after a boot, going to the Wireless Page toggling wireless on and off LEDs function normally..

Also on a reset WPS key or button reset the only LED that appears to work is POWER LED (solid)
WPS button held does not flash nor the (power off + MASTER) button reset (Power LED appears not to flash) ....!!!

cheers

 

[dirtyclyde]

380.59 beta2 "Enable IPTraffic (per IP monitoring)" setting on a AC56 or 68U using custom location " with NAT acceleration "CTF auto" the AC56 or 68U will not recover, must use the WPS or MASTER reset buttons to recover to defaults.... OLD HAT STUFF!

cheers

 

[jb68]

Bug:

With Safari Version 9.1 (11601.5.17.1) on Mac OX 10.11.4, when changing QOS Priority Mode, i.e. from Game to Web Surfing, it will say Applying ... but it will not apply.

This happens on the Latest Asus Beta as well. Changing Browser to Chrome works fine, must be something to do with Safari.

 

[Logi]

Loaded the Beta 2 on my AC5300, running fine so far

 

[vrapp]

I ran dslreports test with different QoS settings while Transmission on the router was downloading - at half speed and at full speed. The results are here
The router is AC-68U with beta2 firmware.
There was one remarkable effect: whenever I changed QoS setting, it caused immediate hang up of the dsl modem (speedstream 5100), had to powercycle it.

 

[cybrnook]

Merlin, are these tweaks specific to this beta build, or can these be used on previous releases as well?

For people who want to experiment even further in bufferbloat reduction, try reducing your network interface queue lengths on your router:

echo "8" > /sys/class/net/eth0/tx_queue_len
echo "40" > /sys/class/net/eth1/tx_queue_len
echo "40" > /sys/class/net/eth2/tx_queue_len

These would work for any router models. They won't survive a reboot (and probably won't survive a restart of the wifi/WAN either)

(idea taken from one of the OpenWRT developers)

 

[barbara]

When I "make" do I need to "clean" the project each time (takes forever!) or can I just clean the www module?

You could probably get away with it for minor changes. However, it doesn't update the build date/time. The build date/time is always stuck at the date/time of the first full compile, not the most recent re-compile as one might expect.

Now, I do have some other words about this.

I had to manually delete some prebuilt "o" files when compiling multiple firmwares for different routers. During compile, some "o" files will be copied from the respective "model" folder to the "prebuild" folder. However, "make clean" does not remove these "o" files from the "prebuild" folder, so I must manually delete them otherwise the wrong prebuilt "o" files gets compiled into the firmware.

Note that this is only for the non-source prebuilt binary blobs distributed by Asus. See below.

cd ~/asuswrt-merlin/release/{platform}
make clean
rm .config
rm -f ~/asuswrt-merlin/release/src/router/rc/prebuild/*.o
rm -f ~/asuswrt-merlin/release/src/router/shared/prebuild/*.o

 

[RMerlin]

Merlin, are these tweaks specific to this beta build, or can these be used on previous releases as well?

Any builds. In fact, probably any Broadcom-based router (just adjust the interface names based on what the firmware uses).

 

[RMerlin]

I ran dslreports test with different QoS settings while Transmission on the router was downloading - at half speed and at full speed. The results are here
The router is AC-68U with beta2 firmware.
There was one remarkable effect: whenever I changed QoS setting, it caused immediate hang up of the dsl modem (speedstream 5100), had to powercycle it.

Thanks for the extensive tests.

It seems to at least partly mirror my own tests, showing that fq_codel is not a panacea, and any improvements versus sfq seem sso far to be fairly marginal, at least from the DSLReports' point of view.

Not sure why the modem would hang tho, all the QoS changes to is reconfigure the router's rules, and reconfigure the firewall.

 

[RMerlin]

I had to manually delete some prebuilt "o" files when compiling multiple firmwares for different routers.

It's safer to have parallel copies for each models. My development setup has one primary tree where I commit stuff to Git, and then one folder per model that is rsync'ed with the primary tree. That way, I can compile all 9 firmwares in parallel. Takes roughly 80-90 minutes to do so.

In your case, you could probably work with only two trees: one clean from git, and one from which you compile. Just re-run an rsync between primary and build trees between each models, it will take care of reverting any changes made for the target model.

 

[charlie2alpha]

No QoS system is perfect, fq_codel is certainly no panacea on its own. For a given QoS to be effective it needs to be fine tuned for the type of transfer medium being used and the kind of services on the network. Which is kind of impossible to do in a firmware level for consumer routers that have to be agnostic of such things to account for all variations possible.

But every little bit helps, and unless fq_codel and it's relevant patches are conflicting with ASUS' code I vote for it to remain in the firmware, worse case to just keep the kernel patches if not the ones in the GUI and qos.c for people who use their own scripts.

 

[RMerlin]

Front LEDs on AC56U are off except for power, as charlie2alpha mentioned on beta 1 thread.
LEDs on the back are working.

Confirmed (I originally thought he was referring to stealth mode leaving the Power LED on).

I've been fighting with the RT-AC56U leds for the past three releases now. For some reason, a change Asus did to the watchdog code a few months ago is creating all kind of issues here. I initially reverted their code as a temporary workaround. When they re-changed that code, I put it back, with just one minor change. Looks like it's still causing some kind of issues.

 

[RMerlin]

But every little bit helps, and unless fq_codel and it's relevant patches are conflicting with ASUS' code I vote for it to remain in the firmware, worse case to just keep the kernel patches if not the ones in the GUI and qos.c for people who use their own scripts.

The main reason why I'm undecided is that every time I divert some more from Asus's code, it increases the chances that I will run into issues merging future GPL releases. The fq_codel does a fair amount of patching to all three ARM kernels, and I will also have to reapply all those patches again if Asus came out with a new platform that also has its separate copy of the kernel.

I'm not really happy with having to handle no less than FOUR copies of the kernel at once. Every time I change something to the ARM kernel, I must reapply the same patch three times.

We'll see once more feedback starts coming in.

 

[LouisvilleUK]

Router: RT-AC-68U with 380.59 beta 2 firmware.
Connection speed down/up: 200/20
Speed Entered on QoS down/up: 190/19
Connection Type: Cable
No rules

My QoS results:

No Qos:
Idle Latency: DC 33ms, NY 27ms, DE 38ms, IL 41ms and GA 42ms
Down speed: 234.8
Up speed: 23.63
Grading: BufferBloat D, Quality A+ and Speed A

Adaptive QoS:
Idle Latency: DC 34ms, NY 39ms, DE 39ms, IL 45ms and GA 44ms
Down speed: 141.2
Up speed: 18.69
Grading: BufferBloat A, Quality A+ and Speed B

Traditional fq_codel:
Idle Latency: DC 33ms, NY 39ms, DE 37ms, IL 43ms and GA 43ms
Down speed: 236.8
Up speed: 18.67
Grading: BufferBloat D, Quality A+ and Speed A

 

[trujulu]

Im getting erros in last betas related with iptv. I get around 1 continuity errors each minute when in the oficial release dont.

 

[RMerlin]

Router: RT-AC-68U with 380.59 beta 2 firmware.
Connection speed down/up: 200/20
Speed Entered on QoS down/up: 190/19
Connection Type: Cable
No rules

My QoS results:

Thanks. Looks like in your case, it makes zero difference. Only reason why the Adaptive QoS bufferbloat is so good is because for some reason your download speed is capped quite low - so you never fill up any buffer.

 

[RMerlin]

Did some checking on the LED front - the same issue also occurs with the latest beta firmware from Asus. Something resets all the LEDs during boot, and the LEDs don't properly come back to their previous states.