Re: [Ntp] SNTP, Old crufty software

The code I looked at was in ntp_proto.c, and I remember this being an 
issue long before that code showed up in 2018.  I suspect that I just 
didn't search thoroughly enough and that "accommodating" the MS behavior 
was done much earlier, in other parts of the code.  A code overhaul 
happened in 2018 and that's when the updates made it to their current 
locations.

While I expect this usage will taper off, there are still plenty of 
folks who have ancient gear that still runs and cannot be upgraded, and 
this gear will continue to be deployed.  I know we have some 
power-related devices that still need ancient java and ancient SSL.  We 
keep this gear on protected VLANs, but it's still "there".

On 8/17/2022 9:07 AM, Greg.Dowd@microchip.com wrote:
> Thanks Harlan!  That was it.  I also think this problem significantly pre-dated Sep 2018 since we wrote some special code to handle the MS MAC format on a product that was obsolete by 2018 but all in all the # of requests is low and it hasn't melted the Internet so I assume they will fade away slowly?
> 
> Thanks..Greg
> 
> Greg Dowd  Microchip - Freq & Time Div.
> 
> Assoc. Technical Fellow – Engineering
> 3870 N First St, San Jose, CA 95134
> Direct: 408-964-7643
> Greg.Dowd@microchip.com
> 
> -----Original Message-----
> From: ntp <ntp-bounces@ietf.org> On Behalf Of Harlan Stenn
> Sent: Tuesday, August 16, 2022 6:36 PM
> To: Greg.Dowd=40microchip.com@dmarc.ietf.org; ntp@ietf.org
> Subject: Re: [Ntp] SNTP, Old crufty software
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 8/16/2022 10:51 AM, Greg.Dowd=40microchip.com@dmarc.ietf.org wrote:
>> Wasn't there an "undocumented" authentication mechanism in windows using ntp with symm active or symm passive request?  A different way of parsing the MAC?  I "think" just sending back server worked for unauthenticated but honestly, it's been so long I could be wrong.
> 
> The issue is that windows clients (I don't recall if or how authentication plays in to this) by default send a symmetric active request instead of sending a client request.  When we see this, we simply send back a MODE_PASSIVE response, without mobilizing an association.
> 
> The fix for this problem looks like it was committed on 12 Sep 2018, but for some reason I think this happened before that.
> 
> See Microsoft KB 875242 for the preferred work-around.
> 
> The "accommodation" for the broken windows clients was included in 4.2.8p13, unless it happened before that.
> 
> H
> 
>> I can say that just about every network admin I work with still uses w32time on some box to verify our ntp server functionality.
>>
>> Thanks..Greg
>>
>> Greg Dowd  Microchip - Freq & Time Div.
>>
>> Assoc. Technical Fellow - Engineering
>> 3870 N First St, San Jose, CA 95134
>> Direct: 408-964-7643
>> Greg.Dowd@microchip.com
>>
>> -----Original Message-----
>> From: ntp <ntp-bounces@ietf.org> On Behalf Of Hal Murray
>> Sent: Saturday, August 13, 2022 1:08 AM
>> To: Martin Burnicki <martin.burnicki@meinberg.de>
>> Cc: Hal Murray <halmurray@sonic.net>; ntp@ietf.org
>> Subject: Re: [Ntp] SNTP, Old crufty software
>>
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the content is safe
>>
>> martin.burnicki@meinberg.de said:
>>> I remember some years ago when Windows XP/Server 2003 was current,
>>> the dumb SNTP client (w32time) shipped with that Windows versions
>>> sent "peer" requests to the NTP server by default,
>>
>> Thanks.  Pool servers are still seeing that.  That's the tiny bump on the tail that I mentioned.  It's ballpark of 1/2% of the NTPv1 requests.
>>
>> Do you know what that version of w32time requires for the Mode in a response?
>> Will it accept Server?
>>
>> If nothing else, we need to make a list of the types of v1 requests that are being sent and the responses they need.
>>
>>> Since SNTP basically uses the same packet format as NTP, in my
>>> opinion the real S(imple) attribute refers to the way the packet
>>> exchange is evaluated at the client side.
>>
>>> I've seen implementations where the client didn't even try to
>>> compensate the network delay, and just used the server's transmission
>>> time stamp to adjust the client time. Probably because the
>>> programmers though that the resulting accuracy id "good enough".
>>
>> Right.  If all you need is within a second or two, it may not be worthwhile to do that admittedly tiny extra calculation.  It's just a couple more lines of code to maintain.
>>
>> I was thinking that we need a section on clocks and networks so people can decide how complicated they need to make their "simple" client and/or how often they need to poll.
>>
>> ------
>>
>> Speaking of cruft...  :)
>>
>> I'm seeing a few v3 and v4 packets with Broadcast Mode.  Anybody know who who/what is doing that?  Some of it looks like real traffic: 64 second polling, LOCL in the RefID, mostly 0s, looks like a time in the transmit slot.
>>
>>
>>
>> --
>> These are my opinions.  I hate spam.
>>
>>
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ntp
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ntp
>>
> 
> --
> Harlan Stenn <stenn@nwtime.org>
> http://networktimefoundation.org - be a member!
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!