[ntp:hackers] Problems with Oncore???

Terje Mathisen terje.mathisen at hda.hydro.com
Wed Jun 1 05:20:43 PDT 2005


jhay at icomtek.csir.co.za wrote:

> Terje,
> 
> 
>>refclock_oncore.c complains about missing CR/LF message terminators on
>>several messages, when I comment out this test I got checksum errors
>>instead, so I modified the source code to dump both the packets and a
>>manually calculated checksum (XOR) of all the bytes, including the
>>checksum byte. This XOR should then always be zero, right?
>>
>>When I find is that three different packets are always terminated by 012
>>012 octal, i.e. LF/LF instead of CR/LF, and the checksum is off by 7,
>>i.e. the manual checksum result is 007 instead of 000.
> 
> 
> Raw mode has been broken in ntp_refclock.c. So when you request LDISC_RAW
> you actually get it slightly cooked. :-/
> 
> I have been using this patch to make my Oncore happy. Don'y know if
> it will break other drivers:
> 
> ##################################
> --- ntpd/ntp_refclock.c.org	Wed Apr 20 21:54:58 2005
> +++ ntpd/ntp_refclock.c	Wed Jun  1 11:04:33 2005
> @@ -854,6 +854,7 @@
>  	 */
>  	ttyp->c_lflag = ICANON;
>  	if (lflags & LDISC_RAW) {
> +		ttyp->c_iflag = 0;
>  		ttyp->c_lflag = 0;
>  		ttyp->c_cc[VMIN] = 1;
>  	}
> @@ -916,6 +917,7 @@
>  	 */
>  	ttyp->c_lflag = ICANON;
>  	if (lflags & LDISC_RAW) {
> +		ttyp->c_iflag = 0;
>  		ttyp->c_lflag = 0;
>  		ttyp->c_cc[VMIN] = 1;
>  	}
> ##################################
> 
> John

I tried your patch, and I seem to get different results!?!

refclock_transmit: at 32 127.127.30.0
poll_update: at 32 127.127.30.0 flags 10a1 poll 4 burst 0 last 32 next 50
ONCORE[0]: Checksum mismatch!
ONCORE[0]: @@Cj 015 012 103 117 120 131 122 111 107 110 124 040 061 071
071 061
055 062 060 060 064 040 115 117 124 117 122 117 114 101 040 111 116 103
056 015
012 123 106 124 127 040 120 057 116 040 043 040 040 040 040 040 066 061
055 107
061 060 062 066 070 101 040 015 012 123 117 106 124 127 101 122 105 040
126 105
122 040 043 040 062 040 040 040 040 040 040 040 040 040 040 015 012 123
117 106
124 127 101 122 105 040 122 105 126 040 043 040 062 040 040 040 040 040
040 040
040 040 040 015 012 123 117 106 124 127 101 122 105 040 104 101 124 105
040 040
101 120 122 040 062 070 040 062 060 060 064 015 012 115 117 104 105 114
040 043
040 040 040 040 120 062 067 063 124 061 062 124 061 067 040 040 040 040
040 015
012 110 100 100 110 141 006 001 007 325 014 012 000 000 000 027 362 014

-------- ^^^^^^ -------------------

333 065
140 002 111 022 163 000 000 037 102 000 000 000 000 014 333 064 262 002
111 023
205 000 000 032 005 000 000 000 000 000 006 000 001 012 214 000 047 011
006 027
010 064 047 010 241 030 010 064 010 010 241 004 010 060 142 010 241 024
010 061
357 010 240 015 010 060 067 010 240 031 010 060 336 010 240 002 000 000
000 000
000 007 000 000 156 000 000 000 000 000 000 000 000 036  (336)

Notice the two bytes of octal 100 above: They are preceeded by a CR LF
combination, then a single 110 (ascii H, right?), and followed by ascii
Ha. I.e. @@Ha which afair is a valid Oncore message.

Could the expected message length in the driver be wrong, or could some
bytes be suppressed by your patch?

The 012 012 combinations did go away though!

Terje
-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"



More information about the hackers mailing list