[Release] Asuswrt-Merlin 384.13 is now available

[bluepoint]

:/tmp/home/root# pwr config --cpuwait on
-sh: pwr: not found

I guess the "pwr" command isn't part of the default installs of amtm, diversion, or entware? how do I install "pwr"?

That command is for AX-88U only.

 

[Wallace_n_Gromit]

That command is for AX-88U only.

...dang...

 

[Jack Yaz]

BTW @RMerlin, getting back to you on the OpenVPN server issue I raised yesterday in the 384.13 Beta thread (it would not startup, despite clearing the keys, defaulting the settings, then re-importing the settings ), after updating to the 384.13 final release version this morning AND formatting the JFFS partition, the problem was solved (I did not need to do a full factory default reset). My previous symptoms and syslog entries were exactly the same as this user posted a few months back over here in the VPN section:
OpenVPN server not starting on Merlin

One curious item I have been noticing lately: if a guest network is set to the normal default of blocking access to the "intranet" (ie: the LAN resources), and we are using Diversion/Skynet, it will also completely block some websites from loading. I have to specifically un-block/allow these guest networks to access to the "intranet" in order to regain access these sites. In a way, I understand what is happening, but it still seems to defeat the purpose of guest networks when we have to grant access to the local LAN resources.

Use YazFi and you can allow the guest to use Diversion/router DNS without throwing open the whole LAN

 

[jsbeddow]

Use YazFi and you can allow the guest to use Diversion/router DNS without throwing open the whole LAN

Thank you Jack, I had been using it previously, but stripped it out when I was having other issues (the VPN server one, as well as one other), then hadn't put it back yet. I will re-install it immediately, thanks for the reminder.

 

[RMerlin]

Can only hope now that it gives ASUS a bit of kick/hurry up, to put out a new firmware release for those routers supported through AiMesh to fix some current problems and increase its functionality to be a TRUE mesh system. ASUS haven't put out a new firmware for the 86U now in nearly 3 months.

Asus has some major enhancements for some AiMesh models coming, probably sometime during Q4. That's all I can say for now.

After the update the following message appears continuously in the syslog. The Mac address is that of the router (AX88U) itself. Can anyone say anything about this?

That's coming from AiMesh nodes.

What is the file path and name of the file that contains dhcp_hostnames?

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

Are the contents of the file the same as the nvram variable dhcp_hostnames - using the < and > characters as separators? Example:

dhcp_staticlist now has the same format as stock firmware:

<MAC>IP

As for dhcp_hostnames:

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

 

[RMerlin]

Thanks a lot. It's wery strange, why it put off.

Since Asus turns it off for some specific hardware revisions, I can only assume that there was an errata issued by Broadcom recommending to disable it for CPUs older than a specific revision.

I noticed that QoA configuration was not reset to its default values during this update. Was that fixed or was I just lucky?

I know Asus fixed it on their end, but I don't know if the fix was part of 384_6210, or will only be part of a future release.

 

[Delusion]

That command is for AX-88U only.

It also works on 86u but instead of --cpuwait , you have --wait.
Try running : pwr show and see if it shows something

Spoiler: PICTURE

 

[Kingp1n]

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.

Hopefully the RT-AC68R is included!!!

 

[JohnSmith]

Upgrade RT-AX88U from V384.13_beta1-gbde70e184d to V384.13_0 Final via dirty firmware upgrade. 30+ devices and all appears to be working.

 

[JoGi]

After a successful 384.13alpha and beta version, also a smooth update to 384.13

openvpn(server) aimesh, dnssec etc.. works great and stable

Thx Eric

 

[dflaer]

It also works on 86u but instead of --cpuwait , you have --wait.

AC86U, Merlin 384.13 updated from beta, alpha. Before changing something:

RT-AC86U:/tmp/home/root# pwr show

Power Management Configuration Functional Block
Status CPU Wait ENABLED
Ethernet Auto Power Down ENABLED
Energy Efficient Ethernet ENABLED
Switch Deep Green Mode ENABLED (status deactivated)​

But CPU temperature is extremely high (also on beta, alpha).
Set CPU wait is ON:

RT-AC86U:/tmp/home/root# pwr config --wait on​

Nothing to change .

 

[dflaer]

Since Asus turns it off for some specific hardware revisions, I can only assume that there was an errata issued by Broadcom recommending to disable it for CPUs older than a specific revision.

Technically it seems easy, Asus want's you to buy new router), when the old one is burned.

 

[skeal]

Technically it seems easy, Asus want's you to buy new router), when the old one is burned.

Actually that's flawed logic. People don't rush out and buy the same item that just failed them. IMHO

 

[dflaer]

Actually that's flawed logic.

You are right, maybe. But if it's Broadcom's idea - this opinion has the right to exist. Broadcom аll the same what device of the vendor you buy, the main thing with new chip revision. (Sorry for my English).

 

[Wallace_n_Gromit]

Not applicable to an AC68U. You have a different yet troubling issue.

Dave, really appreciate all your help which got me to this point.

This is a question that I can't for the life of me, figure out how I did it last time.

After updating to 384.13 and installing diversion(wouldn't install the first attempt on 384.12 so I bypassed it)... already had amtm and entware (needed entware for tcpdump). I tried to run "tcpdump -i eth0 port 853"

:/tmp/home/root# tcpdump -i eth0 port 853
-sh: tcpdump: not found

Was there an installation process from the SSH command line for tcpdump?

 

[skeal]

You are right, maybe. But if it's Broadcom's idea - this opinion has the right to exist. Broadcom аll the same what device of the vendor you buy, the main thing with new revision. (Sorry for my English).

Before I forget, welcome to the forum!!

 

[Val D.]

Since Asus turns it off for some specific hardware revisions...

They may be trying to fix no boot issue after soft reboot on some RT-AC86U and RT-AX88U. Let's see...

 

[skeal]

Dave, really appreciate all your help which got me to this point.

This is a question that I can't for the life of me, figure out how I did it last time.

After updating to 384.13 and installing diversion(wouldn't install the first attempt on 384.12 so I bypassed it)... already had amtm and entware (needed entware for tcpdump). I tried to run "tcpdump -i eth0 port 853"

:/tmp/home/root# tcpdump -i eth0 port 853
-sh: tcpdump: not found

Was there an installation process from the SSH command line for tcpdump?

Run: At a ssh prompt.

opkg update
opkg install tcpdump

 

[SomeWhereOverTheRainBow]

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. Scrambled to find a fan to cool it off. Still running very hot, normal operating temperature was about 75 degrees C +- 3 degrees.

yea my issues the exact opposite, 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...

 

[dflaer]

Before I forget, welcome to the forum!!

Thanks a lot, several years I just only read the snbf since n66u, ac66u....