[Beta] Asuswrt-Merlin 384.12 Beta is now available

[nzwayne]

Beta2 (dirty) install on RT-AX88U, RT-AC87U, RT-AC86U, all ok. Still had to set the "QOS traffic priority list" up as settings still reset to a default afterwards....believe the fix identified..but not available in this code yet?

 

[Vexira]

Beta2 (dirty) install on RT-AX88U, RT-AC87U, RT-AC86U, all ok. Still had to set the "QOS traffic priority list" up as settings still reset to a default afterwards....believe the fix identified..but not available in this code yet?

How does the error looks like so does it reset to default or something, the priorities list, because my AX 88U it's fine last I checked.

But I wanted to check to see if I'm affected.

 

[RMerlin]

.believe the fix identified..but not available in this code yet?

Asus hasn't released any new firmware since identifying the issue on their end.

 

[RMerlin]

Okey found some with samba GUI. Anyone else see this?

Leftovers for the SMBv1 FAQ that was removed. I'll have to remove these too, thanks.

 

[hjohan13]

384-12 B2

Boot fail.

I have my router on autoboot every Saturday and Monday morning so it is supposed to be fresh. This morning it was dead. had to repower the unit to be able to start / boot.

 

[Butterfly Bones]

384-12 B2

Boot fail.

I have my router on autoboot every Saturday and Monday morning so it is supposed to be fresh. This morning it was dead. had to repower the unit to be able to start / boot.

You might have the extremely rare AC86U bug that bites some of us every so often. RMerlin has been unable to duplicate, I see maybe 1 in 50(?) reboots. No known solution. It has been around for quite some time.

Here is a thread trying to find why, still no answers.
https://www.snbforums.com/threads/ac86u-sometimes-powers-completely-off-during-reboot.48296/

 

[Dabombber]

There's been a number of changes in how some services are started at boot time, mainly relative to NTP, and services that require a properly updated clock (DDNS and OpenVPN, due to their TLS needs). Please make sure that these services still start correctly The changes should reduce the number of times these services get restarted at boot, in addition to preventing lengthy stalls during the initial WAN connection (particularly for PPPoE users)..

ddns-start is still getting called a few times, before they would be 30 sec apart, now they all happen at once. And I think openvpn got started by the cron check (#CheckVPNServer1#) before being "started".

Spoiler: syslog.log

May  5 17:05:39 rc_service: waitting "start_ntpd" via ip-up ...
May  5 17:05:39 ntpd: Started ntpd
May  5 17:05:40 rc_service: ip-up 628:notify_rc start_upnp
May  5 17:05:40 rc_service: waitting "stop_upnp" via ip-up ...
Jun 17 16:25:55 ntpd: Initial clock set
Jun 17 16:25:55 rc_service: ntpd_synced 886:notify_rc restart_diskmon
Jun 17 16:25:55 disk_monitor: Finish
Jun 17 16:25:55 start_ddns: update CUSTOM , wan_unit 0
Jun 17 16:25:55 custom_script: Running /jffs/scripts/ddns-start (args: X.X.X.X)
Jun 17 16:25:55 disk_monitor: be idle
Jun 17 16:25:55 watchdog: start ddns.
Jun 17 16:25:55 rc_service: watchdog 427:notify_rc start_ddns
Jun 17 16:25:55 start_ddns: update CUSTOM , wan_unit 0
Jun 17 16:25:55 custom_script: Running /jffs/scripts/ddns-start (args: X.X.X.X)
Jun 17 16:25:56 ddns-start[919]: ddns update already in progress
Jun 17 16:25:56 custom_script: Running /jffs/scripts/upnp.postconf (args: /etc/upnp/config)
Jun 17 16:25:56 start_ddns: update CUSTOM , wan_unit 0
Jun 17 16:25:56 custom_script: Running /jffs/scripts/ddns-start (args: X.X.X.X)
Jun 17 16:25:56 ddns-start[936]: ddns update already in progress
Jun 17 16:25:56 miniupnpd[942]: HTTP listening on port 54394
Jun 17 16:25:56 miniupnpd[942]: Listening for NAT-PMP/PCP traffic on port 5351
Jun 17 16:25:58 ddns-start[890]: IPv4 ddns successfully updated (X.X.X.X)
Jun 17 16:25:58 ddns: Completed custom ddns update
Jun 17 16:25:59 rc_service: hotplug 820:notify_rc restart_nasapps
Jun 17 16:25:59 iTunes: daemon is stopped
Jun 17 16:25:59 FTP_Server: daemon is stopped
Jun 17 16:25:59 wsdd2[507]: Terminated received.
Jun 17 16:25:59 Samba_Server: smb daemon is stopped
Jun 17 16:25:59 kernel: gro disabled
Jun 17 16:26:00 Timemachine: daemon is stopped
Jun 17 16:26:00 miniupnpd[942]: shutting down MiniUPnPd
Jun 17 16:26:00 kernel: gro enabled with interval 2
Jun 17 16:26:00 avahi-daemon[1051]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jun 17 16:26:00 custom_script: Running /jffs/scripts/smb.postconf (args: /etc/smb.conf)
Jun 17 16:26:00 Samba_Server: daemon is started
Jun 17 16:26:00 custom_script: Running /jffs/scripts/minidlna.postconf (args: /etc/minidlna.conf)
Jun 17 16:26:01 custom_script: Running /jffs/scripts/upnp.postconf (args: /etc/upnp/config)
Jun 17 16:26:01 miniupnpd[1119]: HTTP listening on port 43502
Jun 17 16:26:01 miniupnpd[1119]: Listening for NAT-PMP/PCP traffic on port 5351
Jun 17 16:26:01 avahi-daemon[1051]: Alias name "RT-AC88U" successfully established.
Jun 17 16:26:09 dhcp6_client: bound prefix X:X:X:X::/56
Jun 17 16:26:10 wsdd2[1098]: wsdd-http-v6: open_ep: bind: Address already in use
Jun 17 16:26:10 wsdd2[1098]: llmnr-tcp-v6: open_ep: bind: Address already in use
Jun 17 16:26:11 kernel: SHN Release Version: 2.0.1 d32a874
Jun 17 16:26:11 kernel: UDB Core Version: 0.2.18 r3508378
Jun 17 16:26:11 kernel: sizeof forward pkt param = 192
Jun 17 16:26:11 BWDPI: fun bitmap = 83
Jun 17 16:26:14 A.QoS: qos_count=0, qos_check=0
Jun 17 16:26:14 kernel: ERR[qos_start:3364] qos_ops is not registered!
Jun 17 16:26:14 kernel: ioctl_iqos_op_switch(1) fail!
Jun 17 16:26:14 A.QoS: set_qos_on fails
Jun 17 16:26:14 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Jun 17 16:26:15 A.QoS: qos_count=0, qos_check=1
Jun 17 16:26:15 crond[414]: time disparity of 587481 minutes detected
Jun 17 16:26:18 rc_service: ip-up 628:notify_rc start_firewall
Jun 17 16:26:18 rc_service: ip-up 628:notify_rc start_vpnserver1
Jun 17 16:26:18 rc_service: waitting "start_firewall" via ip-up ...
Jun 17 16:26:18 miniupnpd[1119]: shutting down MiniUPnPd
Jun 17 16:26:18 nat: apply nat rules (/tmp/nat_rules_ppp0_eth0)
Jun 17 16:26:18 custom_script: Running /jffs/scripts/nat-start
Jun 17 16:26:18 custom_script: Running /jffs/scripts/upnp.postconf (args: /etc/upnp/config)
Jun 17 16:26:18 miniupnpd[2101]: HTTP listening on port 33101
Jun 17 16:26:18 miniupnpd[2101]: Listening for NAT-PMP/PCP traffic on port 5351
Jun 17 16:26:20 custom_script: Running /jffs/scripts/openvpnserver1.postconf (args: /etc/openvpn/server1/config.ovpn)
Jun 17 16:26:20 ovpn-server1[2306]: OpenVPN 2.4.7 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 16 2019
Jun 17 16:26:20 ovpn-server1[2306]: library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.08
Jun 17 16:26:20 ovpn-server1[2307]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jun 17 16:26:20 ovpn-server1[2307]: Diffie-Hellman initialized with 2048 bit key
Jun 17 16:26:20 ovpn-server1[2307]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun 17 16:26:20 ovpn-server1[2307]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun 17 16:26:20 ovpn-server1[2307]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun 17 16:26:20 ovpn-server1[2307]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun 17 16:26:20 ovpn-server1[2307]: TUN/TAP device tun21 opened
Jun 17 16:26:20 ovpn-server1[2307]: TUN/TAP TX queue length set to 1000
Jun 17 16:26:20 ovpn-server1[2307]: /usr/sbin/ip link set dev tun21 up mtu 1500
Jun 17 16:26:20 ovpn-server1[2307]: /usr/sbin/ip addr add dev tun21 192.168.10.1/24 broadcast 192.168.10.255
Jun 17 16:26:20 ovpn-server1[2307]: updown.sh tun21 1500 1622 192.168.10.1 255.255.255.0 init
Jun 17 16:26:20 ovpn-server1[2307]: Could not determine IPv4/IPv6 protocol. Using AF_INET6
Jun 17 16:26:20 ovpn-server1[2307]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Jun 17 16:26:20 ovpn-server1[2307]: setsockopt(IPV6_V6ONLY=0)
Jun 17 16:26:20 ovpn-server1[2307]: UDPv6 link local (bound): [AF_INET6][undef]:1674
Jun 17 16:26:20 ovpn-server1[2307]: UDPv6 link remote: [AF_UNSPEC]
Jun 17 16:26:20 ovpn-server1[2307]: MULTI: multi_init called, r=256 v=256
Jun 17 16:26:20 ovpn-server1[2307]: IFCONFIG POOL: base=192.168.10.2 size=252, ipv6=0
Jun 17 16:26:20 ovpn-server1[2307]: Initialization Sequence Completed
Jun 17 16:26:54 ddns-start[890]: IPv6 failed to update
Jun 17 16:26:54 rc_service: ntpd_synced 886:notify_rc stop_vpnserver1
Jun 17 16:26:54 rc_service: ntpd_synced 886:notify_rc start_vpnserver1
Jun 17 16:26:54 rc_service: waitting "stop_vpnserver1" via ntpd_synced ...
Jun 17 16:26:54 ovpn-server1[2307]: event_wait : Interrupted system call (code=4)
Jun 17 16:26:54 ovpn-server1[2307]: Closing TUN/TAP interface
Jun 17 16:26:54 ovpn-server1[2307]: /usr/sbin/ip addr del dev tun21 192.168.10.1/24
Jun 17 16:26:54 wsdd2[1098]: wsdd-http-v6: open_ep: bind: Address already in use
Jun 17 16:26:54 ovpn-server1[2307]: updown.sh tun21 1500 1622 192.168.10.1 255.255.255.0 init
Jun 17 16:26:54 ovpn-server1[2307]: SIGTERM[hard,] received, process exiting
Jun 17 16:26:54 wsdd2[1098]: llmnr-tcp-v6: open_ep: bind: Address already in use
Jun 17 16:26:54 kernel: EMF_ERROR: Interface tap21 doesn't exist
Jun 17 16:26:54 kernel: EMF_ERROR: Interface tun21 doesn't exist
Jun 17 16:26:55 custom_script: Running /jffs/scripts/openvpnserver1.postconf (args: /etc/openvpn/server1/config.ovpn)
Jun 17 16:26:55 ovpn-server1[2870]: OpenVPN 2.4.7 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 16 2019
Jun 17 16:26:55 ovpn-server1[2870]: library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.08
Jun 17 16:26:55 ovpn-server1[2875]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jun 17 16:26:55 ovpn-server1[2875]: Diffie-Hellman initialized with 2048 bit key
Jun 17 16:26:55 ovpn-server1[2875]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun 17 16:26:55 ovpn-server1[2875]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun 17 16:26:55 ovpn-server1[2875]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun 17 16:26:55 ovpn-server1[2875]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun 17 16:26:55 ovpn-server1[2875]: TUN/TAP device tun21 opened
Jun 17 16:26:55 ovpn-server1[2875]: TUN/TAP TX queue length set to 1000
Jun 17 16:26:55 ovpn-server1[2875]: /usr/sbin/ip link set dev tun21 up mtu 1500
Jun 17 16:26:55 ovpn-server1[2875]: /usr/sbin/ip addr add dev tun21 192.168.10.1/24 broadcast 192.168.10.255
Jun 17 16:26:55 ovpn-server1[2875]: updown.sh tun21 1500 1622 192.168.10.1 255.255.255.0 init
Jun 17 16:26:55 ovpn-server1[2875]: Could not determine IPv4/IPv6 protocol. Using AF_INET6
Jun 17 16:26:55 ovpn-server1[2875]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Jun 17 16:26:55 ovpn-server1[2875]: setsockopt(IPV6_V6ONLY=0)
Jun 17 16:26:55 ovpn-server1[2875]: UDPv6 link local (bound): [AF_INET6][undef]:1674
Jun 17 16:26:55 ovpn-server1[2875]: UDPv6 link remote: [AF_UNSPEC]
Jun 17 16:26:55 ovpn-server1[2875]: MULTI: multi_init called, r=256 v=256
Jun 17 16:26:55 ovpn-server1[2875]: IFCONFIG POOL: base=192.168.10.2 size=252, ipv6=0
Jun 17 16:26:55 ovpn-server1[2875]: Initialization Sequence Completed

 

[maxbraketorque]

Looked at the boot log after beta2 update on my AC86U. Some startup actions are getting intermixing with the two router OVPN clients making contact with host OVPN servers on other routers. Here is what I see:

.
.
.
May 4 22:05:18 kernel: ubi1: detaching mtd9
May 4 22:05:18 kernel: ubi1: mtd9 is detached
May 4 22:05:19 kernel: SCSI subsystem initialized
.
OVPN stuff...
.
Jun 16 21:46:20 kernel: SHN Release Version: 2.0.1 890c91d
Jun 16 21:46:20 kernel: UDB Core Version: 0.2.18
Jun 16 21:46:21 kernel: sizeof forward pkt param = 280
.
OVPN stuff...
.
Jun 16 21:46:30 kernel: ubi1: attaching mtd9
.
OVPN stuff...
.
Jun 16 21:46:30 kernel: ubi1: scanning is finished
Jun 16 21:46:30 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Jun 16 21:46:30 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Jun 16 21:46:30 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Jun 16 21:46:30 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Jun 16 21:46:30 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Jun 16 21:46:30 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Jun 16 21:46:30 kernel: ubi1: max/mean erase counter: 3/2, WL threshold: 4096, image sequence number: 1960956644
Jun 16 21:46:30 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Jun 16 21:46:30 kernel: ubi1: background thread "ubi_bgt1d" started, PID 2268
.
OVPN stuff...
.
Jun 16 21:46:31 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram", R/O mode
Jun 16 21:46:31 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jun 16 21:46:31 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Jun 16 21:46:31 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Jun 16 21:46:31 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID 700E756D-208E-4C91-B256-B51AA3EDE77F, small LPT model
Jun 16 21:46:31 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Jun 16 21:46:31 kernel: ubi1: detaching mtd9
Jun 16 21:46:31 kernel: ubi1: mtd9 is detached
.
OVPN stuff
.
Jun 16 21:46:52 crond[788]: time disparity of 587501 minutes detected

I guess this now normal and expected?

 

[hjohan13]

You might have the extremely rare AC86U bug that bites some of us every so often. RMerlin has been unable to duplicate, I see maybe 1 in 50(?) reboots. No known solution. It has been around for quite some time.

Here is a thread trying to find why, still no answers.
https://www.snbforums.com/threads/ac86u-sometimes-powers-completely-off-during-reboot.48296/

Thanks Butterfly. Seems like a pretty common fault on 86's. I feel puzzled that even ASUS don't seems to have a fix for it.

 

[Vexira]

You might have the extremely rare AC86U bug that bites some of us every so often. RMerlin has been unable to duplicate, I see maybe 1 in 50(?) reboots. No known solution. It has been around for quite some time.

Here is a thread trying to find why, still no answers.
https://www.snbforums.com/threads/ac86u-sometimes-powers-completely-off-during-reboot.48296/

That's probably because it's a hardware issue that exists in certain hardware revisions.

 

[hjohan13]

That's probably because it's a hardware issue that exists in certain hardware revisions.

That was in my thoughts also......will check the HW revision at home tonight. Lucky I have 2 86's....hopefully I can swap them if they are different.

 

[Grisu]

That's probably because it's a hardware issue that exists in certain hardware revisions.

And why is it then seen on AX88U too?
https://www.snbforums.com/threads/reboot-hangs-on-ax88u.54964/
At least 1 year younger and different hw than 86U which got this feature?
I still suppose it has something to do with the 2 firmwares inside and sometimes the wrong one or none is triggered, or related to only some regions with somehow misconfigured or bad bootloader.

 

[hjohan13]

And why is it then seen on AX88U too?
https://www.snbforums.com/threads/reboot-hangs-on-ax88u.54964/
At least 1 year younger and different hw than 86U which got this feature?
I still suppose it has something to do with the 2 firmwares inside and sometimes the wrong one or none is triggered, or related to only some regions with somehow misconfigured or bad bootloader.

A bug in the bootloader is also not a bad guess...... It it easy to copy a SW bug / fault or HW layout from one platform to another. AC86 to AX88....

 

[MDM]

And why is it then seen on AX88U too?
https://www.snbforums.com/threads/reboot-hangs-on-ax88u.54964/
At least 1 year younger and different hw than 86U which got this feature?
I still suppose it has something to do with the 2 firmwares inside and sometimes the wrong one or none is triggered, or related to only some regions with somehow misconfigured or bad bootloader.

Maybe because HND models are: RT-AC86U, RT-AX88U, GT-AC5300, GT-AX11000, etc...
It's apparently an issue more common with the HND models and their FW?

 

[Vexira]

And why is it then seen on AX88U too?
https://www.snbforums.com/threads/reboot-hangs-on-ax88u.54964/
At least 1 year younger and different hw than 86U which got this feature?
I still suppose it has something to do with the 2 firmwares inside and sometimes the wrong one or none is triggered, or related to only some regions with somehow misconfigured or bad bootloader.

They're quite the same CPU wise, it's the same CPU with two extra cores in the ax 88u.

Most companies recycle the same internal design for newer units and do minor tweaking to them.

 

[hjohan13]

Looked up my routers. Both routers are HW R1.5 and have 384_20467 as default FW. Prod Year 2018. Main router bought last September. Second one bought in April this year. Different stores.

 

[Butterfly Bones]

Thanks Butterfly. Seems like a pretty common fault on 86's. I feel puzzled that even ASUS don't seems to have a fix for it.

Not common to AC86U at all. I see it maybe once in 50 (w.a.g.) reboots and I hate Hate HATE rebooting, being a long time Linux uptime geek.

Keep in mind, that vast majority of people only post here with problems. I would bet the issue is with single digits of AC86U users. Now reportes of the AX88U with the issue. It is just an extremely rare thing. Now that I know that little @#$%& lives in my AC86U, I just watch it more carefully.

 

[hjohan13]

Not common to AC86U at all. I see it maybe once in 50 (w.a.g.) reboots and I hate Hate HATE rebooting, being a long time Linux uptime geek.

Keep in mind, that vast majority of people only post here with problems. I would bet the issue is with single digits of AC86U users. Now reportes of the AX88U with the issue. It is just an extremely rare thing. Now that I know that little @#$%& lives in my AC86U, I just watch it more carefully.

Just a thought….people probable never experience it if they never roboot. After all scheduled reboot is an option. Not a standard.

I read every day on this forum how many days uptime people have......meaning they never reboot.

 

[cmkelley]

Just a thought….people probable never experience it if they never roboot. After all scheduled reboot is an option. Not a standard.

I read every day on this forum how many days uptime people have......meaning they never reboot.

Right. I never reboot my 86U except to upgrade firmware. Without an actual reason to (there are legit reasons to, just none of them apply to me), rebooting is pointless.

 

[maxbraketorque]

Just a thought….people probable never experience it if they never roboot. After all scheduled reboot is an option. Not a standard.

I read every day on this forum how many days uptime people have......meaning they never reboot.

I think the vast majority of people here never reboot unless upgrading firmware or making external device changes. IIRC, most people discussing periodic reboot seem to need it because of ISP issues.