Project

General

Profile

Actions

Bug #7609

closed

NTP Status not parsing all NTP Access Restrictions preventing status display when it is actually allowed

Added by Jed Clear almost 7 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
NTPD
Target version:
Start date:
05/29/2017
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.3.4
Affected Architecture:

Description

Status/NTP displays "Statistics unavailable because ntpq and ntpdc queries are disabled in the NTP service settings", whenever noquery is set in in the Default NTP ACL, in spite of a specific ACL allowing 127.0.0.1 to query. The command line "ntpq -pn" work properly.

To Reproduce:
Start with pfSense synced to NTP peer(s) and the default NTP ACLs. In Service/NTP/ACLs, check Queries in the Default Access Restrictions. Add a Custom Access Restriction that will match 127.0.0.1 and does not have noquery checked. Save. SSH to the pfSense host and run "/usr/local/bin/ntpq -pn" and it will display the peers. Status/NTP complains as above and doesn't display any peers.

I am not even a PHP novice, let alone expert, but can follow the code logic. It appears that that status_ntpd.php is only checking the Default Access Restriction noquery setting before skipping the ntpq and throwing that error message. There really needs to be a best address match on all the NTP ACLs (including default) against 127.0.0.1 and then test the matching noquery entry. And the code to do so might go in services_ntpd_acls.php so it is only done when the ACLs are changed, and sets a flag for status_ntpd.php. That also provides an opportunity to tell the user their config choice has blocked pfSense from providing NTP status, and offer advice, when that occurs.

Actions

Also available in: Atom PDF