Asuswrt-Merlin 378.56 is available

[hggomes]

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.

 

[Shonk]

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.

 

[WaVeR]

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

 

[snakebite3]

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.

 

[wopper]

@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?

 

[XVortex]

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.

 

[hggomes]

I was expecting that kind of behaviour on 378.56, thank you for the confirmation.

 

[cierzo]

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

 

[RMerlin]

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.

 

[RMerlin]

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]

@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.

 

[RMerlin]

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.

 

[RMerlin]

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.

 

[RMerlin]

Those with WAN connectivity issues and an RT-AC87U, please try this test build:

*build removed*

EDIT: Try this second test build instead:

http://www.mediafire.com/download/nw5g3cvd1mchdv2/RT-AC87U_378.56_0-testwan-gbd624b5.zip

 

[cierzo]

Those with WAN connectivity issues and an RT-AC87U, please try this test build:

http://www.mediafire.com/download/7bonx7eo34hlrwx/RT-AC87U_378.56_0-testwan-ga9ea727.zip

The only change was the removal of a patch related to how routing was handled on the WAN interface.

I'm sorry to say no. Still disconnected.
After flashing 9177 with 378.56 settings internet wan connects with no changes in config.

Reverting to 378.55 till further notice,

 

[Shonk]

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.

 

[Shonk]

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.

 

[xptopt]

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

 

[applesnowleo]

I have installed the test wan build on ac87u, vodafone on vlan 100 stays broken.

 

[mlai]

RMerlin, I understand that you can't look at any problems that you cannot reproduce but I am, too, getting kicked out of the GUI on my AC87u and AC68u with 378.56 when accessing with CUSTOM names to the routers/ap where accessing via their respective IP (and also the default router.asus.com) is fine. This problem is also happening with the newest Asus release for both my AC87u (9177) and AC68u (9135).

And I had tested on my AC68u with emergency firmware restore utility and the problem is still there, and the nvram fix did not fix the problem either.

Currently I am falling back to 378.55 on AC68u (which acting only as AP) and the gui is working fine there with CUSTOM hostname. But my AC87 which stays on 378.56 will boot me randomly off GUI when accessing via CUSTOM hostname. I am also using the default LAN port of 80.

The custom hostname is via lines in hosts.add.

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?