Cannot Get Server Time Synced w/ Android for 2-factor

[Speez]

No idea what the issue is this time, but I recently picked up a new phone (pixel 2 xl) and was going about setting up google authenticator for my 2-factor login (previously working fine on my nexus 6p). When I tried to scan the barcode to setup on the new phone, it did not like the code and said the 6 digit code could not be verified. Mind you when I scanned in the barcode the first time (same as before) it put my pixel 2 in "sync" with the 6p as far as what code was showing in authenticator, and I had just used the 6p to login. I did then notice that the 6p, the qnap server (ts-251) and the pixel were not in sync with them displayed times. I tried resetting the time server in qnap, and re-syncing the 2-factor code, but to no avail. It's been a year and a half since I last set this up but I don't remember having any issues, and now its a mess and my 6p isnt working to show codes either.

Any thoughts? There are no time setting options on my phones to sync with the same time server as the qnap (pool.ntp.org previously working just fine), so I'm at a loss for how to get this synced up again.

Thanks,

[schumaku]

Already compared the time of both phones (commonly synched from the network, not from Internet NTP) and the time on the NAS?

Suspect more the NAS is off .... worst case, you might try the "Time correction for codes" in the Google Authenticator hamburger menu top right (settings).

[Speez]

After a couple of restarts of all devices and bouncing settings around...it is working now. Not super reassuring because I am not sure what clicked and fixed it and it would ** to get out of sync again.

What was interesting was all the times were off, the old phone, the new phone, and the NAS clock. When I added the QNAP barcode to the new phone, the ticket in Google authenticator for the new phone was maybe 10-15% "ahead" of the old phone, but showing the same code most of the time (so the new phone ran out and switched codes a few seconds before the old phone, this was true for my Google account, LastPass account, and qnap accounts in authenticator). Immediately prior to adding that barcode to the new phone, I had used the old phone to authenticate my way into my QNAP device, and then the phones codes were Matching but not working. My new phone clock was about 80-90 seconds ahead of the NAS and my old phone was kind of in the middle, no clue what happened there

[Speez]

This appears to be an issue again, my ts251 is out of sync with my phone and Google authenticator by ~45ish seconds. The authenticator codes will not work as my phone is "ahead" of the NAS until the last 15 seconds or so of a countdown when they are on the same code cycle. This is not good, any more thoughts? I have refreshed everything as many times as possible.

Sent from my Pixel 2 XL using Tapatalk

[P3R]

Why not try to use a geographically closer pool?
You can also use the continental zones (For example europe, north-america, oceania or asia.pool.ntp.org), and a country zone (like ch.pool.ntp.org in Switzerland) - for all these zones, you can again use the 0, 1 or 2 prefixes, like 0.ch.pool.ntp.org. Note, however, that the country zone might not exist for your country, or might contain only one or two timeservers.

[mdhwoods]

i had that issue on my iphone. what i found that worked was to disable automatically set time on phone, then reenable. this seemed to force the time to update and i was able to authenticate. I had to do this often but it worked. times looked correct but were obviously off enough to fail.

[schumaku]

i had that issue on my iphone. what i found that worked was to disable automatically set time on phone, then reenable. this seemed to force the time to update and i was able to authenticate. I had to do this often but it worked. times looked correct but were obviously off enough to fail.

Mobile devices fetch the time from the 3G/4G network, not from any ntp services. Strange this time is off that much (>30 seconds) from a standard time (where the NAS clock is not ntpd synched, and can run away, too.

[mdhwoods]

i had that issue on my iphone. what i found that worked was to disable automatically set time on phone, then reenable. this seemed to force the time to update and i was able to authenticate. I had to do this often but it worked. times looked correct but were obviously off enough to fail.

Mobile devices fetch the time from the 3G/4G network, not from any ntp services. Strange this time is off that much (>30 seconds) from a standard time (where the NAS clock is not ntpd synched, and can run away, too.

ya, i thought it was strange also, but its what i had to do. Now on my new phone i do not have this issue.

[P3R]

...where the NAS clock is not ntpd synched, and can run away, too.

Which is a strong argument for configuring automatic time synchronization and using an hourly update interval rather than daily.

Better firewalls (like for example pfSense) offer ntp server functionality or on NASes where virtualization is supported, we could run our own time server as a VM.

Preferably we get the correct time from a geographically nearby ntp pool (as I recommended earlier in the thread) or if running our own local time server we could also use the official national time references of our current location.

[jasisboy]

...where the NAS clock is not ntpd synched, and can run away, too.

Which is a strong argument for configuring automatic time synchronization and using an hourly update interval rather than daily.

Better firewalls (like for example pfSense) offer ntp server functionality or on NASes where virtualization is supported, we could run our own time server as a VM.

Preferably we get the correct time from a geographically nearby ntp pool (as I recommended earlier in the thread) or if running our own local time server we could also use the official national time references of our current location.

This did work for me. Thanks