Incorrect time and date

[PU1JLA]

Hello to all!
I'm new to DMR and Pi-star and so far, I'm enjoying very much. But I'd like to share with you a small issue that I have with my Pi-star (4.1.6 / Dashboard: 20230713).
I know, it's a small detail but it's nice to understand how things work and also why they don't work.
The thing is... the time on my Pi-star dashboard is wrong.

I use DMR only (Brandmeister), time and date are correct on my router and windows 11 PC. DMR communications are working perfectly fine. I use a single slot hotspot Raspberry Pi zero W + MMDVM board and I've noticed that when I connect using internet from my cellphone, time syncs just fine. Also, when I replace my router with a very old and outdated D-link DIR-628 that I have here, again, time and date syncs right away. Well...then my actual router (TP-Link Archer C7 Ver. 4) is the problem. So I decided to replace the stock firmware on my C7 to OpenWRT. Problem persists. Installed DD-wrt instead and nothing. If time syncs correctly at 10:00 for example and I shut it down for two days, when I turn it back on, time and date starts from two days ago.
My knowledge in networking is limited and that's why I come here to seek help. What is so particular to my router that prevents Pi-star from synchronizing time and date?
And again... it's a small detail and is not affecting my operation...I could also buy a new router, yes. But why?
If someone here could help me understand the issue, I would really appreciate it!

73s

[KN2TOD]

Raspberry Pi's do not have a native, onboard clock (RTC) that maintains the time/date between power outages. It "fakes" the clock by saving the current time/date values when powered off and restoring them when you come back up. It's the job of the operating system (not Pi-Star) to resync the clock/date when powering up but that can only happen when a (successful) connection is made to an external clock (i.e. the internet). This process is not instantaneous and usually takes more time than most like.

From what you describe, it sounds like you have a firewall issue: most likely port 123 used by the NTP task is being blocked.

For starters, issue this command:

Code: Select all

$: ntpq -p

You should see something like this:

Code: Select all

     remote                                   refid      st t when poll reach   delay   offset   jitter
=======================================================================================================
 0.debian.pool.ntp.org                   .POOL.          16 p    -   64    0   0.0000   0.0000   0.0019
 1.debian.pool.ntp.org                   .POOL.          16 p    -   64    0   0.0000   0.0000   0.0019
 2.debian.pool.ntp.org                   .POOL.          16 p    -   64    0   0.0000   0.0000   0.0019
 3.debian.pool.ntp.org                   .POOL.          16 p    -   64    0   0.0000   0.0000   0.0019
-time.cloudflare.com                     10.252.8.13      3 u  554 1024  377  10.4433  -0.4870   0.8174
*shaka.ruselabs.com                      89.154.213.243   2 u   86 1024  377  21.8479   0.0093   1.0725
-hc-007-ntp1.weber.edu                   .PPS.            1 u  496 1024  377  55.7635   0.1947   1.0961
+ns1.iu13.org                            47.187.174.51    2 u  142 1024  377  29.2512   0.0222   1.0074
+108.61.73.243                           129.6.15.28      2 u  545 1024  377  27.6522  -0.1680   0.3198
-155.248.196.28                          84.168.88.243    2 u  132 1024  377  57.8347  -0.5558   0.2897

If you only see four lines, then the NTP client is not making it's connection on the required port.

This could be a router problem (port 123 not configured properly) OR it could be an ISP problem (port 123 is being blocked by your ISP).

But, first, what results do you get for the command above?

[PU1JLA]

Yeah...I guess I have a router config issue not ISP because when I use a very old D-Link router that I have here, time syncs ok.
I'll take a look on my router config and see about port 123.



remote refid st t when poll reach delay offset jitter
==============================================================================
0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002
1.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002
2.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002
3.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002

[KN2TOD]

Possible but doubtful. Does your external IP address change when you change routers? Do the external DNS server IP addresses change when you switch routers? Did your ISP assign/suggest those DNS addresses? Can you change them to something else (i.e. will your ISP let you do that)?

But first, try this: get the MAC address for you PI system and add it to your router tables, assigning a fixed internal IP address in the process. (Pick something different than what it is currently assigned.) Then reboot the Pi and see if you have the same problem.

[PU1JLA]

Bingo! I already had my hotspot set static at 192.168.1.188. All I did was change it to 192.168.1.189. Time and date now syncs flawlessly.
Thank you so much KN2TOD for your help!

73s

Code: Select all

0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002       
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002       
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002       
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002       
-sa-north-1.clea 68.47.202.140    2 u   48   64    3   32.589  -11.590   2.162       
-time.cloudflare 10.216.9.198     3 u   19   64    7   18.916  -12.460   3.193       
-Time100.Stupi.S .PPS.            1 u   51   64    1  217.360   -0.085   2.646       
+lrtest2.ntp.ifs 143.107.229.212  2 u   49   64    3   37.118  -13.856   0.936       
+c.ntp.br        200.160.7.186    2 u   19   64    7   37.758  -17.591   4.200       
*lrtest1.ntp.ifs .LRTE.           1 u   18   64    7   42.213  -14.907   3.374       
-ec2-52-67-171-2 23.254.215.107   3 u   21   64    7   26.639  -18.603   2.866       

[KN2TOD]

Thank you for confirming my suspicions/conjectures here!

But as a warning, changing the IP address isn't a permanent fix: your hotspot may "de-sync" down the road (and may go unnoticed if it happens while you're running), so you may have to repeat the "fix" again at some point.

To clarify: what's happening here, what appears to be happening, is that your ISP is, basically, embargoing port 123 on a specific IP address on your subnet because it thinks your device is up-to-no-good by its continuous net activities and thus needs to be throttled. The automated tools ISP's (and DNS services) use to monitor traffic are crude in some respects in that they can't always tell the difference between a device that's getting too excessive trying to time sync and a DOS bot or spam mailer or simply a device locked in a tight loop.

So somewhere, sometime down the road, you may find your device blocked again. So you change the IP address yet again. The blockages seem to be time-limited - they're not permanent but expire after some undisclosed period of time so you may discover a previously blocked IP address can be used again. But YMMV as they say.

[G6WOV]

In SSH Access I get

-bash: ntpq: command not found

Even if I try sudo ntpq -p I get

sudo: ntpq: command not found

But my pi-star is stuck on GMT or UTC even though my pi is on BST

So my pi-star still won't clear clear the Yellow from DMR even after changing my BM Password, and my Pi Password, and my Pi-star Password.

Can I extract some log file to show you, and if so how?

[KN2TOD]

You did not indicate which version of Pi-Star image you're running here and what hardware it's running on. It looks like you've got several problems going on here.

But my pi-star is stuck on GMT or UTC even though my pi is on BST

For starters, let's see what time zone your system thinks it in:

Code: Select all

sudo systemctl

Code: Select all

echo $(date -d "UTC $(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d" " -f5-8)" "+%d %b %Y %T") - $(date "+%d %b %Y %T")

If the time zone is not correct, you'll need to fix that via the configuration selection off the main dashboard.

You can temporarily force the time to sync to the internet if the time zone looks correct:

Code: Select all

sudo date --set="UTC $(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d" " -f5-8)"

So my pi-star still won't clear clear the Yellow from DMR even after changing my BM Password, and my Pi Password, and my Pi-star Password.

Your Pi and Pi-Star passwords do not effect the DMR startup; changing them does nothing.

Check, double check some basic configuration settings:

Under Control Software, you picked the correct software (MMDVMHOST) and the correct mode (simple or duplex)?

Under MMDVMHost Configuration, check that DMR mode is enabled.

Under General Configuration, check: callsign, DMR id, RX/TX frequencies.

Under DMR Configuration, check for a valid Master and Hotspot security code.