NTP (an hour back)

[st3v3n]

iManuB (I mean Fox), Our AC3200 had the same issue a couple of weeks ago, showed up in the tunnel and created a problem for a day. The tunnel kept kicking out and wouldn't hold and ntp resets in the log clued me in. I reset to GMT after reading of this on another thread, then to the same zone our tunnel exits and that everything else is set to. DST was skewed, it was actually backwards from what it should've been set to. Someone had mentioned something similar to RMerlin. I reset to the correct DST changeover, month/day/weekend, saved, rebooted. It didn't take the first try but worked the second time; never recurred. The time pool servers it was set to were affected or weren't syncing automatically as it's done forever, so I chose a tier 1 server in the correct time zone. I made sure the router and everything on the LAN were in sync, and continue to check everything each monring. So far, it's all worked and held. Others in other threads in the forum on other sites have referred to this. Folks at the national pool were/are quite concerned with the level of attacks (as we all are). All of the hints found helped to resolve this for us. Cheers.

 

[iManuB]

Thanks for the answer and call me "FOX". I'm blushing...

Apart from the jokes, setting

For CET Central European Time, set it to:
GMT+01:00
3, 5th, Sun, 2 and
10, 5th, Sun, 2

I solved the problem.

Thanks again for the beautiful explanation.

 

[st3v3n]

Excellent, We were watching XFiles, re the Muldar avatar: don't blush, wife would get after me for any perceived inappropriateness, what seems to be going aroundP)

 

[sfx2000]

Hehe - we here about this twice a year...

And in my core network days - yeah, it's there as well with scripts and what not...

One would think one would call tzdata to keep things in sync - but in the cloud, hosts can be anywhere in the world.

 

[RMerlin]

Hehe - we here about this twice a year...

Exactly...

 

[st3v3n]

Yesterday, the date/time bug/hack kicked in again; moved the date to the future, to the 3rd Sunday in November, no reason for it, the 3200 has run flawlessly otherwise for over a week since I was finished with my config tests. Any ideas are welcome as long as it's not a joke.

 

[thelonelycoder]

Yesterday, the date/time bug/hack kicked in again; moved the date to the future, to the 3rd Sunday in November, no reason for it, the 3200 has run flawlessly otherwise for over a week since I was finished with my config tests. Any ideas are welcome as long as it's not a joke.

This is no joke: Come again?
I can read your comment but not comprehend.

 

[st3v3n]

thelonelycoder, I likely misinterpreted the 'here we are again, twice a year' that fxs2000 and RMerlin mentioned, regret I wasn't clear. I was testing openvpn configs/tunnels from/for our VPN provider over the past 2 months, and struggled with my 3200 for at least 2 full weeks, with the GUI stalling/crashing/being generally not responsive, horrible bandwidth issues, etc. Several other threads involved, others were also reporting similar issues. In the end, it's come down to a bug, or worse, a possible hack that changes the date/time field in the router, that affects everything. After meticulous testing of every single feature in the router, starting from scratch, I discovered that after setting the correct date/time (DST etc), that the field would change. I thought I'd nailed it down, set it to a tier one time server, and it sailed through the DST swap last Sunday without a hiccup. Yesterday with no warning, after 8 hours up, I began to get DDNS fail errors, then the tunnel died very shortly, naturally. The DDNS and server weren't on or used in my previous tests, so that threw me. When I got around to checking the Date/time field, something had changed it to the 3rd Sunday in November, causing the failure. If it had started the day like that, I'd have been preparted to deal with it, since the system wouldn't have connected. The system is clean, protected and there's no contamination, no hacks or entries (at least in the past year) that I can locate. Whatever is causing this is beyond my 30+ years of work in the field. Went through all logs/tests/notes and logically, it's a bug, or a hack. I wish it were senilty, that I can understand more than a ghost haunting the router. I can dig up the links to the other threads if that would help. It was a laborious process, but the router works flawlessly until the Date/Time field suddenly changes. Cheers