I recently bought new wifi access points to upgrade the wifi at home. The main reason was the fact that the TP-Link TL-WDR4300 bought 9 years ago was sometimes 'hanging' which was solved by rebooting it. This was starting to get annoying, and the family wants stable wifi which doesn't need instructions which button to press for reboot.

The upgrade path was going somewhat 'prosumer': support for multiple wireless SSIDs with a main and a guest network, and I wanted an extra access point in the shed for working in the back garden, as tested in april Using the network switch in the shed as remote powerswitch.

The choice was to go with the Mikrotik access points. For the shed and garden I bought the wAP.ac and for the main access point in the house the hAP.ax3. The latter has support for the latest and greatest wifi standards, including wifi 6 and WPA3.

It took me a while to configure them, the Mikrotik routerOS userinterface exposes all the options networking in Linux has, but it takes knowledge of bridging, routing and firewalling to get it all correct and doing what I want.

A remark on mastodon.radio triggered me: Quick reminder that there is a public RSS aggegator that combines all the ham radio blog feeds into one web site

Quick reminder that there is a public RSS aggegator that combines all the ham radio blog feeds into one web site:

blogs.radio

And I wanted to add the latest from my site PE4KH Amateur Radio but there was no RSS feed available.

I've been wanting to add such a feed for a while but didn't get around to it. This was the trigger I needed. The perl script that generates the feed for idefix.net has now been updated to allow for 'filtered' feeds for pe4kh.idefix.net and other sites that have a specific part of the main feed.

And I moved the script to version control so I can work on it on the development server and deploy to production when it's working fine.

Update: you can now find my posts over there

The feed is now accepted and imported on blogs.radio: PE4KH amateur radio - Blogs.radio.

This weekend was the morse edition of the Scandinavian Activity Contest and I decided to participate, mainly to get some more morse contesting experience.

I made 74 contacts, even some on the 10 meter band which cooperated Saturday afternoon.

PE4KH - NON-SCANDINAVIA EU PA

Band      QSO   Points   Multipliers
------------------------------------
80m          0       0       0
40m         13      13       9
20m         55      55      22
15m          0       0       0
10m          6       6       5
------------------------------------
Total       74      74      36

Dupes:     0
Invalid:   0
QSO Total: 74
Score:     2.664 (Diff: 2.664)
CATEGORY:  SINGLE-OP
BAND:      ALL
POWER:     LOW
OVERLAY:   NONE
STATION:   FIXED

I noticed two weeks ago the number of IPs causing failed sshd login attempts as measured by fail2ban was dropping. It was dropping so far I did some tests to make sure all the rules were still working.

Things have returned to 'normal' now, attempts are back and quite visible in the graphs.

A few weeks ago I saw 'buzz' all around about the RTL-SDR v4 dongle coming out: RTL-SDR Blog V4 Dongle Initial Release! and lots of people reporting clicking "buy now". I did the same, without even having a good reason to buy one. It is the third RTL-SDR dongle in the house, but the first one from RTL-SDR.COM. RTL-SDR dongles allow for the reception of radio signals in a wide range of frequencies where the processing of the signals is all done in the computer.

I ordered it through AliExpress but making sure I got the right version via RTLSDRBlog Store on AliExpress.

It arrived earlier and I can't get it to work with the Linux SDR software stack I use, even on the newest laptop, which uses:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name             Version        Architecture Description
+++-================-==============-============-==============================================================
ii  gqrx-sdr         2.15.8-1build1 amd64        Software defined radio receiver
ii  gr-osmosdr       0.2.3-5build2  amd64        Gnuradio blocks from the OsmoSDR project
ii  librtlsdr0:amd64 0.6.0-4        amd64        Software defined radio receiver for Realtek RTL2832U (library)

The dongle is recognized, but there is just noise, no signal to decode, even when I try strong broadcast stations. The previous RTL-SDR dongle receives the same stations fine, so it's an amplification or tuning problem.

Checking the web finds librtlsdr/librtlsdr: Software to turn the RTL2832U into an SDR - GitHub which has a recent commit: add rtl-sdr blog v4 support · librtlsdr/librtlsdr@fe22586 · GitHub which sounds exactly like what I would need. So it's not working.. yet.

One of my ever nagging issues with amateur radio at home is the amount of interference I get, which makes receiving weak amateur radio signals very hard or even impossible.

The mains power cables coming into the house seem to be one of the main sources, which would explain why the source of the interference is hard to pinpoint: it's everywhere around the mains power wires in the walls and ceilings.

I found Clean Up Your Shack – 2019 which has plans for a mains filter that should improve matters.

I ordered parts from Mouser. The exact parts weren't always available, so I had to do some searching for comparable parts. Including a somewhat bigger case and different cable glands. All the ferrite was available from Mouser exactly as wanted.

The order got delivered quickly. The next step was to find time to actually work on this project!

Recently I found time to sort out what I have and what I still miss to build it all. The ferrites ordered are so big and heavy they come in protective packaging to keep them from cracking due to bumps or the package handling!

I also did a 'test fit' putting all the parts in the case I bought. I thought it might be a bit big until I fitted all the ferrite in: the ferrite is very big, so the case I bought isn't really oversized!

I found out I'm not perfectly done yet. I could use a step drill to get the holes in the case perfectly round and I found out the cable glands I bought did not come with the matching nuts. Time for some more on-line orders!

Update

Parts ordered: mains power strip, the matching nuts for the cable glands and spade connectors. I checked which size step drill I would need and it turned out the hole for the cable gland is 15 millimeter and it would be easier to use a 16 millimeter drill.

In interesting DX news I saw OX3LX Greenland - DX-World which is a new entity for me. I got OX3LX in the log on FT8 on 28 August.

I also set an alert for Greenland in morse which helped me get OX3XR in the log on 6 September.

Both contacts were confirmed pretty fast, I am now at 164 entities confirmed in total (any mode) and at 95 entities in morse.

The search to get more countries confirmed in morse is continuing. At the end of July a team was active under the call 1A0C activating the entity Sovereign Militairy Order of Malta which is a catholic order with a lot of history. There is no territory for this entity, but internationally it is seen as a sovereign entity and radio amateurs like having yet another entity.

I got in the log with 1A0C and after donating to the good work of the Order of Malta Italian Relief Corps I got confirmation for these contacts.

Another new country in morse was Luxemburg where LX90RTL is active celebrating 90 years of broadcasting in Luxemburg with Radio Luxembourg. This contact is now also confirmed, and I am at 94 countries confirmed in morse code. The magic 100 for DXCC CW is getting closer.

Ik ben oud genoeg om berichten over waterstanden gehoord te hebben op de radio 's ochtends met "Grave beneden de sluis" en ik heb wel eens bij Grave gekeken op de constructies die daar allemaal zijn in de Maas.

Toen er vrijdag een bericht was Stuw bij Grave stuk: scheepvaart stilgelegd vanwege dalende Maas - NOS was ik wel benieuwd naar meer informatie. Naast de berichtgeving bij de NOS dat het herstel redelijk vlot gaat was ik eigenlijk ook wel op zoek naar wat extra details.

Die ontdekte ik bij Rijkswaterstaat zelf: Nieuwsfeed: Stuw Grave | Rijkswaterstaat waar ook meer technische details staan.

I did a manual apt update and saw an error message again for the grafana packages, which confirmed a posting I saw about grafana having to issue a new GPG key again.

root@gosper:~# apt update
Get:1 https://packages.grafana.com/oss/deb stable InRelease [5,984 B]
Err:1 https://packages.grafana.com/oss/deb stable InRelease
  The following signatures couldn't be verified because the public key is not av
ailable: NO_PUBKEY 963FA27710458545
Hit:2 http://deb.devuan.org/merged beowulf InRelease
Hit:3 http://deb.devuan.org/merged beowulf-security InRelease
Hit:4 http://deb.devuan.org/merged beowulf-updates InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not up
dated and the previous index files will be used. GPG error: https://packages.gra
fana.com/oss/deb stable InRelease: The following signatures couldn't be verified
 because the public key is not available: NO_PUBKEY 963FA27710458545
W: Failed to fetch https://packages.grafana.com/oss/deb/dists/stable/InRelease
The following signatures couldn't be verified because the public key is not avai
lable: NO_PUBKEY 963FA27710458545
W: Some index files failed to download. They have been ignored, or old ones used
 instead.

And again the solution was to update the GPG key for grafana packages, as mentioned in Grafana security update: GPG signing key rotation | Grafana Labs.

I followed the same steps as in the update of the grafana signing key in june 2023 to get things working again.

root@gosper:~# cd /etc/apt/trusted.gpg.d/
root@gosper:/etc/apt/trusted.gpg.d# wget -q -O - https://apt.grafana.com/gpg.key  | gpg --dearmor > grafana.gpg

I also filed a bug with cron-apt because it hides the 'problem with this repository' error from me. Logged as #778 - cron-apt does not report repositories with GPG problems.

Found via James Tucker: "In case you missed it, grafana…" - rag.pub

My favourite mix of subjects: security (or lack of security) and RF signals.

Joseph Gabay has researched how shopping carts with wheel locks are locked and unlocked, and found out it's really easy to replay these signals. The signals for the shopping carts with wheel locks from Gatekeeper systems are at 7.9 kHz (ELF or extremely low frequency) and at 2.4 GHz (UHF or Ultra High Frequency and the license free range also used by WiFi and Bluetooth).

After a lot of work with a coil to act as a (bad) antenna for 7.9 kHz he found out the magnetic field of a speaker in a smartphone can also create the field and do replay attacks via audio files.

All of this at Control Shopping Cart Wheels With Your Phone! including the video of the Defon 29 presentation about this.

Now I really wonder how the shopping carts at our nearby supermarket work! I know it is a wire loop in the parking lot, I've seen the loop transmitter in the supermarket.

Found via Issac Kelly: "Somebody linked this to me rec…" - Mastodon

Update

The nearby supermarket uses the Rocateq system which operates on 8.13 kHz. So I can probably do the same replay attacks to these carts. Found by taking a picture of the loop transmitter in the supermarket and checking for the name in some variations at the searchable FCC ID Database and finding COP Caster STD&OCS; COP User Manual Zhuhai Rocateq Technology which lists the VLF frequency: 8.13 kHz.

I bought a zigbee based power switch a while ago because it would be a powered zigbee repeater in a strategic place. I use it to switch monitors and audio equipment in what is my home office.

With those monitors in powersave I sometimes forget to switch it off at the end of the evening, and that causes some power use during the night. Time for a bit of home automation: initiating a power-off each night at a time I really should be in bed. Enough linux systems to initiate such a command, and I can just put an 'OFF' command in crontab.

koos@testrouter:~$ mosquitto_pub -t zigbee2mqtt/sch-mancave/set -m '{"state": "OFF" }'

And indeed there was a satisfying 'CLICK'.

In the preparation for the CQ WPX CW contest I had a contact with an amateur radio station in Antigua and Barbuda preparing for the contest: V26BP Bill (US callsign W5SJ) operating from Antigua and Barbuda for the contest.

Antigua and Barbuda is a sovereign country in the West Indies.

The QRZ page promised uploads to Logbook of The World (LoTW) so I asked very nicely after a few months for confirmation and got a quick response that the logs would come soon. A week later the confirmation indeed came in.

I'm now at 92 countries confirmed in morse, 100 is getting close...

Somebody gave me a tag 'once used to access the bicycle parking at work' because of my interest in RFID tags. So I checked the tag with the proxmark3 and the proxmark3 had no trouble finding the keys and getting full access in very little time.

I made sure that these tags are no longer used because otherwise I had a good argument to replace that system fast! And they are indeed deprecated, which also means I can write about my experiences without causing new risks.

It's already known the mifare classic is insecure, no news here. But seeing how fast a current proxmark3 can find the keys and dump the contents of the card with the full access confirms this insecurity again.

First I tried seeing what kind of tag this was:

[usb|script] pm3 --> hf search

[+]  UID: 6A BB 43 5C 
[+] ATQA: 00 04
[+]  SAK: 08 [2]
[+] Possible types:
[+]    MIFARE Classic 1K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Prng detection: weak
[#] Auth error
[?] Hint: try `hf mf` commands


[+] Valid ISO 14443-A tag found

[usb|script] pm3 --> hf mf list
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 68 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO14443A - all times are in carrier periods (1/13.56MHz)

      Start |        End | Src | Data (! denotes parity error)                  
                         | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
          0 |       2048 | Rdr |0d  37  21! 92  f2                                                       |  !! | 
      32544 |      34592 | Rdr |5d  37  21! 71! 71                                                       |  !! | 
      35808 |      36064 | Rdr |a1(1)                                                                    |     | 
      37088 |      37344 | Rdr |a3(1)                                                                    |     | 
      38368 |      38624 | Rdr |a5(1)                                                                    |     | INCR(0)
      39648 |      39904 | Rdr |a7(1)                                                                    |     | 

So far I've read the public information the card gives to any compatible NFC reader.

Recent kwam er berichtgeving vanuit de Veron: Raken radioamateurs 430-440 MHz definitief kwijt? Maak bezwaar! - Veron

Na het doorlezen van wat echt het voorstel was vond ik de titel overdreven. We raken de band nu niet kwijt.

Wat wel kan gebeuren is dat de interferentie toeneemt, en dat wil ik als radioamateur ook voorkomen. Ik heb dus ook mijn zienswijze opgeschreven en diverse keren bewerkt om onder de grens van 2500 karakters te blijven. Ik wilde expres niet met een aangehangen document werken om zo mijn zienswijze direct leesbaar te hebben staan.

Tijdens het proces van bewerken heb ik natuurlijk een lokale kopie bijgehouden waar ik ook blij mee was toen de site een keer haperde. Uiteindelijk is het geworden:

Volgens mij zullen de wijzigingen in het Nationaal Frequentieplan voor de frequentiebereiken van 430 tot 436 MHz tot ongewenste situaties leiden.

Binnen het gebied van 430 tot 436 MHz zitten ook frequenties waar binnen de amateurdienst zeer zwakke signalen mogelijk zijn die de primaire gebruikers (radioamateurs) zonder interferentie willen ontvangen. Dit valt uiteen in twee delen, te weten het deel voor zwakke signalen tussen radioamateur stations onderling, op 432 tot 433 MHz en het deel voor signalen van satellieten die ook actief zijn in de amateurbanden, te weten 435 tot 436 MHz.

Mijn verwachting is dat dit slecht samengaat met de nieuw voorgestelde toepassing.

In theorie zou de tertiaire status van de nieuwe gebruiker van dit frequentiegebied betekenen dat deze gebruiker interferentie accepteert van de primaire gebruiker en geen interferentie veroorzaakt of direct stopt als de primaire gebruiker interferentie ervaart. In de praktijk verwacht ik dat dit in het dagelijks gebruik tot conflicten zal leiden. Volgens het document waar deze wijziging op gebaseerd is, EU Document Decision (EU) 2022/180 gaat dit om 'Medical data acquisition devices'. Het publiek zal niet kunnen begrijpen dat een radioamateur die haar of zijn hobby aan het uitoefenen is voorrang zou moeten krijgen op communicatie van een medisch apparaat en dat de radioamateur zou kunnen vragen om dat medische apparaat uit te schakelen.

Ik verwacht conflicten die vergelijkbaar zijn of erger dan met wat er nu al optreed rond 433.9 MHz. Neem bijvoorbeeld dat het algemeen publiek niet snapt dat een zendamateur die bezig is met haar of zijn hobby voorrang heeft op het kunnen openen en sluiten van auto's, terwijl dat bij een pure uitleg van het nationaal frequentieplan wel de status zou moeten zijn. Naast het tekort aan begrip wat kan leiden tot conflictsituaties is er ook de extra emotionele kant dat het om een medisch apparaat gaat, wat ongeacht de kwaliteit van het apparaat ook vrij zwaar zal wegen voor het algemeen publiek als argument dat het voorrang zou moeten hebben.

Naast de eerder genoemde mogelijke conflictsituaties is er ook nog de kans op de omgekeerde situatie als radioamateurs bezig zijn met vermogens richting het maximum voor dit frequentiegebied en dan storing veroorzaken in de medische apparatuur. Ondanks de tertiaire status van de medische apparatuur zie ik ook hier oorzaken van conflicten omdat daar ook dezelfde emotie telt van medische apparatuur versus hobbygebruik.

Verwijzingen en geraadpleegde bronnen:

• Consultatie Pakketwijziging 2023-1 Nationaal Frequentieplan 2014 - Overheid.nl
• [Ontwerp]Besluit van de Minister van Economische Zaken en Klimaat van [datum pm] 2023, nr. BI / [nummer pm], houdende wijziging van het Nationaal Frequentieplan 2014 (implementatie WRC-19, ECC-besluiten en recommandaties, enkele wijzigingen t.b.v. overheidsgebruik en wijzigingen in de 3.8 – 4.2 en 26 GHz-banden). (PDF)
• Commission Implementing Decision (EU) 2022/180 of 8 February 2022 amending Decision 2006/771/EC as regards the update of harmonised technical conditions in the area of radio spectrum use for short-range devices (notified under document C(2022) 644) (Text with EEA relevance)

I had a heavy case of 'Oh Shiny!' this weekend. Recently I've been viewing and listening some DJ mixes on YouTube, most of them with music from the 1980s which I appreciate a lot.

Seeing those DJs mix live in those videos made me wonder 'how do they do it'. In one or more of these mixes I really noticed that a transition seemed to have happened between one well-known song and another, but I wasn't aware of how and when the transition happened. The DJ was so good in mixing the two records together I couldn't hear the point where it happened. In seeking the video I saw that other people viewing the video had been wondering the same, there was clearly a peak in viewing time on the transitions. It was also clear from the look on the face of the DJ he was happy with what he accomplished with that transition!

In the 1980s the DJ had an audio mixer and two turntables, almost always the Technics SL1200 with pitch control and fast start/stop. Nowadays this can be done in software. From a music collection on harddisk with controls to mix 2 or 4 tracks, with effects, equalizer and speed control. The modern DJ has a laptop!

I soon found out there is open source DJ mixing software that supports Linux! Mixxx - Free DJ Mixing Software App is open source and multiplatform. And it is available as an Ubuntu package so I gave it a spin (pun intended). Only having one audio device is 'supported' but it took me some trying to find a setup where I could work 'split' with a master mix in one ear and a headphone mix in the other. So I loaded some music and tried to make it into a bit of a DJ mix. I'm not very good at it, but I enjoyed trying.

Mixxx really prefers Jack audio since it likes having a lot of audio channels. I tried installing Jack audio in linux but couldn't get it to do what I want fast. Mixxx also supports the Alsa drivers and I managed to also set it up to route the main audio to a USB audio device and the headphone audio to the internal headphone jack. But I had nothing connected to the USB audio device and I didn't want to annoy my family with the noises of trying to make a good cutover from one song to the next. Mixxx has an option 'Split' to play the master output to one ear of the headphones and the headphone output to another, this is good for practicing.

Control of all the mixing functions in Mixxx can be done with mouse and keyboard, but the good part is it also supports all kinds of hardware DJ controllers. And some of them aren't too expensive... and available on the second hand market for an even better price.

As I am working towards getting 100 countries confirmed in morse I do keep an overview of countries I have at least one contact with which isn't confirmed yet on Logbook of The World (LoTW). On LoTW a contact is only confirmed when both sides upload a signed log with the same contact.

Yes, LoTW uses X509 certificates and signing, they just hide it mostly from the user.

So when I have a country in the log where I'd like to get digital confirmation I follow a few steps:

I first check the page for the callsign on qrz.com. Most radio amateurs maintain a presence on that site and may mention their policy for confirming contacts. Especially for rare entities where other radio amateurs will be interested in getting those entities confirmed.

If that page doesn't answer this question the next step is to check the call (or calls) with the 'find call' option in LoTW. Here it is possible to see what the last time is a log was uploaded and processed for that call. Or it shows that the call isn't active on LoTW at all. In that case I stop searching. Using LoTW is somewhat complicated and I don't feel the need to convince someone to start using it.

If the amateur is active on LoTW I try to guess whether regular uploads can be expected. Some have not uploaded anything in years, others seem to upload once a year in the month of January. Or the amateur uploads somewhat irregularly.

Now I am nearing 100 countries confirmed in morse I do sometimes write an e-mail to the amateur asking to confirm the contact if I haven't seen confirmation after a few months. With all the details needed to find the contact in the log so they only have to do minimal work to look up the contact.

Getting Nothern-Ireland confirmed

In amateur radio Northern-Ireland is a separate entity and I had a few morse contacts with stations in Northern-Ireland in the log but none confirmed, not even after 3 months. So I mailed two of them which are regularly active on LoTW. The first one responded after a few days with a screenshot of the confirmed contact.

So now I have 91 countries confirmed in morse on LoTW. The certificate for 100 countries in morse is getting closer!

In preparation for a migration at work I wanted to do actual benchmarking of Linux filesystem performance. I think I used bonnie in the last century, so I gave bonnie++ a spin for this.

I have little idea of what 'good' or 'bad' numbers are from bonnie++. I could only compare a "local" filesystem with an NFS filesystem. I use local in quotes because this was in a virtual machine, so it's SSD storage in raid-1, with LVM on top of it, with a logical volume assigned to a KVM-based virtual machine, which uses the virtio disk driver for an ext4 filesystem.

The numbers for the "local" filesystem:

Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
gosper          32G  809k  98  440m  38  215m  22 1590k  99  410m  30  4639 135
Latency             25688us     317ms     143ms    9332us   39208us    2089us
Version  1.98       ------Sequential Create------ --------Random Create--------
gosper              -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency               488us     684us     762us     236us      87us     262us
1.98,1.98,gosper,1,1691401899,32G,,8192,5,809,98,450230,38,220385,22,1590,99,419827,30,4639,135,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,25688us,317ms,143ms,9332us,39208us,2089us,488us,684us,762us,236us,87us,262us

And for NFS, a Synology NAS with spinning disks in raid-5:

Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
gosper          32G 1054k  98 78.7m   7 68.4m  13 1483k  99  109m  10 432.2  12
Latency             11138us     408ms   13261ms   16434us     212ms     274ms
Version  1.98       ------Sequential Create------ --------Random Create--------
gosper              -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 16384  10 16384  16 16384  15 16384   9 16384  18 16384  15
Latency             69194us   53194us   98927us   69144us    1240us   94317us
1.98,1.98,gosper,1,1691398200,32G,,8192,5,1054,98,80605,7,70058,13,1483,99,111574,10,432.2,12,16,,,,,705,10,16184,16,2800,15,693,9,3703,18,2226,15,11138us,408ms,13261ms,16434us,212ms,274ms,69194us,53194us,98927us,69144us,1240us,94317us

Now I am somewhat confused. Sequential write to NFS is slightly faster.

Update 2023-08-08

At work I got different but comparable numbers for iscsi attached storage versus vmware storage (and the layers in between). Those numbers helped make decisions about the storage.