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.