A month later I'm still seeing SMTP floods from 185.222.211.11 and adjacent addresses. I activated the sendmail-reject filter ruleset in fail2ban which keeps several addresses in that range blocked most of the time.

Given reports like 185.222.211.238 | Cloud Core LP | AbuseIPDB and 185.222.211.243 | Cloud Core LP | AbuseIPDB I'm not the only one seeing abuse from this range.

This weekend I participated in the IARU HF Championship and made a nice number of contacts given the available time in which I could call out my callsign. Before the contest the radio propagation was a bit dissapointing and I did most of my preparation at the very last minute.

For the contest logging I used the TLF linux contest logger which does not support the IARU HF Championship out of the box. But someone posted about this contest to the TLF development mailing list and shared the configuration and initial exchange list, so it was minimal work to get going. With this configuration TLF worked as a logger, it just didn't calculate the multipliers in the contest correctly.

In the end I made 95 contacts, which is a nice improvement over the previous time I participated in this contest: IARU HF Championship PE4KH 2017. Of the 95 contacts, 19 were on the 40 meter band (Saturday evening) and 76 on the 20 meter band (Saturday afternoon and Sunday morning).

I did not participate in the 2018 edition because it was the weekend we left for our summer holiday. The 2018 IARU HF championship was also the World Radio Team Championship 2018 so I missed the chance to work one of those stations. I did follow the whole preparation for the WRTC 2018 and had a look at the developments in the scores during that weekend.

Op 9 Juli is de laatste omschakeling van DVB-T naar DVB-T2 geweest in Nederland, waarmee DVB-T ten einde gekomen is. In de ether is dus van 2 oktober 1951 tot 10 december 2006 analoog uitgezonden en van 10 december 2006 tot 9 juli 2019 in DVB-T.

De Samsung televisie die we aangeschaft hebben in mei 2013 snapt er niets meer van bij een scan op het UHF spectrum. Vooraf had ik gezocht of deze televisie DVB-T2 en de gebruikte codec ondersteunde en dat was wat onduidelijk, het hing af van de taal van de handleiding. Uiteindelijk werkt het dus duidelijk niet, de scan voor digitale tv signalen levert helemaal geen resultaat op.

Dus we hebben geen NPO 1/2/3 meer free-to-air wat we gebruikten sinds de prijsverhogingen en wijzigingen van Ziggo in 2015. Bij een eerste test bleken de livestreams van de NPO applicatie met chromecast ook te werken. Alleen heeft een hapering van de internetverbinding ook gelijk het gevolg dat de televisie stopt.

Het voelt wel raar om voor 'broadcast' televisie een stream aan te zetten, maar dat zal wel liggen aan de geschiedenis die er voor mij achter zit.

This weekend was the DL-DX RTTY Contest 2019. In the category 'B': single operator, multiband, 6 hours. Not in the category for dipole or groundplane antenna since I used the endfed antenna.

I made 80 contacts, 37 on the 20 meter band and 43 on the 40 meter band. Propagation wasn't great and most of my contacts were search & pounce mode, answering calls from other contest stations. I did call CQ a few times, and one of those was spotted by the reverse beacon network instantly and gave me 3 contacts in short succession.

Operation in the contest was limited due to other things in the weekend so I fitted in the 6 hour category nicely. I did some other things on the radio on Sunday and somewhere in the afternoon I noticed a funny electronics smell and the output power from the amplifier had dropped. I found out the output voltage from the modified HP DPS-700 GB server power supply had dropped to about 10.6 volts. Time to find out whether this problem fixes itself or it's time to find another server power supply that will deliver over 40 ampere current at somewhere around 13 volt.

Doing some more reading on haveged made me decide to test the actual randomness of my setup with haveged and randomsound which I created to fix the lack of entropy for dnssec signing operations so I booted the same testing virtual machine which can tap from the host /dev/random. I ran rngtest until it was time to shut down the laptop which was showing the output. The result:

$ rngtest < /dev/random 
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
^Crngtest: bits received from input: 4999640
rngtest: FIPS 140-2 successes: 249
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=303.011; avg=543.701; max=5684.774)bits/s
rngtest: FIPS tests speed: (min=43.251; avg=64.587; max=84.771)Mibits/s
rngtest: Program run time: 9194254192 microseconds

I ratelimited the virtio-rng-pci driver from the host, so the test took a really long time. Given earlier tries with dnssec-signzone this is fast enough.

No need to buy a hardware random generator, although they are way cool and it would be an idea to have a source of correctness (NTP) next to a source of randomness.

Update: I ran rngtest on /dev/urandom and I had to ask for a really big load of blocks to get failures. The first test with 249 blocks gave the same result as above, just a lot higher bit rate. So now I know less about the correct randomness of my setup but at least the test shows that I can safely run dnssec-signzone which was the original idea.

I was looking at the options for implementing DNSSEC on the domains I have, and started doing this on a domain name that is just used for web redirects, so I won't break anything serious when I make an error. And I am looking at monitoring options at the same time.

Looking for usable documentation I found DNSSEC signatures in BIND named - sidn.nl which shows and explains a lot of the options for doing this with bind9, including full automation. I want to take steps I understand, so I will start with careful minimal automation on a domain name that I can 'break'.

Following that documentation I created a key-signing key (KSK) and a zone-signing key (ZSK). I used the /etc/bind/keys directory which is the standard location.

The first dnssec-signzone action took 54 minutes. After waiting for a bit I started wondering what was happening and it turned out to be a problem with entropy: the signing uses a lot of data from /dev/random. I have the virtio-rng module loaded but the host wasn't making randomness available to the guest operating system. The host server does run randomsound to get more entropy since there is no hardware random number generator available.

Documentation on how to 'forward' randomness from the host to the client virtual machine: Random number generator device - Domain XML format

So I did some tests with a test virtual machine with a similar configuration. The results:

• Just software kernel rng in the virtual machine: 54 minutes.
• Offering virtio-rng randomness from the host from /dev/urandom running randomsound: less than 1 second.
• Offering virtio-rng randomness from the host from /dev/random running randomsound: 11 minutes 10 seconds.
• Offering virtio-rng randomness from the host from /dev/random running randomsound and haveged: less than 1 second.

Installing haveged which gathers entropy from hardware processes fixes the whole problem.

Now to implement the same settings for the virtual machine running the production nameserver and I'll be able to take the next step.

My wife bought a new inkjet printer because the previous one was failing. The new one is a HP deskjet 2630, and it has wifi support. Out of the box it was playing access-point on the busy 2.4 GHz band making it even more crowded so I asked her to disable the wifi. She used the printer nicely with the USB cable and asked me to look into putting it on the network so it can be in a different room and not in the way.

Today I had a look into that. I hoped it could be a wifi client. Yes it can. The first two explanations on how to set that up started with 'using the windows HP software'. The third one had 'press and hold the wifi button to connect using wps'.

So I enabled wps on the wifi network, did the wps mating and saw arpwatch note the new IPv4 addres in use.

For a laugh I tried whether it has an IPP server running. It has. So adding it under linux should not be completely impossible. Search for 'linux hp deskjet 2630' and notice it needs the hplip package. Which is already installed in my recent Ubuntu.

So I just opened the cups printer browser, saw the HP deskjet show up, selected that and printed a test page. Which came out correctly.

Typing this took longer than the actual steps I took, and searching websites with explanations took most of the time.

I'm still in the "what just happened?" stage, remembering long fights with printer drivers, network printing and losing everything at upgrades.

Update: Adding the printer in Windows 10 was harder, we needed to use the HP software to add it which tried to sell us "HP instant ink" service before allowing the printer to be used in Windows.

I noticed a really big load of probes for names under idefix.net, maybe looking for possible ways to attack systems. Source is a resolver at a VPS hoster (linode). I can find websites that will do such a search for me (some even hosted at linode) but in a quick search I can't get the same pattern in names.

30-Jun-2019 03:53:24.538 client @0x7f578c0c7230 45.33.59.87#11197 (sync.idefix.net): query: sync.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.539 client @0x7f578c0c7230 45.33.59.87#9151 (bugzilla.idefix.net): query: bugzilla.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.540 client @0x7f578c0c7230 45.33.59.87#64181 (mailgw.idefix.net): query: mailgw.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.540 client @0x7f578c0c7230 45.33.59.87#46518 (se.idefix.net): query: se.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.542 client @0x7f578c0c7230 45.33.59.87#31554 (tw.idefix.net): query: tw.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.544 client @0x7f578c0c7230 45.33.59.87#56050 (origin-www.idefix.net): query: origin-www.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.547 client @0x7f578c0c7230 45.33.59.87#24795 (bugzilla.idefix.net): query: bugzilla.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.558 client @0x7f578c0c7230 45.33.59.87#60127 (log.idefix.net): query: log.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.564 client @0x7f578c0c7230 45.33.59.87#16816 (reseller.idefix.net): query: reseller.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.564 client @0x7f578c0c7230 45.33.59.87#46743 (cdn3.idefix.net): query: cdn3.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.567 client @0x7f578c0c7230 45.33.59.87#15593 (books.idefix.net): query: books.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.568 client @0x7f578c0c7230 45.33.59.87#23918 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.570 client @0x7f578c0c7230 45.33.59.87#24503 (srv1.idefix.net): query: srv1.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.570 client @0x7f578c0c7230 45.33.59.87#20759 (cacti.idefix.net): query: cacti.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#62846 (developer.idefix.net): query: developer.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#40156 (delta.idefix.net): query: delta.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#42375 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#25727 (delta.idefix.net): query: delta.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#19060 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#63258 (katalog.idefix.net): query: katalog.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#35848 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.574 client @0x7f578c0c7230 45.33.59.87#50079 (archives.idefix.net): query: archives.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.575 client @0x7f578c0c7230 45.33.59.87#18507 (pg.idefix.net): query: pg.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.577 client @0x7f578c0c7230 45.33.59.87#62479 (manager.idefix.net): query: manager.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.577 client @0x7f578c0c7230 45.33.59.87#41830 (wwwtest.idefix.net): query: wwwtest.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.578 client @0x7f578c0c7230 45.33.59.87#14914 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.581 client @0x7f578c0c7230 45.33.59.87#25754 (auction.idefix.net): query: auction.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.582 client @0x7f578c0c7230 45.33.59.87#42057 (students.idefix.net): query: students.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.729 client @0x7f578c0c7230 45.33.59.87#63617 (gosper.idefix.net): query: gosper.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.866 client @0x7f578c4feb30 45.33.59.87#57706 (books.idefix.net): query: books.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.870 client @0x7f578c0d59c0 45.33.59.87#57714 (delta.idefix.net): query: delta.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.872 client @0x7f578c51d780 45.33.59.87#57718 (delta.idefix.net): query: delta.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.874 client @0x7f578c0d59c0 45.33.59.87#57722 (archives.idefix.net): query: archives.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.874 client @0x7f578c4feb30 45.33.59.87#57726 (wwwtest.idefix.net): query: wwwtest.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.875 client @0x7f578c52bda0 45.33.59.87#57728 (auction.idefix.net): query: auction.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.876 client @0x7f578c51d780 45.33.59.87#57708 (katalog.idefix.net): query: katalog.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.879 client @0x7f578c0d59c0 45.33.59.87#57712 (srv1.idefix.net): query: srv1.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.943 client @0x7f578c0c7230 45.33.59.87#50168 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.945 client @0x7f578c0c7230 45.33.59.87#59186 (cacti.idefix.net): query: cacti.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.947 client @0x7f578c0c7230 45.33.59.87#30509 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.948 client @0x7f578c0c7230 45.33.59.87#25611 (manager.idefix.net): query: manager.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.948 client @0x7f578c0c7230 45.33.59.87#53201 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.950 client @0x7f578c0c7230 45.33.59.87#25331 (students.idefix.net): query: students.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.954 client @0x7f578c0c7230 45.33.59.87#44043 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.954 client @0x7f578c0c7230 45.33.59.87#9075 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.236 client @0x7f578c4feb30 45.33.59.87#57748 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.245 client @0x7f578c52bda0 45.33.59.87#57752 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.250 client @0x7f578c51d780 45.33.59.87#57750 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.257 client @0x7f578c0c7230 45.33.59.87#46992 (katalog.idefix.net): query: katalog.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.259 client @0x7f578c0d59c0 45.33.59.87#57754 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.263 client @0x7f578c0c7230 45.33.59.87#50662 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.264 client @0x7f578c0c7230 45.33.59.87#23392 (eu.idefix.net): query: eu.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.271 client @0x7f578c0c7230 45.33.59.87#62305 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.293 client @0x7f578c0c7230 45.33.48.143#45998 (sam.idefix.net): query: sam.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.293 client @0x7f578c0c7230 45.33.59.87#43255 (banners.idefix.net): query: banners.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.299 client @0x7f578c0c7230 45.33.59.87#29869 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.302 client @0x7f578c0c7230 45.33.59.87#36595 (customer.idefix.net): query: customer.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.322 client @0x7f578c0c7230 45.33.59.87#6272 (cgi.idefix.net): query: cgi.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.327 client @0x7f578c0c7230 45.33.59.87#23561 (awstats.idefix.net): query: awstats.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.331 client @0x7f578c0c7230 45.33.59.87#58477 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.334 client @0x7f578c0c7230 45.33.59.87#12998 (cgi.idefix.net): query: cgi.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.335 client @0x7f578c0c7230 45.33.59.87#41654 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.335 client @0x7f578c0c7230 45.33.59.87#36692 (hd.idefix.net): query: hd.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.337 client @0x7f578c0c7230 45.33.59.87#52048 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.471 client @0x7f578c0c7230 45.33.59.87#11817 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.479 client @0x7f578c0c7230 45.33.59.87#40723 (webgreenblatt.idefix.net): query: webgreenblatt.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.481 client @0x7f578c0c7230 45.33.59.87#57833 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.499 client @0x7f578c0c7230 45.33.59.87#26285 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.525 client @0x7f578c0c7230 45.33.59.87#51562 (cgi.idefix.net): query: cgi.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.533 client @0x7f578c0c7230 45.33.59.87#32101 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.534 client @0x7f578c0c7230 45.33.59.87#36210 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.543 client @0x7f578c0c7230 45.33.59.87#57693 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.568 client @0x7f578c53a3c0 45.33.59.87#57768 (katalog.idefix.net): query: katalog.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.569 client @0x7f578c565900 45.33.59.87#57772 (eu.idefix.net): query: eu.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.598 client @0x7f578c557170 45.33.59.87#57776 (banners.idefix.net): query: banners.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.617 client @0x7f578c590fb0 45.33.59.87#57780 (customer.idefix.net): query: customer.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.620 client @0x7f578c52bda0 45.33.59.87#57782 (awstats.idefix.net): query: awstats.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.630 client @0x7f578c0d59c0 45.33.59.87#57790 (hd.idefix.net): query: hd.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.637 client @0x7f578c5489e0 45.33.59.87#57788 (cgi.idefix.net): query: cgi.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.664 client @0x7f578c0c7230 45.33.59.87#35680 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.765 client @0x7f578c582820 45.33.59.87#57800 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.786 client @0x7f578c0c7230 45.33.59.87#59047 (sk.idefix.net): query: sk.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.805 client @0x7f578c565900 45.33.59.87#57802 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.825 client @0x7f578c590fb0 45.33.59.87#57804 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.840 client @0x7f578c0c7230 45.33.59.87#6873 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.843 client @0x7f578c0c7230 45.33.49.87#39819 (img4.idefix.net): query: img4.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.848 client @0x7f578c0c7230 45.33.49.87#35699 (registration.idefix.net): query: registration.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.856 client @0x7f578c0d59c0 45.33.59.87#57806 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.942 client @0x7f578c0c7230 45.33.49.87#49819 (registration.idefix.net): query: registration.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.081 client @0x7f578c51d780 45.33.59.87#57816 (sk.idefix.net): query: sk.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:26.288 client @0x7f578c0c7230 45.33.59.87#49749 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.309 client @0x7f578c0c7230 45.33.59.87#57344 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.399 client @0x7f578c0c7230 45.33.59.87#44649 (develop.idefix.net): query: develop.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.583 client @0x7f578c50d150 45.33.59.87#57826 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:26.634 client @0x7f578c0c7230 45.33.49.87#9259 (ares.idefix.net): query: ares.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.662 client @0x7f578c0c7230 45.33.59.87#9440 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.694 client @0x7f578c53a3c0 45.33.59.87#57830 (develop.idefix.net): query: develop.idefix.net IN A -E(0)TDC (194.145.201.42)

Ik was vandaag weer eens op de lokatie waar ik eerder tot de conclusie kwam Je draadloze microfoon is prima af te luisteren en dit keer heb ik die bewering gecontroleerd.

Niet eens met een scanner maar met een nog makkelijkere aanpak: een laptop met een rtl-sdr dongle er aan en gqrx er op.

De draadloze microfoons en de ontvangers op die lokatie zijn van Sennheiser, wat als voordeel heeft dat ze niet in kanalen denken maar dat de frequentie waar ze op staan gewoon op het display staat. Ik kon dus simpel aflezen van de ontvangers waar ik de microfoons moest 'zoeken'. In een testje kon ik inderdaad de draaggolf van de microfoon prima vinden na inschakelen en met een FM demodulator ook het geluid prima weergeven op de laptop.

Omdat dit een bijeenkomst was waar ook informatie besproken werd die niet vrij de wereld in mag was ik hier even alert op. Maar dankzij een toegevoegde ruimtemicrofoon aan het plafond werden de draadloze microfoons niet gebruikt tijdens de bespreking van gevoelige informatie. Na de besprekingen ben ik even aan de gang gegaan met de laptop en kon toen de ingeschakelde microfoon prima ontvangen.

Op zich is er niets mis met draadloze microfoons, maar er zijn dus situaties te bedenken waarin je denkt dat je stemgeluid alleen binnen een beperkte ruimte versterkt wordt maar wat er net buiten misschien ook opgevangen wordt.

This weekend I had time for the radio hobby and made some interesting new contacts. Friday evening was a bad start, with serious difficulties reaching other stations with FT8 on 20 or 40 meters. But Saturday daytime the 10 meter band was open and I even made contacts with two new countries on the 10 meter band: Lithuania and Montenegro. I guess it was an E-skip opening as I saw mostly "nearby" stations from Germany, England and other European countries. With ionospheric propagation those are usually "too close".

If you look at the map of 10 meter HF contacts by PD4KH there is a 'ring' with almost no contacts around my home location (I have made some really close contacts, but that would be via direct line of sight). Other contacts start in the south of France, the west of England and Poland. Nowadays ionospheric propagation on 10 meters doesn't happen very often so when I do make contacts it is via other forms of propagation that allow for shorter skip distances.

Later on Saturday the 10 meter band propagation stopped and 20 and 40 meters allowed nice amounts of contacts.

When I can make what contact on what frequency is still magical sometimes. I learn patterns that repeat themselves, but there are still enough surprises left.

Sinds april 1993 heb ik een xs4all login account (ja, van voor de start, mijn account is met de hand aangemaakt door Rop Gonggrijp). Sinds begin 1992 had ik al een xs4all uucp account voor kzdoos.xs4all.nl, tegenwoordig omgezet naar een bsmtp account (waarbij mail binnenkomt bij de xs4all mailservers en na de spamfiltering doorgestuurd wordt naar mijn server). Maar met de laatste plannen van KPN om het merk xs4all te gaan stoppen en zaken samen te voegen ben ik toch bang dat de unieke redenen om daar te blijven langzaam zullen vervallen.

Wat ik nodig heb is een plek met vast IPv4/IPv6 en een aardige uplink snelheid. Via xs4all kan dat gewoon thuis, maar misschien is op den duur een virtuele private server en een goedkope thuisaansluiting met daartussen een vorm van vpn ook een werkende oplossing.

Dus dan is het ook tijd om langzaam minder afhankelijk te worden van de bsmtp service voor kzdoos.xs4all.nl en langzaam maar zeker mijn eigen domeinnaam idefix.net voor e-mail in te voeren als primair adres. Wie weet heeft de bsmtp dienst bij KPN ook niet het eeuwige leven. De extra opties die van xs4all een goede provider maken voor een hobbyist zitten bij andere providers vaak in een zakelijk pakket of worden niet aangeboden.

Ik kon altijd beweren dat ik het e-mail adres wat ik gebruik gewoon ouder was dan spam e-mail.

Due to recent kernel updates I rebooted the home server and ran into only older kernels available. Some searching later I found out it booted from another disk than the disk the update manager was maintaining /boot on.

The solution was to mirror the /boot partition by hand and change the EFI boot setup to try a boot from both disks, so the machine will still boot when one half of the mirror is completely unavailable. I did buy mirrored disks to have the machine available with one disk unavailable.

Changing the EFI boot setup with efibootmgr was somewhat complicated, but I got it all done. How to add a second disk found via Partitioning EFI machine with two SSD disks in mirror - Unix & Linux stackexchange and understanding the numbers in the efibootmgr -v output via "efibootmgr -v" output question.

The ideal solution would be to have /boot and /boot/efi on mirrored partitions without metadata (so they are readable too from the efi loader as an unmirrored partition). According to what I read this is possible in Linux with devicemapper but there is not a lot of experience shared.