[duhceb]

Radio Time Restrictions seem a bit off this build. The radios will disable on schedule but don't come back up without intervention. This is on both of my R9000.

[duhceb]

NTP isn't setting the time for me on the R9000s. Despite several changes to the time zone and the server, I had to manually set my date/time. Interested to see if the time updates at all or if that sync is malfunctioning. It IS working on the R7000 and WRT3200ACM.

[kernel-panic69]

Exact configuration steps to reproduce the issue, please. Screenshots, the whole nine, thanks.

[duhceb]

OK so the NTP was my problem since I goofed on my config after a bad flash, but I've attached a couple screen shots to show the Radio Time Restriction problem. If you change nothing and click Apply Settings, then everything refreshes and is fine. For whatever reason the radios don't come back up on schedule.

[kernel-panic69]

@duhceb: logs, please. You were asked for the WHOLE nine. Do an 'nvram set console_debug=1' and provide dmesg and cat /var/log/messages output in a text file attachment.

[duhceb]

Logs attached...the last build that worked was 59171 (2/14 build affected as well). Logs show that the radio was turned on at the appropriate time, but it didn't actually go active.

[duhceb]

Might be a CRON issue...

[kernel-panic69]

@duhceb: We have a case of mysteriously missing logs. I see no attachments from you anywhere in this thread.

[duhceb]

Second attempt...apparently my first file extension was restricted.

[kernel-panic69]

I guess I should've specified .txt file extension, but you didn't do an nvram set console_debug=1 with optional nvram commit and reboot, so no telling what specifically isn't being called when the radios are being turned back on. From what you've provided, It seems dnsmasq restarts twice. I personally have NTP sync once per 24 hours.

[duhceb]

These entries are missing from the non working build, but show up in the 59171 build that works:
Feb 17 07:00:46.889 R9000_DD-WRT user.info : [hostapd] : daemon on wlan0 with pid 0 is forced to be restarted....
Feb 17 07:00:55.994 R9000_DD-WRT user.info : [hostapd] : successfully started
Feb 17 07:00:55.994 R9000_DD-WRT user.info : [hostapd] : daemon on wlan1 with pid 0 is forced to be restarted....
Feb 17 07:01:05.118 R9000_DD-WRT user.info : [hostapd] : successfully started

I updated my setting to NTP sync every 12 hours rather than every hour (makes sense). Thanks for the suggestion.

[kernel-panic69]

Discussion split out of build thread. Please provide proper logs as requested twice, now three times.

EDIT: I was told it may be related to cron errors that should be fixed in the next release.

https://svn.dd-wrt.com/changeset/59740

[nkaufman]

@duhceb - Has this issue been resolved?

I'm experiencing the same issue.

I reverted back to 12/25/2024 build 58892 since I had a backup of config for that build.
Did a nvram erase && reboot after downgrading and then restored config

I upgraded to 1/27/2025-r59397 and experienced same issue of radio not coming back on.

So something seems to have happened between these 2 builds.

Another reason I downgraded to 12/25/2024 build was Build 03-13-2025-r60276 had reduced range and speed of 5GHz.

Now am getting in the habit of making backup of config after each upgrade so I can go back to earlier version with minimal downtime.

[nkaufman]

I am now on 03-28-2025-r60511 and still facing same issue.
My NTP refresh is now 24 hours - 86400

The steps for 'chimps' like myself seems to be:
Command prompt on Windows, connect to router, run following commands:
>nvram set console_debug=1
>nvram commit and reboot
>dmesg

Copy and paste output in txt file
Then run

>cat /var/log/messages
Again copy and paste the output in txt file

Questions:
(1) Did I capture steps correctly? If not then please help in getting the right steps
(2) Should I run dmesg and cat commands after router radio is turned off e.g. 10PM or after it does not turn on at time it's supposed e.g. 4AM OR some other time?

Thanks

[kernel-panic69]

Those steps are correct, however I think serial console logs would probably be more fruitful for troubleshooting, but maybe tail -f /var/log/messages may also be of use.