[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are now available

[protoncek]

@Val.D. : it would still be nice if you would tell us what is so wrong with this router?

 

[Makaveli]

@Val.D. : it would still be nice if you would tell us what is so wrong with this router?

Maybe better to do that in its own thread or via pm.

off topic for this thread.

 

[Brenneke]

RT-AC68U running flawlessly on 384.14 after upgrade a few days ago from 384.13. I am a little ashamed to admit it but have not ever done a factory reset since buying this router new, loading Merlin and upgrading FW along the way a few years back.

 

[podkaracz]

I have rt86u and the answer is 45717 to anything you ask for. I think install 45717 with removed option to update firmware or change firmware . Make your life easy if you want to forget about router.

 

[podkaracz]

If you dont turn your pc on/off you wont get 1 spam message on 45717 (6 days without single message in log gg) . Beat that with all bugged firmware revisions lets go !

 

[Swistheater]

Hi,
someone already asked but it did not get an answer:
I have a RT-AC88U and came from .13 to .14

After 23 hours all looks good so far and is running but there are lot of mog messages from dnsmasq:

Dec 18 11:39:23 tackaman dnsmasq-script[2237]: connect error: No such file or directory
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: [SEND_AMAS_NODE_EVENT:(4684)] ERROR connecting:No such file or directory.
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: connect error: No such file or directory
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: [SEND_AMAS_NODE_EVENT:(4684)] ERROR connecting:No such file or directory.
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: connect error: No such file or directory
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: [SEND_AMAS_NODE_EVENT:(4684)] ERROR connecting:No such file or directory.
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: connect error: No such file or directory
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: [SEND_AMAS_NODE_EVENT:(4684)] ERROR connecting:No such file or directory.
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: connect error: No such file or directory
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: [SEND_AMAS_NODE_EVENT:(4684)] ERROR connecting:No such file or directory.
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: connect error: No such file or directory
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: [SEND_AMAS_NODE_EVENT:(4684)] ERROR connecting:No such file or directory.
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: connect error: No such file or directory
Dec 18 11:39:23 tackaman dnsmasq-script[2237]: [SEND_AMAS_NODE_EVENT:(4684)] ERROR connecting:No such file or directory.
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted
Dec 18 11:39:23 tackaman dnsmasq[2237]: failed to send packet: Operation not permitted

Is there an explanation? I am using DoT mainly if this is related. Can I do something to analyse it further with your help? thanks.

@RMerlin
Sorry to bring back this old topic, I just want to know if you have discovered anything critical happening with these logs or have found a way to suppress them? are these important or are they negligible? should one redo their mesh pairings if their logs are being flooded with these?

 

[gotdade]

Intermittent problem with unwanted AP client isolation on 384.13_2 on AC-3200.

I have been using 384.13 on the device and it has been rock solid, with no issues, and I only upgraded because the Let's Encrypt certificates stopped renewing.

Now I am having a new problem which did not occur before. I have a Raspberry Pi 4 connected with wifi, running Home Assistant. It has been stable on 384.13. After the router was upgraded to 384.13_2, the connection to the Pi has started behaving oddly. After a few minutes, or hours, the Pi has become "isolated" like if AP Isolation was enabled. That is, it is possible to connect (ping,ssh,...) to the Pi from the router itself, but not from another client connected to the router. The Pi's wifi connection itself appears to be stable. Restarting the router wifi or restarting the router itself enables the routing again.

The AC-3200 is configured with 3-band Smart Connect. It makes no difference when I disable it. I also attempted disabling Turbo QAM, AirTime Fairness and Beamforming, as suggested on this forum. These settings did not appear to improve the situation.

Finally, disabling WMM APSD on 2.4 GHz in the "Professional" wifi settings in the AC-3200 seems to have improved the situation, possibly resolved it. WMM APSD is still enabled for the 5 GHz. 802.11ac Beamforming is still enabled.

I hope this report helps someone.

 

[Khadanja]

Getting this after upgrading on RT-AC68U
Upgraded few days ago but noticed the problem today when devices randomly lose internet access.
Dec 25 23:54:59 syslog: WLCEVENTD wlceventd_proc_event(386): eth2: Deauth_ind 0B:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Dec 25 23:55:03 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth 0B:56, status: 0, reason: d11 RC reserved (0)
Dec 25 23:55:03 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc status: 0, reason: d11 RC reserved (0)

 

[Darcy]

Merry Christmas everyone!


Sent from my iPhone using Tapatalk

 

[ech]

I think I found what's causing it (well, the high level cause though not a specific patch)... in that on the .13 firmware, the wanduck daemon is running, while on the .14 firmware it isn't at all, and that's why the link_internet nvram setting hasn't been updated.

I compiled the current .15 alpha and noticed that that firmware does get wanduck started up and running and so the problem is gone there as well, or at least I haven't seen it there.

Realized (since I didn't see it in the "compile from source" wiki) that I'd compiled a non-mainline .15 firmware, which misses a lot of changes, including the binary blobs... so that explains why my .15 build isn't seeing the problems I saw on the .14 Merlin build (no internet status when there is, and traffic spikes causing useless data in the traffic monitor graphs and data, and traffic statistic stops being updated after an hour or so)... so it looks like something must have crept into the sdk/binary blobs to cause these issues with my config.

Haven't had a chance to test yet but I've built a 384.14 firmware from the 384.14-mainline tag as well as one using that same tag, with the latest ac68u binary blob commit reverted to see what differences I can see in behavior.

 

[Butterfly Bones]

Getting this after upgrading on RT-AC68U
Upgraded few days ago but noticed the problem today when devices randomly lose internet access.
Dec 25 23:54:59 syslog: WLCEVENTD wlceventd_proc_event(386): eth2: Deauth_ind 0B:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Dec 25 23:55:03 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth 0B:56, status: 0, reason: d11 RC reserved (0)
Dec 25 23:55:03 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc status: 0, reason: d11 RC reserved (0)

https://www.snbforums.com/threads/r...13-is-now-available.57860/page-35#post-515660

wlceventd is unrelated to DHCP. It's a daemon Asuswrt runs to detect wireless client connecting/disconnecting. There's a bug in the closed source code that has debugging output getting logged even if debugging is disabled (it doesn't properly check the debug flag state).

 

[RMerlin]

@RMerlin
Sorry to bring back this old topic, I just want to know if you have discovered anything critical happening with these logs or have found a way to suppress them? are these important or are they negligible? should one redo their mesh pairings if their logs are being flooded with these?

No idea. All I know is that it's tied to AiMesh, and since the entire implementation is closed source, it's out of my control.

 

[Asad Ali]

@RMerlin Since RT-AX88U and RT-AC86U use the same CPU and architecture ( except the difference in cores) any specific reason why the System Log-Wireless Log page in RT-AC86U doesn't show the connected client's channel bandwidth information but RT-AX88U does.

RT-AX88U:

RT-AC86U:

P.S. my RT-AC86U is in Access Point mode so can this be the cause of the difference in the log?

 

[RMerlin]

@RMerlin Since RT-AX88U and RT-AC86U use the same CPU and architecture ( except the difference in cores) any specific reason why the System Log-Wireless Log page in RT-AC86U doesn't show the connected client's channel bandwidth information but RT-AX88U does.

Different GPL and SDK.

 

[Snoopotic]

Hi,

can it be that afpd (the Time Machine-feature) is not working properly in this Release?
I have an ac-88u :

Dec 27 11:50:08 tackaman rc_service: httpds 370:notify_rc restart_timemachine
Dec 27 11:50:08 tackaman custom_script: Running /jffs/scripts/service-event (args: restart timemachine)
Dec 27 11:50:08 tackaman avahi-daemon[30494]: Got SIGTERM, quitting.
Dec 27 11:50:08 tackaman avahi-daemon[30494]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Dec 27 11:50:08 tackaman avahi-daemon[30494]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Dec 27 11:50:08 tackaman Timemachine: daemon is stopped
Dec 27 11:50:08 tackaman Timemachine: User select disk start TimeMachine
Dec 27 11:50:08 tackaman avahi-daemon[30494]: avahi-daemon 0.7 exiting.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Found user 'nobody' (UID 65534) and group 'nobody' (GID 65534).
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Successfully dropped root privileges.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: avahi-daemon 0.7 starting up.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Dec 27 11:50:08 tackaman avahi-daemon[30701]: No service file found in /tmp/avahi/services.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Loading new alias name RT-AC88U.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: New relevant interface br0.IPv4 for mDNS.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: New relevant interface lo.IPv4 for mDNS.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Network interface enumeration completed.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Registering new address record for 192.168.1.1 on br0.IPv4.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Registering new address record for 127.0.1.1 on lo.IPv4.
Dec 27 11:50:08 tackaman avahi-daemon[30701]: Registering new address record for 127.0.0.1 on lo.IPv4.
Dec 27 11:50:09 tackaman afpd[30704]: Couldn't open extension maping file /usr/etc/extmap.conf
Dec 27 11:50:09 tackaman afpd[30704]: Couldn't load extension -> type/creator mappings file "/usr/etc/extmap.conf"
Dec 27 11:50:09 tackaman avahi-daemon[30701]: Got SIGTERM, quitting.
Dec 27 11:50:09 tackaman avahi-daemon[30701]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Dec 27 11:50:09 tackaman avahi-daemon[30701]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Dec 27 11:50:09 tackaman cnid_metad[30707]: Couldn't open extension maping file /usr/etc/extmap.conf
Dec 27 11:50:09 tackaman cnid_metad[30707]: Couldn't load extension -> type/creator mappings file "/usr/etc/extmap.conf"
Dec 27 11:50:09 tackaman afpd[30704]: Netatalk AFP/TCP listening on 95.90.134.162:548
Dec 27 11:50:09 tackaman avahi-daemon[30701]: avahi-daemon 0.7 exiting.
Dec 27 11:50:09 tackaman Timemachine: daemon is started
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Found user 'nobody' (UID 65534) and group 'nobody' (GID 65534).
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Successfully dropped root privileges.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: avahi-daemon 0.7 starting up.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Loading service file /tmp/avahi/services/adisk.service.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Loading service file /tmp/avahi/services/afpd.service.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Loading new alias name RT-AC88U.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: New relevant interface br0.IPv4 for mDNS.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: New relevant interface lo.IPv4 for mDNS.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Network interface enumeration completed.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Registering new address record for 192.168.1.1 on br0.IPv4.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Registering new address record for 127.0.1.1 on lo.IPv4.
Dec 27 11:50:09 tackaman avahi-daemon[30710]: Registering new address record for 127.0.0.1 on lo.IPv4.
Dec 27 11:50:09 tackaman cnid_metad[30707]: CNID Server listening on localhost:4700
Dec 27 11:50:10 tackaman avahi-daemon[30710]: Server startup complete. Host name is tackaman.local. Local service cookie is 1346216306.
Dec 27 11:50:10 tackaman avahi-daemon[30710]: Alias name "RT-AC88U" successfully established.
Dec 27 11:50:11 tackaman avahi-daemon[30710]: Service "tackaman" (/tmp/avahi/services/afpd.service) successfully established.
Dec 27 11:50:11 tackaman avahi-daemon[30710]: Service "tackaman" (/tmp/avahi/services/adisk.service) successfully established.

especially on
"Couldn't open extension maping file /usr/etc/extmap.conf"
I wonder if this is ok or not. - but the state is I cannot connect to Time Machine.

 

[JSewell]

Hi,

can it be that afpd (the Time Machine-feature) is not working properly in this Release?

especially on
"Couldn't open extension maping file /usr/etc/extmap.conf"
I wonder if this is ok or not. - but the state is I cannot connect to Time Machine.

The "couldn't open extension making ..." is normal and can be ignored.

Try switching the Time Machine server off and back on again under the USB Application page. Make sure that you re-select the destination disk.

There was a change in how the destination disk is named that 'broke' TM here if updating from a previous version. But once you have done the above on/off & re-select the destination disk, it functions normally with 384.14

 

[Andy1932]

I realize I'm not providing much helpful information here, but I've run into an issue 3x with 384.14.
After approx. 3 days of uptime on my 86u, web pages become unresponsive(won't load at all). I can log into the router and everything looks normal -- nothing at all in the log. The only thing I notice is the cpu core status dancing all over the place, but both cores always adding up to 100% total.
After a reboot, all is good again.

 

[gfondeur]

60, as in reference to 5g channel bandwidth at 60 MHz? Is there a 60 MHz setting available for 5g wireless?[/QUOTE y

My bad, it was a typo, I mean 80Mhz and 40Mhz

 

[dev_null]

The only thing I notice is the cpu core status dancing all over the place, but both cores always adding up to 100% total.

Connect via ssh. What is the output of top (or htop) during these episodes?

 

[sentinelvdx]

On 384.13 2.4Ghz was simply perfect, but on a clean 384.14 (also noticed it in beta versions), 2.4Ghz on the AC88U has some kind of trouble with my S9+. This one gets an exclamation and stops accessing internet/intranet.. I have to turn off and on again to recover connectivity.

I've tried 384.13 again with same config (not using .cfg), just to check was not my phone, and on this version stays connected without any problem.