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.
[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:
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.
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:
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.
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:
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
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:
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.
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.
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:
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.
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:
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:
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
---
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.
-------- 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
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
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.
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.
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.
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).
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'.
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.
echo s > /proc/sysrq-trigger to force a sync
echo u > /proc/sysrq-trigger to force an unmount of all filesystems
I killed the virtual machine with virsh destroy (the virtualization equivalent of pulling the plug)
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
I booted the virtual machine and it had indeed filesystem issues
So reboot in maintainance mode and did a filesystem check
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).
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:
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.
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.
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.
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
$ 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:
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.
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.
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'
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.
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.
----- 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:
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
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:
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.
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.
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.
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:
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.
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!
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
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:
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.
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 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
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.