Project

General

Profile

Actions
Copy link

Bug #7609

closed

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

Added by Jed Clear over 7 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
NTPD
Target version:
2.4.4-GS
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
Copy link

Also available in: Atom PDF