RT-AC87U reboot when netword is satured ?

[babao60]

Hello,

First of all, sorry for my bad english... I turn to you today because I have a problem with my router RT-AC87U. I have a HP Gen8 mini server on my local network with OMV installed on it, I want to save on OMV all data from my computer. I have a Samba share and I make a copy of my computer to the shared folder, my problem is that when I run the copy, the router restart every 15 minutes, here are the logs of the router, it restarted around 9:00:00 :

https://pastebin.com/33TXL2GV

I used the Firmware : 380.69

thank you for your help

 

[ColinTaylor]

Try reformatting the JFFS partition.

Aug 1 02:00:22 kernel: JFFS2 notice: (351) check_node_data: wrong data CRC in data node at 0x00347718: read 0x295d23e9, calculated 0xd6d6cd22.

Administration > System > Persistent JFFS2 partition > Format JFFS partition at next boot

 

[babao60]

Thank you for you help, i have try to reformatting the JFFS partition but i have allways the same problem...
The last message before rebooting is :
Dec 23 17:55:31 QTN: QTN connection lost[169.254.39.23][169.254.39.27]

 

[ColinTaylor]

The last message before rebooting is :
Dec 23 17:55:31 QTN: QTN connection lost[169.254.39.23][169.254.39.27]

Looks like you might be onto something.

The reboot appears to be caused by the watchdog process. It checks whether it can ping the Quantenna Wi-Fi system and if it can't it reboots the router.

 

[babao60]

ok so if i understand well my problem come from this :

if(icmp_check(src_ip, dst_ip) == 0 ){
failed++;
if(failed > 2){
logmessage("QTN", "QTN connection lost[%s][%s]", src_ip, dst_ip);
system("reboot &");
}
}
waiting = 0;
return;
}

but what can i do ? i don't understand...

 

[RMerlin]

but what can i do ? i don't understand...

It means the Quantenna CPU (which runs its own firmware) stopped working, probably because it crashed. You can try a factory default reset, otherwise it would indicate a hardware failure.

 

[ColinTaylor]

It means the Quantenna CPU (which runs its own firmware) stopped working, probably because it crashed. You can try a factory default reset, otherwise it would indicate a hardware failure.

Just a thought, but if this only happens when the network is saturated could it be that Quantenna CPU hasn't crashed but is just slow/unresponsive to the pings?

 

[john9527]

Actually, I think there is an error in that code. It looks like they are looking for 3 successive fails on the check routine, but they never reset the fail counter on a success.

 

[RMerlin]

Just a thought, but if this only happens when the network is saturated could it be that Quantenna CPU hasn't crashed but is just slow/unresponsive to the pings?

Depends how long they wait for the response. I'd be surprised if a timeout would occur accross a 1 GBps RGMII link however. It could be the QTN crashed under the load.

Actually, I think there is an error in that code. It looks like they are looking for 3 successive fails on the check routine, but they never reset the fail counter on a success.

That wouldn't surprise me, considering their past track record... Might be worth taking a look, especially if the issue seem to be more common in more recent firmware releases (where that watchdog code was added).

 

[ColinTaylor]

@babao60 How is your computer and HP Gen8 connected to the router, wired or wireless? If wired, what ports are they plugged into?

 

[john9527]

That wouldn't surprise me, considering their past track record... Might be worth taking a look, especially if the issue seem to be more common in more recent firmware releases (where that watchdog code was added).

Well, the code was added back in 2016...but I still think it may be incomplete. If @babao60 wants to try, I did a test fix
RT-AC87U_380.69_1-g54e17d846.zip
Download: https://1drv.ms/f/s!Ainhp1nBLzMJkCFLXQsNc9_C3Ye_

 

[Blacklistedcard]

I'm testing that test firmware right now.... Lets see if it helps.

 

[john9527]

I'm testing that test firmware right now.... Lets see if it helps.

As a newcomer to the thread, I'm not sure what problem you are having. But the test code only potentially addresses a reboot following a message similar to
QTN: QTN connection lost[169.254.39.23][169.254.39.27]

 

[babao60]

Thank you all for your help. I made a reset of the router and reloaded my backup. I am now saving my files to OMV for about 5 hours and I have not rebooted for now, I hope my problem is solved now !

 

[ColinTaylor]

I made a reset of the router and reloaded my backup.

Can you describe exactly what you did? Thanks.

 

[babao60]

I just made Factory default>Restore/Save/Upload Setting>Factory default, reboot and then Factory default>Restore/Save/Upload Setting>Restore setting with my file backup

 

[ColinTaylor]

I just made Factory default>Restore/Save/Upload Setting>Factory default, reboot and then Factory default>Restore/Save/Upload Setting>Restore setting with my file backup

OK. That's interesting.

If your problem was a configuration error then what you did shouldn't have changed anything, because you've just restored exactly the same settings that you had before. Or was your backup taken some time ago?

 

[babao60]

I made my backup just before made the factory reset so i don't think it was a problem from my setting, however, some parameters have not been restored correctly, such as WAN and my Manual Assignment DHCP, i don't know if it's normal

 

[RMerlin]

Actually, I think there is an error in that code. It looks like they are looking for 3 successive fails on the check routine, but they never reset the fail counter on a success.

It will indeed reboot if there are three totally separate incidents. This should make it only reboot if three consecutive pings failed, making it less likely to get triggered by a false positive.

diff --git a/release/src/router/rc/watchdog.c b/release/src/router/rc/watchdog.c
index ae6f13c..30ab56d 100644
--- a/release/src/router/rc/watchdog.c
+++ b/release/src/router/rc/watchdog.c
@@ -2719,6 +2719,8 @@ void qtn_module_check(void)
                        logmessage("QTN", "QTN connection lost[%s][%s]", src_ip, dst_ip);
                        system("reboot &");
                }
+       } else {
+               failed = 0;
        }
        waiting = 0;

 

[john9527]

It will indeed reboot if there are three totally separate incidents. This should make it only reboot if three consecutive pings failed, making it less likely to get triggered by a false positive.

Exactly the change I made in the test build I posted earlier