PfSense 2.2: ntpd keeps terminating and restarting
-
In ntp 4.2.8 you can use 'interface' to specify which interfaces ntpd should bind to.
Sure like hell does nothing useful wrt binding in any ISC NTPd version and sure like hell never ever worked.
$ ntpd --version ntpd 4.2.8@1.3265-o Mon Dec 22 14:36:36 UTC 2014 (1) $ grep interface /var/etc/ntpd.conf interface ignore all interface listen ste0 $ netstat -an | grep .123 udp6 0 0 ::1.123 *.* udp4 0 0 127.0.0.1.123 *.* udp6 0 0 2001:470:dead:beef:1.123 *.* udp6 0 0 fe80::21f:c6ff:f.123 *.* udp4 0 0 192.168.0.254.123 *.* udp4 0 0 *.123 *.* udp6 0 0 *.123 *.*
-
Though the fixes in 4.2.8p1 are minor (and I don't think the security fix is relevant to pfSense), it might be worth pfSense 2.2.1 updating to the latest release.
pfSense 2.2 is already on 4.2.8.
Already It would also be good to see pfSense's configuration interface to allow configuration using 'pool' as an alternative to 'server', as well as specifying a pool or server as -4 (use IPv4) or -6 (use IPv6).
Support is there, just not yet in the gui or php code. To make experimental changes to your config, behind the gui, edit /etc/inc/system.inc, function system_ntp_configure around line 1492. Otherwise, manual edits to /var/etc/ntpd.conf will be overwritten. Otherwise you can open a feature request ticket in redmine.
Autokey is going to be replaced by something else
IETF 'Network Time Security', work is in progress. Draft: https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-06
But this is drifting away from pfSense; maybe better continued on the pfSense Development forum area. -
Looking at options, pool would be good but how would peer be for an additional choice? I'm no ntp expert but I saw it when reading the man and web pages and it seemed like something I could use here on my little network.
This is what I'm seeing on my 2.2 pfSense box, WAN, LAN and OPT1 ports are configured.
[2.2-RELEASE][root@pfSense.home]/root: ntpd --version ntpd 4.2.8@1.3265-o Mon Dec 22 14:36:40 UTC 2014 (1) [2.2-RELEASE][root@pfSense.home]/root: grep interface /var/etc/ntpd.conf interface ignore all interface listen em1 [2.2-RELEASE][root@pfSense.home]/root: netstat -an | grep .123 udp6 0 0 ::1.123 *.* udp4 0 0 127.0.0.1.123 *.* udp4 0 0 172.16.0.1.123 *.* udp6 0 0 fe80::21b:21ff:f.123 *.* udp4 0 0 *.123 *.* udp6 0 0 *.123 *.*
-
Been running NTP server on pfsense for years (because I either need it so much or just like turning things on - Not sure)
Anyway, its never had a problem. -
I am experiencing this issue, also. Packages are restarted when OpenVPN hiccups. Not sure why NTP should care about this since it only listens on my local LAN.
-
I am experiencing this issue, also. Packages are restarted when OpenVPN hiccups. Not sure why NTP should care about this since it only listens on my local LAN.
Please try the following patches: they simply remove the ntp reconfiguration and kill/restart from the files /etc/inc/newwanip and /etc/inc/newwanipv6. The packages will still be restarted. This will let ntpd use its own code for detecting interface changes. Should also help with https://redmine.pfsense.org/issues/4155 and https://forum.pfsense.org/index.php?topic=78194.0
I've tried to walk through the earlier revisions for these files to see when these lines were added, but couldn't find anything applicable. I suspect they date from when openntpd was being used, which did not handle dynamic interface scanning like the current ntpd does.
--- rc.newwanip.orig 2015-01-22 15:39:45.000000000 -0500 +++ rc.newwanip 2015-03-01 12:41:43.000000000 -0500 @@ -47,8 +47,6 @@ global $oldip, $curwanip, $g; /* restart packages */ - system_ntp_configure(false); - mwexec_bg("/usr/local/sbin/ntpdate_sync_once.sh", true); log_error("{$g['product_name']} package system has detected an IP change or dynamic WAN reconnection - $oldip -> $curwanip - Restarting packages."); send_event("service reload packages"); } --- rc.newwanipv6.orig 2015-01-22 15:39:45.000000000 -0500 +++ rc.newwanipv6 2015-03-01 12:42:07.000000000 -0500 @@ -48,8 +48,6 @@ global $oldipv6, $curwanipv6, $g; /* restart packages */ - system_ntp_configure(false); - mwexec_bg("/usr/local/sbin/ntpdate_sync_once.sh", true); log_error("{$g['product_name']} package system has detected an IP change or dynamic WAN reconnection - $oldipv6 -> $curwanipv6 - Restarting packages."); send_event("service reload packages"); }
-
Please try the following patches: they simply remove the ntp reconfiguration and kill/restart from the files /etc/inc/newwanip and /etc/inc/newwanipv6. The packages will still be restarted. This will let ntpd use its own code for detecting interface changes. Should also help with https://redmine.pfsense.org/issues/4155 and https://forum.pfsense.org/index.php?topic=78194.0
Has anyone tried this and had it resolve their issue and not break anything? I'm pretty confident that's a fine change, and it seems like it should avoid the crash described here. I made this change in 2.3 as part of https://redmine.pfsense.org/issues/4155
-
@cmb:
I'm pretty confident that's a fine change, and it seems like it should avoid the crash described here. I made this change in 2.3 as part of https://redmine.pfsense.org/issues/4155
Yeah, I'm confident it's a fine change as well, though obviously the core issue is somewhere else (i.e., in the ntpd code). Unfortunately, unless you backport fixes to usable pfSense branch, it's like if you did nothing.
-
@cmb:
[Has anyone tried this and had it resolve their issue and not break anything? I'm pretty confident that's a fine change, and it seems like it should avoid the crash described here. I made this change in 2.3 as part of https://redmine.pfsense.org/issues/4155
[/quote]Well, my machines have worked OK with that patch since before I posted it. No known breakage, but I guess I don't count as a second opinion :)
Looking forward to testing 2.3….
-
Well, my machines have worked OK with that patch since before I posted it. No known breakage, but I guess I don't count as a second opinion :)
Your first opinion is appreciated regardless. :) Wasn't clear from your earlier post if you were running it at all at the time, or were still running it now 6 months after the fact.