StarLink as source for NTP

davehart

@Mission-Ghost said in StarLink as source for NTP:

@davehart do you still need the debug log? I’ll produce it later today if so.

No need, I wouldn't spend time on it. I would like to confirm that it's ntpd 4.2.8p18, and get the output of uname -a

I can crank out a fixed x64 binary with that info and post it.

stephenw10

In CE 2.8.1:

[2.8.1-RELEASE][admin@t70.stevew.lan]/root: pkg info ntp
ntp-4.2.8p18_5
Name           : ntp
Version        : 4.2.8p18_5
Installed on   : Thu May 22 14:10:43 2025 BST
Origin         : net/ntp
Architecture   : FreeBSD:15:amd64
Prefix         : /usr/local
Categories     : net
Licenses       : 
Maintainer     : cy@FreeBSD.org
WWW            : https://www.ntp.org/
Comment        : The Network Time Protocol Distribution
Options        :
	ACTS           : on
	ARBITER        : on
	ARCRON_MSF     : on
	AS2201         : on
	ATOM           : on
	AUDIO_CHU      : off
	BANCOMM        : off
	CHRONOLOG      : on
	CHU            : on
	COMPUTIME      : off
	DATUM          : on
	DCF7000        : off
	DEBUG          : off
	DOCS           : off
	DUMBCLOCK      : on
	EXAMPLES       : off
	FG             : on
	GPSVME         : off
	HEATH          : on
	HOPF6021       : off
	HOPFPCI        : on
	HOPFSERIAL     : on
	HPGPS          : on
	IPV6           : on
	IRIG           : on
	JJY            : on
	JUPITER        : on
	LEITCH         : on
	LOCAL_CLOCK    : on
	MD5            : off
	MEINBERG       : off
	MX4200         : off
	NEOCLOCK4X     : on
	NLS            : on
	NMEA           : on
	NTPSNMPD       : off
	NTP_SIGND      : off
	ONCORE         : on
	PALISADE       : on
	PCF            : on
	PERL_UTILS     : off
	PST            : on
	RAWDCF         : off
	RCC8000        : off
	RIPENCC        : off
	SCHMID         : off
	SEL240X        : off
	SHM            : on
	SPECTRACOM     : on
	SSL            : on
	THREADS        : on
	TRIMTAIP       : off
	TRIMTSIP       : off
	TRUETIME       : on
	ULINK          : on
	VARITEXT       : off
	WHARTON        : off
	WWV            : on
	ZYFER          : on
Shared Libs required:
	libintl.so.8
	libevent_pthreads-2.1.so.7
	libevent_core-2.1.so.7
	libedit.so.0
Annotations    :
	FreeBSD_version: 1500029
	build_timestamp: 2025-05-22T00:17:18+00:00
	built_by       : poudriere-git-3.4.99.20250209
	cpe            : cpe:2.3:a:ntp:ntp:4.2.8p18:::::freebsd15:x64:5
	port_checkout_unclean: no
	port_git_hash  : bc3cd471ba72
	ports_top_checkout_unclean: no
	ports_top_git_hash: 87aee0bc23aa
	repo_type      : binary
	repository     : pfSense
Flat size      : 1.71MiB
Description    :
The Network Time Protocol (NTP) is used to synchronize the time of a
computer client or server to another server or reference time source,
such as a radio or satellite receiver or modem.

It provides client accuracies typically within a millisecond on LANs
and up to a few tens of milliseconds on WANs relative to a primary
server synchronized to Coordinated Universal Time (UTC) via a Global
Positioning Service (GPS) receiver, for example.

Typical NTP configurations utilize multiple redundant servers and diverse
network paths, in order to achieve high accuracy and reliability.

Some configurations include cryptographic authentication to prevent
accidental or malicious protocol attacks.

[2.8.1-RELEASE][admin@t70.stevew.lan]/root: uname -a
FreeBSD t70.stevew.lan 15.0-CURRENT FreeBSD 15.0-CURRENT #21 RELENG_2_8_1-n256095-47c932dcc0e9: Thu Aug 28 16:27:48 UTC 2025     root@pfsense-build-release-amd64-1.eng.atx.netgate.com:/var/jenkins/workspace/pfSense-CE-snapshots-2_8_1-main/obj/amd64/AupY3aTL/var/jenkins/workspace/pfSense-CE-snapshots-2_8_1-main/sources/FreeBSD-src-RELENG_2_8_1/amd64.amd64/sys/pfSense amd64

stephenw10

We are looking at building a package with that patch. That will probably be for 26.03-dev though.

cmcdonald

I have Starlink:

Before patch:

After patch:

Another question here for @davehart , should I advocate for including this patch in the upstream FreeBSD port (net/ntp) ? I can make that happen if that is the direction we want to take.

stephenw10

Nice! Looks like some tweaks to the data/parsing required too.

davehart

@cmcdonald said in StarLink as source for NTP:

should I advocate for including this patch in the upstream FreeBSD port (net/ntp) ?

Thanks for verifying that resolves the problem. I'm sure there are many others using pfSense who will benefit.

I have no objection to FreeBSD picking up any of the many pending ntp patches while we wait for NTF/ntp.org to get another release out. It's their call if it's worth their time and safe enough.

cmcdonald

@stephenw10 said in StarLink as source for NTP:

Nice! Looks like some tweaks to the data/parsing required too.

/usr/local/sbin/ntpq -pnw
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.100.1                    1 u   57   64  377    0.546   +0.120   7.203

refid is empty now

tinfoilmatt

You mean it's just not being parsed?

cmcdonald

@tinfoilmatt said in StarLink as source for NTP:

You mean it's just not being parsed?

pfSense expects refid to not be empty, so it ends up shifting all other columns over.

Is there ever a legit condition where refid is indeed empty?

I'm not sure.

tinfoilmatt

Is there ever a legit condition where refid is indeed empty?

No idea. Your comment piqued my curiosity only because this post seems to demonstrate that the StarLink NTP implementation does, in fact, reply with an REFID of ".XFAC."?

Can't read myself since the network I'm on at the moment has the domain www.ntp.org blocked ()—but the search engine description of whatever this page contains regarding REFID seems relevant:

https://www.ntp.org/documentation/ietf/ntp-refid-updates/

davehart

@cmcdonald said in StarLink as source for NTP:

pfSense expects refid to not be empty, so it ends up shifting all other columns over.

Is there ever a legit condition where refid is indeed empty?

ntpd displays text refids bracketed by periods. It seems reasonable to do that for refids with only unprintable/invisible characters. Stratum 1 sources have text refids like .GPS.

Feel free to file a bug report at https://bugs.ntp.org/

davehart

@tinfoilmatt said in StarLink as source for NTP:

Your comment piqued my curiosity only because this post seems to demonstrate that the StarLink NTP implementation does, in fact, reply with an REFID of ".XFAC."?

That's actually generated by the client ntpd to indicate the local address/interface changed for the source since the last response was received. It happens as all prior results for that peer are flushed.

stephenw10

@davehart said in StarLink as source for NTP:

It seems reasonable to do that for refids with only unprintable/invisible characters.

You mean it could be expected to return .. if it doesn't have a printable ID value?

davehart

@stephenw10 said in StarLink as source for NTP:

@davehart said in StarLink as source for NTP:

It seems reasonable to do that for refids with only unprintable/invisible characters.

You mean it could be expected to return .. if it doesn't have a printable ID value?

Exactly. I'd like to be scolding that instead of screen-scraping the peers billboard the web UI should be using a parsing-friendly version (which ntpq calls raw), but in fact there's no raw form of the billboards. It can be done with multiple raw queries to get the list of associations and query the raw peer variables for each association, though, which is what the billboard code in ntpq is doing. Given that lots of folks have resorted to scraping it, making sure there's something in the refid field seems wise.

davehart

@davehart said in StarLink as source for NTP:

I can crank out a fixed x64 binary with that info and post it.

https://www.davehart.net/ntp/test/ntp-stable-dlh-260328.tar.gz is a private test release of mine which includes the bug 3877 fix for rejecting responses with a zero ppoll in the packet.

The issue with the empty refid is a display issue in ntpq. That has not yet been fixed. So this will allow the Starlink to be used as a NTP source, but the column-shifting may still appear.

davehart

@davehart said in StarLink as source for NTP:

@cmcdonald said in StarLink as source for NTP:

pfSense expects refid to not be empty, so it ends up shifting all other columns over.

Is there ever a legit condition where refid is indeed empty?

ntpd displays text refids bracketed by periods. It seems reasonable to do that for refids with only unprintable/invisible characters. Stratum 1 sources have text refids like .GPS.

Feel free to file a bug report at https://bugs.ntp.org/

It's actually ntpq which brackets text refids with periods. Refids are always 32 bits, either up to 4 characters or a dotted-quad a la IPv4. However, an empty refid is displayed as an empty string. To give screen-scrapers a better chance, ".." would be preferable.

I've filed https://bugs.ntp.org/4019 to track that change. For those interested, there are two lines in doprintpeers under the line:

	} else if (!strcmp("refid", name)) {

to update from:

				dstadr_refid = "";

to:

				dstadr_refid = "..";

Ramosel

@davehart Thanks for keep us current on this.

Rick

dennypage

For those of you interested, I've created a Chrony package for pfSense.

me21

This post is deleted!

me21

The NTPd behaviour seems to be caused by this bug and seems to be included in a future version:
https://bugs.ntp.org/show_bug.cgi?id=3870