ASUS RT-AC68U Firmware version 3.0.0.4.374.5047

[RMerlin]

Thankfully we can put the rebooting issues to rest. But with this 5047 firmware I get these strange entries in log

pr  7 04:47:56 miniupnpd[3812]: HTTP listening on port 53092
Apr  7 04:47:56 miniupnpd[3812]: Listening for NAT-PMP traffic on port 5351
Apr  7 08:58:54 miniupnpd[3812]: sendto(udp): Operation not permitted
Apr  7 09:04:02 miniupnpd[3812]: Expired NAT-PMP mapping port 8080 TCP removed
Apr  7 09:04:02 miniupnpd[3812]: Expired NAT-PMP mapping port 8082 TCP removed
Apr  7 09:04:03 miniupnpd[3812]: Expired NAT-PMP mapping port 8083 TCP removed
Apr  7 09:04:03 miniupnpd[3812]: Expired NAT-PMP mapping port 8081 TCP removed
Apr  7 10:20:01 miniupnpd[3812]: sendto(udp): Operation not permitted
Apr  7 10:40:16 miniupnpd[3812]: sendto(udp): Operation not permitted
Apr  7 10:55:26 miniupnpd[3812]: sendto(udp): Operation not permitted
Apr  7 11:20:41 miniupnpd[3812]: sendto(udp): Operation not permitted

Previous beta firmware had no such entries. Wonder what they mean?

UPnP port forwards will expire after a certain period of inactivity. This is what your router just did - removed forwards that were no longer used.

 

[JerryZ72]

ASUS firmware 5047 still rebooting for me

I recently did a full factory reset when installing Asus beta firmware 4887, and my reboot problem did not go away. I installed 5047 when it was released, and I'm sorry to say that I am still seeing the reboot issue - several times per day. I tried the fix that someone else mentioned, setting the wireless preamble to short, and that had no effect... While this is a hassle, it's not the end of the world for me, but I would like this router to just work. Is anyone else still experiencing the reboot issue on 5047 ? If not, any thoughts on what I should be doing differently ?

 

[Kris404]

I recently did a full factory reset when installing Asus beta firmware 4887, and my reboot problem did not go away. I installed 5047 when it was released, and I'm sorry to say that I am still seeing the reboot issue - several times per day. I tried the fix that someone else mentioned, setting the wireless preamble to short, and that had no effect... While this is a hassle, it's not the end of the world for me, but I would like this router to just work. Is anyone else still experiencing the reboot issue on 5047 ? If not, any thoughts on what I should be doing differently ?

Try Merlin's 41 alpha 4.

If that still doesn't help, might be faulty unit, RMA for replacement.

 

[rtcomputersinc]

I recently did a full factory reset when installing Asus beta firmware 4887, and my reboot problem did not go away. I installed 5047 when it was released, and I'm sorry to say that I am still seeing the reboot issue - several times per day. I tried the fix that someone else mentioned, setting the wireless preamble to short, and that had no effect... While this is a hassle, it's not the end of the world for me, but I would like this router to just work. Is anyone else still experiencing the reboot issue on 5047 ? If not, any thoughts on what I should be doing differently ?

With the reboots the uptime in the log goes back to zero that's where you are verifying the reboot?

Factory reset did you restore a backup or do a clean setup? clean setup is better.

The 4887 firmware had seemed to fix the issue for everyone. Maybe do a factory reset again?

 

[RMerlin]

I agree. So far the reboot issue has been resolved for everyone else, so I suspect your issue is a different one (if it is really a reboot - the uptime shown on the web interface would confirm it).

 

[JerryZ72]

Merlin,

The uptime did, in fact, reset when I experienced the outage. I did, however, notice something interesting in the log: a reference to UPnP having some osrt of failure, and a request to restart at exactly the time that the router rebooted. I disabled UPnP, and so far I'm up for several hours without incident. For those who asked about my reset - I did not restore from a backup, I started from scratch and recreated all of my settings.

I've copied my log since 9am this morning (the first restart) - maybe someone will see something that I didn't:

Apr 7 09:08:45 rc_service: ntp 703:notify_rc restart_upnp
Apr 7 09:08:45 rc_service: ntp 703:notify_rc restart_radvd
Apr 7 09:08:45 rc_service: waitting "restart_upnp" via ntp ...
Apr 7 09:08:45 miniupnpd[699]: received signal 15, good-bye
Apr 7 09:08:45 dhcp client: bound 50.191.104.61 via 50.191.104.1 during 345600 seconds.
Apr 7 09:08:46 syslog: SNet version started
Apr 7 09:08:46 miniupnpd[716]: HTTP listening on port 53677
Apr 7 09:08:46 miniupnpd[716]: Listening for NAT-PMP traffic on port 5351
Apr 7 09:08:46 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.36 1c:99:4c:26:80:b5
Apr 7 09:08:46 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.36 1c:99:4c:26:80:b5 android-1c93571a89b39f7b
Apr 7 09:08:46 rc_service: ntp 703:notify_rc restart_diskmon
Apr 7 09:08:46 rc_service: waitting "restart_radvd" via ntp ...
Apr 7 09:08:46 radvd[663]: Exiting, sigterm or sigint received.
Apr 7 09:08:46 radvd[663]: sending stop adverts
Apr 7 09:08:46 radvd[663]: removing /var/run/radvd.pid
Apr 7 09:08:46 radvd[661]: Exiting, privsep_read_loop had readn return 0 bytes
Apr 7 09:08:47 radvd[720]: version 1.10.0 started
Apr 7 09:08:48 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.56 b8:ff:61:00:cc:ea
Apr 7 09:08:48 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.56 b8:ff:61:00:cc:ea Tinas-iPad
Apr 7 09:08:48 disk monitor: be idle
Apr 7 09:08:54 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.54 7c:c5:37:70:fd:d5
Apr 7 09:08:54 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.54 7c:c5:37:70:fd:d5 Tinas-iPhone
Apr 7 09:08:55 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.21 64:20:0c:3a:21:4a
Apr 7 09:08:55 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.21 64:20:0c:3a:21:4a Tinas-New-iPad
Apr 7 09:09:00 kernel: br0: received packet on eth2 with own address as source address
Apr 7 09:09:05 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.57 0c:8b:fd:08:05:5c
Apr 7 09:09:05 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.57 0c:8b:fd:08:05:5c JerryZ-Laptop
Apr 7 09:09:05 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.48 d8:50:e6:f4:ba:84
Apr 7 09:09:05 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.48 d8:50:e6:f4:ba:84 Tina-PC
Apr 7 09:09:13 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 09:09:13 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 09:15:03 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.91 b8:e8:56:e6:65:f2
Apr 7 09:15:03 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.91 b8:e8:56:e6:65:f2 iPhone-5s
Apr 7 09:28:04 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 09:28:04 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 09:46:56 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 09:46:56 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 10:05:47 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 10:05:47 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 10:24:38 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 10:24:38 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 10:43:29 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 10:43:29 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 11:02:20 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 11:02:20 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 11:21:11 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 11:21:11 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 11:40:03 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 11:40:03 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 11:58:40 rc_service: httpd 523:notify_rc restart_wan_if 0
Apr 7 11:58:40 radvd[728]: Exiting, sigterm or sigint received.
Apr 7 11:58:40 radvd[728]: sending stop adverts
Apr 7 11:58:40 radvd[728]: removing /var/run/radvd.pid
Apr 7 11:58:41 rc_service: dhcp6c-state 859:notify_rc start_radvd
Apr 7 11:58:41 rc_service: waitting "restart_wan_if 0" via httpd ...
Apr 7 11:58:42 dnsmasq[517]: read /etc/hosts - 6 addresses
Apr 7 11:58:42 dnsmasq-dhcp[517]: read /etc/ethers - 2 addresses
Apr 7 11:58:42 dnsmasq[517]: using nameserver 8.8.8.8#53
Apr 7 11:58:42 dnsmasq[517]: using nameserver 68.87.64.146#53
Apr 7 11:58:42 stop_wan(): perform DHCP release
Apr 7 11:58:42 kernel: Attempt to kill tasklet from interrupt
Apr 7 11:58:42 kernel: device eth0 left promiscuous mode
Apr 7 11:58:42 kernel: br0: port 1(vlan1) entering forwarding state
Apr 7 11:58:42 dnsmasq[517]: read /etc/hosts - 6 addresses
Apr 7 11:58:42 dnsmasq-dhcp[517]: read /etc/ethers - 2 addresses
Apr 7 11:58:42 dnsmasq[517]: using nameserver 8.8.8.8#53
Apr 7 11:58:42 dnsmasq[517]: using nameserver 68.87.64.146#53
Apr 7 11:58:42 kernel: device eth0 entered promiscuous mode
Apr 7 11:58:42 kernel: br0: topology change detected, propagating
Apr 7 11:58:42 kernel: br0: port 1(vlan1) entering forwarding state
Apr 7 11:58:42 kernel: br0: port 1(vlan1) entering forwarding state
Apr 7 11:58:42 dnsmasq[517]: read /etc/hosts - 6 addresses
Apr 7 11:58:42 dnsmasq-dhcp[517]: read /etc/ethers - 2 addresses
Apr 7 11:58:42 dnsmasq[517]: using nameserver 8.8.8.8#53
Apr 7 11:58:42 dnsmasq[517]: using nameserver 68.87.64.146#53
Apr 7 11:58:43 rc_service: dhcp6c-state 859:notify_rc start_httpd
Apr 7 11:58:43 rc_service: waitting "start_radvd" via dhcp6c-state ...
Apr 7 11:58:43 rc_service: udhcpc 870:notify_rc start_rdnssd
Apr 7 11:58:43 dnsmasq[517]: read /etc/hosts - 6 addresses
Apr 7 11:58:43 dnsmasq-dhcp[517]: read /etc/ethers - 2 addresses
Apr 7 11:58:43 dnsmasq[517]: using nameserver 8.8.8.8#53
Apr 7 11:58:43 dnsmasq[517]: using nameserver 68.87.64.146#53
Apr 7 11:58:43 syslog: module nf_conntrack_ipv6 not found in modules.dep
Apr 7 11:58:44 RT-AC68U: start httpd
Apr 7 11:58:44 rdnssd[896]: Get IPv6 address & DNS from DHCPv6
Apr 7 11:58:44 radvd[886]: version 1.10.0 started
Apr 7 11:58:45 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Apr 7 11:58:45 rc_service: rc 904:notify_rc start_dhcp6c
Apr 7 11:58:47 dnsmasq[517]: read /etc/hosts - 6 addresses
Apr 7 11:58:47 dnsmasq-dhcp[517]: read /etc/ethers - 2 addresses
Apr 7 11:58:47 dnsmasq[517]: using nameserver 8.8.8.8#53
Apr 7 11:58:47 dnsmasq[517]: using nameserver 68.87.64.146#53
Apr 7 11:58:47 rc_service: dhcp6c-state 917:notify_rc start_radvd
Apr 7 11:58:47 rc_service: dhcp6c-state 917:notify_rc start_httpd
Apr 7 11:58:47 rc_service: waitting "start_radvd" via dhcp6c-state ...
Apr 7 11:58:47 radvd[907]: Exiting, sigterm or sigint received.
Apr 7 11:58:47 radvd[907]: sending stop adverts
Apr 7 11:58:47 radvd[907]: removing /var/run/radvd.pid
Apr 7 11:58:47 radvd[905]: Exiting, privsep_read_loop had readn return 0 bytes
Apr 7 11:58:48 RT-AC68U: start httpd
Apr 7 11:58:48 radvd[922]: version 1.10.0 started
Apr 7 11:58:50 rc_service: udhcpc 870:notify_rc stop_upnp
Apr 7 11:58:50 rc_service: udhcpc 870:notify_rc start_upnp
Apr 7 11:58:50 rc_service: waitting "stop_upnp" via udhcpc ...
Apr 7 11:58:50 miniupnpd[716]: received signal 15, good-bye
Apr 7 11:58:51 dhcp client: bound 50.191.104.61 via 50.191.104.1 during 335392 seconds.
Apr 7 11:58:54 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 11:58:54 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 12:00:42 kernel: br0: received packet on eth2 with own address as source address
Apr 7 12:00:46 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.57 0c:8b:fd:08:05:5c
Apr 7 12:00:46 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.57 0c:8b:fd:08:05:5c JerryZ-Laptop
Apr 7 12:02:41 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.91 b8:e8:56:e6:65:f2
Apr 7 12:02:41 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.91 b8:e8:56:e6:65:f2 iPhone-5s
Apr 7 12:17:45 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 12:17:45 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 12:36:36 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 12:36:36 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 12:55:27 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 12:55:27 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 13:14:18 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 13:14:18 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii
Apr 7 13:14:25 kernel: net_ratelimit: 198 callbacks suppressed
Apr 7 13:14:25 kernel: ipv6: Neighbour table overflow.
Apr 7 13:33:10 dnsmasq-dhcp[517]: DHCPREQUEST(br0) 192.168.15.68 8c:cd:e8:84:7b:73
Apr 7 13:33:10 dnsmasq-dhcp[517]: DHCPACK(br0) 192.168.15.68 8c:cd:e8:84:7b:73 Wii

 

[rtcomputersinc]

Lot of people did turn off the upnp so that should be something else that gets passed on to ASUS.

 

[Pedro]

Reboot problem is resolved but now watching video lags. Lost of image when watching video on LaPresse+. Going back to Asuswrt_Merlin 374.40 alpha4

Till now, Asuswrt-Merlin 374.40 alpha4 is the most stable for RT-AC68U

yesterday was my turn for this issue !!

While doing some speedtests on my iphone (often I do to check everything is fine) noticed severe decreases on speed, crashing from 10mbps to 2 etc... To solve that I´ve rebooted router and everything came back. Since other person has reported some bugs with 2,4ghz disabling beamform feature I´ve decided to step back to 374.40 alpha4. Do we have any chance to this issue be fixed on a upcomuing Merlin build?

 

[jim769]

yesterday was my turn for this issue !!

While doing some speedtests on my iphone (often I do to check everything is fine) noticed severe decreases on speed, crashing from 10mbps to 2 etc... To solve that I´ve rebooted router and everything came back. Since other person has reported some bugs with 2,4ghz disabling beamform feature I´ve decided to step back to 374.40 alpha4. Do we have any chance to this issue be fixed on a upcomuing Merlin build?

Hard to say if Merlin bases his next release on the new Asus code the problem may linger.

 

[JerryZ72]

I just wanted to post an update as I think this is probably pertinent. Since turning off UPnP, I have had no reboots whatsoever. I've been up for 1 days 5 hours 38 minutes 12 seconds now. I don't need it on, and will be ecstatic if this problem is also solved for me, but there is still a problem if having UPnP on is causing the reboots.

 

[jim769]

I just wanted to post an update as I think this is probably pertinent. Since turning off UPnP, I have had no reboots whatsoever. I've been up for 1 days 5 hours 38 minutes 12 seconds now. I don't need it on, and will be ecstatic if this problem is also solved for me, but there is still a problem if having UPnP on is causing the reboots.

If your having the reboot issue with this release then you other things going on there the issue was resolved in 4887 and 5047

 

[JerryZ72]

Jim,

That was my point. With UPnP turned on, reboots, UPnP turned off, no reboots. I'm not doing anything unusual in the setup on my router, and have no really odd devices (I also don't really have any need for UPnP to be on). There may still be something buggy in the ASUS code. That was the reason for my posting the update. I had the same issue with reboots using Merlin's 40 alpha 4 build. Per the conversation yesterday, it appears that many have UPnP turned off, so they may not have noticed this particular issue that I was seeing. Regardless, with it off I've been fone for a day an a half now versus reboots every 4 hours or less.

 

[jim769]

Jim,

That was my point. With UPnP turned on, reboots, UPnP turned off, no reboots. I'm not doing anything unusual in the setup on my router, and have no really odd devices (I also don't really have any need for UPnP to be on). There may still be something buggy in the ASUS code. That was the reason for my posting the update. I had the same issue with reboots using Merlin's 40 alpha 4 build. Per the conversation yesterday, it appears that many have UPnP turned off, so they may not have noticed this particular issue that I was seeing. Regardless, with it off I've been fone for a day an a half now versus reboots every 4 hours or less.

I understand every environment is different. I never really checked upnp is this on by default ? I have never had one reboot after 4887. Thanks for posting your finds. For me I am patiently waiting for Merlin to release the next 41 final build. I wish we had some idea when that might be now that for most the reboot issues is solved but I know Merlin don't like to be rushed and I can certainly understand that.

 

[RMerlin]

BTW, Asus are aware of the WOL issue, and it should be resolved in the next release.

 

[mairuay]

So I updated to 5047 on my ac68u. Reset the router and rebooted and then set my parameters all back again manually. All my devices except for my Windows 8.1 desktop connect just fine. The desktop works fine if I use a wired connection; but when I connect wirelessly, it connects, but typically with "limited" access. If it does connect to the internet, it is terribly slow. My laptop and phones connect wirelessly without problem. I disabled the firewall to see if that was issue - made no difference.

Any ideas?

I had the same problem. In my case this was because the Adapter went into Powersaving mode. Disable the "Allow the computer to turn off this device to save power" option in the network Adapter configuration. This is on by default in Windows 8.1.

Cheers

 

[pepeEL]

@RMerlin the source code to version 5047 was realesed. Did you update this in you soft ? And did the option failover from code 5047 was add to your firmware and works the same as in original firmware ASUS v5047 ?

 

[Adamm]

@RMerlin the source code to version 5047 was realesed. Did you update this in you soft ? And did the option failover from code 5047 was add to your firmware and works the same as in original firmware ASUS v5047 ?

He received the update from Asus today and started the diff process, will be a few days at-least before anythings updated and even then it all requires testing. Good things come to those who wait

 

[rtcomputersinc]

I understand every environment is different. I never really checked upnp is this on by default ? I have never had one reboot after 4887. Thanks for posting your finds. For me I am patiently waiting for Merlin to release the next 41 final build. I wish we had some idea when that might be now that for most the reboot issues is solved but I know Merlin don't like to be rushed and I can certainly understand that.

One of the troubleshooting try this was turn off upnp to stop "reboots". So many of us turned it off trying to fix the issue.

The upnp reboot seems like a soft reboot the log time is continuous. The other reboot was like a power off. My log would show Jan 31 until it picked up the correct date and time.

So the upnp issue may have fallen through the cracks.

 

[JerryZ72]

It is interesting that you say that. My reboot, for sure, was not a soft reboot as my log counter reset each time. I could not go more than about 4 hours without a reboot. Since turning off UPnP with the latest ASUS release, I've been up for 2 days 1 hours 40 minutes 57 seconds with no reboot and no issues at all. I know it doesn't make sense compared to what others have reported, necessarily, but it's working for me.

 

[rtcomputersinc]

It is interesting that you say that. My reboot, for sure, was not a soft reboot as my log counter reset each time. I could not go more than about 4 hours without a reboot. Since turning off UPnP with the latest ASUS release, I've been up for 2 days 1 hours 40 minutes 57 seconds with no reboot and no issues at all. I know it doesn't make sense compared to what others have reported, necessarily, but it's working for me.

Jerry your post of log in thread# 46 You see it has all the same date and the time is continuous. For the other reboot people were having was like a power cycle. You would see a bunch of April 7 lines I would get a bunch of April 7 lines and then a bunch of Jan 31 lines then April 7 when the time server sets the time correct again. Im guessing the uptime counter resets in both cases. No wonder this was so hard to fix.