Asuswrt-Merlin 374.39 is out

[RMerlin]

Zuul, the Gatekeeper has been unleashed over the world.

Asuswrt-Merlin 374.39 is now available for all routers, except for the RT-N16U (there's no newer fixed GPL code for that model yet).

This build includes Asus's 374.583 GPL code, which adds (amongst other things) support for USB hubs.

Thanks to Asus taking a break from unleashing more GPL code to merge in, I was able to tackle something that had been on my ToDO list for a long time. So, this release marks the introduction of the new DNSFiltering functionality, available under Parental Control. Heavily based on Asus's own YandexDNS code, DNSFilter expanded it to allow users to chose between different filtering services:

• OpenDNS (general malware protection)
• Norton Connect Safe (three different incremental level of protection: Malware, Malware + adult, Malware + adult + mature content). Note: this service is only available for home, personal use, as per Norton Connect Safe's usage license.
• YandexDNS (two incremental level: malware, malware + adult)

You can chose a security level that will be globally applied to all clients. Additionally, clients can be defined, with each client set to a specific filtering service + level (including "none", which would bypass a global filter).

Important: DNSFilter forces select clients to bypass dnsmasq, and connect directly to the specified DNS server. While this means it will be impossible for clients to manually bypass this (the redirection is done at the firewall level), it also means that clients going through one of these special nameservers will NOT be able to resolve local hostnames, since they will be bypassing the router's own internal DNS. This is the price to pay for filtering to be enforced.

SDK5 builds for the RT-N66U are officially discontinued. The recent EM builds has shown that they are good enough to replace what was a painfully hacked together build (those sdk5 builds).

rp-pppoe was re-upgraded back to 3.11. I never got any positive feedback about 3.10 resolving any of the reported issues. And switching back to 3.11 allowed me to enable support for RFC 4638. In plain English: PPPoE users can now set their MTU to 1500 IF their ISP specifically supports them (through the RFC 4638 specifications).

Lots of miscellaneous bug fixes:

• Various issues related to IPv6 support were fixed (Comcast support fixed through a patch provided by Saintdev, as well as broken IPv6 support if you had changed your router's default username)
• Samba security fix for RT-AC56/RT-AC68 - shares will no longer be accessible over WAN. This fix also incidently fixed the long-standing issue where Samba performance was affected by QoS configuration on these two routers.
• Local name resolution will now properly work when you have the router's primary DNS set to a DNS that does not properly return an NXDOMAIN error when appropriate (OpenDNS is one example). Note that if you are using a separate, internal DNS (for example in a Windows domain environment), then you must re-enable the original behavior by enabling "Forward local domain queries to upstream DNS" under LAN -> DHCP Server.
• Various webui issues and quirks were also fixed (see changelog for the complete list)

That's about it. As usual, all the details are in the Changelog.

Enjoy!

 

[RMerlin]

One additional change I'd like to point out, more aimed at low-level tinkerers.

To help in using the Postconf scripts introduced in 374.38, I have added a helper script that will make it trivial to do most common operations on config files (for example, replacing a config line with another one). Here's an example, as found in the README:

     #!/bin/sh
     CONFIG=$1
     source /usr/sbin/helper.sh

     pc_replace "dhcp-lease-max=253" "dhcp-lease-max=100" $CONFIG

So, if the "sed" syntax gave you headaches or nose bleeding (at least for me it did), it's now dead easy to do common search/replace or insert operations on a config file.

Available functions:

   pc_replace "original string" "new string" "config filename"
   pc_insert "string to locate" "string to insert after" "config filename"
   pc_append "string to append" "config filename"

 

[greggy101]

Merlin,

What is your recommendation for the flashing process on the units that are OC'd? Is it safe to do it straight over or a better idea to reverse to stock first?

Thanks much!

 

[chercm]

in the 374.38_2 , i tried to use the usb3 port to charge the iPad mini with Retina and got the error not charging . does the usb support address this too ?

 

[L&LD]

Just installed on RT-N66U v.374.39_0-em and did a few tests:

On laptop: removed and re-associated the ssid (didn't change it to a new one this time).

On router: rebooted router, upgraded from Asus beta v2239 to .39_0-em, reset to defaults and manually setup router again with same settings as my 374.38_2-em 'report to RMerlin' on that .38 thread.


So far:
Web UI: super responsive.

2.4GHz, 20MHz wide band just as fast as 5GHz, 40MHz wide band for ISP Ookla speed tests (btw, hasn't turned off on me yet: up 50 minutes so far).

5GHz band MUCH faster than 2.4GHz band for actual work related LAN use: backups to NAS. This is at around 35 foot distance from router with an Intel AC7260 client.

inssider shows about the same link scores as 38_2-em and Asus beta v2239 did. This is good.

Web UI: super responsive. Yes, it's that good.


Throughput seems the same too (can't test with same location/files right now) which means; excellent throughput for wireless connections.


I think this is the link I'll stick with for a while.

Many, many fixes (thank you RMerlin and Saintdev) along with great performance.

Like getting a new RT-N66U all over again!

 

[connorm]

im tempted to try this but after switching back to the latest asus firmware i have been liking it more the merlin-wrt. especially since with the asus stock i can get full throughput. with merlin .38_2 or and prior versions in the passed month or 2 i have not been able to get full throughput. it has ranges from 92-103mbit. with asus stock i get full 107 every test.

 

[RMerlin]

Merlin,

What is your recommendation for the flashing process on the units that are OC'd? Is it safe to do it straight over or a better idea to reverse to stock first?

Thanks much!

If your router has been running stable for a few weeks then it's probably safe to flash while overclocked. Worst case scenario you might need to do a factory default reset, then use the Firmware Recovery tool to reflash.

If you don't want to chance it then just drop back to the original clocks, reboot, upgrade, then re-increase clocks.

 

[RMerlin]

in the 374.38_2 , i tried to use the usb3 port to charge the iPad mini with Retina and got the error not charging . does the usb support address this too ?

I highly doubt anything would change there, since Apple loves to do non-standard stuff just because they can. For example, look at Asus providing a special USB tool for their motherboards that increases charge rate ONLY with Apple devices. No idea what Apple does there, but it's definitely not behaving like the rest of the USB ecosystem does when hooked to a USB port with the intend of charging.

 

[RMerlin]

ve. Yes, it's that good.

How does it compare with that recent Asus beta? I saw that they also report having improved webui performance, but I have no idea what they did on their end since they didn't release the GPL for it (and I didn't ask either since it's a beta). I suspect they might have picked up the same change I did in 38_2 (caching images), wondering if they did more than that, or improved performance in a different way.

 

[cmillar6]

im tempted to try this but after switching back to the latest asus firmware i have been liking it more the merlin-wrt. especially since with the asus stock i can get full throughput. with merlin .38_2 or and prior versions in the passed month or 2 i have not been able to get full throughput. it has ranges from 92-103mbit. with asus stock i get full 107 every test.

More than likely its your ISP, not firmware. Merlins builds retain Asus stock code and drivers, I've never seen a difference in throughput between Asus and Merlin firmware on my AC66u.

 

[AnTiLooP]

Merlin,

thanks for the update however it appears that -

>> AC66U

1. The GUI for Media Bridge on the AC66U is broken in the sense that I'm connected to my AC68U bridge but it shows I'm disconnected.

2. Wireless throughput appears to have dropped. I'm on a 300/300 Internet link and managed to get that 100% of the time. after flashing I"m getting 20mbps less on up and down streams.

I've hard reset the AC66U already with no joy. both ends of the bridge have been rebooted as well. I've reflashed the AC66U back to 38_2 and I'm getting back the full 300/300, To be exact 304/302 thereabouts. I cycled the update again and I'm back to square one. Media bridge UI broken and less 20mbps throughout.

any idea why ?

thanks.

 

[Kris404]

..it also means that clients going through one of these special nameservers will NOT be able to resolve local hostnames, since they will be bypassing the router's own internal DNS. This is the price to pay for filtering to be enforced.

That would be perfect for Kids' tablets as those devices would not need local resolution anyway.

 

[RMerlin]

Merlin,

thanks for the update however it appears that -

>> AC66U

1. The GUI for Media Bridge on the AC66U is broken in the sense that I'm connected to my AC68U bridge but it shows I'm disconnected.

I've seen reports about this with the stock firmware as well. I suspect Asus broke it in 374_583/20xx. Not sure what's going on there, I didn't look at it.

2. Wireless throughput appears to have dropped. I'm on a 300/300 Internet link and managed to get that 100% of the time. after flashing I"m getting 20mbps less on up and down streams.

No idea. I stopped stressing about wireless performance since I have zero control over it, and I kept get flooded with contradictory feedback. Barring any major issue, I just stick to whichever is the latest driver provided by Asus. Right now, the only exception is the RT-N66U.

 

[connorm]

More than likely its your ISP, not firmware. Merlins builds retain Asus stock code and drivers, I've never seen a difference in throughput between Asus and Merlin firmware on my AC66u.

its impossible its my isp

Merlin-WRT QOS Enabled = 92-103Mbit (inconsistent)
Merlin-WRT QOS Disabled = 107Mbit every time (consistent)

Asus-WRT QOS Enabled = 107Mbit every time (consistent)
Asus-WRT QOS Disabled = 107Mbit every time (consistent)

its not my ISP. but its hard to tell if its later versions of merlin-wrt causing this. because i used to only get 97 down and not notice it. since about 2 months ago my isp bumped my provisioned rate from 102mbit to 112. allowing me to get 106.9 instead of 97.5.

merlin firmware jumps around 92-103. mainly around 93-95mbit.

NOT my ISP. firmware...

 

[sinshiva]

everything working fine, but some weirdness in the beginning that i think may have resolved itself if i had just rebooted the router again after the flash;

i had to reformat jffs after the flash and my sdcard wasn't mounted to sda1. i rebooted again and the sdcard mounted on boot. so, i wonder if jffs would have kept if i hadn't reformatted it before rebooting again.

 

[RMerlin]

That would be perfect for Kids' tablets as those devices would not need local resolution anyway.

Indeed. Personally, I recommend that people leave the global filter to "None", and just specifically filter devices that actually need it. I left the possibility of defining a global (default) filter for people that aren't worried about losing local resolution.

 

[AnTiLooP]

I've seen reports about this with the stock firmware as well. I suspect Asus broke it in 374_583/20xx. Not sure what's going on there, I didn't look at it.



No idea. I stopped stressing about wireless performance since I have zero control over it, and I kept get flooded with contradictory feedback. Barring any major issue, I just stick to whichever is the latest driver provided by Asus. Right now, the only exception is the RT-N66U.

cool with that. I've dropped back to 38_2 as that appears better for me .

good work regardless. I have the 39_0 sticking with my main router AC68u.

cheers Merlin and I appreciate your work here.

 

[L&LD]

How does it compare with that recent Asus beta? I saw that they also report having improved webui performance, but I have no idea what they did on their end since they didn't release the GPL for it (and I didn't ask either since it's a beta). I suspect they might have picked up the same change I did in 38_2 (caching images), wondering if they did more than that, or improved performance in a different way.

The Asus beta v2239 seemed just a little better than the 374.38_2-em build in ui responsiveness, but most likely was equivalent if I could actually measure them.

The 374.39_0-em version is easily faster feeling than both the v2239 and the 38_2-em version was. I don't know what you did or how it differs from the 38_2-em version, but it is almost like I am browsing my SSD's file folders.

To try to define the increase in speed a little better; it is almost like it is building/generating the page to be shown, before it is shown.

This is on a Windows 8.1 64bit PC with IE 11 as the browser, just in case it makes a difference.


And to be honest, the rest of the web shares this better, faster more fluid feeling responsiveness with the RT-N66U.

 

[RMerlin]

To try to define the increase in speed a little better; it is almost like it is building/generating the page to be shown, before it is shown.

Previously, the webui would let the browser decide what it wanted to cache. Since the router's httpd daemon is single-threaded, it means that page load could be quite long, as each image, css and js had to be transferred one by one, with the page rendering progressively between each element. This was VERY visible when using https, which added the performance overhead of having to encrypt/decrypt every file.

In 38_2, I configured the httpd to instruct browsers to cache any jpeg or png for at least a few minutes, which is usually enough for typical use. So after you loaded the first page, accessing other pages would only need to transfer the css and js, and the larger images were loaded from local cache.

In 39, I also added CSS caching, since these are also static files. So the "render-as-it-loads" has disappeared since most of the files required for the rendering are already present in your browser cache.

This is probably the limit to what can be gained through cacheing. Javascripts can't be cached, as they contain a lot of dynamic data that is processed by the httpd daemon before it gets sent to the client.

For the record, the current (as of 374_39) cacheing behavior mirrors that of Tomato. People often pointed out how responsive Tomato's UI was. Part of it is because it's much more lightweight than Asus's, but another reason was its more aggressive caching of web elements.

 

[L&LD]

Ah, so it is not my imagination then; the web gui is much more responsive.

Reaches for another beer (toast to RMerlin, of course!).