No issues IPV6, Major issues IPV4

Server operators
1

Forgive me but I am pretty new with all this. I am trying to set up a server using a pi and a GPS receiver. Everything appears to be OK with the IPV6 side and was easy to set up, but when I tried to setup IPV4 I cannot get it to work correctly. I have constantly negative score. IPV4 is setup using noip and the port 123 was fowarded in my router to 192.168.1.101. This is not my pi address, but it was the only way I could get it unblocked, I just followed the other rules in the router. I would not unblock using the pi address. If I can’t get this sorted out I will just not be using IPV4.

IPV4 - pool.ntp.org: Statistics for 108.35.166.21
IPV6 -pool.ntp.org: Statistics for 2600:4040:a1df:6400:8720:68fd:64d8:6af7

2

Are you sure your IPv4 is setup and working correctly? I get “no route to host” with telnet and “Destination Host Unreachable” when trying to ping -4 your address.

3

Welcome to the forum, @Macintoshdan!

NTP seems reachable fine, at least something is responding. Most of the time anyway.

But the time is off. When the offset exceeds a certain threshold, the score increase steps get smaller, become zero at 250ms offset, and then dip below zero (negative values, i.e., score decrease), with a maximum of two points subtracted eventually (or four, if the offset exceeds 3 seconds).

The graph pretty much shows it already, but looking at the numbers for one monitor as example, it is clear that the offset is somewhat outside the comfort zone of the scoring algorithm.

ts_epoch,ts,offset,step,score,monitor_id,monitor_name,leap,error
1749929016,2025-06-14 19:23:36,-0.899312969,-2,-28.857841492,69,usiad1-3grrbhg,,
1749928149,2025-06-14 19:09:09,-0.880236955,-2,-28.271411896,69,usiad1-3grrbhg,,
1749927336,2025-06-14 18:55:36,-0.862823873,-2,-27.654119492,69,usiad1-3grrbhg,,
1749926584,2025-06-14 18:43:04,-0.844263023,-2,-27.004335403,69,usiad1-3grrbhg,,

Compare that with the values seen for the IPv6 side of the server.

ts_epoch,ts,offset,step,score,monitor_id,monitor_name,leap,error
1749929219,2025-06-14 19:26:59,0.000492325,1,19.999847412,68,usiad2-3grrbhg,,
1749928623,2025-06-14 19:17:03,-0.000179601,1,19.999839783,68,usiad2-3grrbhg,,
1749927949,2025-06-14 19:05:49,-0.000646865,1,19.999832153,68,usiad2-3grrbhg,,
1749927262,2025-06-14 18:54:22,0.000176273,1,19.999822617,68,usiad2-3grrbhg,,

Are you sure the IPv4 traffic really reaches the same server as the IPv6 traffic? At least Miroslav’s NTP dedup tool doesn’t seem to think so, so maybe something else is responding to IPv4 requests, e.g., perhaps the router itself?

pi@RPi:~ $ ./ntpdedup.py -i 4 -w 10 -v 108.35.166.21 2600:4040:a1df:6400:8720:68fd:64d8:6af7
Iteration 1: responded 2/2 servers
Iteration 2: responded 2/2 servers
Iteration 3: responded 2/2 servers
Iteration 4: responded 2/2 servers
Duplicates:
Statistics:
  IPv4 servers                1
    with IPv4 duplicates      0 (0.0%)
    with IPv6 duplicates      0 (0.0%)
  IPv6 servers                1
    with IPv4 duplicates      0 (0.0%)
    with IPv6 duplicates      0 (0.0%)
  Unique servers              2

I don’t fully understand the setup you have, but when you write

that seems to hint at it not being your RPi that is responding as well.

4

I think I have limited down the issue to the port forwarding not working correctly. I think that you are right, the 192.128.1.101 is a different device on my network (probably router), and when it forwarded to that it was connecting to a different server. For the life of me I cannot get it to forward to the Pi. It might be an issue with the router port forwarding itself, I am not sure. I don’t see any indication that the pi is blocking the port. I am throwing in the towel for now, I cannot spent any more time on this. Maybe one day I will be able to sort it out (if anyone is familiar with port forwarding on a FiOS CR1000A). Thank you for the help.

5

You could use something like the following on the RPi to double-check (after re-enabling whatever port forwarding setting you had before):

sudo tcpdump -p ip and udp port ntp

Regardless of whether the RPi is blocking the traffic via local firewall or not, this would show whether any NTP packets reach your device. (tcpdump grabs the packets before they reach a place where they could be blocked on the device side.) That would be the first thing I’d check, to see whether the issue is on the RPi, or with something in the network in front of it. This should show some packets after a few minutes.

Hmm, I am not familiar with that particular device, but from the manual available online, it looks like it follows a common pattern for this sort of thing (section 5.0e). But wouldn’t be the first time that a device doesn’t behave exactly as described…

From your descriptions, I gather that the IP address configured in the port forwarding rule might not be the proper one. You can use ip a or ifconfig on the RPi to see its addresses. Hopefully, the IPv4 address determined that way appears in the drop-down menu of the port forwarding rule as well.

Anyway, I fully understand when you don’t have the time or the nerve to investigate further at this time. Just reach out in this forum again, and people can assist with further troubleshooting steps.

6

The IPv4 and IPv6 addresses are different systems.

The IPv4 system is consistently stratum 2. Whatever the device is, it doesn’t really implement NTP.
Root delay is fixed at zero (this is wrong), Offset is high and variable, etc.

The IPv6 system is often stratum 1, but sometimes drops to stratum 2.
My guess is when the reference ID is GPS, the server is sync’d to NMEA.
When the reference ID is kPPS, it is using PPS.
100% of my test client’s IPV6 NTP requests got responses.
Basic NTP functionality looks ok.

7

The device it was connecting to was my set top box (192.168.1.101), it was not connecting to the pi. I pretty much have it limited down to the fact that the router refuses to forward the ports to the pi. I don’t see any way I can resolve it.

8

…or the other way round. At least the description in the manual might be confusing when it says configure its inbound and outbound port numbers: The “outbound” port number should not be relevant for port forwarding.

Rather, it is often possible to use a different port number on the internal device than what is exposed externally, I guess that might be what they are referring to. At least the figure in that section shows this properly, i.e., referring to “Original port” and “Fwd to port”. Unless you have explicitly configured a port other than 123 on the RPi (e.g., chronyd allows that), those numbers should both be 123.

9

Im using NTP and didn’t change any settings, I have the port forwarding set to 123 UDP to the pi IP IPV4 address to port 123. I also created a port fowarding rule UDP 123 to 123 for good measure. Neither appear to work as of now. I don’t understand why forwarding worked to the set top box but won’t work to the pi.

10

cpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:21:29.832269 IP 198.199.75.250.31003 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:21:30.133291 IP 157.245.102.2.10001 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:21:46.519492 IP koala.miuku.net.49539 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:21:51.521580 IP koala.miuku.net.47036 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:21:56.523644 IP koala.miuku.net.45408 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:22:01.524715 IP koala.miuku.net.35789 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:22:22.470014 IP 104-182-38-68.lightspeed.sntcca.sbcglobal.net.19202 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:22:50.594398 IP ntpcgn1.ntppool.net.43361 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:22:55.589450 IP ntpcgn1.ntppool.net.58132 > 192.168.1.249.ntp: NTPv4, Client, length 48
18:23:00.595522 IP ntpcgn1.ntppool.net.35835 > 192.168.1.249.ntp: NTPv4, Client, length 48
^C
10 packets captured
11 packets received by filter
0 packets dropped by kernel

Looks like there is traffic of some sort.

11

Ive made major progress, looks like something went awry when trying to set static IP when I first set up pi… I noticed I couldn’t connect to download noip client (Was going to give it a shot over using router). Did ping tests and had no connection to multiple sites. I cleared that out and now everything appears to be working OK. I am getting I/O timeouts on ipv4 though but the score is quickly rising out of the negative. I also can’t verify server but I guess thats because there are duplicates.

1 Like
12

Short questions: Do you have a symetric or asymetric connection ? And is your external IP fixed or will it change in future ?

13

My connection is 1 gig up and down. It shouldn’t change, I still need to iron that out. Ipv4 won’t change, I need to figure out how to get ipv6 static.

14

No worries… Just wanted to know if sym ot asym :slight_smile: