ntpclient sanity checks

[Denis Vlasenko]

On Saturday 28 October 2006 21:30, ldoolitt at recycle.lbl.gov wrote:
> Friends -
> 
> Apologies if this seems semi-off-topic, but ntpclient doesn't have
> its own mailing list, and several members of this group show interest
> in it, enough that it was recently added to busybox.
> 
> I am polishing up a new release, which has a bunch more sanity checks
> on the packets it receives.  This is considered a good thing, and
> mostly brings it into conformance with the recommendations of RFC-4330.
> However, under some circumstances this is a non-compatible change relative
> to previous ntpclient versions, as I discovered trying to connect to a
> badly maintained (by me) time server.
> 
> The checks on the UDP reply packet are:
>    source port is 123
>    source address matches server we sent to

NTP is done on top of UDP, so it is fairly easy to
get multihomed server to respond from wrong IP
(it's typical problem with any UDP service).

I tried to fix it, but ntp project rejected my patch.
They come up, oh no, _promised to come up_
with alternative solution which is order of magnitude
larger code-wise and is generally insane (imho).

I stopped using NTP servers (djb's stuff is better :)

But I digress. So dropping packets from "wrong" IPs
is maybe not a good idea.

>    LI is not 3 (unsynchronized)
>    VN (version) is not less than 3
>    MODE is 4
>    orgtime matches what we sent
>    xmttime is not 0
>    delay is between -65536 and 65536
>    disp is between -65536 and 65536
>    stratum is not 0

The rest is probably good.

> My question to the group is, should these checks apply optionally (when
> selected with a new command switch), usually (unless deselected with a
> new command switch), or always?  Plus, if a bad packet is received,
> should the server stand mute, or give a warning message (and with what
> level of detail as to how the packet flunked the tests)?

Give a message. You may make it configurable:

ntpclient: dropped malformed packet[: <optionally what's wrong>]

> This next version will be a little easier to suck into busybox: I already
> put in most of the "static"s.  If y'all have any other requests, let me
> know.

Thanks!
--
vda