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*/**