Asuswrt-Merlin 384.8 is now available

[Gar]

@RMerlin Hi after installing the latest firmware 384.8_2 in my AC88U I keep getting this warning:

Dec 10 15:33:57 avahi-daemon[14674]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!View attachment 15427

Is there anyway to fix this? Thanks.

I see the same in mine.

 

[RMerlin]

I did factory reset since I had issues with my external drive of 8TB showing up as USB 2.0 in your latest firmware. In ASUS firmware it shows up as USB 3.0. Any idea how to resolve it?

The USB kernel code is identical to stock firmware, so there's no reason for behaviour to be different there. Check the USB mode setting on the System page.

Is there anyway to fix this? Thanks

There's nothing to fix, those warnings are normal.

 

[jrmtz85]

I absolutely does matter! I have found that temporarily disabling Diversion frees up enough RAM in order to successfully upgrade firmware.

Ah, will do then. Do you disable it within the GUI, or what's the best way to free up the most memory then (installed it only a month ago)?

 

[visortgw]

Ah, will do then. Do you disable it within the GUI, or what's the best way to free up the most memory then (installed it only a month ago)?

From ssh session into router:

# diversion
d
1 (to disable/re-enable)
e​

 

[Veky]

What does it show when you click on it?

Again guys, I am unable to reproduce this on any of my routers here. Do you have any special firewall or DNS setup which could interfere with it? Are update checks enabled on the Other Settings page?

My AC66U_B1 was running 384.7_2. "New firmware version check" was disabled. Upgraded to 384.8, update notification appears. Manually set the flag per your instruction, notification disappears.

Upgraded to 384.8_2, notification not present.

Unset the flag for testing:

admin@router:/tmp/home/root# nvram show | grep webs
webs_notif_flag=
webs_last_info=

Enable new firmware version check, click on check:

admin@router:/tmp/home/root# nvram show | grep webs
webs_notif_flag=
webs_last_info=
webs_state_update=1
webs_state_info=384_8_2
webs_state_url=
webs_state_info_beta=384_8_beta2
webs_state_flag=0
webs_state_error=0
webs_state_upgrade=

Seems to be working fine now.

 

[RMerlin]

My AC66U_B1 was running 384.7_2. "New firmware version check" was disabled. Upgraded to 384.8, update notification appears. Manually set the flag per your instruction, notification disappears.

Upgraded to 384.8_2, notification not present.

Unset the flag for testing:

admin@router:/tmp/home/root# nvram show | grep webs
webs_notif_flag=
webs_last_info=

Enable new firmware version check, click on check:

admin@router:/tmp/home/root# nvram show | grep webs
webs_notif_flag=
webs_last_info=
webs_state_update=1
webs_state_info=384_8_2
webs_state_url=
webs_state_info_beta=384_8_beta2
webs_state_flag=0
webs_state_error=0
webs_state_upgrade=

Seems to be working fine now.

The only theory I have at this time is for some users the boot time check fails. This means the flag should normally get cleared on the next check scheduled to happen 48 hours later.

 

[Stevens243]

That's happening on stock 384.45149 86U FW also.

I saw that post earlier but went and re-read it since you posted. I'm reading that as a seperate issue. I don't know why the daemon is failing and I'm not seeing any other posts on it within the ASUS WRT nor MERLIN forums using search...

 

[john9527]

The only theory I have at this time is for some users the boot time check fails. This means the flag should normally get cleared on the next check scheduled to happen 48 hours later.

Wonder if they are using the stubby or dnscrypt add-ons?

 

[Henrik Troudi]

384.8_2 same behaviour for me with http:/192.168.1.1 access, but htpps://192.168.1.1:8443 works fine.

I'm still wondering why this is happening? Is it a normal behaviour with the latest firmware?

 

[RMerlin]

Wonder if they are using the stubby or dnscrypt add-ons?

No, that's something else, since I finally got it to occur on one of my routers this morning. I will have to do a test build with watchdog debug logging and hope I can reproduce it again. Since I haven't done any change to that code, I have to assume it's something Asus changed in the watchdog code that interferes with it.

 

[Mutzli]

I'm getting the following system log message after updating my new AX-88U: Dec 10 15:11:05 WLCEVENTD: ReAssoc F4:B7:E2:07:10:67
What is that from? I don't have a device with this MAC address on my network?

 

[RMerlin]

What is that from? I don't have a device with this MAC address on my network?

This is definitely something that reassociated to your wifi router with that MAC. Note that some Apple device will randomize their MAC, so it could be it. Could also be something else trying to connect but without the proper key, so it was able to associate, but not to authenticate.

 

[RMerlin]

Speaking of the update server, I had a hard time believing the analytics provided by Cloudflare, so I did a temporary configuration change this weekend to gather traffic data and generate my own analysis. They pretty much confirm what Cloudflare reported, that there are close to 150,000 Asuswrt-Merlin users out there (not counting those who disabled the update checking). That is... mind blowing.

 

[gattaca]

I need to report that 384.8_beta 2 GUI just went south sometime in last 12 hours. No response on refresh and no login. I was still sshed to the box so top showed things running and the router in general was working / routing. I have all the goodies amtm 1.5 enabled. I have a feeling the httpd died but I did not know how to restart it so I had to power off the router. On reboot, things recovered and the ASUS GUI is now talking to me. Running on an RT-AC86U

Note, I also noticed the "flashing yellow !" indicating an upgrade is there when it is not. That is discussed earlier too.

Accessing via https://192.168.50.1:8443

Later!

 

[Datalink]

You know, @RMerlin, you should think about creating your own firewall/router firmware, and control the entire product end to end. That wouldn't necessarily be something that loads on an Asus router, but, something that loads on some form of mini-pc. Food for thought....

 

[skeal]

You know, @RMerlin, you should think about creating your own firewall/router firmware, and control the entire product end to end. That wouldn't necessarily be something that loads on an Asus router, but, something that loads on some form of mini-pc. Food for thought....

That could strain his relationship with Asus development.

 

[Henrik Troudi]

I just want to say thank you RMerlin for putting down so much work and effort. In my book you are a true legend

/ Swedish viking

 

[RMerlin]

You know, @RMerlin, you should think about creating your own firewall/router firmware, and control the entire product end to end. That wouldn't necessarily be something that loads on an Asus router, but, something that loads on some form of mini-pc. Food for thought....

I have nowhere near the required level of know-how for such a major project, and it would require a whole team of developers to get anywhere. Router firmwares are far too complex nowadays to be the work of a single developer. Look at OpenWRT as a good example. Personally, I consider them to be the reference in that field.

Keep in mind that under the hood, 90% of the work is still done by Asus and their whole team of engineers there. They actually deserve more credit than they get, as the vast majority of the actual development is from them. I merely do my own changes on top of their own work. My work would certainly be easier if I wasn't held back by the increasing amount of closed source code, but I don't see that changing anytime soon, so I've learned to live with it for now.

Tinkering/improving an existing platform is not the same ball game as developing the whole product.

 

[bbunge]

Wonder if they are using the stubby or dnscrypt add-ons?

384.8-2 on RT-AC66U_B1 with Entware, Stubby and Transmission. Dirty flash from 384.8. No issues!

Sent from my SM-T380 using Tapatalk

 

[RMerlin]

At this stage, my best theory is this is a timing issue, were the boot time check might be missed or skipped in some cases.

Only way to track down is to carpet bomb the watchdog with debug logging, and hope I can reproduce it again.