News items for tag time - Koos van den Hout

2018-01-23 Avoiding the linux statefull firewall for some traffic 2 months ago
I was setting up a linux based firewall on a busy ntp server and to make sure everything worked as designed I added the usual:
iptables -A INPUT -j ACCEPT --protocol all -m state --state ESTABLISHED,RELATED
And after less than half an hour the system log started filling with
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
It is indeed a busy server. The solution is to exclude all the ntp traffic from the stateful firewall. Which means I have to allow all kinds of ntp traffic (outgoing and incoming) by itself.

The specific ruleset:
iptables -t raw -A PREROUTING --protocol udp --dport 123 -j NOTRACK
iptables -t raw -A OUTPUT --protocol udp --sport 123 -j NOTRACK

iptables -A INPUT -j ACCEPT --protocol udp --destination-port 123
I also made sure the rules for the ntp traffic are the first rules.

Traffic at this server is somewhat over 1000 ntp request per second. So the counters of the NOTRACK rules go fast.
# iptables -t raw -L -v
Chain PREROUTING (policy ACCEPT 1652K packets, 126M bytes)
 pkts bytes target     prot opt in     out     source               destination 
9635K  732M CT         udp  --  any    any     anywhere             anywhere             udp dpt:ntp NOTRACK
1650K  125M CT         udp  --  any    any     anywhere             anywhere             udp dpt:ntp NOTRACK

Chain OUTPUT (policy ACCEPT 1522K packets, 117M bytes)
 pkts bytes target     prot opt in     out     source               destination 
9029K  686M CT         udp  --  any    any     anywhere             anywhere             udp spt:ntp NOTRACK
1520K  116M CT         udp  --  any    any     anywhere             anywhere             udp spt:ntp NOTRACK
But no packets are dropped, which is good as this server is supposed to be under a constant DDoS.

Tags: , , ,
2018-01-19 Collecting ages of ntpd mode 7 probes 3 months ago
I noticed today one of the ntp servers I manage has been collecting ages of ntpd mode 7 probes without ever responding. But it makes a nice overview of probing IPv4 addresses:
remote address          port local address      count m ver rstr avgint  lstint
===============================================================================
184.105.139.82          1714 xxx.xxx.xxx.xxx        3 7 2      1 3413098   40058
184.105.139.72         14152 xxx.xxx.xxx.xxx        7 6 2      1 1107023   60553
185.165.29.145         33482 xxx.xxx.xxx.xxx        9 7 2      1 647886   73704
91.200.12.126          47493 xxx.xxx.xxx.xxx        2 7 2      1  12199   78678
185.94.111.1           33066 xxx.xxx.xxx.xxx       44 7 2      1 139771   83493
212.237.45.33          39353 xxx.xxx.xxx.xxx        1 7 2      1      0   84058
184.105.139.122        16124 xxx.xxx.xxx.xxx        4 7 2      1 1830407  127241
165.227.44.214         36749 xxx.xxx.xxx.xxx        1 7 2      1      0  138342
185.82.203.150         38141 xxx.xxx.xxx.xxx       12 7 2      1 147806  143793
185.2.81.90            33119 xxx.xxx.xxx.xxx        6 7 2      1 199742  180842
184.105.139.110        57630 xxx.xxx.xxx.xxx        6 7 2      1 968029  223794
77.87.79.97            34540 xxx.xxx.xxx.xxx        2 7 2      1  31910  251316
184.105.139.102        50130 xxx.xxx.xxx.xxx        3 7 2      1 2950157  308291
185.55.218.227         33716 xxx.xxx.xxx.xxx        2 7 2      1 853413  311971
104.243.41.54          30820 xxx.xxx.xxx.xxx        2 7 2      1 3258925  334017
123.249.27.176         35963 xxx.xxx.xxx.xxx        7 7 2      1 452131  339518
191.96.249.173         42895 xxx.xxx.xxx.xxx       10 7 2      1 692139  348753
71.194.80.50           51096 xxx.xxx.xxx.xxx        2 7 2      1  74579  392665
184.105.139.126        38393 xxx.xxx.xxx.xxx        2 7 2      1 3535530  394349
185.55.218.250         48871 xxx.xxx.xxx.xxx        2 7 2      1 537671  411921
184.105.139.86         34651 xxx.xxx.xxx.xxx        5 7 2      1 1361673  478157
123.249.24.175         37973 xxx.xxx.xxx.xxx        6 7 2      1 476469  502270
184.105.139.98         21269 xxx.xxx.xxx.xxx       10 7 2      1 718112  567076
184.105.139.70         38190 xxx.xxx.xxx.xxx        6 7 2      1 1107237  649625
66.55.135.62           54536 xxx.xxx.xxx.xxx        8 7 2      1  40836  721372
138.197.130.148        39857 xxx.xxx.xxx.xxx        2 7 2      1 415601  788308
191.96.249.113         36079 xxx.xxx.xxx.xxx        2 7 2      1 1501700  862267
184.105.139.78         37702 xxx.xxx.xxx.xxx        4 7 2      1 1637431  908028
159.89.47.224          47766 xxx.xxx.xxx.xxx        5 7 2      1 361160  913255
162.209.168.12         39122 xxx.xxx.xxx.xxx        2 7 2      1 109901  976174
123.249.26.159         34990 xxx.xxx.xxx.xxx       41 7 2      1  88999 1045070
184.105.139.74         38666 xxx.xxx.xxx.xxx        6 7 2      1 822261 1079624
185.55.218.242         54815 xxx.xxx.xxx.xxx        7 7 2      1  89032 1102095
191.96.249.12          48406 xxx.xxx.xxx.xxx        4 7 2      1 1133779 1198815
101.100.146.139        39660 xxx.xxx.xxx.xxx        3 7 2      1 1951322 1244586
209.250.238.186        39459 xxx.xxx.xxx.xxx        2 7 2      1  53072 1252190
119.1.109.85           51099 xxx.xxx.xxx.xxx       10 7 2      1 223881 1325320
184.105.139.118        34319 xxx.xxx.xxx.xxx        4 7 2      1 905995 1339133
184.105.139.106        15081 xxx.xxx.xxx.xxx        2 7 2      1 2932231 1430316
191.96.249.131         35972 xxx.xxx.xxx.xxx        2 7 2      1 1499287 1491171
185.55.218.237         43409 xxx.xxx.xxx.xxx        2 7 2      1 4255207 1497992
185.55.218.236         55927 xxx.xxx.xxx.xxx        3 7 2      1 1566148 1718947
138.68.247.41          41914 xxx.xxx.xxx.xxx        2 7 2      1  53524 1936953
184.105.139.94         41523 xxx.xxx.xxx.xxx        5 7 2      1 1112720 1948506
45.63.27.150           40862 xxx.xxx.xxx.xxx        2 7 2      1 1676933 1991259
185.188.207.13         45915 xxx.xxx.xxx.xxx       20 7 2      1 156321 2041538
185.44.107.183         45785 xxx.xxx.xxx.xxx        2 7 2      1 132706 2107890
184.105.139.90         35315 xxx.xxx.xxx.xxx        5 7 2      1 350936 2206670
191.96.249.61          30296 xxx.xxx.xxx.xxx        3 7 2      1  59063 2226284
195.22.127.173         40060 xxx.xxx.xxx.xxx        2 7 2      1  20615 2253429
184.105.139.114        56609 xxx.xxx.xxx.xxx        4 7 2      1 604491 2291452
104.243.41.52            123 xxx.xxx.xxx.xxx        2 7 2      1  85831 2381504
103.9.78.129           50367 xxx.xxx.xxx.xxx        2 7 2      1 868629 2449128
167.88.15.18           40815 xxx.xxx.xxx.xxx        2 7 2      1 182471 2525650
167.88.180.82          40640 xxx.xxx.xxx.xxx        2 7 2      1  66892 2715823
192.158.229.240        39284 xxx.xxx.xxx.xxx        4 7 2      1 163873 2759391
51.15.45.102           45371 xxx.xxx.xxx.xxx        2 7 2      1  92720 2768083
185.198.58.55          18637 xxx.xxx.xxx.xxx        2 7 0      1 802096 2787683
123.249.24.197         40362 xxx.xxx.xxx.xxx       37 7 2      1  85431 2983252
167.88.180.26          49125 xxx.xxx.xxx.xxx        4 7 2      1  60114 3023906
188.213.49.83          34969 xxx.xxx.xxx.xxx        2 7 2      1 254056 3095396
45.76.24.165           41025 xxx.xxx.xxx.xxx        2 7 2      1 107397 3103557
213.183.54.46          40409 xxx.xxx.xxx.xxx        5 7 2      1 206100 3224158
145.239.237.23         35814 xxx.xxx.xxx.xxx        2 7 2      1 571497 3264230
165.227.220.24         39557 xxx.xxx.xxx.xxx        2 7 2      1  52796 3292818
123.249.35.214         47756 xxx.xxx.xxx.xxx        2 7 2      1 242695 3296347
123.249.76.52          59698 xxx.xxx.xxx.xxx        8 7 2      1 246226 3446607
123.249.79.178         52301 xxx.xxx.xxx.xxx        2 7 2      1 839605 3455884
207.254.182.131        52337 xxx.xxx.xxx.xxx        4 7 2      1   1384 3648002
185.55.218.109         37602 xxx.xxx.xxx.xxx        2 7 2      1 752428 3652434
128.14.61.111          53586 xxx.xxx.xxx.xxx        3 7 2      1 103699 3796467
104.238.146.66         52224 xxx.xxx.xxx.xxx        2 7 2      1 138668 3837468
95.215.62.72           42111 xxx.xxx.xxx.xxx        4 7 2      1 608618 3932262
45.76.195.157          59987 xxx.xxx.xxx.xxx        2 7 2      1 143642 4096101
123.249.79.232         40165 xxx.xxx.xxx.xxx        4 7 2      1 146715 4317577
86.105.9.86            55857 xxx.xxx.xxx.xxx        4 7 2      1 115972 4329305
217.147.89.197         49717 xxx.xxx.xxx.xxx        4 7 2      1 314874 4463013
182.18.22.246          58611 xxx.xxx.xxx.xxx        3 7 2      1 359548 4485937
185.82.203.107         56661 xxx.xxx.xxx.xxx        7 7 2      1 176060 4516810
79.124.60.148          58043 xxx.xxx.xxx.xxx        2 7 2      1 687406 4684505
185.107.94.66          46254 xxx.xxx.xxx.xxx        2 7 2      1 1263073 4750583
191.96.249.84          49259 xxx.xxx.xxx.xxx        2 7 2      1 329846 5160890
111.121.193.201         6065 xxx.xxx.xxx.xxx        3 7 0      1 101832 5558503
185.188.207.15         33999 xxx.xxx.xxx.xxx        3 7 2      1  90416 5655119
185.117.74.118         52973 xxx.xxx.xxx.xxx        2 7 2      1   2174 5717159
185.82.203.58          59170 xxx.xxx.xxx.xxx        2 7 2      1  47838 5847404
185.162.128.66         39141 xxx.xxx.xxx.xxx        2 7 2      1   4837 5895126
All IP addresses with only 1 packet removed.

Tags: , ,
2017-01-01 Leaped into 2017! 1 year ago
Jan  1 00:59:59 greenblatt kernel: [2538111.748198] Clock: inserting leap second 23:59:60 UTC
I usually distribute the leap second file to all servers I control to make sure there are no strange problems around it.

I wish everyone a good 2017!

Tags: , ,
2016-03-31 Interesting report from pskreporter 2 years ago
PSKreporter negative time Interesting report from pskreporter psk map today: a negative time at which the signal was reported. I guess the reported time is taken from the original spotter, I had EB4DDQ in the log at 18:12 UTC, he had me in the log at 19:12 UTC.

Tags: , , ,
2016-01-28 Shodan using the IPv6 ntp pool to find active IPv6 addresses 2 years ago
Recently posted: shodan.io actively infiltrating ntp.org IPv6 pools for scanning purposes. So I tried:
ntpdate -d -u 2a03:b0c0:3:d0::18:b001
And indeed:
Jan 28 14:42:25 server kernel: [1187976.106758] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=49717 DPT=55554 WINDOW=54358 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.107191] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34680 DPT=50070 WINDOW=26315 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.107256] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=49717 DPT=32764 WINDOW=15398 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.107309] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=41249 DPT=44818 WINDOW=15146 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.107380] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=52 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=13864 DPT=30718 LEN=12 
Jan 28 14:42:25 server kernel: [1187976.107427] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=59140 DPT=25565 WINDOW=53087 RES=0x00 SYN URGP=0 
Jan 28 14:42:25 server kernel: [1187976.108613] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=55 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=32950 DPT=8888 LEN=15 
Jan 28 14:42:25 server kernel: [1187976.110197] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=39721 DPT=64738 LEN=20 
Jan 28 14:42:25 server kernel: [1187976.110315] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=50 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=46499 DPT=5632 LEN=10 
Jan 28 14:42:25 server kernel: [1187976.110405] FW dropped: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=65 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=UDP SPT=21934 DPT=47808 LEN=25 
Jan 28 14:42:31 server kernel: [1187981.938880] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34235 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
Jan 28 14:42:31 server kernel: [1187982.030058] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34235 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
Jan 28 14:42:31 server kernel: [1187982.197203] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34237 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
Jan 28 14:42:33 server kernel: [1187984.398977] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34245 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
Jan 28 14:42:34 server kernel: [1187984.620836] FW reject: IN=ppp0 OUT= MAC= SRC=2604:a880:0800:0010:0000:0000:00fe:d001 DST=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx LEN=60 TC=0 HOPLIMIT=55 FLOWLBL=0 PROTO=TCP SPT=34244 DPT=993 WINDOW=0 RES=0x00 RST URGP=0 
I would have expected more ports tested.

Tags: , , ,
2015-07-01 And the leap second leaped fine 2 years ago
The world did not fall apart at the leap second...
Jul  1 01:59:59 greenblatt kernel: [5562265.176016] Clock: inserting leap second 23:59:60 UTC
Jul  1 01:37:53 ritchie ntpd[14950]: local_clock: ntp_loopfilter.c line 688: kernel reports positive leap second warning state
Jul  1 01:59:59 ritchie kernel: [5807507.207473] Clock: inserting leap second 23:59:60 UTC
Jul  1 02:13:11 ritchie ntpd[14950]: local_clock: ntp_loopfilter.c line 688: kernel reports leap second has occured

Tags: ,
2015-06-30 Incoming leap second... 2 years ago
Previous there was just an announcement:
associd=0 status=0119 leap_none, sync_pps, 1 event, leap_armed
But the current state is that it's less than 24 hours until the leap second:
ntpq -nc readvar
associd=0 status=4619 leap_add_sec, sync_ntp, 1 event, leap_armed,
version="ntpd 4.2.6p3@1.2290-o Mon Apr 13 13:41:30 UTC 2015 (1)",
processor="x86_64", system="Linux/3.2.0-80-generic", leap=01, stratum=2,
precision=-20, rootdelay=21.302, rootdisp=962.377, refid=131.211.8.244,
reftime=d93ccb6a.5bf9c564  Tue, Jun 30 2015 10:01:46.359,
clock=d93ccb70.10208b70  Tue, Jun 30 2015 10:01:52.062, peer=21283, tc=6,
mintc=3, offset=-23.354, frequency=7.280, sys_jitter=0.205,
clk_jitter=8.257, clk_wander=0.087, tai=35, leapsec=201507010000,

Tags: ,
2015-01-05 Leap second announcement 3 years ago
Promptly after fixing the previus leapsecond file I get the IERS Bulletin C number 49 today which states:
                                   UTC TIME STEP
                            on the 1st of July 2015


 A positive leap second will be introduced at the end of June 2015.
 The sequence of dates of the UTC second markers will be:

                          2015 June 30,     23h 59m 59s
                          2015 June 30,     23h 59m 60s
                          2015 July  1,      0h  0m  0s
And I notice the IETF seems to update the canonical leap-seconds file about two months after the decision is made by the IERS.

It's a good thing ntpd starts complaining when the file is about to expire.

Update 2015-01-06: An update was available from ftp://time.nist.gov/ but only when I connected over IPv6. An interesting form of IPv6 promotion. Notice the difference in messages between the old file and the new file loading:
Jan  5 13:54:33 ritchie ntpd[13710]: leapsecond file ('/etc/ntp/leap-seconds.3644438400'): good hash signature
Jan  5 13:54:33 ritchie ntpd[13710]: leapsecond file ('/etc/ntp/leap-seconds.3644438400'): loaded, expire=2015-06-28T00:00Z ofs=35 (no entries after build date)
Jan  6 10:14:17 ritchie ntpd[26348]: leapsecond file ('/etc/ntp/leap-seconds.3629404800'): good hash signature
Jan  6 10:14:17 ritchie ntpd[26348]: leapsecond file ('/etc/ntp/leap-seconds.3629404800'): loaded, expire=2015-12-28T00:00Z last=2015-07-01T00:00Z ofs=36

Tags: , ,
2014-12-29 Time to update the leapsecond file 3 years ago
I recently upgraded ntpd due to the vulnerabilities found in ntpd prior to version 4.2.8. This version is also a bit better in error logging, and I started seeing in the logs:
Dec 21 20:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): loaded, expire=2014-12-28T00:00Z ofs=35 (no entries after build date)
Dec 21 20:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): will expire in less than 7 days
Dec 22 20:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): will expire in less than 6 days
Dec 23 20:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): will expire in less than 5 days

Dec 28 00:53:06 ritchie ntpd[6918]: leapsecond file ('/etc/ntp/leap-seconds.3535228800'): will expire in less than one day
So I followed the documentation in ConfiguringNTP: 6.14. Using the NIST Leap Second File and upgraded to leap-seconds.3644438400 which now loads fine:
Dec 29 11:25:29 ritchie ntpd[28281]: leapsecond file ('/etc/ntp/leap-seconds.3644438400'): good hash signature
Dec 29 11:25:29 ritchie ntpd[28281]: leapsecond file ('/etc/ntp/leap-seconds.3644438400'): loaded, expire=2015-06-28T00:00Z ofs=35 (no entries after build date)

Tags: , ,
2014-10-04 (#) 3 years ago
It seems the Garmin GPS 18 LVC for timekeeping in the ntp server on ritchie.idefix.net is having weird issues. It stops responding with the carrier high and sometimes restarts.
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,3,1,11,01,00,098,00,02,57,048,00,24,00,210,00,25,47,265,00*77
$GPGSV,3,2,11,26,05,15�
On such a 'hang' the carrier detect is high. Weird problem.

Tags: ,
2014-05-25 (#) 3 years ago
After testing the gps sky view it's now time to test with ntpd. First step was to recompile ntpd because the debian default package had no pps support. Recompiling on a 500 MHz AMD Geode takes a bit of time.

Results look ok for a first test:
root@ritchie:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+greenblatt.idef 131.211.8.244    2 u   17   64  377    1.177  101.732  63.403
*metronoom.dmz.c .PPS.            1 u   17   64  377   19.499  100.512   6.722
+auth1.xs4all.nl 193.67.79.202    2 u   11   64  377   18.403  104.008   3.669
oGPS_NMEA(0)     .GPS.            0 l    6    8  377    0.000  114.073   7.364
root@ritchie:~# ntpdc -c loopi
offset:               0.001986 s
frequency:            94.434 ppm
poll adjust:          -30
watchdog timer:       342 s
root@ritchie:~# ntpdc -c kerni
pll offset:           3.3e-08 s
pll frequency:        94.434 ppm
maximum error:        0.175258 s
estimated error:      2e-06 s
status:               2007  pll ppsfreq ppstime nano
pll time constant:    3
precision:            1e-09 s
frequency tolerance:  500 ppm
root@ritchie:~# ntpdc -c sysi
system peer:          GPS_NMEA(0)
system peer mode:     client
leap indicator:       00
stratum:              1
precision:            -19
root distance:        0.00000 s
root dispersion:      0.00749 s
reference ID:         [GPS]
reference time:       d72cb010.dc91595e  Sun, May 25 2014 20:08:16.861
system flags:         auth monitor ntp kernel stats pps 
jitter:               0.006714 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s
It will need some more calibration probably.

Update: It keeps looking nice after some calibration. Stats gathered at NTP server ritchie.idefix.net stats.

This does mean one of the old project sundial goals has been met: the weather station computer in the shed is now also a time server.

Tags: , , ,
2014-02-18 (#) 4 years ago
After getting the gps running in the shed I noticed a bit of variation in the output location as logged from the NMEA $GPGGA strings in the clockstats file. And reading Tom van Baak testing the MG1613S GPS Receiver noting the variation in location made me decide to do a bit of plotting of location on my own. As Tom notes, plotting distance in meters gives a better idea of scale. So I wrote a bit of perl to massage the lat/long pairs into X/Y meters from a starting point. I was lazy: I used the first measurement as starting point. The resulting X/Y pairs are graphed using gnuplot.

Update: I'm a security specialist, not a programmer: I found some errors in the routines that convert output from the GPS to degrees to meters. Fixed them, so the first graph has been redrawn using data from 17 and 18 Februari.

Tags: , ,
2014-02-16 (#) 4 years ago
Since the old gpskit gps was showing problems in ntp tests earlier I decided now that the weatherstation computer is up and running on the alix.1c board to try a different gps unit: The Holux GR-213 GPS I still have from earlier wardriving. holux 213 gps

Not much of a succes sofar. First the GPS did not get a lock at all. I was expecting a delay in acquiring a lock since it hadn't been used in over a year but after a day and a half it still wasn't locking. So I moved it a bit which led to a lock (blinking led). But ntpd was still not using the GPS_NMEA driver. When I had time to have more of a look than just the graphs at NTP server ritchie.idefix.net stats I noticed ntpd was still seeing GPS_NMEA as a falseticker. Which is about right, when I look at the peer stats the GPS_NMEA clock has an offset of about 500 milliseconds(!!) compared to the rest.

To my best knowledge I can find the right offset with 'enable calibrate'. But documentation is very minimal on this matter: Reference clock drivers - ntp 4.0.99k documentation has:
The recommended procedure is to enable the function, let it run for an hour or so, then edit the configuration file using the time1 values displayed by the ntpq utility and clockvar command.
With 'enable calibrate' on I see after a long run:
ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+greenblatt.idef 131.211.8.244    2 u  137  512  377    1.012    1.780  87.722
*metronoom.dmz.c .PPS.            1 u  166  512  377   18.297   -1.207  46.401
+auth1.xs4all.nl 193.67.79.202    2 u  119  512  377   16.604   -1.104  27.267
xGPS_NMEA(0)     .GPS.            0 l    4   16  377    0.000  -529.94   3.286
ntpq> clockvar
associd=0 status=0000 , no events, clk_unspec,
device="NMEA GPS Clock",
timecode="$GPGGA,210752.000,5206.6230,N,00507.0976,E,1,06,1.5,-0.1,M,47.1,M,,0000*7F",
poll=762, noreply=0, badformat=0, baddata=0, fudgetime1=0.000, stratum=0,
refid=GPS, flags=0
So even after running for a long time with clearly an offset between the other clocks and the reference clock there is no change in the suggestion for the time1 factor, still showing 0.000.

Remarks in [ntp:questions] enable calibrate? suggest 'enable calibrate' will only work when there is a PPS signal available, and confirm the lack of documentation and samples I found.

The Holux GR-213 also does not have a PPS signal to the outside at all, so I can't use a PPS signal anyway.

Update: Some sleep, thinking and reading later: first of all, time1 is the PPS time offset and time2 is the gps message offset, found by reading ntpd documentation Generic NMEA GPS driver.

So I started looking for the right offset with the 127.127.20.0 driver in noselect mode. After some testing I found a reasonable answer with:
# GPS as time source without pps
server 127.127.20.0 minpoll 1 maxpoll 4
fudge 127.127.20.0 time2 +0.544
And now things look better:
ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+greenblatt.idef 131.211.8.244    2 u    2   64   77    0.956   -2.252  41.400
*metronoom.dmz.c .PPS.            1 u    5   64   77   17.921   -2.236   1.190
-auth1.xs4all.nl 193.67.79.202    2 u    3   64   77   16.254   -2.750   0.880
+GPS_NMEA(0)     .GPS.            0 l    2    8  377    0.000   -5.916   1.100

Tags: ,
2013-12-30 The wonderful world of week number standards 4 years ago
The wonderful thing about standards:
$ date "+%u %w %U %V %W"
1 1 52 01 52
And the explanations:

%u day of week (1..7); 1 is Monday

%w day of week (0..6); 0 is Sunday

%U week number of year, with Sunday as first day of week (00..53)

%V ISO week number, with Monday as first day of week (01..53)

%W week number of year, with Monday as first day of week (00..53)

And it's easy to find days with 3 different week numbers:
31 dec 1990 is 52 01 53
03 jan 1993 is 01 53 00
02 jan 1994 is 01 52 00
01 jan 1995 is 01 52 00
30 dec 1996 is 52 01 53
31 dec 1996 is 52 01 53
03 jan 1999 is 01 53 00
02 jan 2000 is 01 52 00
02 jan 2005 is 01 53 00
01 jan 2006 is 01 52 00
31 dec 2007 is 52 01 53
03 jan 2010 is 01 53 00
02 jan 2011 is 01 52 00
01 jan 2012 is 01 52 00
03 jan 2016 is 01 53 00
01 jan 2017 is 01 52 00
31 dec 2018 is 52 01 53
03 jan 2021 is 01 53 00
02 jan 2022 is 01 52 00
01 jan 2023 is 01 52 00
30 dec 2024 is 52 01 53
31 dec 2024 is 52 01 53
03 jan 2027 is 01 53 00
02 jan 2028 is 01 52 00
31 dec 2029 is 52 01 53
Calendering software, including the one from a software developer quite known for not following standards has converged on the ISO week number.

Tags: , ,
2013-12-24 (#) 4 years ago
Modelled after the ntp server statistics at cs.uu.nl I created years ago I recently started gathering stats on my own. Today I had some time to spare to actually create some graphs from those ntp stats: NTP server stats.

Tags: , ,
2013-12-17 (#) 4 years ago
I looked up the details of the right configuration for ntpd to allow a reset of the packet counters without restarting ntpd for the ntp server project. Relevant part of /etc/ntp.conf:
keys /etc/ntp/ntp.keys
trustedkey 10
requestkey 10
controlkey 10
And in /etc/ntp/ntp.keys is one key 10. And it works:
ntpdc> syss
time since restart:     12
time since reset:       12
packets received:       10
packets processed:      8
current version:        8
previous version:       0
..
ntpdc> reset sys
Keyid: 10
MD5 Password: 
done!
ntpdc> syss
time since restart:     19
time since reset:       3
packets received:       2
packets processed:      1
current version:        1
previous version:       0
..
Learned from How do I configure remote administration - ntp faq and miscellaneous commands and options - ntpd.

Tags: , ,
2013-12-17 (#) 4 years ago
End of an era: just shut down doei.cs.uu.nl which was timeserver for cs.uu.nl from August 2003 to August 2006 and still saw active ntp traffic today. The complete history of timekeeping at cs.uu.nl is at Ntp events log - helpdesk.cs.uu.nl.

Tags: ,
2013-05-14 (#) 4 years ago
Update to the NTP server project: I took pictures of the hardware and all the crystals I saw on the mainboard, visible at NTP server set on flickr. And the crystal involved in timing was easy to find: the standard timing crystal in PCs uses a 14.318 MHz crystal, the fourth crystal in the pictures.

Tags: ,
2013-05-13 (#) 4 years ago
I found the old rockwell jupiter gps board which I had not used in years and hooked it up to the NTP server project system. I was used to this GPS taking ages to get a location fix and being very finicky about reception. Not this time: between hooking it up to the system and walking back to my laptop and checking the gps output with minicom it already had enough of a location fix to start sending PPS pulses. And next..
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xxxxxxxxxxxxxxx .PPS.            1 u    1   16    7   15.570   -6.927   9.294
 xxxxxxxxxxxxxxx .INIT.          16 u    -   64    0    0.000    0.000   0.000
 chime1.surfnet. 194.171.167.130  2 u   35   64    1   18.643   -7.491   0.000
 chime2.surfnet. .GPS.            1 u   34   64    1   19.214   -6.526   0.000
oPPS(0)          .PPS.            0 l    1   16    3    0.000   15.431   1.227

Update: But the situation isn't ideal, the PPS is voted falseticker after a while. Looking at the NMEA data, specifically the $GPRMC messages I notice there is no fix at all, but the PPS indicator (carrier detect) keeps ticking so minicom keeps switching between 'Online' and 'Offline'. At least this means all the bits are working.

Tags: , ,
2013-05-12 (#) 4 years ago
Update for the NTP server project: the SATA cables arrived and I managed to fit everything in the case. I think I removed and replaced the central fan in the case about 15 times, it is always in the way whenever anything happens in the front area of the 1U case. Ubuntu 12.04 LTS is now happily installing on a linux software raid.

Interestingly, when I copy the Ubuntu 12.04 LTS .iso to an USB stick as-is it boots and works fine, when I use usb-creator-gtk on an Ubuntu 10.04.4 LTS system with the Ubuntu 12.04 LTS .iso (amd64) it creates an USB stick which hangs during boot. I guess Ubuntu is also using isohybrid for .iso images now but usb-creator-gtk doesn't recognize those somehow.

Update: The ntp package from Ubuntu 12.04 includes no ATOM refclock support (refclock 22). So I removed the package again and built ntpd from sources, using the hints from LinuxPPS NTPD support on how to make sure the right timepps.h is available. The first tests look good:
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xxxxxxxxxxxxxxx .PPS.            1 u   11   16  377   15.920   -2.472  35.941
 xxxxxxxxxxxxxxx .INIT.          16 u    -   64    0    0.000    0.000   0.000
+chime1.surfnet. 192.87.106.3     2 u   39   64  177   14.826   -1.898  28.043
+chime2.surfnet. .GPS.            1 u   30   64  177   18.103   -3.296   1.623
 PPS(0)          .PPS.            0 l    -   16    0    0.000    0.000   0.000
I have a rockwell jupiter gps board with PPS support available to test with.

Tags: , ,
  Older news items for tag time ⇒
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews, Weather maps