Bug 1683472 - chronyd 3.2 do not respond to NTP version 1 mode 0 requests
Summary: chronyd 3.2 do not respond to NTP version 1 mode 0 requests
Keywords:
Status: CLOSED DUPLICATE of bug 1636117
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: chrony
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-26 23:21 UTC by Michal Žejdl
Modified: 2019-06-20 14:19 UTC (History)
1 user (show)

Fixed In Version: chrony-3.4-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-20 14:19:18 UTC
Target Upstream Version:

Attachments (Terms of Use)
patch made by git diff (1.86 KB, patch)
2019-02-26 23:21 UTC, Michal Žejdl 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Description Michal Žejdl 2019-02-26 23:21:45 UTC 
Created attachment 1538990 [details]
patch made by git diff

After upgrading my ntp pool server from CentOS 6.10 ntpd to CentOS 7.6 chronyd I noticed that chronyd do not respond to RFC 1059 packets. There was 8.6 % NTPv1 mode 0 requests from all IPv4 NTP pakets in one 100k-packets sample (the IPv6 clients seem to use versions 3 and 4 only).


This is already fixed in the upstream:

https://git.tuxfamily.org/chrony/chrony.git/commit/ntp_core.c?id=fbca570d0b12e47f502a2e4ecc76f1a05d2c2d12


A patched version of chrony 3.2 is already running on my server and it responds to version 1 mode 0 packets with mode 4 (server). Hope the clients are satisfied with mode 4 although this behavior doesn't follow the RFC 1059. Unfortunately I have no such version 1 client to test if it cares about mode 4.


It would be nice to include this fix in current RHEL 7 chrony package.


Thanks.
Comment 2 Miroslav Lichvar 2019-02-27 08:17:28 UTC 
The chrony package will probably be rebased in RHEL7.7 to version 3.4 (bug #1636117), which should have this bug fixed.
Note You need to log in before you can comment on or make changes to this bug.