News items for tag time - Koos van den Hout

2021-01-13 Fiber to the shed 1 month ago
There is no fiber to our home in the near future but I am working on laying another fiber route: from the switch in the cupboard downstairs to the shed. This is because the NTP server in the shed still has intermittent connectivity issues when using 2.4 GHz wifi due to the 2.4 GHz wifi channels being very crowded. The wifi dongle has no 5 GHz support and I don't think I would get it very reliable. But other options are also not ideal. As a radio amateur I can't go back to using powerline (network over power cables) and I wouldn't feel safe with a network cable running that far should a lightning strike ever occur. I should write "occur again" since I have had a network switch with probable lightning damage before.

The only option left is what you guessed from the title of this post: fiberoptic cable. No interference to my radio reception and a lot less chance of lightning blowing up parts of the network and connected computers. But a whole new world of fiber types, fiber lengths, wavelengths, connector types and interface types opened up to me. The switch in the cupboard downstairs has SFP ports, but how to get beyond that.

The raspberry Pi 3B+ that I use is 100 mbit only and I wasn't sure how to handle that. So I asked someone who is very good with fiber networks to explain to me what options are available and that person dug up some lengths of fiber that are no longer used and some 100 mbit fiberoptic transverters that were also a wrong purchase. So I already have the connectivity hardware available.

Now all I need is a physical route between the shed and the rest of the network. There is an old plastic pipe from the shed to the crawlspace of our house that was once used for heating will probably do the trick once I figure out how to remove the old heating pipes from it. I guess there is some real dirty work below the floor of our house and in the shed in my near future. I will also need to buy plastic tubing to safely guide the vulnerable fiber. And some hooks to hang this tube and other cables from the floor instead of having them lie in the sand in the crawlspace.

Since there is also an old gas pipe in the plastic pipe I will make really really sure first that one isn't connected somewhere.

This was all triggered by adding the ntp server in the shed to the NTP pool and having the pool monitoring system gripe about the server becoming unreachable as soon as I have wifi problems. The things I will do for serving the right time!

Tags: , ,
2020-10-04 Moved the new Raspberry Pi ntp server to the shed and did the last bits of configuration 4 months 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 7 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 7 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! 7 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 7 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 8 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 8 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 8 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: , ,

IPv6 check

Running test...
, 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

RSS
Meningen zijn die van mezelf, wat ik schrijf is beschermd door auteursrecht. Sommige publicaties bevatten een expliciete vermelding dat ze ongevraagd gedeeld mogen worden.
My opinions are my own, what I write is protected by copyrights. Some publications contain an explicit license statement which allows sharing without asking permission.
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews
This page generated by $Id: newstag.cgi,v 1.34 2020/12/31 15:36:31 koos Exp $ in 0.021034 seconds.