What's new

Asus RT-AC67U Reboot

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Twist282

New Around Here
I have an RT-AC67U and every now and then it restarts.

I have done a factory reset and update to the latest firmware.

Here is what is on the log.



Code:
Jan 13 16:00:12 rc_service: httpd 622:notify_rc restart_net_and_phy
Jan 13 16:00:14 iTunes: daemon is stoped
Jan 13 16:00:14 FTP Server: daemon is stopped
Jan 13 16:00:14 Samba Server: smb daemon is stoped
Jan 13 16:00:14 kernel: gro disabled
Jan 13 16:00:15 miniupnpd[6863]: shutting down MiniUPnPd
Jan 13 16:00:17 pppd[736]: Connection terminated.
Jan 13 16:00:19 kernel: et0: et_mvlan_netdev_event: event 9 for vlan1 mvlan_en 0
Jan 13 16:00:19 kernel: et0: et_mvlan_netdev_event: event 2 for vlan1 mvlan_en 0
Jan 13 16:00:20 kernel: et0: et_mvlan_netdev_event: event 13 for vlan1 mvlan_en 0
Jan 13 16:00:20 kernel: et0: et_mvlan_netdev_event: event 1 for vlan1 mvlan_en 0
Jan 13 16:00:20 kernel: et0: et_mvlan_netdev_event: event 4 for vlan1 mvlan_en 0
Jan 13 16:00:20 kernel: et0: et_mvlan_netdev_event: event 4 for vlan1 mvlan_en 0
Jan 13 16:00:21 avahi-daemon[10650]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 13 16:00:21 pppd[10651]: pppd 2.4.7 started by admin, uid 0
Jan 13 16:00:21 pppd[10651]: Connected to 20:e0:9c:df:05:67 via interface eth0
Jan 13 16:00:21 pppd[10651]: Connect: ppp0 <--> eth0
Jan 13 16:00:21 pppd[10651]: CHAP authentication succeeded
Jan 13 16:00:21 pppd[10651]: peer from calling number 00:A0:0A:AA:00:00 authorized
Jan 13 16:00:21 syslog: main(961): wlceventd Start...
Jan 13 16:00:21 pppd[10651]: local  IP address xxx.xxx.xxx.xxx
Jan 13 16:00:21 pppd[10651]: remote IP address xxx.xxx.xxx.xxx
Jan 13 16:00:21 pppd[10651]: primary   DNS address xxx.xxx.xxx.xxx
Jan 13 16:00:21 pppd[10651]: secondary DNS address xxx.xxx.xxx.xxx
Jan 13 16:00:21 avahi-daemon[10650]: Alias name "RT-AC67U" successfully established.
Jan 13 16:00:22 watchdog: restart httpd
Jan 13 16:00:22 rc_service: watchdog 627:notify_rc stop_httpd
Jan 13 16:00:22 rc_service: waitting "restart_net_and_phy" via  ...
Jan 13 16:00:22 wan: finish adding multi routes
Jan 13 16:00:22 syslog: it is advised to use network interface name instead of 192.168.0.1/255.255.252.0
Jan 13 16:00:22 miniupnpd[10729]: HTTP listening on port 56657
Jan 13 16:00:22 miniupnpd[10729]: Listening for NAT-PMP/PCP traffic on port 5351
Jan 13 16:00:24 acsd: selected channel spec: 0x1008 (8)
Jan 13 16:00:24 acsd: Adjusted channel spec: 0x1008 (8)
Jan 13 16:00:24 acsd: selected DFS-exit channel spec: 0x1008 (8)
Jan 13 16:00:24 acsd: selected channel spec: 0x1008 (8)
Jan 13 16:00:24 acsd: Adjusted channel spec: 0x1008 (8)
Jan 13 16:00:24 acsd: selected channel spec: 0x1008 (8)
Jan 13 16:00:24 acsd: acs_set_chspec: 0x1008 (8) for reason APCS_INIT
Jan 13 16:00:28 acsd: selected channel spec: 0xe06a (100/80)
Jan 13 16:00:28 acsd: Adjusted channel spec: 0xe06a (100/80)
Jan 13 16:00:28 acsd: selected DFS-exit channel spec: 0xe06a (100/80)
Jan 13 16:00:28 acsd: selected channel spec: 0xe06a (100/80)
Jan 13 16:00:28 acsd: Adjusted channel spec: 0xe06a (100/80)
Jan 13 16:00:28 acsd: selected channel spec: 0xe06a (100/80)
Jan 13 16:00:28 acsd: acs_set_chspec: 0xe06a (100/80) for reason APCS_INIT
Jan 13 16:00:28 RT-AC67U: start httpd:80
Jan 13 16:00:29 syslog: it is advised to use network interface name instead of 192.168.0.1/255.255.252.0
Jan 13 16:00:29 miniupnpd[10769]: MiniUPnPd is already running. EXITING
Jan 13 16:00:29 httpd: Save SSL certificate...80
Jan 13 16:00:29 httpd: mssl_cert_key_match : PASS
Jan 13 16:00:29 httpd: Succeed to init SSL certificate...80
Jan 13 16:00:32 rc_service: watchdog 627:notify_rc start_httpd
Jan 13 16:00:32 RT-AC67U: start httpd:80
Jan 13 16:00:35 httpd: Save SSL certificate...80
Jan 13 16:00:35 httpd: mssl_cert_key_match : PASS
Jan 13 16:00:35 httpd: Succeed to init SSL certificate...80
Jan 13 16:00:36 zcip client: configured 169.254.99.38
Jan 13 16:00:41 WAN Connection: WAN was restored.
Jan 13 16:15:29 acsd: selected channel spec: 0x100b (11)
Jan 13 16:15:29 acsd: Adjusted channel spec: 0x100b (11)
Jan 13 16:15:29 acsd: selected channel spec: 0x100b (11)
Jan 13 16:15:29 acsd: acs_set_chspec: 0x100b (11) for reason APCS_CSTIMER
Jan 13 16:30:33 acsd: selected channel spec: 0x1008 (8)
Jan 13 16:30:33 acsd: Adjusted channel spec: 0x1008 (8)
Jan 13 16:30:33 acsd: selected channel spec: 0x1008 (8)
Jan 13 16:30:33 acsd: acs_set_chspec: 0x1008 (8) for reason APCS_CSTIMER
Jan 13 16:45:37 acsd: selected channel spec: 0x1008 (8)
Jan 13 16:45:37 acsd: Adjusted channel spec: 0x1008 (8)
Jan 13 16:45:37 acsd: selected channel spec: 0x1008 (8)
Jan 13 16:45:37 acsd: acs_set_chspec: 0x1008 (8) for reason APCS_CSTIMER
Jan 13 17:00:41 acsd: selected channel spec: 0x1008 (8)
Jan 13 17:00:41 acsd: Adjusted channel spec: 0x1008 (8)
Jan 13 17:00:41 acsd: selected channel spec: 0x1008 (8)
Jan 13 17:00:41 acsd: acs_set_chspec: 0x1008 (8) for reason APCS_CSTIMER
Jan 13 17:15:45 acsd: selected channel spec: 0x100a (10)
Jan 13 17:15:45 acsd: Adjusted channel spec: 0x100a (10)
Jan 13 17:15:45 acsd: selected channel spec: 0x100a (10)
Jan 13 17:15:45 acsd: acs_set_chspec: 0x100a (10) for reason APCS_CSTIMER
Jan 13 17:30:48 acsd: selected channel spec: 0x100b (11)
Jan 13 17:30:48 acsd: Adjusted channel spec: 0x100b (11)
Jan 13 17:30:48 acsd: selected channel spec: 0x100b (11)
Jan 13 17:30:48 acsd: acs_set_chspec: 0x100b (11) for reason APCS_CSTIMER
 
We'd need to see the complete syslog to understand the problem. The part of the log you posted just shows the WAN connection restarting, but there's no context to draw any conclusion from it.
 
We'd need to see the complete syslog to understand the problem. The part of the log you posted just shows the WAN connection restarting, but there's no context to draw any conclusion from it.

The link below shows everything in the log... Not sure if that is what you mean as the rest is from last year...

 
Thanks. The May 5th entries are just the default date and time the router has when it first boots up, before it can get the correct date/time from the internet.

The log shows the router starting up at about 11:24 today. Then at 14:45 the router is rebooted from the web interface. At 15:31 the router briefly looses its connection to the modem. At 16:00 there appears to have been another brief network interruption.

Have you been restarting the modem connected to this router.
 
It restarts about 3 to 4 times an hour.
Apart from the times I mentioned above there's nothing in the log to suggest it is restarting. For example, after the event at 16:00 there is nothing of any consequence until the log ends at 18:16. How are you determining that it's restarting?
 
I am unable to ping when I lose connection and am unable to access the admin panel of the router. This happens to all devices.
 
The next time it happens make a note of the exact time. Then don't reboot anything and just wait until you can log back into the router. When you can get in save the system log and post it here for us to look at and say the time the problem occurred.

BTW Change your LAN subnet mask back to 255.255.255.0. The router's network map is known to be incompatible with anything larger than this.
 
I have done a factory reset and update to the latest firmware.
wrong, you should first update to latest fw, then make factory default with initialization
 
So it was 0851GMT it went down for approx 20 seconds. I don't think it reboots because the uptime timer did not change.
However, the log did not publish anything at that time

Code:
Jan 14 05:55:05 miniupnpd[20326]: shutting down MiniUPnPd
Jan 14 05:55:06 syslog: it is advised to use network interface name instead of 192.168.0.1/255.255.255.0
Jan 14 05:55:06 miniupnpd[21309]: HTTP listening on port 58577
Jan 14 05:55:06 miniupnpd[21309]: Listening for NAT-PMP/PCP traffic on port 5351
Jan 14 05:55:06 WAN Connection: WAN was restored.
Jan 14 06:04:10 acsd: selected channel spec: 0x100b (11)
Jan 14 06:04:10 acsd: Adjusted channel spec: 0x100b (11)
Jan 14 06:04:10 acsd: selected channel spec: 0x100b (11)
Jan 14 06:04:10 acsd: acs_set_chspec: 0x100b (11) for reason APCS_CSTIMER
Jan 14 06:19:14 acsd: selected channel spec: 0x1007 (7)
Jan 14 06:19:14 acsd: Adjusted channel spec: 0x1007 (7)
Jan 14 06:19:14 acsd: selected channel spec: 0x1007 (7)
Jan 14 06:19:14 acsd: acs_set_chspec: 0x1007 (7) for reason APCS_CSTIMER
Jan 14 06:34:18 acsd: selected channel spec: 0x100b (11)
Jan 14 06:34:18 acsd: Adjusted channel spec: 0x100b (11)
Jan 14 06:34:18 acsd: selected channel spec: 0x100b (11)
Jan 14 06:34:18 acsd: acs_set_chspec: 0x100b (11) for reason APCS_CSTIMER
Jan 14 06:49:22 acsd: selected channel spec: 0x1002 (2)
Jan 14 06:49:22 acsd: Adjusted channel spec: 0x1002 (2)
Jan 14 06:49:22 acsd: selected channel spec: 0x1002 (2)
Jan 14 06:49:22 acsd: acs_set_chspec: 0x1002 (2) for reason APCS_CSTIMER
Jan 14 07:04:25 acsd: selected channel spec: 0x1005 (5)
Jan 14 07:04:25 acsd: Adjusted channel spec: 0x1005 (5)
Jan 14 07:04:25 acsd: selected channel spec: 0x1005 (5)
Jan 14 07:04:25 acsd: acs_set_chspec: 0x1005 (5) for reason APCS_CSTIMER
Jan 14 07:19:29 acsd: selected channel spec: 0x1007 (7)
Jan 14 07:19:29 acsd: Adjusted channel spec: 0x1007 (7)
Jan 14 07:19:29 acsd: selected channel spec: 0x1007 (7)
Jan 14 07:19:29 acsd: acs_set_chspec: 0x1007 (7) for reason APCS_CSTIMER
Jan 14 07:34:33 acsd: selected channel spec: 0x1009 (9)
Jan 14 07:34:33 acsd: Adjusted channel spec: 0x1009 (9)
Jan 14 07:34:33 acsd: selected channel spec: 0x1009 (9)
Jan 14 07:34:33 acsd: acs_set_chspec: 0x1009 (9) for reason APCS_CSTIMER
Jan 14 07:49:37 acsd: selected channel spec: 0x1008 (8)
Jan 14 07:49:37 acsd: Adjusted channel spec: 0x1008 (8)
Jan 14 07:49:37 acsd: selected channel spec: 0x1008 (8)
Jan 14 07:49:37 acsd: acs_set_chspec: 0x1008 (8) for reason APCS_CSTIMER
Jan 14 08:04:41 acsd: selected channel spec: 0x100b (11)
Jan 14 08:04:41 acsd: Adjusted channel spec: 0x100b (11)
Jan 14 08:04:41 acsd: selected channel spec: 0x100b (11)
Jan 14 08:04:41 acsd: acs_set_chspec: 0x100b (11) for reason APCS_CSTIMER
Jan 14 08:19:45 acsd: selected channel spec: 0x1009 (9)
Jan 14 08:19:45 acsd: Adjusted channel spec: 0x1009 (9)
Jan 14 08:19:45 acsd: selected channel spec: 0x1009 (9)
Jan 14 08:19:45 acsd: acs_set_chspec: 0x1009 (9) for reason APCS_CSTIMER
Jan 14 08:34:50 acsd: selected channel spec: 0x1003 (3)
Jan 14 08:34:50 acsd: Adjusted channel spec: 0x1003 (3)
Jan 14 08:34:50 acsd: selected channel spec: 0x1003 (3)
Jan 14 08:34:50 acsd: acs_set_chspec: 0x1003 (3) for reason APCS_CSTIMER
Jan 14 08:49:54 acsd: selected channel spec: 0x1007 (7)
Jan 14 08:49:54 acsd: Adjusted channel spec: 0x1007 (7)
Jan 14 08:49:54 acsd: selected channel spec: 0x1007 (7)
Jan 14 08:49:54 acsd: acs_set_chspec: 0x1007 (7) for reason APCS_CSTIMER
 
Just happened again this time for 2 minutes from 0859 still nothing changed in the log
So it looks like it isn't a problem with the router but something upstream of it. I suspect it's your modem, or possibly and ISP issue. Log into your modem and examine its logs.

P.S. It's probably a good idea to change your 2.4GHz WiFi channel from Auto to a fixed channel (e.g. 11) and 20MHz bandwidth. That will stop it changing channels every 15 minutes and forcing clients to reconnect.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top