I have a little Soekris box whose ONLY task is to get the time from a simple DCF77 time signal receiver and redistribute it with NTP. The update from 10.1 to 10.2 has broken this functionality. The relevant ntp.conf configuration... server 127.127.8.0 mode 14 fudge 127.127.8.0 time1 0.235 ... now results in the obscure error message: PARSE receiver #0: parse_start: parse_setfmt() FAILED. The ntp code is not very transparent, but I think the root cause are the ntp/config.h changes that came with the 4.2.8p3 update. A number of previously disabled obscure clock drivers were enabled, but crucially CLOCK_RAWDCF was disabled, and this is the PARSE subdriver needed to use the popular DCF77 serial receivers. Frankly, it looks like we used to have a carefully considered selection of clock drivers which has been blindly splattered with the upstream defaults in the last update. I don't know how to proceed here. The system ntpd is broken. The ntpd in ports also doesn't enable this clock type by default, so no package. The whole raison d'?tre for this setup was to have a maintenance-free NTP server that does not require custom compiling ntpd. *sigh* -- Christian "naddy" Weisgerber naddy at mips.inka.de
On Sat, 2015-08-15 at 15:46 +0000, Christian Weisgerber wrote:> I have a little Soekris box whose ONLY task is to get the time from > a simple DCF77 time signal receiver and redistribute it with NTP. > The update from 10.1 to 10.2 has broken this functionality. > > The relevant ntp.conf configuration... > > server 127.127.8.0 mode 14 > fudge 127.127.8.0 time1 0.235 > > ... now results in the obscure error message: > > PARSE receiver #0: parse_start: parse_setfmt() FAILED. > > The ntp code is not very transparent, but I think the root cause > are the ntp/config.h changes that came with the 4.2.8p3 update. A > number of previously disabled obscure clock drivers were enabled, > but crucially CLOCK_RAWDCF was disabled, and this is the PARSE > subdriver needed to use the popular DCF77 serial receivers. > > Frankly, it looks like we used to have a carefully considered > selection of clock drivers which has been blindly splattered with > the upstream defaults in the last update. > > I don't know how to proceed here. The system ntpd is broken. The > ntpd in ports also doesn't enable this clock type by default, so > no package. The whole raison d'?tre for this setup was to have a > maintenance-free NTP server that does not require custom compiling > ntpd. *sigh* >Dunno as to what happened with ntp or how to fix it, but there are a couple other ntp soultions in ports that might work. NTP is known to be very complex, IIRC phk@ is being paid by the Linux Foundation to write a replacement, ntimed. While there has not yet been an official release ntimed is in ports. Another option is OpenNTPD from OpenBSD, the portable version of this is in ports as well. I have no idea if they will work any better with your receiver, but since they are completely separate implementations they might be worth a try. Not really an expert here, you mentioned trying the ntp port, and I was aware of these two alternative implementations. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5761 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150815/28ee95aa/attachment.bin>
On 15/08/2015 16:46, Christian Weisgerber wrote:> The ntp code is not very transparent, but I think the root cause > are the ntp/config.h changes that came with the 4.2.8p3 update. A > number of previously disabled obscure clock drivers were enabled, > but crucially CLOCK_RAWDCF was disabled, and this is the PARSE > subdriver needed to use the popular DCF77 serial receivers. > > Frankly, it looks like we used to have a carefully considered > selection of clock drivers which has been blindly splattered with > the upstream defaults in the last update.Hmmm.... I suggest raising a PR with patches to revert the changes in the set of enabled clock drivers (or merge with the current list). It's not going to get you a working DCF77 receiver in a -RELEASE version any time soon, I'm afraid, as you'll have to wait until the next release for the changes to percolate down, but having a sensible list of enabled clock drivers in base is definitely a good move. For a more timely solution[*], it looks like the ports is your best option. By default the net/ntp port disables all of the clock drivers, but allows you to configure the port to enable whatever drivers you want. If you built your own package it would be simple to get the right support compiled in. However, that won't help if you're determined to use pre-built packages only, in which case there would need to be a slave port with enabled clock drivers. That's something you could certainly argue for; This is a symptom of the current state of the ports tree -- we've switched over to pkg(8), but we're still working through a lot of changes to fully enable pkg capabilities. A lot of the functionality still only really works if you build your own ports. There are changes planned, like sub-packages and package flavours which should help, but in the case of net/ntp where clock drivers are compiled into the main binary unfortunately those won't apply. If NTP clock drivers were implemented as loadable modules it would be a lot easier... Cheers, Matthew [*] Pun unintentional. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 971 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150816/a8556ac2/attachment.bin>