>> I suspect the problem is back in ntpd, which is sending bad mode 6.
> Fortunately, that kind of thing is easy to fix once characterized. And I
> know that code *really* well. Post an issue one you've figured out what's
> going wring, I'll be on it instantly.
The ntpd side of ntpq -c "cv &<n>" (where n gets the parse refclock) is
sending uninitialized stuff and/or non-text stuff.
The first message in this thread says:
--8<---------------cut here---------------start------------->8---
associd=30868 status=0000 no events, clk_unspec,
device="RAW DCF77 CODE (Conrad DCF77 receiver module)", name="RAWDCF_CONRAD",
timecodeWDCF_CONRAD"� poll="1, noreply=0,\r\nbadformat=0, baddata=0,
fudgetime1=880.500, fudgetime2=27.350,\r\nstratum=0, refid=PCFk, flags=0,
refclock_time="<UNDEFINED>",\r\nrefclock_status="", refclock_format="RAW DCF77
Timecode",\r\nrefclock_states="*NOMINAL: 00:00:07 (100.00%); running time:
00:00:07"refclock_driver_version="4.81 2009/05/01 10:15:29""
--8<---------------cut here---------------end--------------->8---
I see similar problems on other refclocks. In particular the PPS driver.
device="PPS Clock Discipline", name="PPS",
timecodeS"� poll="59,\r\nnoreply=0
Looks like the timecode slot is sending garbage. Maybe just uninialitized. Or
maybe just the close quote is missing. Note the \r\n in the above. Or maybe
there is a " in the data text so the quotes get out of sync.
The CC_TIMECODE slot does:
ctl_putstr(clock_var[id].text,
pcs->p_lastcode,
(unsigned)pcs->lencode);
I'd guess the problem is that the p-lastcode and/or lencode slots aren't
getting initialized correctly.
For something like the NMEA driver, they hold the last sentence received.
--
These are my opinions. I hate spam.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
