News archive August 2023 - Koos van den Hout

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.