I would expect that the commands Luniz2k1 provided would work.
I only ran V23 for a few weeks if even that and never needed to issue the commands.
I know rebooting the router updates the time.
If it were that easy I would have already done it. Sadly the build I'm running was created before DST was changed, so the start/stop dates are not accurate. It was an easy enough fix on my FreeBSD systems, just run make install in /usr/ports/misc/zoneinfo then run tzsetup and reselect my TZ. There is no obvious upgrade path for the TZ info, and since I can't even seem to find where in the directory structure the info is kept I have no hope of correcting it myself. I could just set the wrong TZ for a few weeks, then set it back, but I'd prefer to fix it than work around it.
I guess I could just go to a current build, but getting my router to take a flash is always an exercise in frustration.
I need to just move a FreeBSD box up to the front of the network and use it for routing, but I'm lazy like that.
Give a sec or 2 between each command. No reboot needed. Uptime will not be lost. _________________ (05/02/17) std - 31924
Linksys WRT400N
Buffalo WHR-G300N
Give a sec or 2 between each command. No reboot needed. Uptime will not be lost.
Worked for me to update time on WRT320N to account for DST change but did cause a hiccup in my OpenVPN site-to-site connection. Will see if this corrects the fast running clock issue I'm having with the WRT320N: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=417189&highlight=#417189 _________________
So...this seems to have worked automatically for exactly no one, including me. What's going on? Surely having it set right and on a working NTP is enough, and surely it checks these things once a day. Apparently not.
Joined: 04 Jan 2007 Posts: 11564 Location: Wherever the wind blows- North America
Posted: Mon Mar 15, 2010 11:10 Post subject:
rseiler wrote:
So...this seems to have worked automatically for exactly no one, including me. What's going on? Surely having it set right and on a working NTP is enough, and surely it checks these things once a day. Apparently not.
No...once again...an ongoing problem.
It is checked at boot up...then after 120 seconds for a second time....that's it.
Joined: 24 Aug 2009 Posts: 2070 Location: South Florida
Posted: Mon Mar 15, 2010 11:28 Post subject:
Ughh...I hate DST. Almost 7:30am here and still dark out...Hate it! _________________ Optware, the Right Way
Asus RT-AC68U
Asus RT-N66U
Asus RT-N10
Asus RT-N12
Asus RT-N16 x5
Asus WL520gU
Engenious ECB350
Linksys WRT600Nv1.1
Linksys WRT610Nv1
Linksys E2000
Netgear WNDR3300
SonicWall NSA220W
SonicWall TZ215W
SonicWall TZ205W
SonicWall TZ105W
Wow, I definitely missed that conversation before.
And that dovetails perfectly with the WAN graph issue seen by some now and again, where it stops recording bandwidth. One reason is because the time is wrong (not an hour off, but unset). The time can be wrong because the router was rebooted when your connection wasn't live for whatever reason (e.g. DSL down, or a modem problem), and unaided the router never checks time again after that. I don't know why in that scenario the router doesn't simply stick with the time it had before the reboot instead of resetting it--and maybe it usually does remember it--but it certainly doesn't always do that.
So...this seems to have worked automatically for exactly no one, including me. What's going on? Surely having it set right and on a working NTP is enough, and surely it checks these things once a day. Apparently not.
No...once again...an ongoing problem.
It is checked at boot up...then after 120 seconds for a second time....that's it.
IF it gets the time. That isn't always the case. All it takes is for a reboot when the NTP server is offline or when there's a momentary WAN interruption.