RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2047415 - Make chrony use NTP settings from DHCPv6
Summary: Make chrony use NTP settings from DHCPv6
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: chrony
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: Ondrej Mejzlik
Šárka Jana
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-27 19:20 UTC by David Haupt
Modified: 2022-11-15 12:53 UTC (History)
8 users (show)

Fixed In Version: chrony-4.2-1.el9
Doc Type: Enhancement
Doc Text:
.`chrony` now uses DHCPv6 NTP servers The NetworkManager dispatcher script for `chrony` updates the Network time protocol (NTP) sources passed from Dynamic Host Configuration Protocol (DHCP) options. Since RHEL 9.1, the script uses NTP servers provided by DHCPv6 in addition to DHCPv4. The DHCP option 56 specifies the usage of DHCPv6, the DHCP option 42 is DHCPv4-specific.
Clone Of:
Environment:
Last Closed: 2022-11-15 11:12:16 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
pcapng and explaination on howto encode dhcpv6 option 56 for dnsmasq (844 bytes, application/gzip)
2022-01-27 19:20 UTC, David Haupt 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1800901 1 medium CLOSED Make chrony use NTP settings from DHCP 2023-09-14 05:52:09 UTC
Red Hat Issue Tracker RHELPLAN-110765 0 None None None 2022-02-02 15:14:26 UTC
Red Hat Product Errata RHBA-2022:8273 0 None None None 2022-11-15 11:12:20 UTC

Description David Haupt 2022-01-27 19:20:00 UTC 
Created attachment 1857195 [details]
pcapng and explaination on howto encode dhcpv6 option 56 for dnsmasq

Created attachment 1857195 [details]
pcapng and explaination on howto encode dhcpv6 option 56 for dnsmasq

This request is basically the same as https://bugzilla.redhat.com/show_bug.cgi?id=1800901 but for IPv6

I was installing a disconnected IPv6 only cluster using the bare-metal IPI method and wanted to try see if I could get rhcos to accept ntp-server information form option 56 of DHCPv6 specified in RFC 5908, but I could not get it to work. It seemed to me like the solution to https://bugzilla.redhat.com/show_bug.cgi?id=1800901 is for IPv4 only.

I have attached a tcpdump of the DHCPv6 request/response from rhcos to my dhcpserver and it appears like rhcos is actually asking for ntp-server information, but is not applying it.

It was a bit complicated to have my dhcp server (dnsmasq) insert the ntp-server properly as I had to encode the response manually, this is the dnsmasq config line I used:
dhcp-option=openshift0,option6:ntp-server,00:03:00:25:06:64:68:61:75:70:74:05:63:6c:6f:75:64:03:6c:61:62:03:65:6e:67:03:62:6f:73:06:72:65:64:68:61:74:03:63:6f:6D:00
Some information on how to encode is available in the attachment.

ClusterID: 8069ab59-8ac3-485a-a14e-add5f5925b72
ClusterVersion: Stable at "4.9.13"
ClusterOperators:
	All healthy and stable

must-gather logs available, but they are too large to upload, let me know if I should share them with someone on gdrive.

It would be nice if getting ntp server from DHCP worked in with DHCPv6 as well as it works in IPv4.
Comment 1 Dusty Mabe 2022-01-28 23:14:08 UTC 
This looks like an RFE for upstream chrony. If I understand correctly here's the code where DHCPv4 is implemented https://git.tuxfamily.org/chrony/chrony.git/tree/examples/chrony.nm-dispatcher.dhcp

Tagging in @mlichvar to see if they have any comment.
Comment 2 Miroslav Lichvar 2022-01-31 07:49:25 UTC 
This needs to be supported in NetworkManager first. Last time I checked, it didn't support the NTP DHCPv6 option, so there was no way for the dispatcher script to get it.
Comment 3 Dusty Mabe 2022-01-31 21:32:24 UTC 
The NetworkManager team confirmed that this is not currently supported. @dhaupt can you open a feature request against the NetworkManager team for this?

We need NM support and then a Chrony dispatcher script to take advantage of it.
Comment 4 David Haupt 2022-02-01 14:11:13 UTC 
This is being worked on here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1078
(This is amazing, shout-out to Lubomir and the NetworkManager team for picking this up automatically!)

I small note on the priority, this is low priority/severity, I have no customer asking for this, it was just something I was looking into when installing an openshift cluster on my own.
Comment 5 Dusty Mabe 2022-02-01 15:30:17 UTC 
@mlichvar - considering the code recently added to NM in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1078 - would chrony be able to use this as part of an NM dispatcher once it's available?
Comment 6 Miroslav Lichvar 2022-02-02 14:37:57 UTC 
I'm not sure if I'm configuring it correctly, but it doesn't seem to work for me. I configured the DHCPv6 server to provide the NTP option. It's visible in packet capture:

    NTP Server
        Option: NTP Server (56)
        Length: 20
        Value: 0001001020010db80ca200020000000000000001
        NTP Server Address
            Suboption: NTP Server Address (1)
            Length: 16
            NTP Server Address: 2001:db8:ca2:2::1

But NetworkManager (as of dc1092e22b2) doesn't seem to accept it or make a variable for it that would be visible in the dispatcher script. The only DHCP6 variables I see are:

DHCP6_DHCP6_NAME_SERVERS
DHCP6_IP6_ADDRESS

Any hints?
Comment 7 Miroslav Lichvar 2022-02-02 14:58:35 UTC 
My bad, I wasn't actually testing the NetworkManager rpm I built. It works.

There is a DHCP6_DHCP6_NTP_SERVER variable visible in the dispatcher script. That shouldn't be difficult to support. I guess I just need to make sure that if a FQDN is provided, it doesn't contain any unexpected characters.

Please reassign this bug to the RHEL chrony component or submit a new bug.
Comment 8 Lubomir Rintel 2022-02-02 15:04:00 UTC 
(In reply to Miroslav Lichvar from comment #6)
> I'm not sure if I'm configuring it correctly, but it doesn't seem to work
> for me. I configured the DHCPv6 server to provide the NTP option. It's
> visible in packet capture:
> 
>     NTP Server
>         Option: NTP Server (56)
>         Length: 20
>         Value: 0001001020010db80ca200020000000000000001
>         NTP Server Address
>             Suboption: NTP Server Address (1)
>             Length: 16
>             NTP Server Address: 2001:db8:ca2:2::1

Please kill off the nm-dispatcher, if any is running, and run one in debug mode:

  /usr/libexec/nm-dispatcher --debug --persist

Here's a snippet from dhcpd6.conf I've used for testing straight from David's comment + the output of nm-dispatcher that suggests the environment variable has been set:

  option dhcp6.ntp-servers code 56 = string;
  option dhcp6.ntp-servers 00:03:00:25:06:64:68:61:75:70:74:05:63:6c:6f:75:64:03:6c:61:62:03:65:6e:67:03:62:6f:73:06:72:65:64:68:61:74:03:63:6f:6D:00;

  (nm-dispatcher:4498): nm-dispatcher-DEBUG: 15:53:19.615: req:5 'up' [enp9s0]: environment: DHCP6_DHCP6_NTP_SERVER=dhaupt.cloud.lab.eng.bos.redhat.com

I've tried your option and it seems to work too:

  option dhcp6.ntp-servers code 56 = string;
  option dhcp6.ntp-servers 00:01:00:10:20:01:0d:b8:0c:a2:00:02:00:00:00:00:00:00:00:01;

  (nm-dispatcher:4498): nm-dispatcher-DEBUG: 15:57:04.681: req:10 'up' [enp9s0]: environment: DHCP6_DHCP6_NTP_SERVER=2001:db8:ca2:2::1

Note that there might actually be multiple addresses and FQDNs joined with a comma (","). I guess it's okay if you don't take that into consideration given RFC 5908 specifically forbids that.
Comment 9 Lubomir Rintel 2022-02-02 15:07:03 UTC 
(In reply to Miroslav Lichvar from comment #7)
> My bad, I wasn't actually testing the NetworkManager rpm I built. It works.
> 
> There is a DHCP6_DHCP6_NTP_SERVER variable visible in the dispatcher script.
> That shouldn't be difficult to support. I guess I just need to make sure
> that if a FQDN is provided, it doesn't contain any unexpected characters.

Yes. Note that the RFC also states that internationalized domain names are
explicitly disallowed, so I guess you can go really conservative.

> Please reassign this bug to the RHEL chrony component or submit a new bug.

Done.
Comment 11 Miroslav Lichvar 2022-02-02 15:24:11 UTC 
(In reply to Lubomir Rintel from comment #8)
> Note that there might actually be multiple addresses and FQDNs joined with a
> comma (","). I guess it's okay if you don't take that into consideration
> given RFC 5908 specifically forbids that.

It seems RFC 5908 requires one suboption in the NTP server option, but allows multiple NTP server options. Would it make sense to rename the variable to DHCP6_DHCP6_NTP_SERVERS?

I tried two FQDNs with dnsmasq, but it uses multiple suboptions in one server option.

The variable contained the two FQDNs separated by space.
Comment 12 Lubomir Rintel 2022-02-03 10:46:52 UTC 
(In reply to Miroslav Lichvar from comment #11)
> (In reply to Lubomir Rintel from comment #8)
> > Note that there might actually be multiple addresses and FQDNs joined with a
> > comma (","). I guess it's okay if you don't take that into consideration
> > given RFC 5908 specifically forbids that.
> 
> It seems RFC 5908 requires one suboption in the NTP server option, but
> allows multiple NTP server options. Would it make sense to rename the
> variable to DHCP6_DHCP6_NTP_SERVERS?

Yes, entirely possible at this point:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1085

> I tried two FQDNs with dnsmasq, but it uses multiple suboptions in one
> server option.
> 
> The variable contained the two FQDNs separated by space.

Ok, so not a comma. Thank you -- I stand corrected.
Comment 13 Miroslav Lichvar 2022-02-08 08:25:42 UTC 
Upstream commit:
https://git.tuxfamily.org/chrony/chrony.git/commit/?id=5bd13c8d593a74ad168057efe94dd2b3aeeffe14
Comment 26 errata-xmlrpc 2022-11-15 11:12:16 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (chrony bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8273
Note You need to log in before you can comment on or make changes to this bug.