Posted: Tue Jan 16, 2024 21:03 Post subject: [Solved]RT-N66U CTF Crash/Reboot
Having upgraded ISP speed, I found CTF was necessary to take advantage of this new speed (500Mbps), having been previously using SFE.
Moving to CTF gains much higher throughput, but appears to result in a ~15 min crash/reboot loop. The device will function fine for around 10-15 mins, then crash, reboot etc.
Capturing the logs for this crash is proving difficult, given it's overwritten on reboot. Is the remote syslog server the only way to capture this?
Build is v3.0-r54914 mega. I've reverted a couple of builds back (to r54682) to check if it's a recent regression that's been missed, but this behaviour appears in r54682 also.
Hopefully it's something obvious I've missed as I'd rather not have to upgrade hardware just yet (if CTF isn't stable on the N66U or something similar)
Last edited by toma678 on Mon Jan 29, 2024 20:04; edited 1 time in total
Store logs on USB pendrives (2022) _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
I've managed to get the log saving to a USB stick. I don't have a spare PSU with that barrel jack on, but I do have a 19V laptop charger that's looking a fair candidate to sacrifice (just needs the connector soldering on). I'd have expected the USB stick to have caused a PSU brownout if it was that close to the limit. Equally, with SFE enabled, the processor regularly hits 100% and as such should theoretically be drawing max current (unless the CTF silicon is particularly hungry?).
The logs aren't particularly useful - The last entry was a routine NTP update before a kernel warning that the USB stick wasn't properly dismounted. There was however a line reporting a successful shutdown of a cron but this is contradicted by a line saying cron death and fail to lock cron.pid.
The sudden nature of failure does appear to point to a PSU fault, but the traffic flowing at the time was relatively minimal (i.e. pretty much idle). Is there a way I can increase the verbosity of the logs? I will try a different PSU in the meantime.
nvram set console_debug=1 && nvram commit _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
Thanks very much for the assistance both.
After finally receiving the correct size barrel jacks in the post (who thought a 2.5x0.7mm jack was a good idea!), I soldered it onto the spare charger lead and (so far) have had no issues, with an uptime of just under 2 days.
I will mark the post as solved.