News items for tag time - Koos van den Hout

2020-10-04 Moved the new Raspberry Pi ntp server to the shed and did the last bits of configuration 1 month ago
I moved the new ntp server to the shed today. I found a nice case for it: an actual wooden box. I climbed on the roof of the shed to find a place for the GPS antenna (with magnetic base). Parts of the enclosures around our solar panels are from ferrous metals, so I found a place with an ok view of the sky to place the antenna and led the cable to a ventilation shaft to get it inside the shed. I made sure the cable was going up in the ventilation shaft first to avoid having a drip loop on one of our bicycles.

Although I did most work on the w1retap configuration before I couldn't get it running at first. I kept seeing the error message:
koos@henkp:~ $ LD_LIBRARY_PATH=/usr/local/lib/w1retap w1find DS2490-1
Error 119: Failed to set libusb configuration
It took some serious searching to find a hint: that is caused by the usb device file access rights. Solution is to install the 45-w1retap.rules that comes with w1retap into /etc/udev/rules.d.

At the moment weather data is being fetched on the Raspberry but the wifi between shed and house is so bad that the data stays there. I'm not sure how that can be fixed. It turns out the external wi-fi dongle I bought was listed as having 5 GHz support, but the reviews of the chipset used say it doesn't. The congestion in the 2.4 GHz band makes it very difficult to reach the pi. Doing a ping test over longer time gives me 91% packet loss.

I dug up a different 2.4 GHz antenna from the junkbox and suddenly the connection is stable with a lot less packet loss. This antenna is directional and now pointing right at my access point.

Now the weather data is collected and forwarded to the server for Weather station Utrecht Overvecht.

NTP didn't seem to work on the first try, I'm not seeing any data for the GPS_NMEA server. This works again after a powerdown/up.
Read the rest of Moved the new Raspberry Pi ntp server to the shed and did the last bits of configuration

Tags: , , ,
2020-07-04 Again with systemd in the new GPS Pi 4 months ago
Again and again systemd annoys me. This time in the GPS Pi configured for timing.

Since I want it to work perfectly at start I added the systemd rules as suggested by A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog with /etc/systemd/system/ublox-init.service containing:
[Unit]
Description=u-blox initialisation
Before=gpsd.service
Before=ntp.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/gpsctl -q -a -B 115200 --configure_for_timing

[Install]
WantedBy=multi-user.target
After reboot ntp was running, but no data at all from the gps unit, and gpsctl was unable to revive it. The solution was to disable the above unit and ntpd, powerdown and restart the whole system and try again. After that doing the changes by hand and starting ntpd worked fine.

It's probably some sort of race condition, but any time I try to make a system with systemd do something reliably I run into things like this.

Tags: , , ,
2020-07-03 Switched the GPS configuration to one optimized for timing 4 months ago
Based on A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog I switched the gps to a configuration optimized for timing. The default settings are optimized for location services, but I want an NTP server.

I used gpsctl to configure the ublox chip in the GPS/RTC Hat:
$ gpsctl -a -B 115200 --configure_for_timing -vv
Serial port ("/dev/ttyAMA0") open...
Serial port open and configured...
Automatically determining baud rate...
Trying 230400 baud...
Trying 115200 baud...
Trying 57600 baud...
Trying 38400 baud...
Trying 19200 baud...
Trying 9600 baud...
Synchronized on 9600 baud...
Changing baud rate to 115200...
Successfully changed baud rate to 115200...
After that I got location data at a high speed. I changed the /etc/ntp.conf parameters to use the GPS_NMEA and PPS drivers, with:
# PPS reference
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS

# GPS NMEA driver
server 127.127.20.0 mode 89 minpoll 4 maxpoll 4 iburst prefer
fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 time2 0.043 refid GPS
And now I get much better numbers:
$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l   14   16  377    0.000   -1.656   0.134
*GPS_NMEA(0)     .GPS.            2 l   13   16  377    0.000  -11.730   0.517
+ntpritchie.idef 131.211.8.244    3 u   44   64  377    4.263    1.436  62.373
+metronoom.dmz.c 192.87.106.3     2 u   44   64  377   12.141   -2.250  49.247
koos@henkp:~ $ ntpdc -c kern
pll offset:           -0.00142676 s
pll frequency:        7.468 ppm
maximum error:        4.934e-06 s
estimated error:      3.372e-06 s
status:               2001  pll nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  500 ppm
The time offset factors still need work, but I'm getting close!

Tags: , ,
2020-07-03 The GPS ticks! 4 months ago
I remembered the junkbox contains an active GPS antenna which I bought together with the gpskit gps unit in 2003(!). And some other bits and pieces included a SMA to BNC adapter so I put the little GPS antenna outside and connected it to the GPS/RTC Hat.

Before I was back behind a computer it was showing a location and within a few minutes it had a PPS pulse. I was used to cold start taking at least 15 minutes with the gpskit!

So I tested with ntpd talking to gpsd via shared memory. This gave an interesting offset between local gps time and a nearby ntp server.
$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*SHM(2)          .PPS.            0 l    6   64  377    0.000   -0.149   1.672
xSHM(0)          .GPS.            0 l    5   64  377    0.000  -104.51   1.943
+ntpritchie.idef 131.211.8.244    3 u  101   64  376    2.774    0.950  13.948
+metronoom.dmz.c 131.211.8.252    2 u   99   64  376   10.482   -0.844  10.638
$ ntpdc -c kern
pll offset:           -0.000136461 s
pll frequency:        -11.054 ppm
maximum error:        1.3748e-05 s
estimated error:      1.7071e-05 s
status:               2001  pll nano
pll time constant:    6
precision:            1e-09 s
frequency tolerance:  500 ppm
I'm not too happy about the fact that the GPS NMEA messages are seen as wrong, so I'm going to stop using gpsd and go for a setup optimized for timing.

Tags: , ,
2020-07-02 Setting up the Raspberry Pi to talk to the GPS/RTC board 4 months ago
With most of the hardware in, it is time to configure the Raspberry Pi to allow the GPS/RTC board to be installed. One tip was to do this before installing the board to avoid serial conflicts.

First steps based on Building a GPS Time Server with the Raspberry Pi 3 which uses a different GPS board.

Disabling tty service on the UART:
# systemctl stop serial-getty@ttyAMA0.service
# systemctl disable serial-getty@ttyAMA0.service
And make changes to /boot/cmdline.txt to disable serial console, removing the console=serial0,115200 part.

Also needed is to disable the use of the hardware uart for bluetooth. This device does not need to do bluetooth at all, so I disable the software.
sudo systemctl disable hciuart
And add the lines to disable the bluetooth uart to /boot/config.txt:
dtoverlay=pi3-disable-bt
And with that the UART is completely free to use for GPS and PPS messages. I made all these changes and only added the GPS/RTC hat to the Pi after these changes were done.

Next steps were to add the i2c settings according to the GPS/RTC manual. For this I added
dtoverlay=i2c-rtc,rv3028
dtoverlay=pps-gpio
And indeed the i2c bus appears as the manual says:
# apt-get install python-smbus i2c-tools
[..]
# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- 42 -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
I removed the fake-hwclock package and tested operation. On the commandline it works, but in a reboot I still see weird times in the log.

After that I did the changes to /lib/udev/hwclock-set, now it looks like:
dev=$1

#if [ -e /run/systemd/system ] ; then
#    exit 0
#fi
if [ -e /run/udev/hwclock-set ]; then
    exit 0
fi

if [ -f /etc/default/rcS ] ; then
    . /etc/default/rcS
fi

# These defaults are user-overridable in /etc/default/hwclock
BADYEAR=no
HWCLOCKACCESS=yes
HWCLOCKPARS=
HCTOSYS_DEVICE=rtc0
if [ -f /etc/default/hwclock ] ; then
    . /etc/default/hwclock
fi

if [ yes = "$BADYEAR" ] ; then
#    /sbin/hwclock --rtc=$dev --systz --badyear
    /sbin/hwclock --rtc=$dev --hctosys --badyear
else
#    /sbin/hwclock --rtc=$dev --systz
    /sbin/hwclock --rtc=$dev --hctosys
fi

# Note 'touch' may not be available in initramfs
> /run/udev/hwclock-set
The rtc has to be configured correctly, I used information from A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog to configure the rv3028 chip. Get the gpsctl tool and use configure-rv3208.sh to set up the chip. Now the rtc is correct and used at boot time.

I'm seeing NMEA messages when I run gpsd or ask the serial port for data. The NMEA messages are very limited because there is no GPS antenna connected yet.

Tags: , ,
2020-07-01 A new home timeserver: GPS/RTC board 4 months ago
The Raspberry Pi GPS/RTC Expansion Board from uputronics came in today (thanks mailman!).

Next part needed: a gps antenna. But that's on backorder with another supplier.

Also needed: time to install raspbian on the Pi and start testing.

Tags: , , ,
2020-06-20 A new home timeserver: first parts, a Raspberry Pi 5 months ago
And yet another Raspberry Pi is showing up for my home network. This will become the GPS-based timeserver. I may add it to the NTP Pool when I'm satisfied enough with it.

It will probably also replace the 'shed' weather station computer in the long run, to save on power use.

I added an extra USB-based wifi adapter to the Pi. The shed has no wired network and my experience with the other computer there is that dual-band (2.4 GHz and 5 GHz) wifi support is the best way to have a chance to get working network.

I also ordered the Raspberry Pi GPS/RTC Expansion Board directly from uputronics.

Tags: , , ,
2020-06-15 A new home timeserver on order 5 months ago
After earlier tries to have a nice GPS-based timeserver for my home network I noticed a simple but very effective GPS 'hat' for the Raspberry Pi, the Raspberry Pi GPS Hat from Uputronix. While the Pi's are already taking over the home network just one more could be a nice addition. In the longer run this will probably replace the shed computer.

So I ordered a Pi with an added dual-band WiFi adapter, a case, the GPS hat and a GPS antenna. The GPS hat has PPS support so I will get the time correct. With the instructions from 5 minute guide to making a GPS Locked Stratum 1 NTP Server with a Raspberry Pi it should be easy. If this all works I may even add the resulting Pi to the IPv6 NTP Pool.

Update 2020-06-16: SOS Solutions came back with some bad news: the uputronix Pi GPS Hat isn't available anymore. I'm now looking at the comparable adafruit hardware which is somewhat more expensive, but offers the same options.

Update 2020-06-18: And the adafruit hardware is also not available soon. I cancelled the GPS unit part of the order and I'm looking at sourcing a GPS module for the Pi from another source. The GPS hat which sossolutions no longer sells is originally from uputronics where a newer version of the Raspberry Pi GPS/RTC Expansion Board is listed as available on the site. Based on a ublox chipset which allows me access to a lot of the GPS data.

Tags: , , ,
2019-11-13 Trying Suricata intrusion detection system (IDS) 1 year ago
After hearing about intrusion detection systems a few times I decided to give one a try at home. Although a lot of attacks are blocked I sometimes see weird attacks and it would be nice to have a better idea of what exactly the attack was.

Yes, I have weird interests sometimes. I'm glad I have an ISP (xs4all) where I can select the option 'give me the completely unfiltered Internet connection' so I even see SMB protocol attempts.

I first tried 'snort' but that doesn't deal with PPP interfaces by default. It can be recompiled to accept those but I did not want that. The next option I heard about is 'Suricata' which is running at the moment.

I was amused by the reports of DDoS-like NTP traffic. Those are caused by the NTP statistics gathering. I know NTP can be abused for generating DDoS traffic but all security reports about NTP servers I manage have been false positives.

Anyway it's running and complaining a lot about the traffic it sees. For example the IPv6 port scan/network mapping attempts I noticed two months ago are still active.
11/13/2019-15:06:59.703451  [**] [1:2002911:6] ET SCAN Potential VNC Scan 5900-5920 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 240e:00f7:4f01:000c:0000:0000:0000:0003:6050 -> 2001:0980:14ca:0001:020d:56ff:fece:ffe1:5901
11/13/2019-15:08:39.645780  [**] [1:2002911:6] ET SCAN Potential VNC Scan 5900-5920 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 240e:00f7:4f01:000c:0000:0000:0000:0003:5167 -> 2001:0980:14ca:0001:020d:56ff:fece:ffe6:5901

Tags: , ,
2018-01-23 Avoiding the linux statefull firewall for some traffic 2 years 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 2 years 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! 3 years 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 4 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 4 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 5 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... 5 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 5 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 5 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 (#) 6 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 (#) 6 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: , , ,
  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