Asuswrt-Merlin 378.56 is available

[RMerlin]

Saw the beta thread, didn't see anything except for someone else having the same issue that was resolved by changing the server and a reboot? That didn't work for me.

And no, no logging dns queries to a usb stick.

Check your system log for any error message related to NTP or dnsmasq.

 

[RMerlin]

RT-AC66U: not possible to set channel 13 manually in 2,4 GHz band anymore

Are you in Japan, using a Japan-bought router?

 

[RMerlin]

After upgrading to 378.56 wan stays disconnected (ppoe to vlan 6, movistar spain)

378.55 and official 9177 connect without problem.

I've tried with and without factory reset and also manual and movistar profiles with no success.

I've read an user in adslzone.net with the same problem with 378.56 beta 2

RT-AC87U

The only change done to WAN was related to route handling (a bug fix submitted by another developer). The rest of the WAN code (like the whole VLAN handling) is unchanged from 9177.

I'll try to compile a test build tonight with that particular fix removed, to see if it helps. In the mean time, try experimenting with the DHCP routing settings available on the IPTV page. See if one of these settings works for you.

 

[RMerlin]

Hi. I found a problem when editing PF with some ports in the definition. see uploaded file.

Basically, when editing the setup for a PF setting with a number of ports that goes off field, the "..." that is visualized is then also considered in the edited field...

thanks,

M

This should have been fixed already. Can you double check that you are indeed running 378.56 final and not a beta build?

 

[RMerlin]

- Overclocking does not work anymore. It works on 378.55 previously.

It seems that Asus changed the way they handle nvram settings that are inherited from the CFE (bootloader), probably to prevent users from bypassing regional and power settings. There's no simple way to prevent this from the firmware, simplest method is for people to re-define the nvram setting in an init-start script. From what people reported, at boot time the overclock gets applied, but afterward the clkfreq gets reset back to the CFE values. Re-setting it at boot time should allow the overclock to persist through reboots.

 

[hggomes]

The very simple answer to overclock not being accepted on recent ASUS FWs IMO:

Any ARM model (RT-AC56U/S, RT-AC68U/P, RT-AC87U, RT-AC3200, RT-N18U) can be overclocked to the same speeds (1.4GHZ) than new unreleased models available the end of this year (RT-AC88U, RT-AC3100 and RT-AC5300) and have the EXACT same performance.

Should i say more?

 

[Shrmn]

The only change done to WAN was related to route handling (a bug fix submitted by another developer). The rest of the WAN code (like the whole VLAN handling) is unchanged from 9177.

I'll try to compile a test build tonight with that particular fix removed, to see if it helps. In the mean time, try experimenting with the DHCP routing settings available on the IPTV page. See if one of these settings works for you.

I am experiencing the exact same issue.

I have 2 AC87 units set up at two different locations on differing Fibre ISPs.

One requires a VLAN to access the internet and for IPTV, while the other has direct access to the internet without any VLAN (no IPTV service on this second one).

I updated the latter to 378.56 and no issues without any factory resets required from 378.55.

Updated the former (VLAN-required ISP) and no internet. Tried on a factory reset, still no internet.

 

[IAAI]

The very simple answer to overclock not being accepted on recent ASUS FWs IMO:

Any ARM model (RT-AC56U, RT-AC68U/P, RT-AC87U, RT-AC3200, RT-N18U) can be overclocked to the same speeds (1.4GHZ) than new unreleased models available the end of this year (RT-AC88U, RT-AC3100 and RT-AC5300) and have the EXACT same performance.

Should i say more?

Exactly

Want Higher speed = buy the new one


Sent from my iPad using Tapatalk HD

 

[snakebite3]

The very simple answer to overclock not being accepted on recent ASUS FWs IMO:

Any ARM model (RT-AC56U, RT-AC68U/P, RT-AC87U, RT-AC3200, RT-N18U) can be overclocked to the same speeds (1.4GHZ) than new unreleased models available the end of this year (RT-AC88U, RT-AC3100 and RT-AC5300) and have the EXACT same performance.

Should i say more?

It seem to me there might be an issue with including the reboot cmd when applying the settings. I applied the settings 3 times but doesn't seem to get applied until I leave out the reboot cmd and reboot using the GUI. For those of you with troubles get it to work maybe try it that way. It could be random luck getting it applied.

 

[snakebite3]

The very simple answer to overclock not being accepted on recent ASUS FWs IMO:

Any ARM model (RT-AC56U, RT-AC68U/P, RT-AC87U, RT-AC3200, RT-N18U) can be overclocked to the same speeds (1.4GHZ) than new unreleased models available the end of this year (RT-AC88U, RT-AC3100 and RT-AC5300) and have the EXACT same performance.

Should i say more?

Is it really the EXACT same performance? Didn't merlin say the CPU in the 3200, 87 is faster than the 68u at the same clock speed? I remember him saying it was like a 20% improvement.

 

[hggomes]

Thats the default clock speeds set at each model, RT-AC56U/S, RT-AC68U, RT-N18U are set at 800MHZ by default, all the other models are set to 1000MHZ, but at the end they all can reach 1.4GHZ without a problem, a small percentage could need to lower to 1.2GHZ because of stability problems, i never faced that scenario, but it could happen depending on each specific CPU batch.

Clock to Clock speeds are the same on any ASUS ARM router model.

 

[snakebite3]

I notice the system time is 1 hour behind. This issue is in the offical FW as well.

 

[hggomes]

I can't really confirm the situation yet, since i didnt touch more than 10m on .56 FW, i would need to do some testings on it.

http://www.snbforums.com/threads/overclocking-rt-ac56u.12578/page-17#post-213361

 

[zoomee]

Hey Merlin,

Does this 378.56 final build have a fix for the problem I was having with the GUI not appearing after initial configuration on official 9135 (RT-AC3200)?

thanks

 

[Maurizio]

This should have been fixed already. Can you double check that you are indeed running 378.56 final and not a beta build?

I'm positive, downloaded from the page reached from the router

 

[pilotboy72]

Hi Merlin,

As always, excellent work on the firmware. My RT-AC3200 is running better than ever!

Brian

 

[hggomes]

Even the clkfreq shows you at default/stock speeds the router is still overclocked, after give a quick test on .56, its definetely FALSE ALARM, heres the result:

378.55:

http://pastebin.com/SL9Pyh0E

378.56:

http://pastebin.com/6r6GGgNb

Confirmation should always be done looking at router BOGOMIPS and OPENSSL benchmark.

 

[kvic]

Even the clkfreq shows you at default/stock speeds the router is still overclocked, after give a quick test on .56, its definetely FALSE ALARM

I believe your observation is correct. Personally I'm still on 378.55. Based on Merlin and other ppl's descriptions so far, my guess is that Asus just overwrite the clkfreq values at a few entry points. Just like how they did it with TxPower I think.

So for ppl eagerly want a way out, a quick workaround could possibly be adding the following to /jffs/scripts/services-stop

nvram set clkfreq=x,y
nvram commit

Replace x and y with your current overclocked values.

When the router is running, no way Asus can underclock as the CPUs don't support dynamic freq adjustment. So it's unlike TxPower in which they could reboot the wireless driver at run-time.

This will guarantee that the next time your router boots up, the clk remains overclocked. (If anyone with 378.56 tries this, could you report back the result?)

EDIT:

Based on this, putting the above code in /jffs/scripts/init-start seems better as the temp workaround. It gets both GUI display and next reboot right.

 

[hggomes]

I think you didnt understand the point, everything is working like before, simply will ALWAYS report the default values on nvram, you need to check on BOGOMIPS or OPENSSL benchmark to see the OC working.

Probably the behaviour can be reverted yes, but at the end thats not the most important thing, it was alot worse if OC was really unavailable at all, not only the nvram reported value.

 

[kvic]

I think you didnt understand the point, everything is working like before, simply will ALWAYS report the default values on nvram, you need to check on BOGOMIPS or OPENSSL benchmark to see the OC working.

Perhaps I don't. I never played with 378.56. But based on people's description, display revert back to default after boot. Actual clocks revert back to default after *reboot*. Is that the case after you reboot?