Asuswrt-Merlin 3.0.0.4.374.37 is out

[sinshiva]

the problems _asus_ introduced had to do with getting usb hubs to work, and was incomplete. all merlin is trying to do is release the most stable of the code asus gives him + his own tweaks. so if your shirt works, you can thank merlin. otherwise, piss off

 

[saintdev]

hint- dont reply to my posts like idiots if you dont want me proving you wrong....

Go away troll.

 

[KGB7]

Ive been on the road for the past few days, working and i was pondering why one of my AC68 routers randomly freezes up, but the other AC68 that is set up as Media Bridge never skipped a beat. And ive tried different firmwares.


So Merlin, buddy. Got a question for you. Can you create a utility/tool, or perhaps implement it on to your firmware, that will allow me to under-clock my RAM back to factory default 533Mhz?
The AC68 that is running as a router has RAM OCed to 666Mhz with Asus utility, but the second AC68 does not.

The lock ups are random, so at the end of the day, i dont have any specific event to use as a basis to diagnosis the issue.


Thanks in advance.

 

[RMerlin]

So Merlin, buddy. Got a question for you. Can you create a utility/tool, or perhaps implement it on to your firmware, that will allow me to under-clock my RAM back to factory default 533Mhz?
The AC68 that is running as a router has RAM OCed to 666Mhz with Asus utility, but the second AC68 does not.

Did you try modifying the clkfreq nvram setting to reduce RAM frequency back to 533? I'm not sure if the new CFE will still apply it or will enforce the new 666 MHz frequency, but it's worth a shot. Unfortunately there is no way to verify afterward if the value did get properly applied (short of testing with benchmarking tools that would actually stress out RAM).

I can't do anything about the CFE itself, sorry. Someone skilled enough with it might be able to recompile or modify the existing CFE, but with all the risk of permanent bricking involved, I wouldn't touch that myself.

 

[KGB7]

Did you try modifying the clkfreq nvram setting to reduce RAM frequency back to 533? I'm not sure if the new CFE will still apply it or will enforce the new 666 MHz frequency, but it's worth a shot. Unfortunately there is no way to verify afterward if the value did get properly applied (short of testing with benchmarking tools that would actually stress out RAM).

I can't do anything about the CFE itself, sorry. Someone skilled enough with it might be able to recompile or modify the existing CFE, but with all the risk of permanent bricking involved, I wouldn't touch that myself.

To be honest, i have no idea how to modify the "clkfreq nvram" setting. I will try to google and see if i can find an answer. But in the meant time, it would be nice if you can provide me with a short cut.

Im running fw 37_2.

Thanks again.

 

[RMerlin]

To be honest, i have no idea how to modify the "clkfreq nvram" setting. I will try to google and see if i can find an answer. But in the meant time, it would be nice if you can provide me with a short cut.

Im running fw 37_2.

Thanks again.

Run these commands over SSH, or one at a time through the Tools -> Run Cmd page:

nvram set clkfreq=800,533
nvram commit
reboot

Again, no guarantee that the router will actually apply these values. I don't know if the updated CFE still heeds them, or ignores them when the value is lower than its default value.

 

[KGB7]

Run these commands over SSH, or one at a time through the Tools -> Run Cmd page:

nvram set clkfreq=800,533
nvram commit
reboot

Again, no guarantee that the router will actually apply these values. I don't know if the updated CFE still heeds them, or ignores them when the value is lower than its default value.

Thanks dude.

I did find
nvram set clkfreq=
nvram commit
reboot

But i didnt know what numbers to use for "set clkfreq", as the once i found had 3 different numbers.

So im guessing there is no way to check if the " nvram set clkfreq" even got applied in the first place? And im guessing if i do Reboot or Power Cycle the router, then the commands will get erased.

Ill keep on eye on the router and see what happens. In the mean time i will contact Asus and see if they are willing to write a tool that will allow me to set the RAM Frequency back to 553.

Thanks again.

 

[Mayhem85]

Hi i just registre on the site from Europe to tell that the command

nvram set clkfreq=800,533
nvram commit && reboot

Works. my rt-ac68u allways freezes with ind 1-2min with the update 666mhz ram and tryd alot of firmwares with the same outcome, after i wrote the command above to 533mhz all is working perfect Again thanks
Like this.

On the Administration|System tab you have to enable telnet. Then you need a client, the most widely-used seems to be a program called Putty. A Google search should yield a download link for Putty. Once you have it set up on your system open the program by selecting "Putty.exe" from the Putty folder (make sure to note it's location when you unzip the program file). In the Host Name (or IP address) field enter the router's IP address, usually 192.168.1.1 and make sure to highlight the telnet radio button just below that field and the click on the "Open" button.
That will bring up a telnet communications window. Enter the login for your router, usually "admin" unless you have assigned something else and press the "Enter" key. Then enter your password. That brings you to the root# prompt. This is where you will enter

nvram set clkfreq=800,533 (Press Enter)
nvram commit && reboot (Press Enter)
DONE

 

[MarkyPancake]

Update: N16, N66U and AC66U releases delayed while I figure out a USB issue that only occurs on these models.

How is the N66U version progressing?

 

[RMerlin]

How is the N66U version progressing?

The USB issues were resolved with the new GPL code I got from Asus last week. Last night's tests with the new driver went well, however the SDK5 versions is currently completely broken (router fails to boot).

 

[lilstone87]

The USB issues were resolved with the new GPL code I got from Asus last week. Last night's tests with the new driver went well, however the SDK5 versions is currently completely broken (router fails to boot).

Well if you get to the point you feel good with the N66U release with new drivers, and don't have the SDK5 version sorted yet. I am sure there will be a few of us that will be fine beta testing it. As I have explained before the SDK5 drivers are useless to me, as i have stability issue with them, and it makes the DNLA server useless crashing often with my setup.

 

[MarkyPancake]

The USB issues were resolved with the new GPL code I got from Asus last week. Last night's tests with the new driver went well, however the SDK5 versions is currently completely broken (router fails to boot).

That's a shame. I've had better success with SDK5 version so far. I have been tempted to try the SDK6 version again though.

 

[Bagman]

Sooner or later, the people with the old SDK 5 may have to make do with the older feature set, if the new code from Asus doesn't work with SDK 5.

Alternatively, it may be the case that Broadcom/Asus will eventually get their WiFi drivers fixed, and backporting to SDK 5 may become unnecessary.

 

[RMerlin]

Well if you get to the point you feel good with the N66U release with new drivers, and don't have the SDK5 version sorted yet. I am sure there will be a few of us that will be fine beta testing it. As I have explained before the SDK5 drivers are useless to me, as i have stability issue with them, and it makes the DNLA server useless crashing often with my setup.

That is currently shaping up as the plan: release 374.38 without its SDK5 sibling for now, and see if people report positive enough feedback with the new driver to make SDK5 builds either no longer required. If not, I will take another look at it later on when I get more time to spend on it. My time will be a bit limited over the next week to do further tests on this (and I still have the RT-N16 that needs to be tested on the new code too).

The annoying bit is that it's a 15-minutes process every time I have to reflash the N66U over its recovery interface - that really slows things down.

 

[brummygit]

That is currently shaping up as the plan: release 374.38 without its SDK5 sibling for now, and see if people report positive enough feedback with the new driver to make SDK5 builds either no longer required. If not, I will take another look at it later on when I get more time to spend on it. My time will be a bit limited over the next week to do further tests on this (and I still have the RT-N16 that needs to be tested on the new code too).



The annoying bit is that it's a 15-minutes process every time I have to reflash the N66U over its recovery interface - that really slows things down.

That approach would get my vote. I've been using the SDK5 builds but would happily try 374.38 with the improved SDK6 and simply regress to my current version should it not work for me.

 

[MarkyPancake]

Please can someone remind me what SDK6 wireless drivers improve over SDK5 to make Asus use them.

 

[sinshiva]

compatibility with more wifi cards, iirc.

 

[stafli]

That is currently shaping up as the plan: release 374.38 without its SDK5 sibling for now, and see if people report positive enough feedback with the new driver to make SDK5 builds either no longer required.

I'd be happy to test the .38 with SDK6 on my N66U.

 

[RMerlin]

Please can someone remind me what SDK6 wireless drivers improve over SDK5 to make Asus use them.

The newer driver is more actively developped by Broadcom than the old SDK5 version. It also adds PPPoE HW acceleration support (which was broken until recently), the ability to disable a function that was incompatible with XBox 360 (by ticking the "Optimize for XBox" option - that option doesn't work on SDK5), and probably more low-level improvements by Broadcom.

The latest SDK5 driver (5.110) was broken and a lot of wireless adapters couldn't even connect at all to it.

 

[MarkyPancake]

The newer driver is more actively developped by Broadcom than the old SDK5 version. It also adds PPPoE HW acceleration support (which was broken until recently), the ability to disable a function that was incompatible with XBox 360 (by ticking the "Optimize for XBox" option - that option doesn't work on SDK5), and probably more low-level improvements by Broadcom.

The latest SDK5 driver (5.110) was broken and a lot of wireless adapters couldn't even connect at all to it.

I experience better signal strength with SDK5, even after lowering it from the default value, and devices connect to the router much quicker than SDK6.

In light of recent complications with SDK5 I think I will do a fresh install of your latest SDK6 build.