[Beta] Asuswrt-Merlin 384.14 Beta is now available

[RMerlin]

Since the update from beta1 to beta2 I have this acsd lines in my log which I have never seen before:

That's simply Asus enabling logging in the acsd daemon, nothing wrong there.

I see the same thing @RMerlin under the system log section.

Sounds like a corrupted dict file entry, since that message should AFAIK only be on the firmware upgrade page, where there is (currently disabled) code to eventually support scheduled automatic updates with the stock firmware.

 

[Neil62]

Sure, my 2.4GHZ band is set to -60 and the 5GHZ band is set to -70 for the RA. In addition, I also use the same SSID for both bands. My channels are also fixed, as is the bandwidth across both bands, i.e no router "AUTO' settings. As I stated earlier, I also don't use smart connect for 'steering' between bands. Never had much luck with smart connect, wants to set channels, etc to auto, and it doesn't seem much good when a lot of your environment is 'open', i.e outdoors vs indoors. I for one, have found auto channel rotation (selection), from the router to be nothing but problematic, but horses for courses, as all WI-FI environments are different.

On a different note I am now seeing these entries in the log today:

Anyone have any idea what they are?

Nov 26 13:59:57 kernel: wfd_unregisterdevice Successfully unregistered ifidx 1 wfd_idx 1
Nov 26 13:59:58 kernel: wfd_unregisterdevice Successfully unregistered ifidx 1 wfd_idx 0
Nov 26 13:59:58 kernel: wfd_registerdevice Successfully registered dev wds1.0.2 ifidx 1 wfd_idx 1
Nov 26 13:59:58 kernel: Register interface [wds1.0.2] MAC: 40:b0:76:c9:5e:e4
Nov 26 13:59:59 kernel: wfd_registerdevice Successfully registered dev wds0.0.4 ifidx 1 wfd_idx 0
Nov 26 13:59:59 kernel: Register interface [wds0.0.4] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:11:42 kernel: wfd_unregisterdevice Successfully unregistered ifidx 1 wfd_idx 0
Nov 26 14:11:42 kernel: wfd_unregisterdevice Successfully unregistered ifidx 1 wfd_idx 1
Nov 26 14:11:42 kernel: wfd_unregisterdevice Successfully unregistered ifidx 2 wfd_idx 0
Nov 26 14:11:42 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 1
Nov 26 14:11:42 kernel: wfd_unregisterdevice Successfully unregistered ifidx 4 wfd_idx 0
Nov 26 14:11:42 kernel: wfd_unregisterdevice Successfully unregistered ifidx 4 wfd_idx 1
Nov 26 14:11:42 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:11:42 kernel: wfd_unregisterdevice Successfully unregistered ifidx 2 wfd_idx 1
Nov 26 14:11:46 kernel: wfd_registerdevice Successfully registered dev wds1.0.1 ifidx 1 wfd_idx 1
Nov 26 14:11:46 kernel: Register interface [wds1.0.1] MAC: 40:b0:76:c9:5e:e4
Nov 26 14:11:46 kernel: wfd_registerdevice Successfully registered dev wds1.0.2 ifidx 2 wfd_idx 1
Nov 26 14:11:46 kernel: Register interface [wds1.0.2] MAC: 40:b0:76:c9:5e:e4
Nov 26 14:11:46 kernel: wfd_registerdevice Successfully registered dev wds0.0.2 ifidx 1 wfd_idx 0
Nov 26 14:11:46 kernel: Register interface [wds0.0.2] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:11:46 kernel: wfd_registerdevice Successfully registered dev wds0.0.3 ifidx 2 wfd_idx 0
Nov 26 14:11:46 kernel: Register interface [wds0.0.3] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:11:46 kernel: wfd_registerdevice Successfully registered dev wds1.0.4 ifidx 3 wfd_idx 1
Nov 26 14:11:46 kernel: Register interface [wds1.0.4] MAC: 40:b0:76:c9:5e:e4
Nov 26 14:11:48 kernel: wfd_registerdevice Successfully registered dev wds0.0.5 ifidx 3 wfd_idx 0
Nov 26 14:11:48 kernel: Register interface [wds0.0.5] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:11:49 kernel: wfd_registerdevice Successfully registered dev wds1.0.5 ifidx 4 wfd_idx 1
Nov 26 14:11:49 kernel: Register interface [wds1.0.5] MAC: 40:b0:76:c9:5e:e4
Nov 26 14:12:25 kernel: wfd_registerdevice Successfully registered dev wds0.0.7 ifidx 4 wfd_idx 0
Nov 26 14:12:25 kernel: Register interface [wds0.0.7] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:12:33 kernel: wfd_unregisterdevice Successfully unregistered ifidx 4 wfd_idx 0
Nov 26 14:12:33 kernel: wfd_registerdevice Successfully registered dev wds0.0.7 ifidx 4 wfd_idx 0
Nov 26 14:12:33 kernel: Register interface [wds0.0.7] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:09 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:15:10 kernel: wfd_registerdevice Successfully registered dev wds0.0.5 ifidx 3 wfd_idx 0
Nov 26 14:15:10 kernel: Register interface [wds0.0.5] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:14 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:15:14 kernel: wfd_registerdevice Successfully registered dev wds0.0.5 ifidx 3 wfd_idx 0
Nov 26 14:15:14 kernel: Register interface [wds0.0.5] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:18 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:15:18 kernel: wfd_registerdevice Successfully registered dev wds0.0.5 ifidx 3 wfd_idx 0
Nov 26 14:15:18 kernel: Register interface [wds0.0.5] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:23 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:15:23 kernel: wfd_registerdevice Successfully registered dev wds0.0.5 ifidx 3 wfd_idx 0
Nov 26 14:15:23 kernel: Register interface [wds0.0.5] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:27 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:15:27 kernel: wfd_registerdevice Successfully registered dev wds0.0.5 ifidx 3 wfd_idx 0
Nov 26 14:15:27 kernel: Register interface [wds0.0.5] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:32 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:15:41 kernel: wfd_registerdevice Successfully registered dev wds0.0.5 ifidx 3 wfd_idx 0
Nov 26 14:15:41 kernel: Register interface [wds0.0.5] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:47 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:15:52 kernel: wfd_registerdevice Successfully registered dev wds0.0.5 ifidx 3 wfd_idx 0
Nov 26 14:15:52 kernel: Register interface [wds0.0.5] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:54 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 0
Nov 26 14:15:54 kernel: wfd_unregisterdevice Successfully unregistered ifidx 4 wfd_idx 1
Nov 26 14:15:54 kernel: wfd_unregisterdevice Successfully unregistered ifidx 4 wfd_idx 0
Nov 26 14:15:54 kernel: wfd_unregisterdevice Successfully unregistered ifidx 3 wfd_idx 1
Nov 26 14:15:54 kernel: wfd_unregisterdevice Successfully unregistered ifidx 2 wfd_idx 0
Nov 26 14:15:54 kernel: wfd_unregisterdevice Successfully unregistered ifidx 2 wfd_idx 1
Nov 26 14:15:54 kernel: wfd_unregisterdevice Successfully unregistered ifidx 1 wfd_idx 0
Nov 26 14:15:54 kernel: wfd_unregisterdevice Successfully unregistered ifidx 1 wfd_idx 1
Nov 26 14:15:59 kernel: wfd_registerdevice Successfully registered dev wds1.0.1 ifidx 1 wfd_idx 1
Nov 26 14:15:59 kernel: Register interface [wds1.0.1] MAC: 40:b0:76:c9:5e:e4
Nov 26 14:15:59 kernel: wfd_registerdevice Successfully registered dev wds1.0.2 ifidx 2 wfd_idx 1
Nov 26 14:15:59 kernel: Register interface [wds1.0.2] MAC: 40:b0:76:c9:5e:e4
Nov 26 14:15:59 kernel: wfd_registerdevice Successfully registered dev wds0.0.2 ifidx 1 wfd_idx 0
Nov 26 14:15:59 kernel: Register interface [wds0.0.2] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:59 kernel: wfd_registerdevice Successfully registered dev wds0.0.3 ifidx 2 wfd_idx 0
Nov 26 14:15:59 kernel: Register interface [wds0.0.3] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:59 kernel: wfd_registerdevice Successfully registered dev wds1.0.4 ifidx 3 wfd_idx 1
Nov 26 14:15:59 kernel: Register interface [wds1.0.4] MAC: 40:b0:76:c9:5e:e4
Nov 26 14:15:59 kernel: wfd_registerdevice Successfully registered dev wds0.0.4 ifidx 3 wfd_idx 0
Nov 26 14:15:59 kernel: Register interface [wds0.0.4] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:15:59 kernel: wfd_registerdevice Successfully registered dev wds1.0.5 ifidx 4 wfd_idx 1
Nov 26 14:15:59 kernel: Register interface [wds1.0.5] MAC: 40:b0:76:c9:5e:e4
Nov 26 14:16:34 kernel: wfd_registerdevice Successfully registered dev wds0.0.6 ifidx 4 wfd_idx 0
Nov 26 14:16:34 kernel: Register interface [wds0.0.6] MAC: 40:b0:76:c9:5e:e0
Nov 26 14:16:35 lldpd[1063]: unable to bind to raw socket for interface wds0.0.6: No such device

 

[Maghook]

As always: updating to current version (.14b2) and afterwards resetting nvram values (RT-AC86u in ap mode).

After completing fresh setup, noticed following:

• First time trying to enable SSH through web-ui getting a popup, claiming "port 22 is defined for usage of ssh". Therefor I can't apply this change (enable ssh daemon) in administration tab (getting this popup forever). First I had to change to another port (23) in order to apply successfully (enable SSH on port 23). After rebooting I could change back port from 23 to 22. @asus: come on, please stop on messing around with SSH.
• Due to ASUS change on LAN IP page concerning hostname some nvram vars don't get set anymore. These are in my case: computer_name, daapd_friendly_name, dms_friendly_name and lan_hostname

 

[rgnldo]

Out of curiosity why the 2.4 GHz band should be improved?

My 2.4GHz network was just 45mb/s. Now 68mb/s. In general, as the FW update, there are problems with these rates at 2.4GHz frequency.

 

[rgnldo]

Interesting bug reports. My device is AC86U. No errors found. Running everything round for me.

 

[rgnldo]

2.4 GHz band should be improved

 

[rgnldo]

Anyone have any idea what they are?

 Compiled in drivers/net/wireless/bcmdhd on Nov  9 2019 at 05:27:52
May  5 02:05:09 kernel: wfd_registerdevice Successfully registered dev eth6 ifidx 0 wfd_idx 1
May  5 02:05:09 kernel: Register interface [eth6]  MAC: 04:d4:c4:43:53:1c

It can be a problem of how you set up your wifi and clients. Here normal. All updates need adaptations.

 

[HyperCris]

I'm currently using the 384.13 stable (very happy with it, thanks @RMerlin !) and I only disabled the Smart Connect feature because the "not so intelligent" Fire TV Stick wasn't able to connect to the 5GHz band. Frankly I thought that those features you disables were useful, am I being naive?

Thanks

 

[rgnldo]

Frankly I thought that those features you disables were useful, am I being naive?

It goes out of necessity. At least home, I have no need for MU-MIMO. I often isolate on the guest network the Alexa echo dot and Android Box. I have few devices.

Fire TV Stick

Enable IGMP Snooping
Preamble Type: Short
Disable UPnP

 

[Eluna]

I had used Merlinwrt with AC68U for 2 years without any problem. However since 384.14 beta 1, the internet status has been displayed as Disconnected (although it was actually fully connected to internet) and NTP time sync service neither worked. Let's Encrypt challenge is still facing an auth error even on 384.14 beta 2. Reset didn't work.

Nov 26 16:57:41 kernel: [Tue Nov 26 16:57:41 GMT 2019] ACCOUNT_THUMBPRINT='Q-Jrbg_RjQiih2xJHJHUQhD2sZBUullX50iuDTKsWNI'
Nov 26 16:57:41 kernel: [Tue Nov 26 16:57:41 GMT 2019] Creating domain key
Nov 26 16:57:44 kernel: [Tue Nov 26 16:57:44 GMT 2019] The domain key is here: /jffs/.le/unnamed.asuscomm.com/unnamed.asuscomm.com.key
Nov 26 16:57:44 kernel: [Tue Nov 26 16:57:44 GMT 2019] Single domain='unnamed.asuscomm.com'
Nov 26 16:57:45 kernel: [Tue Nov 26 16:57:45 GMT 2019] Getting domain auth token for each domain
Nov 26 16:57:49 kernel: [Tue Nov 26 16:57:49 GMT 2019] Getting webroot for domain='unnamed.asuscomm.com'
Nov 26 16:57:49 kernel: [Tue Nov 26 16:57:49 GMT 2019] get to authz error.
Nov 26 16:57:49 kernel: [Tue Nov 26 16:57:49 GMT 2019] _authorizations_map='unnamed.asuscomm.com,{"identifier":{"type":"dns","value":"unnamed.asuscomm.com"},"status":"pending","expires":"2019-12-03T07:57:46Z","challenges":[{"type":"http-01","status":"pending","url":"https://acme-v02.api.letsencrypt.org/acme/chall-v3/1412748812/XBY7sw","token":"DEHJswzSl8X0OgZUApEDSewbezP7YBi_IN8PHc5Ahn8"},{"type":"dns-01","status":"pending","url":"https://acme-v02.api.letsencrypt.org/acme/chall-v3/1412748812/2WX
Nov 26 16:57:49 kernel: '
Nov 26 16:57:49 kernel: [Tue Nov 26 16:57:49 GMT 2019] Please add '--debug' or '--log' to check more details.
Nov 26 16:57:49 kernel: [Tue Nov 26 16:57:49 GMT 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
Nov 26 07:58:00 rc_service: service 3547:notify_rc restart_letsencrypt

* I replaced the actual domain name to unnamed for privacy.

Both being displayed as disconnected and NTP bugs are fixed with rollback to 384.13 build or earlier.

And I found these bugs are reproduced on ASUS's latest stock firmware. Soo I guess it's came from asus' codes..

 

[gburlingame]

I just updated from beta 1 to beta 2 on a RT-AC88U.

I noticed this popping up in the System Log every few minutes. Sometimes a single entry, sometimes multiple bursts.

Nov 25 06:28:44 dnsmasq-script[314]: connect error: No such file or directory
Nov 25 06:28:44 dnsmasq-script[314]: [SEND_AMAS_NODE_EVENT:(4684)] ERROR connecting:No such file or directory.

It's probably nothing, but I thought I should report it.

Cheers!

I want to share some experiences in case they help anyone having troubles.

I logged into the router last night and did a bunch of googling but couldn't find any details about the error SEND_AMAS_NODE_EVENT. I don't know what AMAS is related to, but I did find there is an AMAS_LIB running on the router which I believe is an Asus routine. It shows up when you run TOP.

Interesting while poking around the logs I found a SAMBA log with many errors. I was curious so I checked the GUI and found that a bunch of features were enabled under USB Application section. I thought that was odd because I have no memory of ever turning those features on. I then went through every screen in the GUI and made sure everything that I wanted OFF was OFF, and everything I wanted ON was ON. I rebooted the router hoping the SEND_AMAS_NODE_EVENT error might be gone, but unfortunately it was still present.

I reverted back to Asus' most recent release for the RT-AC88U (Version 3.0.0.4.384.81116 dated 9/23/2019). With this firmware loaded I no longer find any SEND_AMAS_NODE_EVENT errors in the system log, but I observed other unexplained entries in the system log . I forget the specifics, but the errors suggested a device (such as a Nest camera) quickly lost and regained its IP address. That particular camera had a glitch issue for a while now. It's one of the reasons I decided to experiment with Merlin's firmware.

Ultimately I reverted back to an even older build of Asus' firmware for the RT-AC88U (Version 3.0.0.4.384.45717 dated 5/13/2019). With this firmware loaded I am not seeing anything unexplained in the logs. Everything for me appears to be working as expected.

I get the sense that after the May release Asus introduced a number of pretty troublesome bugs. Like others, I am concerned with the apparent degrading quality of Asus' firmware which unfortunately Merlin's code is based upon.

 

[RMerlin]

Due to ASUS change on LAN IP page concerning hostname some nvram vars don't get set anymore. These are in my case: computer_name, daapd_friendly_name, dms_friendly_name and lan_hostname

lan_hostname is set by entering it on the LAN webpage, and is the proper one used by all these services now.

While computer_name can still be set on the Samba page, lan_hostname will be used when generating the Samba config file, unless you overrode it with computer_name.

Same with daapd and dms friendly names - lan_hostname is now used. These should be cleared if you had them manually set to something else.

 

[RMerlin]

And I found these bugs are reproduced on ASUS's latest stock firmware. Soo I guess it's came from asus' codes..

Disable both ping and dns-based WAN monitoring on the System page.

As for the LE update, using Let's Encrypt with a public domain name like asuscomm.com will always be problematic, because Let's Encrypt throttles requests on a per domain basis. It should eventually complete once the request loads for asuscomm.com drops a bit. The code itself however works, I've done lots of tests on it last weekend.

 

[RMerlin]

I don't know what AMAS is related to

It's the original development name for AiMesh.

I don't have GPL code for the RT-AC88U 81351 release yet, so the AiMesh components are still based on the previous 81116 release.

 

[cmkelley]

Ultimately I reverted back to an even older build of Asus' firmware for the RT-AC88U (Version 3.0.0.4.384.45717 dated 5/13/2019). With this firmware loaded I am not seeing anything unexplained in the logs. Everything for me appears to be working as expected.

It's worth noting that "unexplained" log entries are most definitely not the same thing as "problems". Developers turn on debugging outputs and forget (or don't bother) to turn them off, some developers think everyone will "obviously" know a certain log entry is just for information no matter how poorly worded, and English is not the 1st (or sometimes not even the 2nd) language for many developers, so the log entries may not be worded to reflect the developers' intent. I'm sure there are other caveats I've omitted.

The point is, even ominous-looking log entries can be purely informational, or just debugging outputs only useful to the original developer. Even somewhat meaningful log entries such as the infamous dcd_tainted crash, are really a "so what" because the service just restarts itself (and then crashes again, rinse, lather, repeat), which, while it is crappy programming on ASUS/Trend Micro's part, it doesn't affect router operation at all.

 

[Elmer]

Had minimal problems going from 384.13 to 384.14 beta1, but when jumping to beta2 the following things happened:
1. WAN "connect to DNS server automatically" defaulted to yes and I didn't catch it until I noticed the internet status page showing my ISP's DNS servers (I use DNS privacy)
2. The LAN device name reverted to an Asus default, and when I tried to change it back, the system hung, needed a power reset, my LAN DHCP span reverted to the full span (no big deal) - seen the last before.
3. QOS was disabled (again, no big deal)
4. My USB drive showed "unmounted" and when I tried to do a rescan to remount it, I got a gray UI screen saying it was trying to discover my mesh unit. Again it required a power down/up to get things back to normal.
Didn't expect these problems to pop up when jumping from beta 1 to beta 2. Normally this is something you'd see going version to version.

 

[RMerlin]

WAN "connect to DNS server automatically" defaulted to yes and I didn't catch it until I noticed the internet status page showing my ISP's DNS servers (I use DNS privacy)

That didn't change, and has always been the default. The only way this setting would have changed is if you changed it, or if you did a factory default reset.

2. The LAN device name reverted to an Asus default

Already documented in the changelog.

 

[Elmer]

WAN "connect to DNS server automatically" defaulted to yes and I didn't catch it until I noticed the internet status page showing my ISP's DNS servers (I use DNS privacy)
That didn't change, and has always been the default. The only way this setting would have changed is if you changed it, or if you did a factory default reset.

Maybe I should have said it reverted back to yes for "connect to DNS server automatically." I didn't knowingly do a factory default reset; just cycled power.

 

[FLA_NL]

Running beta2 for almost a day now, no dnsmasq issues like in beta1. (RT-AC86U)

 

[rgnldo]

I suggest streamlining FW Merlin release posts. Otherwise the FW Merlin development team will be confused.

Topics:

- Device Asus:

- Upgrade Procedure:

- Uptime

- Features and services enabled:

- Problems found: