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
Incorrect time and date
Re: Incorrect time and date
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:
You should see something like this:
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?
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
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
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?
Re: Incorrect time and date
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
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
Re: Incorrect time and date
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.
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.
Re: Incorrect time and date
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
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
Re: Incorrect time and date
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.
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.
Re: Incorrect time and date
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?
-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?
Re: Incorrect time and date
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.
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:
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.
For starters, let's see what time zone your system thinks it in:But my pi-star is stuck on GMT or UTC even though my pi is on BST
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")
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)"
Your Pi and Pi-Star passwords do not effect the DMR startup; changing them does nothing.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.
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.