[Ntp] ntpd-rs: RefID/LI incorrectly reported for source-less stratum-1 config (root cause + patch); also a draft-ID interop note

[Pranutha Sundeep <[e-mail]>]

Hello,

I'm a PhD researcher at the University of Texas at Dallas, working on
cross-protocol time synchronization accuracy (NTPv4, NTPv5, PTP). Through
my work managing a production network, I've had the opportunity to test
this across a fleet of ~90 HPE Aruba AOS-CX switches. As part of that work
I've been running ntpd-rs as an NTPv5-capable reference source (GMR6000
grandmaster -> ptp4l/phc2sys -> ntpd-rs, source-less, local-stratum=1), and
identified and fixed a bug that seems worth sharing with the group.

*Symptom: *a correctly configured source-less ntpd-rs instance
(local-stratum=1, clock authority is phc2sys, not an upstream NTP/NTS
source) correctly reports Stratum=1 to clients, but always emits LI=3
(Unsynchronized) and RefID="XNON", regardless of the configured
reference-id. This matches upstream issue #1718.

*Root cause:* in ntp-proto/src/system.rs, NtpSnapshot::from_used_sources()
unconditionally initializes reference_id = ReferenceId::NONE, only
overwriting it if used_sources.peek() finds an active source. It never
falls back to synchronization_config.reference_id when the source list is
legitimately empty (i.e., stratum-1 with an external clock authority).
Separately, update_used_sources() overwrites the entire snapshot on every
call, clobbering any one-time fix applied at startup in NtpManager::new().
The LI bug is a related but separate path, in update_time_snapshot().

*Proposed Fix:* thread a configured_reference_id parameter into
from_used_sources(); when used_sources is empty and local_stratum == 1,
initialize reference_id from synchronization_config.reference_id instead of
ReferenceId::NONE. A parallel fix gates the LI value the same way.

*Verification: *patched, rebuilt, and confirmed at the wire level -- 8
captured NTPv4 response packets to a production AOS-CX switch all show LI=0
(NoWarning), Stratum=1, RefID='PTP ' as expected. On the switch itself, the
NTP association went from a permanent reach=0/.INIT. state to reach=7
(climbing) with REF-ID=.PTP.. -- its first successful NTP association in
this deployment. Zero regressions observed.

I'm happy to open a PR against ntpd-rs with this if useful.

And on a separate note, a smaller observation regarding draft ID
mismatch. While
testing against a real ntpd-rs NTPv5 server, I found it identifies as
"draft-ietf-ntp-ntpv5-08". A client sending a non-matching draft ID (e.g.
-09) has its packets silently dropped, with the only trace being a
TRACE-level log line ("Mismatched draft ID ignoring packet!"). From an
interop-robustness standpoint this seems worth a note somewhere (e.g. a
louder log level, or a response/rejection rather than a silent drop), since
it's easy for an operator or implementer to mistake for a network issue.

Happy to share more detail, packet captures, or the patch itself if useful.

Best,

Pranutha Malickal

PhD Researcher, Computer Engineering, University of Texas at Dallas

Network and Security Manager, Dallas Theological Seminary, Dallas