What's new

Asuswrt-Merlin 378.56 is 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!

Status
Not open for further replies.
Once again i will explain:

Imagine the clock speeds at 1000,800 on a specific model.

When you do the commands:

cat /proc/cpuinfo
nvram get clkfreq
openssl speed aes-128-cbc

You will see the results from 1000,800 clock speeds.

If you revert to a accepted clock (lets say 1200,800) or a not accepted one (lets say 2000,1000) will always after rebooting show you on nvram get clkfreq que stock/default value, in this case 1000,800, the difference is:

If a accepted clock you will see "cat /proc/cpuinfo" BOGOMIPS value change, and also the OPENSSL benchmark results.

If not accepted clock, it will keep the original values on "cat /proc/cpuinfo" BOGOMIPS and OPENSSL benchmark results.

nvram get clkfreq will ALWAYS show you the SAME original/stock/default speeds.

That was my conclusion, but i will need to check it further later today, i can be wrong.
 
Some models dont seem to do it
a family members rt-ac56u is fine

where as the rt-ac66u its present 100% of the time
i have been pointing this out for weeks

maybe you should test it with an ac66u
instead of just putting it down to user error

I've done all my development/tests by accessing my routers through their hostnames, and never encountered the issue.
 
Are you in Japan, using a Japan-bought router?
Hello RMerlin,

I have the same behavior with the last firmware and I'm located in Switzerland. I was able to use the channel 13 with the previous versions
 
If a accepted clock you will see "cat /proc/cpuinfo" BOGOMIPS value change, and also the OPENSSL benchmark results.

If not accepted clock, it will keep the original values on "cat /proc/cpuinfo" BOGOMIPS and OPENSSL benchmark results.

nvram get clkfreq will ALWAYS show you the SAME original/stock/default speeds.

That was my conclusion, but i will need to check it further later today, i can be wrong.
Your conclusion is correct. I read some say the setting is lost after a reboot. I assumed they checked using CPUinfo.

I'll report back the result later if you didn't confirm it yet.

Is there a way to fix the system time? It's set to Eastern Time US but it's one hour slower than my PC.
 
Last edited:
@RMerlin why is the DHCPv6 option gone in .56 i like to use IPv4 DNS instead of the IPv6 DNS via my tunnelborker (they are slower).

Is it possible to select the RA and DHCPv6 separate as before?
 
The problem with the overclock persistence caused by refresh_cfe_nvram function. It is located in the closed part of the source code (ate-broadcom).
It's opens /dev/mtd0 (CFE) FLSH area, passes all the variables, and does nvram_set. So clkfreq resets to default values at next boot.
The function is called every time you start the router. We can nvram_get important values prior to call it, then nvram_set after.
In my firmwares this function is simply disabled. It is safe now.
 
I was expecting that kind of behaviour on 378.56, thank you for the confirmation.
 
I have installed magician 378.55 without ningun problem in my asus rt-ac87u previously always are instaldo the original versions of asus but I have seen these firmwares and have decided instalarlo.todo good well speed.. Puer well I have installed from the thread 378.56 thread 1 and the stable 378,56 and there is no form of tenert connection the wan light always in color red .. have I seen that from the forum happens to several equally me podeis to say if solved habeis?? Graces and regards to all
 
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'll try in the morning when I can turn internet off at home ;)
Thank's for the answer
 
I notice the system time is 1 hour behind. This issue is in the offical FW as well.

Asuswrt uses an old, outdated DST database. Manually set it on the Administration -> System page.
 
Some models dont seem to do it
a family members rt-ac56u is fine

where as the rt-ac66u its present 100% of the time
i have been pointing this out for weeks

maybe you should test it with an ac66u
instead of just putting it down to user error

I spent a good amount of time on an RT-AC66U yesterday to test the 378.56 release. All tests were done over http://rtac66:8080 as the URL.
 
@RMerlin why is the DHCPv6 option gone in .56 i like to use IPv4 DNS instead of the IPv6 DNS via my tunnelborker (they are slower).

Is it possible to select the RA and DHCPv6 separate as before?

It's gone because there's the dhcpv6 server was removed months ago, when Asus migrated the IPv6 stack to dnsmasq. That setting only worked with that server.
 
Hello RMerlin,

I have the same behavior with the last firmware and I'm located in Switzerland. I was able to use the channel 13 with the previous versions

Could be a regional limitation that was revised by Asus. In any case, regulation controls are outside of my control.
 
The problem with the overclock persistence caused by refresh_cfe_nvram function. It is located in the closed part of the source code (ate-broadcom).
It's opens /dev/mtd0 (CFE) FLSH area, passes all the variables, and does nvram_set. So clkfreq resets to default values at next boot.
The function is called every time you start the router. We can nvram_get important values prior to call it, then nvram_set after.
In my firmwares this function is simply disabled. It is safe now.

You can thank all the people going through hoops in their attempts to bypass their local regulations by overriding their bootloader settings. Now it's also affecting overclocking as a side-effect, as Asus is forced to tighten control.
 
I have no idea
though you arnt running the router as the primary device handing out the range..
which may or may not affect the results

also you binding to port 8080 may affect the results..

atleast 5 people have reported this problem now
as i have said its present in asus's release also on the rt-ac66u

another thing i have noticed
any reason mDNSNetMonitor is running with itunes support disabled?


I spent a good amount of time on an RT-AC66U yesterday to test the 378.56 release. All tests were done over http://rtac66:8080 as the URL.
 
Last edited:
to be fair if you where stuck on 4 channels for 5ghz if you lived in the uk
due to either broadcom or asus being slack

i suspect you would do the same

here's what's legal in the uk
http://www.digitalairwireless.com/wireless-blog/recent/quick-guide-to-5ghz-uk-part-1.html

You can thank all the people going through hoops in their attempts to bypass their local regulations by overriding their bootloader settings. Now it's also affecting overclocking as a side-effect, as Asus is forced to tighten control.
 
Last edited:
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.

hi, i have the same problem on my RT-AC87 i tested with the Meo profile and the manual configuration but get no wan IP.

I checked the vlan config and ports with robocfg show and it's all like it should be .

Note.. It's working correctly on my AC-3200
 
I have installed the test wan build on ac87u, vodafone on vlan 100 stays broken.
 
Status
Not open for further replies.

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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