Rt-ac68u connection stability issue on 378.56_2

[Sir flamington]

Hi guys

Have been using the rt-ac68u with merlin firmware for some time without any major issues, have found it does require a reboot every few days.

Recently updated to the 378.56 and then 378.56_2 firmwares and since then have found serious stability issues with what I think is with the dns side of things.

Randomly, all devices will loose internet access, whereas all lan communication works fine. If I go into wan dns settings and change from automatically assigned by ISP to google, apply, then back to automatically assigned it sometimes fixes things, sometimes won't and requires reboot. Any incoming connections (try to connect via phone to the network via VPN server I'm running) also don't connect.

Have tried a factory reset with the firmware update but that hadn't helped.

The modem (net gear cg3100d-2) seems to be holding a stable internet connection the whole time, so it doesn't appear to be the modem dropping out.

Is there any wan specific configuration I need to alter to fix this? I've tried dropping from aggressive to normal mode for dhcp query frequency.

 

[joegreat]

Have been using the rt-ac68u with merlin firmware for some time without any major issues, have found it does require a reboot every few days.

Recently updated to the 378.56 and then 378.56_2 firmwares and since then have found serious stability issues with what I think is with the dns side of things.

Hi,

Did you configure the router with minimal settings manually after the factory reset and let it run for a while to see if the problem comes again? No restore of all settings after the reset!

If the minimal settings runs stable, you can add feature by feature and the see where the faulty option is hiding!

With kind regards
Joe

PS.: My AC68U and N66U run stable with the the 56 versions and the the 57 alpha version!

 

[Sir flamington]

Hi,

Did you configure the router with minimal settings manually after the factory reset and let it run for a while to see if the problem comes again? No restore of all settings after the reset!

If the minimal settings runs stable, you can add feature by feature and the see where the faulty option is hiding!

Hi Joe,

I didn't restore any of the settings from a backup / saved configuration file, I reconfigured them manually. Having said that, the only things I configured were 4 manually assigned dhcp settings, a single port forwarding rule, openvpn client with some jffs scripts and ddns settings.

 

[DavidS]

Hi guys

Have been using the rt-ac68u with merlin firmware for some time without any major issues, have found it does require a reboot every few days.

Recently updated to the 378.56 and then 378.56_2 firmwares and since then have found serious stability issues with what I think is with the dns side of things.

My AC68 with this same version started doing reboots every hour this morning. This just started out of the blue. No network changes. My router has become very unstable now and is constantly rebooting.

I just happened to be logged in looking at the logs and caught it before it got in trouble. I saved the log and have included a little bit here. After the reboot, this part of the log was gone probably because it wasn't written to flash.

Any ideas? (Note, newest entries are on top.)

Dec 3 21:31:09 dnsmasq[434]: failed to allocate 124 bytes
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPREQUEST(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPOFFER(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPDISCOVER(br0) bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPNAK(br0) 10.1.1.130 bc:ee:7b:86:ef:68 no leases left
Dec 3 21:31:09 dnsmasq[434]: failed to allocate 124 bytes
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPREQUEST(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPOFFER(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPDISCOVER(br0) bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPNAK(br0) 10.1.1.130 bc:ee:7b:86:ef:68 no leases left
Dec 3 21:31:09 dnsmasq[434]: failed to allocate 124 bytes
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPREQUEST(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPOFFER(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPDISCOVER(br0) bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPNAK(br0) 10.1.1.130 bc:ee:7b:86:ef:68 no leases left
Dec 3 21:31:09 dnsmasq[434]: failed to allocate 124 bytes
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPREQUEST(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPOFFER(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPDISCOVER(br0) bc:ee:7b:86:ef:68
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPNAK(br0) 10.1.1.130 bc:ee:7b:86:ef:68 no leases left
Dec 3 21:31:09 dnsmasq[434]: failed to allocate 124 bytes
Dec 3 21:31:09 dnsmasq-dhcp[434]: DHCPREQUEST(br0) 10.1.1.130 bc:ee:7b:86:ef:68
Dec 3 21:28:54 dnsmasq[434]: failed to allocate 1028 bytes
Dec 3 21:27:14 dnsmasq[434]: failed to allocate 1028 bytes
Dec 3 21:27:13 dnsmasq[434]: failed to allocate 1028 bytes
Dec 3 21:27:13 dnsmasq[434]: failed to allocate 1028 bytes
Dec 3 21:27:12 dnsmasq[434]: failed to allocate 1028 bytes
Dec 3 21:08:07 dnsmasq-dhcp[434]: DHCPACK(br0) 10.1.1.150 f4:09:d8:b9:8c:ca android-ac95083846ca0c79
Dec 3 21:08:07 dnsmasq-dhcp[434]: DHCPREQUEST(br0) 10.1.1.150 f4:09:d8:b9:8c:ca
Dec 3 21:08:07 dnsmasq-dhcp[434]: DHCPOFFER(br0) 10.1.1.150 f4:09:d8:b9:8c:ca
Dec 3 21:08:07 dnsmasq-dhcp[434]: DHCPDISCOVER(br0) f4:09:d8:b9:8c:ca
Dec 3 21:07:38 dnsmasq-dhcp[434]: DHCPACK(br0) 10.1.1.71 f4:09:d8:ee:e1:1d android-c38622821f9b0550
Dec 3 21:07:38 dnsmasq-dhcp[434]: DHCPREQUEST(br0) 10.1.1.71 f4:09:d8:ee:e1:1d
Dec 3 21:07:36 crond[442]: time disparity of 180187 minutes detected
Dec 3 21:07:30 dnsmasq-dhcp[434]: DHCPACK(br0) 10.1.1.10 24:0a:64:6a:a3:c2 Susan-ASUS
Dec 3 21:07:30 dnsmasq-dhcp[434]: DHCPREQUEST(br0) 10.1.1.10 24:0a:64:6a:a3:c2
Dec 3 21:07:26 hour monitor: daemon is starting

 

[Sir flamington]

Iv actually seen similar in my log files also, I just assumed it was a device (in this case my android phone) being allocated an ip address from the dhcp server.

 

[DavidS]

Iv actually seen similar in my log files also, I just assumed it was a device (in this case my android phone) being allocated an ip address from the dhcp server.

But I am seeing 100's of these messages in one second and the message "no leases left" and "failed to allocate 124 bytes" makes me wonder if there isn't a more serious problem. And I've never seen them in the logs before, and I don't see them after a crash/reboot which makes me think they happen right before a crash. I've also seen a few times where I couldn't login it to the admin web server. Maybe it was in this race condition at that time. I'm just guessing, but it seems there are at least two of us with very similar issues with 378.56_2 so I'm just trying to provide information that may be helpful.
Thanks.

 

[Sir flamington]

But I am seeing 100's of these messages in one second and the message "no leases left" and "failed to allocate 124 bytes" makes me wonder if there isn't a more serious problem. And I've never seen them in the logs before, and I don't see them after a crash/reboot which makes me think they happen right before a crash. I've also seen a few times where I couldn't login it to the admin web server. Maybe it was in this race condition at that time. I'm just guessing, but it seems there are at least two of us with very similar issues with 378.56_2 so I'm just trying to provide information that may be helpful.
Thanks.

Yeah, I didn't have as many as you in the logs, however that could be because as what you've said, when it crashes it doesn't get written to the flash.

Are you by chance running an openvpn client as well?

 

[DavidS]

I am not running an openvpn client. I have a simple setup. Just forwarding two ports. I am using an RT-AC66U as a media server on the 5G band. But again, everything has been working fine and stable for several weeks. Then by looking at the logs, I can see that it started frequently rebooting starting 12/2.

 

[RMerlin]

Your router is running out of RAM. Make sure you are running 378.56_2, as it resolve a common issue causing the router to run out of RAM due to a debug log growing too much. If you still have the issue, then it's probably caused by another logfile, less commonly encountered issue. You can either try the Preview 380.57 builds posted in this forum, or downgrade to 378.55 until the next release.

 

[DavidS]

Thank you. When the router started rebooting a lot, I increased the log level, so maybe that is part of the memory error issues. But I only did that after the router started having problems. I'll try the newer version or downgrade. Thank you.

 

[Sir flamington]

Can confirm I'm running _2. I've noticed a different message in my log files relating to my openvpn client. I'll see if I can find it. Could it be the VPN client is causing the log to overflow?

also noticed my CPU is running consistently at 87c - seems quite high.

 

[roofy]

I also encountered a similar issue where my 68U was running out of RAM. I first saw this behavior in release .56.....As stated by Merlin it was caused by a log file growing too large...Unfortunately in my case .56_2 still displays this behavior although takes longer before requiring a reboot (48 hours on .56 vs 17 days on .56_2). I could not spend any more time troubleshooting the issue and ended up rolling back to .55.....Hope the next release works out better with regard to log management.

 

[RMerlin]

I also encountered a similar issue where my 68U was running out of RAM. I first saw this behavior in release .56.....As stated by Merlin it was caused by a log file growing too large...Unfortunately in my case .56_2 still displays this behavior although takes longer before requiring a reboot (48 hours on .56 vs 17 days on .56_2). I could not spend any more time troubleshooting the issue and ended up rolling back to .55.....Hope the next release works out better with regard to log management.

The smb log issue is already fixed in development code, which is why I suggested trying the 380.57 alpha builds.

 

[roofy]

The smb log issue is already fixed in development code, which is why I suggested trying the 380.57 alpha builds.

That's good news. Thanks Merlin. I'll give .57 alpha a spin over the weekend and provide feedback.

 

[DavidS]

I went to .55 as it looks like .57 isn't available for AC68U yet. I'll post back if I experience any issues, which I doubt I will. Thank you.

 

[joegreat]

I went to .55 as it looks like .57 isn't available for AC68U yet. I'll post back if I experience any issues, which I doubt I will. Thank you.

I installed .57_alpah3 some time ago - search harder to find it...

 

[RMerlin]

I went to .55 as it looks like .57 isn't available for AC68U yet.

It's available for all models:

http://www.snbforums.com/threads/preview-380-57-alpha-test-builds-for-all-models.28426/

 

[Sir flamington]

Happened again today - have gone through the logs, and it seems something is causing the connection to drop, which then causes the VPN to loose connection, and then keep trying to reconnect, thus filling the log file.

Its approximately 1300 lines, so I won't paste it here. If someone cares to look to see what could be causing it, its here - http://pastebin.com/XWg6gDcs

 

[Sir flamington]

Updated to the 380-57 Alpha and am still having connectivity issues/DNS drops outs. Uptime of 30 minutes, then when trying to load a website, get the unresolved DNS error message. Am using 8.8.8.8 & 8.8.4.4 as my DNS settings. In the log, just before it happened the following occured:

Dec 6 13:12:13 kernel: * Make sure sizeof(struct sw_struct)=160 is consistent
Dec 6 13:12:13 kernel: IDPfw: TrendMicro forward module ver-1.0.31
Dec 6 13:12:13 kernel: IDPfw: Apply module param dev_wan=vlan2
Dec 6 13:12:13 kernel: IDPfw: Apply module param sess_num=30000
Dec 6 13:12:13 kernel: IDPfw: Init chrdev /dev/idpfw with major 191
Dec 6 13:12:13 kernel: IDPfw: IDPfw is ready
Dec 6 13:12:13 kernel: sizeof forward param = 160
Dec 6 13:12:26 kernel: mod epilog takes 0 jiffies
Dec 6 13:12:27 kernel: IDPfw: Exit IDPfw
Dec 6 13:12:27 kernel: Stop the IPS/AppID engine...
Dec 6 13:12:27 kernel: IDPfw: Exit chrdev /dev/idpfw with major 191
Dec 6 13:12:27 rc_service: bwdpi_check 453:notify_rc start_firewall
Dec 6 13:12:28 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Dec 6 13:12:28 custom script: Running /jffs/scripts/firewall-start (args: vlan2)

Is there something occuring with my OpenVPN client that is causing the issue? I'm using the scripts from the wiki (openvpn_event and firewall-start) to route traffic from a static IP directly through VPN.

Thanks

 

[joegreat]

Is there something occuring with my OpenVPN client that is causing the issue? I'm using the scripts from the wiki (openvpn_event and firewall-start) to route traffic from a static IP directly through VPN.

Remove/Disable the VPN and wait the 30 minutes and you will recognize that your firewall-start script messes the things up (or not)...
...or you stop using the the useless TrendMicro stuff which triggers the unstable firewall-settings to be used multiple times!