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.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?
.believe the fix identified..but not available in this code yet?
Okey found some with samba GUI. Anyone else see this?
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.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.
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)..
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
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.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.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 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.That's probably because it's a hardware issue that exists in certain hardware revisions.
And why is it then seen on AX88U too?That's probably because it's a hardware issue that exists in certain hardware revisions.
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....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...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.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.
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.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.
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.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.
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.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!