What's new

[Release] Asuswrt-Merlin 384.13 is now 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.
Dirty flashed yesterday all supported models from beta to 384.13. Every thing seems to be functioning 100% so far. I haven't had to invoke @skeal 's law yet, "if it can, it will" , or @L&LD 's famous guides for the nuclear reconstruction.
 
Run: At a ssh prompt.
Code:
opkg update
opkg install tcpdump

AWESOME!!!!! That worked. Those lines did look very familiar (just didn't remember and couldn't find reference of them in any posts or links)

This has been a whirlwind week, installing Merlin, after lots of trail and error getting/proving DoT working, finding a workable solution to an old overheating router, changing all my devices (computers, tablets, phones, lots of Raspberry Pi's <---love those things) to route DNS through my DoT router.

...After all that I think my mind did it's own tcpdump. ;)
 
Last edited:
Hi,

I'm new here at the forum.
Created an account for three reasons:
First off I wanna say thanks to the developer(s) of this terrific software!
I have installed it for the first time a couple of months ago and just updated to 384.13.

Secondly, I think I have run into a minor bug. I noticed it first in 384.12, but didn't know about this forum so I didn’t report it sooner.
When I go the the DDNS page (under WAN) I get a pop up stating "Invalid Character". I have entered my email address for No-IP.org with the corresponding password. The username is changed to the username of the router.
In the logs it says:
Start_ddns: update WWW.NO-IP.COM default@no-in.com, wan unit 0
Then a few lines later:
[inadyan] 2061: [401 unauthorized] badauth^M
Which isn’t surprising if the router tries to authenticate with default@no-is.com :)

And last: the logs show that the lets_encrypt service restarts every minute:
rc_service: service <number>: notify_rc restart_letsencrypt
Can’t tell if this is new with 384.13, haven’t noticed it before.

I have a ASUS RT-AC5300, if that helps.
 
Dirty upgrade on my RT-AC87U. Thanks for the firmware.

Have been having sporadic connection drops last few weeks. Been surfing about an hour and these are gone.

Currently pulling stupid stunts and running a public web server on an Intel NUC.
 
yea my issues the exact opposite:eek::eek::eek::eek:, what was your solution, my temperatures are never this low.
i usually rock it in the high 80's low 90's any advice, what was you solution for dealing with high temps, maybe i need to do the opposite to bring my high temps back...

You can't be serious. Making fun of the new guy, I see. ;) Why would anyone want their temps to run extremely high--100c or over. Seems you risk over the intermediate term (at minimum) a failure of the PCB, desoldering, errors, reboots, system instability etc etc..... IMHO
 
Last edited:
You can't be serious! Making fun of the new guy, I see. Why would anyone want their temps to run extremely high--100c or over). Seems you risk over the intermediate term (at minimum) a failure of the PCB, desoldering, errors, reboots, system instability etc etc.....
yes, sorry I did not notice your disposition, I was merely wondering if something was wrong with mine , as I am use to seeing it in the high 80's and low 90's as stated.
 
yes, sorry I did not notice your disposition, I was merely wondering if something was wrong with mine , as I am use to seeing it in the high 80's and low 90's as stated.
My apologies. I thought you were teasing me. Not offended. (should have left off the exclamation point) I can now see that, from your perspective, any change in "operating parameters" <--fancy phrase ;) should beg the question why did that change, even if it changed for the better.
If the changelog should indicate that this was an expected improvement then great, but if it didn't, why did it change/improve?

BTW you asked what was my solution. I don't have one. Both my routers are sitting on a small desktop HEPA air cleaner with fairly high (clean) airflow. One CPU temp reads 61C, the other 101C. Both used to read in the 70's when NOT being actively cooled. I doubt the two are really running with a 40 degree C temperature difference while sitting side by side. If you really want to raise the operating temperature, maybe put it on heater? :O
 

Attachments

  • Screenshot_2019-08-01 ASUS Wireless Router RT-AC68U - System Information(2).png
    Screenshot_2019-08-01 ASUS Wireless Router RT-AC68U - System Information(2).png
    22.4 KB · Views: 388
  • Screenshot_2019-08-01 ASUS Wireless Router RT-AC68U - System Information(3).png
    Screenshot_2019-08-01 ASUS Wireless Router RT-AC68U - System Information(3).png
    22.2 KB · Views: 450
Last edited:
I just can't get the AC87U to work in AP mode anymore. Same thing with 384.12. After factory reset it works just fine, but when enabling AP mode it looks like WAN port won't wakeup and the router doesn't get an IP address. And neither does any device connected to access point. Is there anything you can do Merlin about this issue? 384.11.2 is the last working version.
Should be in the LAN 1 port.
 
Asus has some major enhancements for some AiMesh models coming, probably sometime during Q4. That's all I can say for now.



That's coming from AiMesh nodes.



/jffs/nvram/dhcp_hostnames (it's in the same folder where Asus stores their own larger nvrams).



dhcp_staticlist now has the same format as stock firmware:

Code:
<MAC>IP

As for dhcp_hostnames:

Code:
<MAC>Hostname

It's exactly the same format as the dhcp_hostname nvram on pre-HND models, just that it gets read/written through jffs_nvram_get() and jffs_nvram_set() for HND models. Unfortunately the userspace nvram tool cannot automatically handle it, since the list of large nvrams is hardcoded by Asus, so I cannot make my own additions to it.
Thank you. That helps clarify. Looks like all I need to do is add a check for the nvram variable "model" in the code. If it is an HND model, parse the hostnames from /jffs/nvram/dhcp_hostnames rather than the nvram variable dhcp_hostnames for the non-HND models.
 
Dirty flash from 13 Beta. Both my 86 and 88U flashed perfectly. All seems to be working as advertised. Log quiet too. Great work!

Edit: 86U running at 73 deg. Can I check the mesh node temp? I can't log into it as a mesh (at least it's not letting me).
 
Is the default for these both off? Earlier firmware used to check the internet connection.

Network Monitoring
DNS
Query Ping
 
downloaded and installed the latest firmware 384.13. While going through all the settings, I see in <Tools > Sysinfo> that my CPU temperature had bumped up over 30 degrees C.

I have RT-AC68U router as well, but all my router temps remained the same after dirty flash to 384.13. No change whatsoever.

One CPU temp reads 61C, the other 101C. Both used to read in the 70's when NOT being actively cooled. I doubt the two are really running with a 40 degree C temperature difference while sitting side by side.

Maybe the other router has developed a bad contact between the cpu heat sink and cpu?
 
Last edited:
My apologies. I thought you were teasing me. Not offended. (should have left off the exclamation point) I can now see that, from your perspective, any change in "operating parameters" <--fancy phrase ;) should beg the question why did that change, even if it changed for the better.
If the changelog should indicate that this was an expected improvement then great, but if it didn't, why did it change/improve?

BTW you asked what was my solution. I don't have one. Both my routers are sitting on a small desktop HEPA air cleaner with fairly high (clean) airflow. One CPU temp reads 61C, the other 101C. Both used to read in the 70's when NOT being actively cooled. I doubt the two are really running with a 40 degree C temperature difference while sitting side by side. If you really want to raise the operating temperature, maybe put it on heater? :O
After investigating all my processes are running correctly with no issues, so I am under the impression something must have been broken that got fixed with the update----(I use to have to have mine on a cooler like yours). I hope your issue gets resolved though. keep us updated if you come up with "internal" solutions.
 
Dirty upgrade on my RT-AC86U from .12, seems to be stable so far. The problem I had with the beta where the WebUI would lock up after my second VPN client fires up does not seem to be present in the release firmware so that's good.
 
They may be trying to fix no boot issue after soft reboot on some RT-AC86U and RT-AX88U. Let's see... :rolleyes:

No, the change only affects the RT-AX88U and RT-AX92U. I would have expected the GT-AX1100 to also be affected since it shares the same SDK version, but apparently not.
 
Yes I can confirm the gtax11000 to not be affected(yet) probably because the various updates are not always as current as the rt models of the same sdk.
 
When I go the the DDNS page (under WAN) I get a pop up stating "Invalid Character". I have entered my email address for No-IP.org with the corresponding password. The username is changed to the username of the router.

Disable your browser's autofill for that page, it's incorrectly filling some of the fields.

Thank you. That helps clarify. Looks like all I need to do is add a check for the nvram variable "model" in the code. If it is an HND model, parse the hostnames from /jffs/nvram/dhcp_hostnames rather than the nvram variable dhcp_hostnames for the non-HND models.

Or if you want to be future-proof, simply check if /jffs/nvram/dhcp_hostnames exists. If it doesn't, check for the content of the nvram.

Edit: 86U running at 73 deg. Can I check the mesh node temp? I can't log into it as a mesh (at least it's not letting me).

You can access the nodes over ssh.

https://www.snbforums.com/threads/rt-ac86u-cpu-and-radio-temperature-commands.43089/
https://www.snbforums.com/threads/command-line-to-check-87u-cpu-temp.21702/
 
I have to say my merlin-nodes on average run a couple of degrees cooler than when on stock running as nodes. My average temp on stock is between 76~78 where as on merlin they are 72~74. I don't know what merlin does different , but the merlin nodes run just as well as being on stock and they stay cooler for me.
 
Thank you for another great release!

Dirty upgrade from 384.12 to 384.13 on RT-AC5300 - everything working great and dhcp settings all converted properly.
 
Upgraded RT-AC88U 384.12 to 384.13 without any issues.

Added AirMesh node RT-AC68U running stock firmware went fine as well. However after I added the node check for firmware update would lead to an error saying cannot talk to the server. So I manually uploaded the latest stock firmware on the mesh node and now update check button is working.

Also when I uploaded firmware for the AirMesh node a pop-up window with a login screen opened up and then it asked me to upload a file. When I was running stock Asus I thought this was inline but not 100% sure as I have been enjoying Merlin for a while now :)

Thanks RMerlin.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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