I'm polling the system clock on a couple dozen Windows machines ranging from Win8 to Win11. I'm using a "net time" call from a RHEL7 Linux box using net version 4.10.16. This has been running pretty smoothly for about five years now.
Every now and then the net time call will produce an error which doesn't bother me much because I just use the time from the previous call. But now there is one machine that I haven't been able to poll for a week, every time giving this error message:
Protocol negotiation failed: ERRDOS:ERRnomem
Some Internet research on this has led me to believe that the error somehow happens on the Windows side, accompanied by suggestions on how to change system settings / registry (which I won't do, see below). However, when I do the call from a RHEL8 Linux box with net version 4.13.3, the call succeeds.
Questions:
Is it possible that the two different versions of "net" use different protocol versions?
Is it possible to find out which protocol the two parties end up negotiating? Sadly even with debug cranked up to level 10, the output of both net versions looks the same.
If the protocols are indeed different, and I figure out in which way, is it possible to somehow set the protocol version that net uses (like in cifs.mount)?
The Windows boxes are controllers for industrial production machines that cost millions each and must run 24/7. I might try and restart whatever service it is that answers to "net" calls on the Windows side, but there are some restraints:
The Windows boxes cannot be synced to network time. I haven't been able to find out why.
No changes to system settings or OS updates on the Windows machines.
No rebooting of Windows machines.
I'm also reluctant to play with the "net" version on the RHEL8 box because that is also administered outside of my direct control.
