News archive October 2020 - Koos van den Hout

This weekend was the CQWW DX SSB contest, which is one of the bigger contests on the amateur radio calendar. I had planned to participate, I made sure to get my contest software TLF completely configured and tested before the contest. But I didn't get around much to it most of Saturday. I only started Saturday evening to make some contacts on 40 meters which wasn't very successful from my home station.

Sunday afternoon things got a lot better when I tried the 20 meter and 10 meter amateur bands. Yes, 10 meter was open during the contest. This wasn't completely surprising as I made a number of 10 meter FT8 contacts earlier in the week.

The claimed results:

Band   160   80   40   20   15   10
QSO's    0    0    5   31    0   25
Cty      0    0    4   16    0   15
Zone     0    0    3    4    0    3
Pts: 61  Mul: 45 Score: 2745       

The raw scores in the "Assisted low all bands" category put me at rankings #862 (of 997) for world, #510 (out of 566) for Europe and #46 (out of 54). Not bad for the time I had available.

I have one Apache server exposed to the outside world for IPv6 clients (because of a history in hostnames going back to the 20th century). So after enabling OCSP for haproxy I decided to have a look at OCSP stapling for Apache 2.4. That's even easier than haproxy since Apache 2.4 will fetch the ocsp data itself. I followed Apache 2.4 SSL/TLS Strong Encryption: How-To OCSP Stapling and it works.

So now the current score at the Qualys SSL server test for koos.idefix.net is A+ both via IPv4 and IPv6.

I am upgrading Devuan linux installations from ascii to beowulf to get newer packages and continued security updates. There is only one package where I really want a newer version: openssl, so I can start using TLSv1.3.

This upgrade is just as simple as the upgrade from Devuan jessie to ascii three years ago. Just change the release name version and use apt update and apt dist-upgrade commands.

Today I did the development webserver and apache didn't start afterwards. I found out I need to enable php7.3 by hand, in the previous configuration php7.0 was enabled. A thing to keep in mind when upgrading the production webserver.

Uit de text/plain versie van de laatste mail van azerty:

DUMMY HEADER

Vestibulum volutpat pretium libero. Cras id dui. Aenean ut eros et nisl sagittis
 vestibulum. Nullam nulla eros, ultricies sit amet, nonummy id, imperdiet feugia
t, pede. Sed lectus. Donec mollis hendrerit risus. Phasellus nec sem in justo pe
llentesque facilisis. Etiam imperdiet imperdiet orci. Nunc nec neque. Phasellus
leo dolor, tempus non, auctor et, hendrerit quis, nisi.

Productnaam 1

Nam pretium turpis et arcu. Duis arcu tortor, suscipit eget, imperdiet nec, impe
rdiet iaculis, ipsum.

https://azerty.nl

MEE INFO

Productnaam 3

Nam pretium turpis et arcu. Duis arcu tortor, suscipit eget, imperdiet nec, impe
rdiet iaculis, ipsum.

https://azerty.nl

meer info

Productnaam 4

Nam pretium turpis et arcu. Duis arcu tortor, suscipit eget, imperdiet nec, impe
rdiet iaculis, ipsum.

https://azerty.nl/

meer info

De text/html versie bevat wel informatie. Iets met hardware voor gamers, dus ik kan verder de mail van harte weggooien.

I noticed when viewing my resulting track that there was something weird about the time. In the gpx file it was visible that the waypoints were not processed in order. So I searched for the way to make gpsbabel sort the waypoints by time. It took a bit of searching because I couldn't find any sample of sorting by time or other sorting options. But with some reading and thinking I found:

koos@kernighan:~/garmin$ gpsbabel -x sort,time -i garmin_fit -f 2020-10-20\ 13-12-51.fit -o gpx -F 2020-10-20\ 13-12-51.gpx
koos@kernighan:~/garmin$ 

The -x sort,time is 'sort by time'.

And I cycled 36 kilometers today. Some slight uphill parts, which lower my speed seriously. And the accompanying downhill parts increase my speed (and I keep pedalling, no need to limit my speed options as long as it's safe).

I have a few days holiday and today I decided to work on cycling a bigger distance. In the end I cycled 90 kilometers (on my cycle computer) or 84 kilometers (according to the GPS). Both are fine with me, a good test of doing such a distance.

I tried to get routes with lots of long straight paths, which are nice on my recumbent. That worked out ok. I cycled home - De Bilt - Bunnik - Odijk - Werkhoven - Cothen - Wijk bij Duurstede - Amerongen - Elst - Veenendaal - Renswoude - Scherpenzeel - Woudenberg - Zeist - De Bilt - home.

Average speed according to my cycling computer which will stop measuring when I pause: 20.60 kilometers per hour. Top speed was 47 kilometers per hour on a long downhill stretch near Zeist.

On my to-do list was the idea to look at OCSP stapling for haproxy. OCSP is Online Certificate Status Protocol which wraps the revocation status of a certificate in the certificate negotiation. This speeds up the TLS setup a bit since the client doesn't have to make an extra connection to the OCSP responder of the certificate issuer and it adds a bit of privacy because the certificate issuer doesn't see which client requests the status of a certificate.

Finding the right way to get the ocsp updates to haproxy was a bit of work, eventually made some modifications to the script in HAProxy OCSP stapling. I also used the remarks in OCSP stapling with HAProxy. From pitfall to euphoria because I saw the "OCSP single response: Certificate ID does not match any certificate or issuer" error message. I had to restart haproxy first to make it enable ocsp processing (because now each server certificate has its own .ocsp file) and now it accepts the "set ssl ocsp-response" command.

Update: I'm not completely happy yet: after a certificate was renewed haproxy complained about the .ocsp file being out of date. Which is fully correct, since that .ocsp file was about a previous version of the certificate. This needs more work. Ideally I would check the validity of the .ocsp file before deciding to renew it. And fetch the new ocsp data before reloading a renewed certificate.

Anyway, the 'TLS setup' part of connecting to sites like idefix.net goes from 20-21 milliseconds to 5-8 milliseconds. Not a blinding fast improvement but all bits help and I like to have optimal security and privacy.

I had a look at some weblogs and after removing the entries caused by webbots most of the rest of the traffic was attacks. All on stuff I don't have (usually wordpress), but one thing was noticeable:

37.59.47.61 - - [13/Oct/2020:00:17:34 +0200] "GET ////nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 404 747 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"
37.59.47.61 - - [13/Oct/2020:00:17:41 +0200] "GET /////nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 301 715 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"
37.59.47.61 - - [13/Oct/2020:00:17:43 +0200] "GET /nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 404 747 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"

From what I've found about the 'nette microframework' there are callbacks, but none of those is called shell_exec.

pi4raz igate running showing packet

I dug into 'how to build code for the ESP32' and found Installing ESP32 Add-on in Arduino IDE (Windows, MacOS X, Linux) and since I have the Arduino IDE working enough for the previous project with a programmable microcontroller: the nanoKeyer morse keyer I did the steps to add ESP32 support.

I had to find the right settings for the specific ESP32 chip and since it is labeled "ESP-WROOM-32" I ended up at ESP-WROOM-32: Uploading a program with Arduino IDE and used the settings 'Board: FireBeetle-ESP32', 'Flash Frequency: 80 MHz', 'Upload Speed: 921600'.

The sourcefile to compile and upload to the ESP32 in the pi4raz igate is pa2rdk/APRS_IGate/APRS_IGate.ino.

I changed the definition of struct StoreStruct for a bigger wifi password (64 chars) and noticed that after uploading the updated code the last parts of the StoreStruct got mangled. I changed to #define EEPROM_SIZE 174 which seems to fix this.

I will admit to doing a bit of cargo-culting here: just following some google results and fiddling a bit until it works, with limited idea what I'm actually doing and what the effect of my changes is. The kind of weird results I got after growing the wifi password buffer suggested clearly to me that I was looking at some sort of buffer overflow, so I started looking for buffer sizes.

But the igate is now talking to the APRS network. First results visible at PE4KH-10 tracked on aprs.fi.

Vandaag actief met de radio met 40 meter en 20 meter morse en FT8, en heel regelmatig valt de VDSL link uit en moet opnieuw opgebouwd worden. Op zoek naar meer informatie over de Draytek Vigor 130 en impulse noise protection kwam ik DrayTek Vigor 130/165 Status Begriffe und Abkürzungen (cookiewalled) tegen met de uitleg over vdsl status more.

Op mijn modem:

> vdsl status more
  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
                  Near End        Far End    Note
 Trellis      :      1               1
 Bitswap      :      0               0
 ReTxEnable   :      0               1
 VirtualNoise :      0               1
 20BitSupport :      0               0
 LatencyPath  :      0               0
 LOS          :      8              26
 LOF          :      0               0
 LPR          :      0               8
 LOM          :      0               0
 SosSuccess   :      0               0
 NCD          :      0               0
 LCD          :      0               0
 FECS         :      0            209592 (seconds)
 ES           :      0              50 (seconds)
 SES          :      0              18 (seconds)
 LOSS         :      0               0 (seconds)
 UAS          :     85            7778 (seconds)
 HECError     :      0               0
 CRC          :      0             748
 RsCorrection :      0               0
 INP          :     10             360 (symbols)
 InterleaveDelay :    800               0 (1/100 ms)
 NFEC         :    123              32
 RFEC         :     16              16
 LSYMB        :   8977              16
 INTLVBLOCK   :    123              32
 AELEM        :      0            ----

Die 'ReTxEnable' is het ingeschakeld zijn van G.INP volgens bovenstaande pagina dus wilde ik dus aan beide kanten aan hebben. Commando gevonden: om dat te configureren:

> vdsl optn retx bi on
 retx         [US] =     ON, [DS] =     ON.

You have to reboot the system after you change settings.

Maar ook na reboot en heronderhandeling VDSL geen ReTxEnable voor het near end.

After finishing the Raspberry Pi ntp server in the weekend I continued on a long-running project: the PI4RAZ igate I started working on in June (and ordered in September 2019). I dragged the soldering iron, the soldering mat and lots of parts downstairs to work on it on Sunday evening. Soldering lots of pins to an Arduino nano is hard work.

I finished the last soldering on Monday evening and had a long and hard look at all the connections and redid a few. I used a multimeter to make sure three really close soldering islands weren't connected, found two with 0 ohms between them in both polarities so I fixed that issue.

After that I took the plunge of actually powering up the print and it looks good. The display shows output and I can walk through the setup when I connect a usb cable to the ESP32 module.

I can't make it run yet: the space for the wifi password in the ESP32 module is only 25 characters which is not enough for our home network. So I will have to look into changing the code (it has an update anyway: Software update iGate - PI4RAZ) and find a working way to program an ESP32 from linux.

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.