In what time zone are the parental controls?

[StR]

I encountered a strange problem with Parental Controls -> Time Scheduling: After the change to the daylight saving time on March 12 (in the US), it looks like the scheduled times remained in the non-daylight saving time. I have a computer for which the offtime is 21:00-7:00, and now it gets the network at 8am instead of 7am.
The router system time is correct. I even rebooted the router just in case something was cached, but that didn't help.
It was working fine throughout the winter. I don't remember if I had that schedule in the fall, before the end of the daylight saving time.

(I don't think it matters, but this router is currently on Merlin-386.7_2)

Any thoughts on this issue? Has anybody seen it?

 

[ColinTaylor]

It ought to be in the local timezone. When the time changed to DST there should have been a message to that effect in the syslog together with it restarting the firewall and wan precisely to avoid this problem.

Oct 30 01:00:11 watchdog: restart_firewall due DST time changed(1->0)
Oct 30 01:00:11 rc_service: watchdog 1530:notify_rc restart_firewall
Oct 30 01:00:11 rc_service: watchdog 1530:notify_rc restart_wan

 

[StR]

That's what I expected, but, something doesn't compute.

There was no message changing to DST, but a bunch of processes reported restarting/reloading:
Mar 12 03:00:30 miniupnpd[2803]: shutting down MiniUPnPd
then
ovpn-server1 also restarted (causing dnsmasq to restart and reread its configuration a few times along the way).
dnsmasq-dhcp, wsdd2, inadyn - reported starting/reloading activities...

 

[ColinTaylor]

It's possible that the watchdog message didn't show up in log depending on what the log level was set to. But the other messages you saw are consistent with the WAN being restarted. But even if that wasn't the case you said that you've rebooted the router so that should have fixed any problems.

Maybe you can use the pc command to find some information about the current state.

# pc -?
Usage: pc [show]
          showrules
          enabled [1 | 0]
          daytime [1-7] [0-23]
          apply
          flush

Otherwise try this:

iptables-save | grep PControls

 

[StR]

First of all, thank you, @ColinTaylor for suggesting these commands to check the rules.
The rules look fine, but after that initial incident, I didn't experience this problem.
Unfortunately, I didn't have time to look at the iptables at the time of the incident, as my kiddo needed to start the remote lesson ASAP.

So, I am note quite sure what was happening. I'll try to watch in the fall, after the next clock switch.