JakeHenry
commented
4 months ago Disappointed to see no response to this issue. I'm experiencing the same problem with the 'Rx timestamp not returned and may be unsupported on the current network interface.' error and there's virtually no information on the web about it. I ran through the validation guide for this and I still get the error. My NTP server refuses to respond to clients.
Windows 10 Enterprise LTSC 2019
[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)
FileLogName: d:\w32timelog.txt (Local)
FileLogEntries: 0-300 (Local)
FileLogSize: 10000000 (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)154625 16:45:20.3486845s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123)
154625 16:45:20.3488256s - HA Pkt Rcv: delay:0 DestTimeStamp:133596603203488143
154625 16:45:20.3488562s - Rx timestamp not returned and may be unsupported on the current network interface.
154625 16:45:20.3488853s - ListeningThread -- response heard from 10.101.5.77:123 <- 10.101.5.15:123
154625 16:45:20.3489460s - /-- NTP Packet:
154625 16:45:20.3489574s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B
154625 16:45:20.3489687s - | Stratum: 1 - primary reference (syncd by radio clock)
154625 16:45:20.3489765s - | Poll Interval: 10 - 1024s; Precision: -23 - 119.209ns per tick
154625 16:45:20.3489968s - | RootDelay: 0x0000.0000s - unspecified; RootDispersion: 0x000A.0000s - 10s
154625 16:45:20.3490156s - | ReferenceClockIdentifier: 0x4C4F434C - source name: "LOCL"
154625 16:45:20.3490284s - | ReferenceTimestamp: 0xE9E62A9DEF5682C3 - 13359660317934913800ns - 154625 16:45:17.9349138s
154625 16:45:20.3490474s - | OriginateTimestamp: 0x0000000000000000 - unspecified
154625 16:45:20.3490614s - | ReceiveTimestamp: 0x0000000000000000 - unspecified
154625 16:45:20.3490762s - | TransmitTimestamp: 0xE9E62A9F038FEEF5 - 13359660319013915000ns - 154625 16:45:19.0139150s
154625 16:45:20.3490972s - >-- Non-packet info:
154625 16:45:20.3491074s - | DestinationTimestamp: 154625 16:45:20.3491161s - 0xE9E62AA0594BE4DA154625 16:45:20.3491241s - - 13359660320348814300ns154625 16:45:20.3491332s - - 154625 16:45:20.3488143s
154625 16:45:20.3491448s - | RoundtripDelay: 1334899300ns (1s)
154625 16:45:20.3491607s - | LocalClockOffset: -667449600ns - 0:00.667449600s
154625 16:45:20.3491835s - \--
154625 16:45:20.3492530s - TransmitResponse: sent 0.0.0.0:123()->10.101.5.77:123
As the „Validation Guide - Software Timestamping.docx” mentions that the supported OS-es are Windows Server 2019 and Windows 10 (v1809) or later. But this is not actually accurate.
As @Donis- mentioned in #8 this phenomenon may have some similarities to his/her issue.
I’ve done some testing in our lab, and it shows the following:
Windows Server 2019 Standard or Datacenter can enable this feature (Enable-SWTimestamping -NetAdapterName '[Name of the Ethernet connection]') as per in the forementioned document. Regardless it is a physical or a virtualized computer.
On the other side, desktop versions like Windows 10 Enterprise/Pro for Workstations or 11 Enterprise are capable of enabling this feature only if they are in a virtualized environment.
I’ve done everything word-by-word as in the Validation Guide. But for some reason the desktop physical clients always show this log entry:
“Rx timestamp not returned and may be unsupported on the current network interface.”
On this same machine I’ve installed Windows Server 2019 Standard and after that Datacenter with clean installs each time, I can see something like this in the log file:
“HA ESD:1 ASD:0 ETD:236 ATD:953 (FT units)”
So here are the steps to reproduce this:
There are the computers, and their roles:
DC.contoso.com Windows Server 2019 Standard VM on Hyper-V DC2.contoso.com Windows Server 2019 Standard VM on Hyper-V DC4.contoso.com Windows Server 2019 Datacenter physical machine, PDC role DC5.contoso.com Windows Server 2019 Datacenter physical machine HV1.contoso.com Windows Server 2016 Datacenter, physical machine, Hyper-V role Runs DC.contoso.com and DC2.contoso.com VMs HV2.contoso.com Windows Server 2016 Standard, physical machine, Hyper-V role Runs vm001.contoso.com Windows 10 Enterprise and vm002.contoso.com Windows 10 Pro for Workstations desktop001.contoso.com Windows 10 Enterprise, physical machine,runs VMWare Workstation 16 Pro runs vm003.contoso.com Windows 11 Enterprise Insider Preview, VM runs srv001.contoso.com Windows Server 2022 Datacenter, VM [desktop002].contoso.com this physical machine was the test bench. With all clean installation of OS-es I added different names to the computer, SRV02, 03, DESKTOP010, 011 respectively.
I’ve installed Windows Server 2019 Standard and Windows Server 2019 Datacenter and configured timestamping. It works.
Then I’ve installed Windows 10 Enterprise and Windows 10 Pro for Workstations and configured timestamping. It didn’t work for neither.
Even further on desktop001 on the host Windows 10 Enterprise, timestamping didn’t work. But on the VMs running inside VMware it works.
On the Domain Controllers, regardless it is VM or physical, it works.
I’ve also tried on two different desktops in the domain, running Windows 10 Enterprise, it didn’t work.
So, my conclusion is that Windows desktop OS-es only supports timestamping, when they run in some kind of virtualization environment.
But why?
Can someone please point to the right direction, to make it work on physical desktop OS-es.
Update: Added the log files from same hardware, different OS.
w32tm_working_Server_2019.log
w32tm_not_working_windows_10.log