W32Time Server: Rx timestamp not returned

Anonymous
2024-05-08T19:43:21+00:00

Windows Specifications:

Edition Windows 10 Enterprise LTSC 2019
Version 1809
Installed on 09/15/2018
OS build 17763.107

Device Specifications:

Processor Intel(R) Atom(TM) Processor E3930 @ 1.30GHz
Installed RAM 8.00 GB
System type 64 - bit operating system, x64-based processor

I am experiencing an issue with the Windows Time Service on Windows 10 Enterprise LTSC 2019.

We are trying to leverage w32tm as a NTP client as well as a server.

The client half of the w32tm service syncs successfully to the remote IP address we specify in the Windows registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Parameters\NtpServer

However, the server half never appears to respond to external clients connected on the same LAN subnet.

I've enabled w32time logging at 0-300 verbosity on the server which reveals the following information when a client sends an NTP packet to the server address.

In this case, client 10.101.5.77 is trying to sync time to the server at 10.101.5.15. The error that jumps out at me is the 'Rx timestamp not returned and may be unsupported on the current network interface.' error.

154625 17:34:44.2444745s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123)

154625 17:34:44.2446267s - HA Pkt Rcv: delay:0 DestTimeStamp:133596632842446147

154625 17:34:44.2446597s - Rx timestamp not returned and may be unsupported on the current network interface.

154625 17:34:44.2446903s - ListeningThread -- response heard from 10.101.5.77:56104 <- 10.101.5.15:123

154625 17:34:44.2447424s - /-- NTP Packet:

154625 17:34:44.2447518s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B

154625 17:34:44.2447632s - | Stratum: 14 - secondary reference (syncd by (S)NTP)

154625 17:34:44.2447710s - | Poll Interval: 1 - out of valid range; Precision: 0 - out of valid range

154625 17:34:44.2447819s - | RootDelay: 0x0000.0000s - unspecified; RootDispersion: 0x0000.0000s - unspecified

154625 17:34:44.2448068s - | ReferenceClockIdentifier: 0x4C4F434C - source IP: 76.79.67.76

154625 17:34:44.2448199s - | ReferenceTimestamp: 0xE9E63632E1893647 - 13359663282880999900ns - 154625 17:34:42.8809999s

154625 17:34:44.2448389s - | OriginateTimestamp: 0x0000000000000000 - unspecified

154625 17:34:44.2448532s - | ReceiveTimestamp: 0x0000000000000000 - unspecified

154625 17:34:44.2448682s - | TransmitTimestamp: 0xE9E63632E1893647 - 13359663282880999900ns - 154625 17:34:42.8809999s

154625 17:34:44.2448894s - >-- Non-packet info:

154625 17:34:44.2448998s - | DestinationTimestamp: 154625 17:34:44.2449087s - 0xE9E636343E9F11A8154625 17:34:44.2449169s - - 13359663284244614700ns154625 17:34:44.2449261s - - 154625 17:34:44.2446147s

154625 17:34:44.2449379s - | RoundtripDelay: 1363614800ns (1s)

154625 17:34:44.2449540s - | LocalClockOffset: -681807400ns - 0:00.681807400s

154625 17:34:44.2449754s - --

154625 17:34:44.2450427s - TransmitResponse: sent 0.0.0.0:123()->10.101.5.77:56104

What I've Tried:

Installing SoftwareTimestamping as described in the SoftwareTimestamping guide for network interfaces in the Microsoft Github. I've followed the steps and verified that SoftwareTimestamping is successfully installed using the verification steps mentioned in that guide. I do not know if this is even required and only installed it because it's one of the few areas online that I was able to find information regarding the error message mentioned above. After installing SoftwareTimestamping and applying it to both network interface cards on my machine, the time service still throws the same exception and no behavioral change of any kind is observed.

I've also installed NTPTool and placed it on the server machine. I enter the localhost IP address as the server and click 'Query'. Using this tool to test the NTP server from the localhost yields the same result and the 'tx' error is still thrown and response is never recieved. Because of this, I am suspicious of a w32time service/configuration issue rather than a networking issue.

There is NO firewall enabled whatsoever on either the client PC or server PC. That is, it's completely disabled on both ends.

It's also notable that the route table is fine on the server PC so it is definitely not a packet return route issue. This is further evidenced by the fact that the NTPTool test tool does not work when run from the server localhost either.

Running the same configuration shown below on Windows 7 and Windows 10 Pro works without any issue.

What could be the problem here?

W32TM Service Configuration:

[Configuration]

EventLogFlags: 2 (Local)

AnnounceFlags: 5 (Local)

TimeJumpAuditOffset: 28800 (Local)

MinPollInterval: 10 (Local)

MaxPollInterval: 15 (Local)

MaxNegPhaseCorrection: 54000 (Local)

MaxPosPhaseCorrection: 54000 (Local)

MaxAllowedPhaseOffset: 1 (Local)

FrequencyCorrectRate: 4 (Local)

PollAdjustFactor: 5 (Local)

LargePhaseOffset: 50000000 (Local)

SpikeWatchPeriod: 900 (Local)

LocalClockDispersion: 10 (Local)

HoldPeriod: 5 (Local)

PhaseCorrectRate: 1 (Local)

UpdateInterval: 360000 (Local)

[TimeProviders]

NtpClient (Local)

DllName: C:\Windows\SYSTEM32\w32time.DLL (Local)

Enabled: 1 (Local)

InputProvider: 1 (Local)

AllowNonstandardModeCombinations: 1 (Local)

ResolvePeerBackoffMinutes: 15 (Local)

ResolvePeerBackoffMaxTimes: 7 (Local)

CompatibilityFlags: 2147483648 (Local)

EventLogFlags: 1 (Local)

LargeSampleSkew: 3 (Local)

SpecialPollInterval: 32768 (Local)

Type: NTP (Local)

NtpServer: 160.212.6.75 (Local)

NtpServer (Local)

DllName: C:\Windows\SYSTEM32\w32time.DLL (Local)

Enabled: 1 (Local)

InputProvider: 0 (Local)

AllowNonstandardModeCombinations: 1 (Local)

***moved from Windows / Windows 10 / Performance and system failures*/**

Windows for business | Windows Client for IT Pros | User experience | Remote desktop services and terminal services

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

0 comments No comments
{count} votes
Accepted answer
  1. Anonymous
    2024-05-09T19:34:37+00:00

    Hello,

    Here are a few additional suggestions you might consider:

    1. Verify that the Windows Time service is actually running on the server. You can check this by running services.msc and looking for the 'Windows Time' service.
    2. Run w32tm /query /configuration to check the current time service configuration and w32tm /query /status to check the service status. This may yield helpful clues.
    3. Check the NIC specifications to ensure that they support the required timestamping feature. You may also want to try configuring the w32time service to use a different NTP server to see if the issue persists. Additionally, you can try resetting the w32time service to its default settings and reconfiguring it from scratch.
    4. Run the System File Checker tool can identify and fix any corrupted system files that may be causing the issue. Use the sfc /scannow command in an elevated Command Prompt.
    5. Check the Event Viewer logs, specifically the Windows Logs > System, for any related error messages or warnings that could give more information about the issue.
    6. Ensure that the system is fully updated, as there might be a patch or update available that addresses this issue which you haven't received yet.

    References: Windows Time service tools and settings | Microsoft Learn

    I hope this helps.

    Best regards

    0 comments No comments
Accepted answer
  1. Anonymous
    2024-05-09T17:36:45+00:00

    Update:

    After installing the latest Windows Updates to update KB5036896 the time service server began operating as expected.

    Comparing file sizes from before/after the update it's clear that some updates to the service have been made so my assumption is that some issue was addressed in the update.

    It is notable that the 'Rx timestamp not returned and may be unsupported on the current network interface.' exception is still thrown in the w32tm log file even though the server is now responding to NTP sync requests from external clients successfully.

    Prior to update:

    Post update to KB5036896:

    The only notable difference in the log output is the population of the NTP server IP address in the final log file line when a NTP client request is received at the server:

    154626 17:20:56.3941084s - TransmitResponse: sent 0.0.0.0:123(10.101.5.15:123)->10.101.5.77:123

    The IP address in this log message was blank prior to the Windows update.

    Regards

    0 comments No comments

0 additional answers

Sort by: Most helpful