News archive 2020 - Koos van den Hout

It's the christmas holiday and that gives me some time to fix things that have been on the wishlist for a while. This includes some parts of the scripts that make up my homepage.

The update was a learning process, I found out getting caching right is still very hard and I learned about preformatted text and the CSS grid which worked differently than expected. All fixed now.

This is now fixed, and I may find more things to fix in the (near) future.

Changes include:

• The pages are now using a CSS grid
• Pages have a usable righthandside
• Updates to the footer have been made on all pages
• The history function of the newstag page has been fixed to give usable permanent urls
• The IPv6 check is active on more pages

I found out the mobile version of my homepage was a lot wider than the desktop version (which tries to fit on the screen). This didn't show when I learned about the CSS grid for Camp Wireless.

The difference is that my homepage regularly uses log samples which are displayed as preformatted text. I used the grid width 1fr which allows for the full width of <pre> items. Changing this to 100% fixed it. The desktop version uses two columns and those are already split using percentages of the full screen width.

I haven't written anything about wardriving since I noticed I fell out of the WiGLE top 100 but I still do it from time to time. At the same rate as I wrote back then, switching on the WiGLE app on an Android phone when I realize I may be in an 'interesting' area for finding networks and I have the time. I don't go out on wardriving trips on purpose, but there are enough networks to be found.

By now I have dropped to the number 312 rank in the WiGLE user statistics. I guess there are other wardrivers a lot more active and plotting every day wardriving expeditions.

WiGLE also logs found bluetooth devices and there are a lot of those out there.

After switching my websites to https I found out caching works differently on https (for good reasons) and files included by lots of pages got reloaded a lot.

So I added some caching hints. I especially did not want the stylesheet to be reloaded constantly. So I added an ExpiresByType directive to cache stylesheets for a week.

But on the change of camp-wireless to a new stylesheet and programming language I got bitten by this: some browsers had the old css code cached and saw no reason to check for updates. The site looked strange (but wasn't really broken).

I recently made some changes to parts of my homepage too, also going to the CSS grid model, just like the changes in Camp Wireless to the CSS grid model. And I had the same problems with the CSS in the production version. It took a bit of searching to find the source of the Expires statement, it was in the .htaccess file.

Now fixed to a much shorter cache time, it is quite possible to have versions of the pagecode and CSS differ in the browser.

I acquired a Blaupunkt BLP6100 Bluetooth speaker. Which turns out to support the following services via bluetooth:

• Headset (audio for phone calls)
• Handsfree operation (use buttons to accept, hangup or reject calls)
• Audio sink (the main function of a bluetooth speaker)
• Serial port

That last one I did not expect. I have tried opening the port with minicom and it will say carrier detect but sofar trying to wake it at 115200 or 9600 hasn't resulted in anything.

As a linux audio device it works fine. Or as a bluetooth speaker for my phone so I can listen to podcasts while walking around at home.

But the serial port makes me wonder!

On Sunday I wanted to do some cycling and deliver something in another part of the city of Utrecht. Those two can be combined! After finding the right part to do my delivery I cycled out of the city in north-west direction and returned via the northern ringway.

I like participating in radio contests. Not to win them, but to improve my own score and have the fun of making a high number of structured radio contacts in a short time.

There is also the factor that radio contests bring out participants in places that are normally hard to reach for radio amateurs. Last weekend I was tuning on the 20 meter band looking for phone contacts and I heard a Canadian station giving out the abbreviation Quebec Charly (QC) as an exchange. I looked it up and found out the RAC Canada Winter contest was running. I made the contacts and spun the dial looking for other Canadian stations, because I never had a confirmed voice contact with a Canadian station.

That doesn't mean I haven't talked to Canadians over amateur radio, I had a really nice chat with a Canadian who knows the area where I grew up a few months ago. That's totally different from a contest contact and also very nice to have.

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.

And yes the first LoTW confirmation already came in, so I now have Canada confirmed on phone.

Other DX update: Patience helps, I now have the earlier contact with Cuba confirmed.

Interesting find in the logs: SMTP authentication brute force.

Dec 20 20:57:22 gosper saslauthd[1616]:                 : auth failure: [user=iknidcam1974] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 20:57:26 gosper saslauthd[1613]:                 : auth failure: [user=iknidcam1974] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Dec 20 21:54:42 gosper saslauthd[1615]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 21:54:47 gosper saslauthd[1617]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Dec 20 21:57:14 gosper saslauthd[1614]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 21:57:23 gosper saslauthd[1615]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

With lots more for different names. The last one is probably this session:

Dec 20 21:57:16 gosper sm-mta[15854]: STARTTLS=server, relay=[5.188.206.203], version=TLSv1.2, verify=NOT, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Dec 20 21:57:24 gosper sm-mta[15854]: 0BKKvEuN015854: [5.188.206.203] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-SSL

Due to the fact that they abort the session when they can't log in the IP is seen as annoying by fail2ban and added to the deny list. But that list grows (suggesting a distributed attack) and is at this moment at 142 currently blocked hosts.

In de services scan kwamen de volgende services beschikbaar:

• NPO 1 tv
• NPO 2 tv
• NPO 3 tv
• RTV Utrecht tv
• Omroep West tv
• NPO 2 Extra tv
• NPO Radio 1 radio
• NPO Radio 2 radio
• NPO 3FM radio
• NPO Radio 4 radio
• NPO Radio 5 radio
• NPO Soul & Jazz radio
• FunX radio

Volgens Publieke themazender NPO 2 Extra nu ook te zien via Digitenne is die pas net toegevoegd. Ik ben benieuwd naar de bitrates per dienst.

Sinds het uitschakelen van digitale televisie in de DVB-T standaard keken we de live uitzendingen van NPO 1/2/3 via de NPO app voor android en de chromecast. Meestal werkt dat, maar op de dag dat er meer storingen waren bij google wilde de chromecast ook niet werken op een onhandig moment.

Tijd om toch eens te kijken naar een manier om live NPO 1/2/3 te kijken waarbij er niet zo'n afhankelijkheid is van verschillende complexe systemen en aanbieders met verschillende belangen. Terug naar TV kijken met een antenne en eigen ontvangst dus, die ook werkt als er een hapering met Internet is. Op zoek naar een simpele DVB-T2 ontvanger die voor de FTA (free to air, gratis te ontvangen) kanalen van Digitenne werkt kwam ik terecht bij deze: Edision Picco T265 - DVB-T2 H.265 HEVC - cardwriter.nl waar heel erg duidelijk in de omschrijving staat dat deze alleen voor de FTA kanalen van digitenne is. Precies wat ik zocht.

Deze is nu binnen en doet het. De ontvangst van DVB-T2 komt wel gevoeliger over, ik moet echt een goede plek voor de binnenantenne zoeken. En de 'digitale klif' is duidelijk, of er komt HD beeld uit of het staat stil / geeft blokjes.

Back when I started with world wide web things I created my own links page. For my own use, so I had my web links available on all my computers.

With the rise of 'search engine optimization' I started to receive requests to add certain links. First as bulk 'link exchange' mails but later as automated "personal" requests which have their own special rant.

The "personal" requests sometimes used interesting backstories such as a school project where the children had found such a good resource together and the teacher hoped to bring a smile to the childrens' faces by having the suggestion from the schoolchildren actually implemented.

So I added a line at the beginning of the page:

If you want to mail me to notify me about your very special link that really needs to be here to help children all over the world, enable world peace, would be the best resource ever or simply increase your pagerank: Don't. These are my links.

and this seems to help. For now.

I noticed the certificate for idefix.net was expired according to my webbrowser. I dug up the reason and found out the scripts to maintain the ocsp files managed to confuse the Makefile to keep the haproxy certificates updated.

The ocsp responses have more updates than the certificates, but a certificate update needs to be processed anyway.

So I updated the Makefile in the previous post. The dependency is now certificate-stamp depends on installed certificates, installed certificates depend on copied certificates. And installing the certificate also updates the ocsp response.

Interesting scam e-mail today, I guess it tries all possible scams and hopes to find out which one(s) work. Sent using the invite option of google forms, which seems to be popular with scammers recently.

I've invited you to fill out a form:
Attention Dear Customer
Attention Dear Customer,

We attempted to dispatch your item at 11:29 AM GMT+1 on the 19th of November, 2020 [11-19-2020].

Your delivery attempted to be delivered was affirmed to be among the list of deliveries abandoned in our delivery factory loft in the category

of the delivery file cases that consist of Stimulus Payment, Lottery Winners/Contract payments, Compensation & Inheritance Payments and

unclaimed consignments(concealed funds) From 2017 - 2020 and was abandoned due to the the COVID-19 (Coronavirus) pandemic that has

caused the lockdown in the country at large including the Holiday that has stopped it from getting to you respectively.

The shipping charge of this delivery has been paid & covered, so this notification has been automatically sent to notify you of this parcel

because if the parcel is not re-scheduled for delivery or picked up within 72 hours, it will be cancelled/confiscated along with the Tracking

details which will be null & void.

Yours sincerely,
Bruce Springs
404-666-6485
fedexpress109@hotmail.com
Secretary, FedEx Factory Loft


**************************
The content of this email is confidential and intended for the recipient specified in this message only. It is strictly forbidden to share any

part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to

this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
************************************************************

1006205-4-9-US-EN-80147623


©2020 FedEx. The content of this message is protected by copyright and trademark laws under U.S. a

At work there is a sort-of competition for the best christmas decorations in the office. At the end of last year I considered doing something with programmable LEDs to 'participate' in this competition in 2020.

This year turned out somewhat different, but slowly my son is also somewhat interested in electronics, soldering and making the computer do something.

So I set out to find fully programmable LED strips. I found a good comparison of LED strips in a Youtube video: LED Strips, what's the difference? WS2811, WS2812B, 2812Eco, WS2813, WS2815, SK6812, SK9822. which compares the several available types and their pros and cons. After viewing this video and for my limited experiment I thought the WS2812B based LED strip would be the best choice. The next hurdle was controlling it and I found Connect and Control WS2812 RGB LED Strips via Raspberry Pi which has pointers to the right code.

I am not following the advice on that page about working with mains power cables. That looks dangerous.

I ordered a WS2812B based LED strip and a matching power supply for 5V 40Watt from a Dutch webshop and got it in a few days later. I was amused by the warning the webshop gave that a LED strip like this is for advanced users only because you have to add a controlling device and do all the programming. That is exactly what I intended to do!

Programming is in Python3, and I haven't written any Python code before. But with a lot of google searches and looking at samples I got the idea right.

I now have the LED strip blinking in exactly the patterns I want, including a nice pattern for a christmas tree. And it blinks 'MERRY CHRISTMAS' in morse code, because why not!

This evening I upgraded the production webserver from Devuan ascii to Devuan beowulf and to have the option available to roll back everything I created a snapshot and left that running until I was satisfied with the new configuration and everything worked.

The steps were simple, found via Commit or revert a Linux LVM snapshot? - serverfault:

Before starting the upgrade, create a snapshot:

# lvcreate -L 10G -s -n turing_upgrade /dev/conway_ssd/turing_root

Do all the upgrade stuff, reboot, make sure everything works again.

The usage of the snapshot went up to 22.38 percent:

# lvs
  LV               VG         Attr       LSize   Pool Origin    Data%  Meta%  Move Log Cpy%Sync Convert
  turing_root      conway_ssd owi-aos---  30.00g
  turing_upgrade   conway_ssd swi-a-s---  10.00g      turing_root 13.17

After everything worked, remove the snapshot:

# lvremove /dev/conway_ssd/turing_upgrade

Past weekend was the CQWW CW contest and I participated for a while. Not many contacts because I had a lot of trouble decoding the morse, even with help from the RX-morse smartphone app.

I made 8 contacts. On the 15 meter band, using the remote radio. Four to Russia, one to the Ukraine and three to the United States. That does add the United States to the list of countries I had morse contacts with.

A bit of explanation: CW stands for "continuous wave" and is another term for morse since morse is switching a continuous wave on and off.

Update 2020-12-05: And the first confirmation of a United States morse contact is in. Raw score before log checking: 84 points. Ranking in the category "assisted low power 15 meters" is #133 (out of 133) for world, #70 (out of 70) for Europe and #2 (out of 2) for the Netherlands. So the lowest score!

Update 2021-05-04: Final score is unchanged so I made no errors and all 8 other stations got my callsign correct. Ranking is now #129 world, #69 europe and #2 the Netherlands.

I noticed I documented my original script to fetch the upstream and downstream DSL speed from the Fritz!Box 7360 but never documented the additional steps I took later to add the attainable upstream and downstream speeds to the current upstream and downstream speeds.

After switching to the Fritz!Box 7590 I missed my VDSL statistics so I dug up the scripts I had for the 7360 and tested whether they still work. And yes they do, so no changes there. The complete script:

#!/usr/bin/perl -w

use strict;

my ($fritzuser,$fritzpass);

$fritzuser="root";
$fritzpass="VerySecretPassword";

system("wget --user=$fritzuser --password=$fritzpass --post-file=wanifcfgrequest.xml --header=\"Content-Type: text/xml\" --header=\"SOAPAction: \\\"urn:dslforum-org:service:WANDSLInterfaceConfig:1#GetInfo\\\"\" --no-check-certificate http://fritz.koos.koffie.dot:49000/upnp/control/wandslifconfig1 -O wanifcfganswer.xml -o getfritz.log");

open(STATUSFILE,"){
        if (/(\d+)<\/NewUpstreamMaxRate>/){
                $upstream = $1;
        }
        if (/(\d+)<\/NewDownstreamMaxRate>/){
                $downstream = $1;
        }
        if (/(\d+)<\/NewUpstreamCurrRate>/){
                $upstreamcur = $1;
        }
        if (/(\d+)<\/NewDownstreamCurrRate>/){
                $downstreamcur = $1;
        }
}

if (defined $upstream and defined $downstream){
        my $line=sprintf("N:%d:%d:%d:%d",$downstream*1000,$upstream*1000,$downstreamcur*1000,$upstreamcur*1000);
        print $line."\n";
}

This does need the wanifcfgrequest.xml file:

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
   xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
   s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <s:Body>
      <u:GetInfo xmlns:u="urn:dslforum-org:service:WANDSLInterfaceConfig1">
      </u:GetInfo>
   </s:Body>
</s:Envelope>

And I get a usable wanifcfganswer.xml:

<?xml version="1.0"?>
 <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetInfoResponse xmlns:u="urn:dslforum-org:service:WANDSLInterfaceConfig:1">
<NewEnable>1</NewEnable>
<NewStatus>Initializing</NewStatus>
<NewDataPath>Fast</NewDataPath>
<NewUpstreamCurrRate>33032</NewUpstreamCurrRate>
<NewDownstreamCurrRate>111049</NewDownstreamCurrRate>
<NewUpstreamMaxRate>35725</NewUpstreamMaxRate>
<NewDownstreamMaxRate>117129</NewDownstreamMaxRate>
<NewUpstreamNoiseMargin>50</NewUpstreamNoiseMargin>
<NewDownstreamNoiseMargin>60</NewDownstreamNoiseMargin>
<NewUpstreamAttenuation>80</NewUpstreamAttenuation>
<NewDownstreamAttenuation>110</NewDownstreamAttenuation>
<NewATURVendor>41564d00</NewATURVendor>
<NewATURCountry>0400</NewATURCountry>
<NewUpstreamPower>498</NewUpstreamPower>
<NewDownstreamPower>513</NewDownstreamPower>
</u:GetInfoResponse>
</s:Body>
</s:Envelope>

This works without any change both on the Fritz!Box 7360 and the Fritz!Box 7590.

I still have a (short) list of European "countries" that I not yet have an amateur radio contact with. Jan Mayen was on that list and I set a specific alert in HamAlert to let me know when signals are seen from that part of the world. Today the alert fired and I had time to operate the radio. JX2US was active on 20 meter FT8. I joined the load of stations calling him and got an answer and a valid contact after trying for a while.

Jan Mayen is a very northern island belonging to Norway, but for amateur radio it is a separate entity. Jan Mayen has no permanent residents. According to the JX2US qrz page he does amateur radio in his spare time outside work in shifts.

Ik bleef er last van houden dat bij iedere activiteit met zenden op de radio het modem de verbinding verbrak en weer op moest bouwen. Eerder was dat een keer per week per band waarop ik actief werd maar de laatste tijd lijkt het bij frequentiewijzigingen of gewoon bij activiteit nog veel meer te gebeuren.

Ik weet wel een simpele oplossing: de aanbeveling in hoofdstuk 7.2.1.2 van ITU-T Recommendation G.993.2 uitvoeren: instellen dat alle amateur banden compleet overgeslagen worden en dat daar geen signaal aanwezig mag zijn (zogenaamde notches).

VDSL2 transmitters shall be able to reduce the PSD of the transmitted signal to a level below −80dBm/Hz in 16 arbitrary frequency bands simultaneously. An example list of frequency bands (the amateur radio bands) is shown in Table7-1.

In ITU G.993.2 zit een keurige lijst van amateur frequenties onder de 30 MHz die bijgewerkt is naar de huidige stand van zaken.

Dus ik had dit in een contactverzoek naar xs4all gezet. Maar zo makkelijk doen ze dat niet. Ze zien dat ik een ander modem gebruik (klopt, de Draytek Vigor 130) en dat het modem wat ik van hun heb verouderd is (klopt, een fritz!box 7360v1). Dus ze sturen eerst een nieuw Fritz!box 7590 modem op, daarmee kan ik dan testen wat de stabiliteit doet en dan weer contact opnemen als de problemen blijven.

Ik ben benieuwd. Ik zie veel meldingen van collega-zendamateurs dat ze notches laten instellen om zo van stabiliteitsproblemen af te zijn. Ik heb het idee dat in het afgelopen jaar ergens een update naar de DSLAM is gegaan die ervoor gezorgd heeft dat dit makkelijker onderbrekingen geeft, en bijvoorbeeld ook de samenwerking met de Draytek Vigor 130 met modem8 driver moeilijker maakte.

Verzoek in de doos is om het 'oude modem', dus de fritz!box 7360v1 te retourneren. Ik weet niet eens zeker of ik die in bruikleen heb van xs4all of dat dat toen nog een 'gratis' modem was maar ik ga er verder toch niets mee doen dus ze kunnen het modem terugkrijgen.

Update:

Na wat prutsen met de configuratie heb ik iets werkends met de fritz!box 7590. Eerst maar eens een standaard configuratie met de fritz!box 7590 zodat ik een firmware update kan doen. Daarna op zoek naar de gewenste configuratie waarbij ik de PPPoE sessie zelf afhandel op de server.

De fritz!box heeft wel de optie om PPPoE passthrough toe te staan maar als tegelijkertijd de PPPoE client in de fritz!box zelf een verbinding opzet is de PPPoE sessie al in gebruik en heb ik nog niet mijn gewenste verlegde eindpunt van de verbinding.

Oplossing: niet configuratie voor xs4all kiezen maar een onmogelijke configuratie gebaseerd op 'andere internetaanbieder' met vlan-id 6 en ik heb gekozen voor 'bridged' plus PPPoE passthrough. Nu mag ik wel de verbinding opbouwen vanaf mijn eigen router. En klaagt het modem dat het geen internet verbinding heeft.

Configuratie screenshots:

• Internettoegang instellingen: andere internet aanbieder, DSL
• Internettoegang instellingen: verbindingsinstellingen, VLAN en 'bridged dhcp' foute instelling, maar zo bouwt de fritzbox zelf geen internet verbinding op
• Internettoegang instellingen: PPPoE-passthrough toelaten

De fritz!box onderhandelt wel impulse noise protection (G.INP) met de DSLAM en mag ook dynamisch de downstream snelheid aanpassen bij storing (Seamless rate adaptation). Met actief worden over diverse stukjes van de 40 meter band krijg ik het modem nog wel aan het verbreken maar uiteindelijk is de verbinding stabiel terwijl ik met de radio actief ben. De impulse noise protection valt me wel op: met de Draytek Vigor 130 was dit uitgeschakeld.

Het nadeel is dat de MTU van de verbinding nu weer 1492 is want de fritz!box ondersteund niet een ethernet MTU van 1508 voor PPPoE passthrough. Helaas. Het voelt als een beetje net-niet oplossing als zo'n detail niet klopt.

I came across Using MIFARE Classic in 2020 - revk which states

So please, do not use MIFARE Classic as if they are secure!

and I couldn't agree more. There seem to be newer attacks that are even faster to crack the keys, which I will give a try soon.

For work I currently spent quite a bit of time in video conferences. I have an external webcam from work which gives a better image than the built-in webcam, but it regularly started giving problems in the image. Hickups or blinking images, suggesting some communications problem between the webcam and the computer.

Since the webcam, a Microsoft lifecam studio, is still being sold and advertised as works good with Windows 10 I thought it wasn't the age of the webcam or a problem with the drivers.

So I tried a different solution which is almost the standard solution of a radio amateur for interference problem: add more ferrite to the cables. The USB cable is thin which suggests to me there is not a lot of room for good shielding. Pulling the USB cable through a ferrite core twice right after the USB plug made the problems go away.

For most Dutch amateurs the first countries they have HF contacts with outside Europe are in North and South America. For some reason my DX from home has a slant to the east, so a lot of the Americas is still on my 'wanted' list.

This weekend I was active on the remote radio which has a 10-12-15-17-20 meter band antenna and I heard a Cuban station on 15 meters phone. After a number of tries I had the contact so that was my first contact with a Cuban station.

I also heard a station from Vatican City (for radio this is a separate entity) making contacts but it had so many stations responding I did not get through even with trying for almost 20 minutes.

Update 2020-11-04: Another new country in the log: the Seychelles islands. A country name that I usually associate with bad corners of the Internet at work is now a positive development as I got S79KW in the log with a very marginal FT8 contact on the 20 meter band, but I saw his final '73' report so it should have been logged on the other side.

This weekend was the CQWW DX SSB contest, which is one of the bigger contests on the amateur radio calendar. I had planned to participate, I made sure to get my contest software TLF completely configured and tested before the contest. But I didn't get around much to it most of Saturday. I only started Saturday evening to make some contacts on 40 meters which wasn't very successful from my home station.

Sunday afternoon things got a lot better when I tried the 20 meter and 10 meter amateur bands. Yes, 10 meter was open during the contest. This wasn't completely surprising as I made a number of 10 meter FT8 contacts earlier in the week.

The claimed results:

Band   160   80   40   20   15   10
QSO's    0    0    5   31    0   25
Cty      0    0    4   16    0   15
Zone     0    0    3    4    0    3
Pts: 61  Mul: 45 Score: 2745       

The raw scores in the "Assisted low all bands" category put me at rankings #862 (of 997) for world, #510 (out of 566) for Europe and #46 (out of 54). Not bad for the time I had available.

I have one Apache server exposed to the outside world for IPv6 clients (because of a history in hostnames going back to the 20th century). So after enabling OCSP for haproxy I decided to have a look at OCSP stapling for Apache 2.4. That's even easier than haproxy since Apache 2.4 will fetch the ocsp data itself. I followed Apache 2.4 SSL/TLS Strong Encryption: How-To OCSP Stapling and it works.

So now the current score at the Qualys SSL server test for koos.idefix.net is A+ both via IPv4 and IPv6.

I am upgrading Devuan linux installations from ascii to beowulf to get newer packages and continued security updates. There is only one package where I really want a newer version: openssl, so I can start using TLSv1.3.

This upgrade is just as simple as the upgrade from Devuan jessie to ascii three years ago. Just change the release name version and use apt update and apt dist-upgrade commands.

Today I did the development webserver and apache didn't start afterwards. I found out I need to enable php7.3 by hand, in the previous configuration php7.0 was enabled. A thing to keep in mind when upgrading the production webserver.

Uit de text/plain versie van de laatste mail van azerty:

DUMMY HEADER

Vestibulum volutpat pretium libero. Cras id dui. Aenean ut eros et nisl sagittis
 vestibulum. Nullam nulla eros, ultricies sit amet, nonummy id, imperdiet feugia
t, pede. Sed lectus. Donec mollis hendrerit risus. Phasellus nec sem in justo pe
llentesque facilisis. Etiam imperdiet imperdiet orci. Nunc nec neque. Phasellus
leo dolor, tempus non, auctor et, hendrerit quis, nisi.

Productnaam 1

Nam pretium turpis et arcu. Duis arcu tortor, suscipit eget, imperdiet nec, impe
rdiet iaculis, ipsum.

https://azerty.nl

MEE INFO

Productnaam 3

Nam pretium turpis et arcu. Duis arcu tortor, suscipit eget, imperdiet nec, impe
rdiet iaculis, ipsum.

https://azerty.nl

meer info

Productnaam 4

Nam pretium turpis et arcu. Duis arcu tortor, suscipit eget, imperdiet nec, impe
rdiet iaculis, ipsum.

https://azerty.nl/

meer info

De text/html versie bevat wel informatie. Iets met hardware voor gamers, dus ik kan verder de mail van harte weggooien.

I noticed when viewing my resulting track that there was something weird about the time. In the gpx file it was visible that the waypoints were not processed in order. So I searched for the way to make gpsbabel sort the waypoints by time. It took a bit of searching because I couldn't find any sample of sorting by time or other sorting options. But with some reading and thinking I found:

koos@kernighan:~/garmin$ gpsbabel -x sort,time -i garmin_fit -f 2020-10-20\ 13-12-51.fit -o gpx -F 2020-10-20\ 13-12-51.gpx
koos@kernighan:~/garmin$ 

The -x sort,time is 'sort by time'.

And I cycled 36 kilometers today. Some slight uphill parts, which lower my speed seriously. And the accompanying downhill parts increase my speed (and I keep pedalling, no need to limit my speed options as long as it's safe).

I have a few days holiday and today I decided to work on cycling a bigger distance. In the end I cycled 90 kilometers (on my cycle computer) or 84 kilometers (according to the GPS). Both are fine with me, a good test of doing such a distance.

I tried to get routes with lots of long straight paths, which are nice on my recumbent. That worked out ok. I cycled home - De Bilt - Bunnik - Odijk - Werkhoven - Cothen - Wijk bij Duurstede - Amerongen - Elst - Veenendaal - Renswoude - Scherpenzeel - Woudenberg - Zeist - De Bilt - home.

Average speed according to my cycling computer which will stop measuring when I pause: 20.60 kilometers per hour. Top speed was 47 kilometers per hour on a long downhill stretch near Zeist.

On my to-do list was the idea to look at OCSP stapling for haproxy. OCSP is Online Certificate Status Protocol which wraps the revocation status of a certificate in the certificate negotiation. This speeds up the TLS setup a bit since the client doesn't have to make an extra connection to the OCSP responder of the certificate issuer and it adds a bit of privacy because the certificate issuer doesn't see which client requests the status of a certificate.

Finding the right way to get the ocsp updates to haproxy was a bit of work, eventually made some modifications to the script in HAProxy OCSP stapling. I also used the remarks in OCSP stapling with HAProxy. From pitfall to euphoria because I saw the "OCSP single response: Certificate ID does not match any certificate or issuer" error message. I had to restart haproxy first to make it enable ocsp processing (because now each server certificate has its own .ocsp file) and now it accepts the "set ssl ocsp-response" command.

Update: I'm not completely happy yet: after a certificate was renewed haproxy complained about the .ocsp file being out of date. Which is fully correct, since that .ocsp file was about a previous version of the certificate. This needs more work. Ideally I would check the validity of the .ocsp file before deciding to renew it. And fetch the new ocsp data before reloading a renewed certificate.

Anyway, the 'TLS setup' part of connecting to sites like idefix.net goes from 20-21 milliseconds to 5-8 milliseconds. Not a blinding fast improvement but all bits help and I like to have optimal security and privacy.

I had a look at some weblogs and after removing the entries caused by webbots most of the rest of the traffic was attacks. All on stuff I don't have (usually wordpress), but one thing was noticeable:

37.59.47.61 - - [13/Oct/2020:00:17:34 +0200] "GET ////nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 404 747 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"
37.59.47.61 - - [13/Oct/2020:00:17:41 +0200] "GET /////nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 301 715 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"
37.59.47.61 - - [13/Oct/2020:00:17:43 +0200] "GET /nette.micro?callback=shell_exec&cmd=ifconfig HTTP/1.1" 404 747 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"

From what I've found about the 'nette microframework' there are callbacks, but none of those is called shell_exec.

pi4raz igate running showing packet

I dug into 'how to build code for the ESP32' and found Installing ESP32 Add-on in Arduino IDE (Windows, MacOS X, Linux) and since I have the Arduino IDE working enough for the previous project with a programmable microcontroller: the nanoKeyer morse keyer I did the steps to add ESP32 support.

I had to find the right settings for the specific ESP32 chip and since it is labeled "ESP-WROOM-32" I ended up at ESP-WROOM-32: Uploading a program with Arduino IDE and used the settings 'Board: FireBeetle-ESP32', 'Flash Frequency: 80 MHz', 'Upload Speed: 921600'.

The sourcefile to compile and upload to the ESP32 in the pi4raz igate is pa2rdk/APRS_IGate/APRS_IGate.ino.

I changed the definition of struct StoreStruct for a bigger wifi password (64 chars) and noticed that after uploading the updated code the last parts of the StoreStruct got mangled. I changed to #define EEPROM_SIZE 174 which seems to fix this.

I will admit to doing a bit of cargo-culting here: just following some google results and fiddling a bit until it works, with limited idea what I'm actually doing and what the effect of my changes is. The kind of weird results I got after growing the wifi password buffer suggested clearly to me that I was looking at some sort of buffer overflow, so I started looking for buffer sizes.

But the igate is now talking to the APRS network. First results visible at PE4KH-10 tracked on aprs.fi.

Vandaag actief met de radio met 40 meter en 20 meter morse en FT8, en heel regelmatig valt de VDSL link uit en moet opnieuw opgebouwd worden. Op zoek naar meer informatie over de Draytek Vigor 130 en impulse noise protection kwam ik DrayTek Vigor 130/165 Status Begriffe und Abkürzungen (cookiewalled) tegen met de uitleg over vdsl status more.

Op mijn modem:

> vdsl status more
  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
                  Near End        Far End    Note
 Trellis      :      1               1
 Bitswap      :      0               0
 ReTxEnable   :      0               1
 VirtualNoise :      0               1
 20BitSupport :      0               0
 LatencyPath  :      0               0
 LOS          :      8              26
 LOF          :      0               0
 LPR          :      0               8
 LOM          :      0               0
 SosSuccess   :      0               0
 NCD          :      0               0
 LCD          :      0               0
 FECS         :      0            209592 (seconds)
 ES           :      0              50 (seconds)
 SES          :      0              18 (seconds)
 LOSS         :      0               0 (seconds)
 UAS          :     85            7778 (seconds)
 HECError     :      0               0
 CRC          :      0             748
 RsCorrection :      0               0
 INP          :     10             360 (symbols)
 InterleaveDelay :    800               0 (1/100 ms)
 NFEC         :    123              32
 RFEC         :     16              16
 LSYMB        :   8977              16
 INTLVBLOCK   :    123              32
 AELEM        :      0            ----

Die 'ReTxEnable' is het ingeschakeld zijn van G.INP volgens bovenstaande pagina dus wilde ik dus aan beide kanten aan hebben. Commando gevonden: om dat te configureren:

> vdsl optn retx bi on
 retx         [US] =     ON, [DS] =     ON.

You have to reboot the system after you change settings.

Maar ook na reboot en heronderhandeling VDSL geen ReTxEnable voor het near end.

After finishing the Raspberry Pi ntp server in the weekend I continued on a long-running project: the PI4RAZ igate I started working on in June (and ordered in September 2019). I dragged the soldering iron, the soldering mat and lots of parts downstairs to work on it on Sunday evening. Soldering lots of pins to an Arduino nano is hard work.

I finished the last soldering on Monday evening and had a long and hard look at all the connections and redid a few. I used a multimeter to make sure three really close soldering islands weren't connected, found two with 0 ohms between them in both polarities so I fixed that issue.

After that I took the plunge of actually powering up the print and it looks good. The display shows output and I can walk through the setup when I connect a usb cable to the ESP32 module.

I can't make it run yet: the space for the wifi password in the ESP32 module is only 25 characters which is not enough for our home network. So I will have to look into changing the code (it has an update anyway: Software update iGate - PI4RAZ) and find a working way to program an ESP32 from linux.

I moved the new ntp server to the shed today. I found a nice case for it: an actual wooden box. I climbed on the roof of the shed to find a place for the GPS antenna (with magnetic base). Parts of the enclosures around our solar panels are from ferrous metals, so I found a place with an ok view of the sky to place the antenna and led the cable to a ventilation shaft to get it inside the shed. I made sure the cable was going up in the ventilation shaft first to avoid having a drip loop on one of our bicycles.

Although I did most work on the w1retap configuration before I couldn't get it running at first. I kept seeing the error message:

koos@henkp:~ $ LD_LIBRARY_PATH=/usr/local/lib/w1retap w1find DS2490-1
Error 119: Failed to set libusb configuration

It took some serious searching to find a hint: that is caused by the usb device file access rights. Solution is to install the 45-w1retap.rules that comes with w1retap into /etc/udev/rules.d.

At the moment weather data is being fetched on the Raspberry but the wifi between shed and house is so bad that the data stays there. I'm not sure how that can be fixed. It turns out the external wi-fi dongle I bought was listed as having 5 GHz support, but the reviews of the chipset used say it doesn't. The congestion in the 2.4 GHz band makes it very difficult to reach the pi. Doing a ping test over longer time gives me 91% packet loss.

I dug up a different 2.4 GHz antenna from the junkbox and suddenly the connection is stable with a lot less packet loss. This antenna is directional and now pointing right at my access point.

Now the weather data is collected and forwarded to the server for Weather station Utrecht Overvecht.

NTP didn't seem to work on the first try, I'm not seeing any data for the GPS_NMEA server. This works again after a powerdown/up.

I was wondering until the last moment whether to do it or not but eventually I did participate in the CQWW RTTY Contest in the last weekend. Seeing other radio amateurs get ready on social media helped me decide and jump in.

I made 165 contacts on the 20 and 40 meter band. No new countries! I was seeing decodes from a station from Thailand but he did not decode my replies. It was also interesting to see how some stations that couldn't hear me at one time were almost easy to contact at other times. But not the one from Thailand, that one never came back.

I only worked search and pounce, looking for other stations available for contacts. Some stations had major pile-ups but coming back later helped.

Getting my log in a format that I could upload was a bit of an issue. I selected the CQWW-RTTY contest in the contest setup of fldigi, and it logged the CQ zone numbers and state in the right windows. But on the export to cabrillo there is no option to export those values. Workaround: select the right adif part of the log and use the CQ WW RTTY DX Contest ADIF to Cabrillo Convertor. I did have to fix my one US contact since the state wasn't exported correctly.

Update 2020-10-04: My raw score before log checking is 22579 points according to 2020 CQ WW RTTY Contest raw scores.

Update 2021-04-10: Final score: 162 valid contacts, 1 US state, 13 zones, 53 countries: 21373 points. Ranking #23 the Netherlands.

We went cycling today and I fixed the speed computer on my bicycle and brought the GPS unit to get a good tracklog. Both worked fine so I know where I cycled, when and how fast.

The Garmin GPS saves data in .fit format but it's easy to convert that to gpx using gpsbabel, and visualising the resulting gpx is done with gpxviewer. The maps in gpxviewer are from openstreetmap, which means they are both good and free to use.

The magic conversion command from Garmin .fit to .gpx :

koos@kernighan:~/garmin$ gpsbabel -i garmin_fit -f 2020-09-27\ 16-37-30.fit -o gpx -F 2020-09-27\ 16-37-30.gpx

Which doesn't produce any output messages when things go well. No news is good news.

Yesterday I read about changes at LetsEncrypt that influence LetsEncrypt intermediate certificates and DANE and had a look at my own DANE record set up in december 2019.

I decided to change the 'usage' value to 1, meaning 'EE match validated by public CA' because it's linked to a known public CA, and the old value 3 meaning 'private EE' wasn't completely true because it's linked to a known public CA.

But I received a notification this morning, with:

Only certificate usages DANE-TA(2) and DANE-EE(3) are supported with SMTP.

With references to rfc 7672 section 3.1.1 and further which makes a valid point about CA validation in SMTP sessions.

So the validation chain is purely based on DNSSEC.

My start on the HF bands versus the sunspot cycle. Click for full graph with legend.

Recently the start of the new sunspot cycle is mentioned a lot in radio amateur news because the influence on ionospheric propagation is strong and the start of counted sunspot cycle 25 has started. Looking at the graphs I felt like I started just at the downward trend of the previous sunspot cycle.

So I looked it up at Solar Cycle Progression - NOAA / NWS Space Weather Prediction Center and zoomed in to the time when I made my first contacts making the screenshot in this article. And indeed, August / September 2014 was part of the last peaks of cycle 24, and it went mostly downhill from there. So my experience that I made my first HF contacts on 10 meter and soon had to go to lower frequencies to get any propagation matches those measurements.

Dit weekend was ik weer eens behoorlijk actief met amateurradio en als ik ging zenden was dit eigenlijk iedere keer onder de 17 MHz, dus binnen het VDSL spectrum. Ik was actief net boven 14 MHz (20 meter band) en net boven 7 MHz (40 meter band). Iedere keer als ik naar een andere frequentie ging verbrak de VDSL de verbinding en moest die opnieuw opgebouwd worden, ook als ik binnen dezelfde band opschoof. Ook waren er in de nachten nadat ik actief geweest was nog onderbrekingen.

Dit keer ook opvallend: het 'geheugen' van de VDSL verbinding is veel korter. Een avond later kreeg ik weer een onderbreking als ik op dezelfde frequenties actief werd, ik was gewend dat dat bij meer dan een week was.

Al met al is de VDSL dus een stuk gevoeliger voor het soort storingen wat amateurradio veroorzaakt (korte storingen op wisselende frequenties). Ik dacht dat dat in DSL termen "impulse noise". Nu begrijp ik ook dat de firmware met 'optimized for KPN' modem driver die ik nu gebruik anders reageert op dit punt dan de versie die ik gebruikte voordat er problemen met rare verbroken verbindingen kwamen. Geen vooruitgang dus. Wanneer komt er glasvezel naar de huizen? Glasvezel veroorzaakt geen storing op radiofrequenties en het raakt niet verstoort van nabij radiogebruik.

After lots of other things a weekend where I made time for amateur radio. I set up the endfed antenna and used a mast to raise the antenna at the end of the garden a bit, which hopefully increases the range a bit.

The big new thing was the last radio contact of the weekend: I decided to get on the air with the paddle as an exercise in morse. After looking for a contact at a reasonable speed where the exchange would be more than just callsigns and signal report I heard someone call CQ on the 40 meter band at about 20 words per minute. So to exercise my sending and not try to decode everything at 20 words per minute I cheated and used the computer to decode most of the morse code. I answered with my call and some basic information, with the printed CW QSO example in front of me. The other radio amateur had the patience to listen to my relatively slow speed (12 words per minute) and I had the contact. So I ended with a good - ..- which is morse for TU which is the abbreviation for "Thank You!"

Earlier in the weekend I made lots of FT8 and some FT4 contacts, just getting more calls in the log. I saw some for me new countries active. I managed to get French Guadeloupe as a new country in the log, and Saint Julia on a new band.

My notifications for the Bulgarian Saints showed me that LZ595IP was active in PSK31. I haven't used that mode in a while. I made the contact, so now I have that call in morse and PSK31, still looking for other modes.

Ze zijn er weer! Ruim 15 jaar nadat ik met vertraging ontdekte dat Adam Curry aan podcasting was begonnen is ook Jeroen van Inkel begonnen met een podcast, en gelijk over het onderwerp waar ik graag dingen over terugluister: Curry en Van Inkel, het radioprogramma wat ik elke vrijdagavond wilde horen in 1984-1987.

Ook nu weer met vertraging, want deze podcast loopt al sinds november 2019. Maar dat maakt de lol niet minder! Het is echt weer genieten van de oude jingles, stukken 'aircheck' (opnames die gemaakt werden van de gehele uitzending zoals die er uit ging), gesprekken met mensen die er bij waren, anecdotes en stukjes van de muziek zoals die toen was (geen lange stukken, want de muziekrechten blijven een ding).

De lol die ik er toen in had om er naar te luisteren komt ook gelijk weer terug. Waarbij ik ook sommige dingen ontdek die ik in die jaren gemist heb, wat dan te maken heeft met de ondertussen iets meer gevorderde leeftijd.

Het mooie is dat het me uit de eerste aflevering duidelijk wordt dat al het archiefmateriaal wat in de podcast gebruikt wordt beschikbaar is in digitale en doorzoekbare vorm omdat een enorme fan de hele voorraad met audiocassettes heeft gekregen van Jeroen, en een jaar later was er een gedigitaliseerd archief.

For more than 12 years now(!) the house has temperature sensors using the 1-wire protocol. I recently redid some of the wiring between floors and I finally got around to rerouting the 1-wire network via this new route.

I also added a temperature sensor in the big room in the attic, we are thinking of using that room more often. To get an idea of how good that idea is we wanted to get an idea of the temperatures up there and that's what I have 1-wire sensors for! I soldered an 18b20 sensor to the end of a 4-wire flat phone cable, added it to the network and it's measuring.

So now 12 environmental temperatures are measured every 5 minutes: 9 in the house, one in the weather hut, one in the shed and one on the roof of the shed.

I also updated the 1-wire projects overview with how I use 4-wire flat phone cable in RJ45 connectors for 1-wire network. I had to look up how I did that previously before I could start adding new cables!

I decided to have a look whether I can set up the static routes like those needed to get ads-b data out to plane finder via the dhcp server. This works a lot better than having to set those routes by hand after a reboot.

This can be done with the rfc3442 classless static routes extension in DHCP, which isn't supported out of the box by isc dhcpd. But there is support in the dhclient configuration on raspbian, so I only had to add the server side.

All the samples I could find for adding this to the server side added arrays of bytes which is harder to read/comprehend. I had a look at the dhcp-options manpage which showed the option to add a structured record with IPv4 addresses.

Main configuration adding the option:

option rfc3442-classless-static-routes code 121 = array of { integer 8, ip-address, ip-address };
# netmask bit count, destination, via

Specific host configuration using the option with the current address for pfclient-upload.planefinder.net. Which may change!

        host joy {
            hardware ethernet b8:27:eb:ae:ad:47;
            option rfc3442-classless-static-routes 32 80.84.58.2 10.42.2.1;
        }

This pushes route to 80.84.58.2/32 via 10.42.2.1.

Hosts that get this option via dhcp should ignore the default router option so if you need that too you will need to add a route for 0.0.0.0/0. In my specific usecase I don't want to set a default IPv4 route.

Dankzij het thuiswerken de laatste maanden viel mijn conditie recent toch flink tegen. Omdat ik voor de toekomst wilde plannen heb om door Europa te gaan ligfietsen vond ik het een goed idee om eens een stuk te gaan ligfietsen vandaag. De tijd was wat beperkt dus ik had al een plan gemaakt waar heen te gaan (een keer naar het Oosten) met diverse mogelijkheden om terug te keren als de tijdlimiet er aan kwam.

Maar ik had er niet op gerekend dat ik onderweg meerdere regenbuien mee zou krijgen en ook nog door een beweging mezelf zou openhalen aan een scherp deel van de fiets. Toen leek het me toch een goed idee om terug te gaan rijden maar dat ging uiteindelijk weer vlotter dan gedacht. Hier en daar is de keuze in routes soms wat beperkt. Uiteindelijk toch relatief veel 'bekend terrein' en minder ver gekomen dan ik verwacht had. De resultaten vielen ook een beetje tegen: 23.81 kilometer gefietst met uiteindelijk gemiddeld 13.90 kilometer per uur (inclusief schuilen voor de regen). Als ik serieuze afstanden wil afleggen in een langere fietstocht moet er toch meer uitkomen.

The new Camp Wireless that looks almost the same, but is completely rewritten is on-line.

It should look and work better on mobile devices. According to the statistics about half of the visitors is using a mobile device, so that is an important part.

I am a great fan of not breaking existing links, so they will keep working. There is a change in the url scheme for the site, but all old links redirect to the correct new location.

The details: Camp Wireless was completely written in PHP since the start of Camp Wireless in June 2004. But I didn't update the code a lot over the last years because I wasn't using PHP anymore and doing all my newer webprojects in modperl. This was becoming a risk, I didn't like updating the code anymore. I had to fix several things when I moved from the old homeserver to the new one because the new system came with PHP 7.

Since the url design of Camp Wireless was 'technology neutral' from the start (the main urls do not include .php or other hints to the used technology) it was possible to rewrite it in another language, as long as it could handle all the urls the same way.

I made one change to the url scheme: in the old setup the directory of campsites had urls with /database/region/ and /database/site/. Although there is indeed a database behind the site, the better term to use is directory, so I developed with /directory/region/ and /directory/site/ urls. And wrote a rewrite rule handler to redirect all the old links, because I don't like breaking old links.

I rewrote the site it in modperl. It was hosted on the development webserver and after implementing and testing each function I committed the result to version control. I still use cvs because that's what I once dove into.

After testing for a while with an acceptance version I finally made the switch today. After that I found a few functions missing so I added those promptly. Still using version control, so I know what I changed when and why.

In the last few weeks I had actual time to work on the planned rewrite of Camp Wireless in perl.

I rewrote it in perl and redid a small part of the CSS to use the CSS grid model to optimize Camp Wireless based on screen size. In the coming days I will create an 'acceptance' version of the site using the production version of the database, to iron out the last errors.

I still need to finish the correct 404 generation from within mod_perl scripts, advertising and some specific cases. And it's a good idea to run a website security scan on my work.

The look and feel hasn't changed a lot. I decided to present the same information in the same order and maintain most of the screenlayout.

De VDSL verbinding blijft soms in de nacht een of twee keer verbreken. De verbinding is vrij snel weer terug dus er zijn verder geen problemen, maar het valt me wel op dat het met wat regelmaat gebeurd. Ik was voor afgelopen Juni gewend dat de verbinding echt lang actief kon blijven, maar dat zit er momenteel niet in.

Gisterenmiddag viel de VDSL weer eens 'ouderwets' uit zonder aanwijsbare redenen. Tijdens thuiswerken, wat natuurlijk niet handig is. De maximale snelheid ging even naar ADSL snelheden (7 mbit down, 2 mbit up) maar was snel weer op hoge snelheid. Het kostte een paar pogingen weer een stabiele PPP connectie te krijgen dus misschien was er ergens anders in het netwerk ook even iets mis.

Gisterenavond werd ik actief met amateurradio op 14 en 7 MHz. Dat gaf diverse verstoringen van de VDSL, ik was gewend dat de verbinding per nieuwe band waarop ik actief ben een keer 'leert' om het stuk waar ik actief ben niet te gebruiken. Ik bleek ook een storing in de antenne op 7 MHz te hebben waardoor veel signaal reflecteerde, wat misschien de oorzaak was van de meervoudige storingen. Uiteindelijk dat op kunnen lossen en daarna bleef de VDSL verbinding ook actief.

Afgelopen nacht is er nog wel twee keer een uitval geweest. Maar het is vlot hersteld zonder dat het script wat een vdsl reboot forceert actief is geworden.

Saudisat 1c / SO-50

A few weeks ago I tried the Baofeng UV-5R on a satellite pass again to at least receive signal. It did receive something but kept closing the squelch during reception even at squelch level 0. This seems to be a common problem with this model radio.

I decided to put some money into a handheld radio that can do full-duplex. My original Wouxun seems to have developed serious issues receiving on the 2 meter side, but it has served me very well as a handheld radio over the years. So based on reviews about the Wouxun KG-UVD8D/KG-UVD9D models and how their full-duplex capabilities worked in combination with satellites I decided to buy one of these. The current model is the KG-UV9K which adds airband receive capability. I ordered one from bamiporto which came after a few days.

Based on the settings in AO-85 & Wouxun KG-UV9D - more testing I set mine up and tried a number of passes. The passes on satellites AO-91 (Fox-1B) and AO-92 (Fox-1D) all failed. The passes weren't too high and during busy weekends so there was a lot of competition for the uplink. With only 4 watts I am a bit limited there.

The difference between the Baofeng UV-5R and the Wouxun KG-UV9K in handling audio from satellites with the squelch full open is clear: with the Wouxun I only get an interruption when I let go of the transmit button.

Yesterday evening I tried a high SO-50 pass. A southwest to northeast pass, which gave me the option to stand in the front yard with radio, antenna and a smartphone with the W1ANT satellite tracker. I had trouble understanding some stations but could hear others fine who seemed to understand most stations fine, given the contacts I heard. In a gap I called F5ERS/P which turned into a good first contact and after that G0ABI called me and that was a good second contact.

The spam trying to sell me PC hardware keeps going on and I had a closer look. I noticed they all were sent with the following header line:

X-Mailer: Sendy (https://sendy.co)

I had a look through the last months of valid mail and spam mail: 1 valid mail using Sendy, 87 already seen as spam and 104 reports to spamcop. Those are clear numbers, so I created some spamassassin rules:

header LOCAL_MAILER_SENDY X-Mailer =~ /^Sendy \(https:\/\/sendy\.co\)$/
score LOCAL_MAILER_SENDY 1
describe LOCAL_MAILER_SENDY Sendy mailer

Starting with adding 1 for using sendy, but I can add more. Reporting the 'PC hardware' spammers again and again and again via spamcop to charter.net hasn't helped yet.

I'm still trying to learn morse and I currently make too many errors while sending with the paddle at a reasonable speed (12 words per minute).

Digging into the documentation for the winkeyer protocol showed me the option to get the morse it thinks I sent back to the computer.

This is even a supported option in winkeydaemon, the -e option.

       -e     Turns  on  winkeyer's  'echo'  feature and makes the daemon echo
              transmitted CW to all active clients (see '-p').

              Test this feature with the  'netcat'  utility:  'echo  |  nc  -u
              127.0.0.1  6789'.  This creates an active, echo-only client ses‐
              sion.

And indeed I can test my work:

$ ./winkeydaemon -s 13 -e
$ echo | nc -u localhost 6789
CQ CQ DE PE4KH

This could be used to write a morse trainer program. For now I use it to test whether I paddle what I want.

After the earlier issues with backing up to a remote webdav server I let the problem rest but made sure my backups were in order from time to time.

Until I came across a mention about rclone which especially mentions copying to various cloud services. Since I am trying to backup to a webdav server based on owncloud I had a look and this is a supported configuration in rclone. So I installed rclone to give it a try.

From the devuan distribution I got rclone version 1.35 which seemed to have problems with the specific owncloud server. So I had a look and newer .deb packages are available on the Rclone download page. This worked better.

On the first run rclone was convinced a lot of the files were modified locally since I transfered them with fusedav+rsync, so those were refreshed. But now it is all synchronized correctly the changes are minimal and the runtime isn't very long. I do make sure my uplink isn't filled completely so I limit the bandwidth. Command:

$ rclone --bwlimit 1M -v sync /camera/ owncloudservice:backuptest/camera/

After mention of the internet.nl tests at work I tested my webserver with the test from internet.nl and got a failed for the cipher order test. I do have the 'best' configuration according to the Mozilla SSL Configuration Generator but the test at internet.nl disagrees on this point because of the ordering of the ciphers. So with a lot of checking I now have:

ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256

Which is not the order Mozilla suggests, but gives me an A+ on the Qualys SSL Server test and a good result on the standards test at internet.nl.

I also found out generating my own Diffie-Hellman parameters is not good for parameter sizes of 2048 bits and up. I changed to a known-good group of 4096 bits.

I separated my amateur radio twitter from my work and other contacts twitter to get less depressing world politics in my timeline and today Twitter showed me very clearly that I'm supposed to get agitated and depressed and not retreat into a safer bubble.

I got notifications on the @PE4KH account (including on my phone) to look at this tweet by Phil Karn KA9Q: Fascism has arrived in America. which quotes another political tweet.

I really appreciate the work Phil Karn has done in the past for networking and amateur radio, and as a person I feel sorry for him and others to have to live their daily lives in a situation like this.

But at the same time I don't want to be reminded constantly, because I can't do much about it and I will just feel more depressed. So it really annoys me that Twitter goes out of its way to point me to something that will agitate and depress me.

It seems like Twitter wants more doomscrolling and more depression to increase "engagement" at the short term.

Since a few weeks I notice a lot of spam with deals in PC and mobile phone hardware. Several different domain names, but all with an overview of latest models and prices. When searching in the log for the names, the patterns are visible:

info2@bulk-laptops-europe.com
info2@notebooks-store-flow.com
info2@pc-b2bsales.com
info3@bigbuyit.eu
info3@computer-eu-trading.com
info3@elektronikresale.eu
info3@global-hardware-trading.eu
info3@notebook-resale.com
info4@laptopspro.eu
info6@bulk-laptops-europe.com
info6@it-stock-trade.eu
info6@technology-wholesale.com
info7@bigbuyit.eu
info7@elektronikresale.eu
info7@notebookb2bpartners.eu
info8@notebook-resale.com
info9@pc-stock-resales.com

Hosting seems to be at 2 or three places.

Sinds de overschakeling naar de modem5 vectored VDSL driver voor de Draytek vigor 130 is er maar een keer een VDSL uitval geweest, en die was gerelateerd aan amateurradio activiteit op de 40 meter band (7 MHz) en dat ben ik gewend.

Het lijkt er dus op dat dit een verder stabiele configuratie is. Daar was ik ook wel weer aan toe na alle problemen sinds begin Juni.

Snelheden zijn sinds die herstart wel anders. De ruimte tussen 'attainable' en 'current' zijn nu groter. Upstream is 34.5 / 30.9 en downstream is 69.1 / 111.0. Snel genoeg in ieder geval voor wat ik wil.

There were some ideas for one or more new virtual machines in the homeserver conway 2017 and the current volume group is almost full. Time to order some new diskspace because there's also some upcoming Devuan upgrades where I'd like to keep a snapshot of the 'before' situation so I can go back if everything breaks.

So I ordered 2 960 Gb SSDs. They will run in a mirror anyway. I was wondering whether to add them to the current volume group or take the 2 256 Gb SSDs out of the volume group. I decided to take those two out: there will be enough space after the upgrade and it can save some power. This does mean the new SSDs will also be set to be bootable and I will have to do a move of the volume group.

The order of changes:

• Shut down machine
• Install 2 new disks
• Boot up machine
• Partition 2 new disks with boot partition, make bootable with UEFI
• Test boot from new disk
• Make raid-1 device from the rest of the space on both disks
• Add new raid-1 to volume group
• Move volume group away from old raid-1
• Remove old raid-1 from volume group
• Unlink old raid-1
• Shut down machine
• Remove 2 old disks
• Boot up again

Quite a number of steps, this will take some time.

Weer eens spam voor een belg, met zelfs de naam "Maes-Swerts/A." weer in de adressering, wat dus betekent dat ze het bestand gebruiken wat ik in augustus 2012 traceerde als illegale bron.

Dat voldoet dus absoluut niet aan de huidige wetgeving op dit gebied en zowel de Nederlandse als de Belgische toezichthouder hebben ondertussen stevige boetes uitgedeeld voor het niet opvolgen van verwijderverzoeken. Een leuk overzicht bij dailybits.be: Overzicht GDPR/AVG boetes en schadevergoedingen.

Misschien maak ik ook wel kans op schadevergoeding, na 8 jaar ergernis.

Eerder, eerder, eerder, eerder, eerder, eerder, eerder, eerder, eerder.

I shared my earlier mishap with systemd on twitter: @khoos: Another run-in with systemd and got a reply to check the prerequisites: @devbeard: Is there something that needs to come after, before the thing is there for gpsctl to configure? and I added a dependency on the serial driver for the right port.

This seems to work now, it all comes up as planned. Updated file /etc/systemd/system/ublox-init.service:

[Unit]
Description=u-blox initialisation
Before=gpsd.service
Before=ntp.service
Requires=sys-devices-platform-soc-3f201000.serial-tty-ttyAMA0.device

[Service]
Type=oneshot
ExecStart=/usr/local/bin/gpsctl -q -a -B 115200 --configure_for_timing

[Install]
WantedBy=multi-user.target

And now I'm greeted by a working ntpd at 115200 bps when I log in to the Pi.

Again this year one of the important radiocontests for me: the IARU HF contest was this weekend. I made both SSB and CW contacts on several bands.

I made 22 contacts in morse. I concentrated on SSB during the day, aiming to get some nice contacts in the log. There were good 10 and 15 meter openings which is always nice in a contest. I haven't done a lot of contesting on those bands so those enabled me to get more multipliers and a higher score.

In the end I made 159 contacts, with a claimed score of 343 qso points * 74 multipliers = 25382.

Update 2021-04-10: I did a check of results in several contests. My results for the IARU HF contest 2020: 153 valid contacts, 73 multipliers, score 23798. Ranking #63 for the Netherlands. This gives me a ranking of #9 in the 'Single operator unlimited, mixed mode, low power' category. Which isn't a very busy category.

Ook de aanpassingen aan de configuratie van het Draytek Vigor 130 modem gaven niet het gewenste resultaat: zondag was er weer uitval. Dus het is niet een conflict tussen de pppoe client op mijn router en die in het Draytek Vigor 130 modem.

Om nu meer richting een ondersteunde configuratie te komen heb ik de nieuwste firmware er op gezet maar dan met de 'modem5' vectored VDSL driver. Ik hoop dat dat een betere situatie oplevert. De 'modem5' driver is volgens Draytek documentatie 'optimized for KPN'. Die levert wel wat meer vertraging op, maar dat is in de orde van milliseconden.

En als extra aanpak van het probleem heb ik een script geschreven wat het modem vraagt om een vdsl herstart. Dit script roep ik aan als het er alle tekenen van heeft dat de verbinding naar buiten weg is.

Again and again systemd annoys me. This time in the GPS Pi configured for timing.

Since I want it to work perfectly at start I added the systemd rules as suggested by A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog with /etc/systemd/system/ublox-init.service containing:

[Unit]
Description=u-blox initialisation
Before=gpsd.service
Before=ntp.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/gpsctl -q -a -B 115200 --configure_for_timing

[Install]
WantedBy=multi-user.target

After reboot ntp was running, but no data at all from the gps unit, and gpsctl was unable to revive it. The solution was to disable the above unit and ntpd, powerdown and restart the whole system and try again. After that doing the changes by hand and starting ntpd worked fine.

It's probably some sort of race condition, but any time I try to make a system with systemd do something reliably I run into things like this.

De vervelende lange onderbrekingen van de Internet verbinding bleven aanhouden en ik zocht hulp in de xs4all.adsl nieuwsgroep.

Ik kreeg een suggestie om de configuratie van het Draytek Vigor 130 modem aan te passen. Ondanks dat deze in PPPoE passthrough staat blijft de interne PPPoE client toch proberen om een verbinding op te bouwen. En dat geeft een probleem als het proberen op te bouwen van een nieuwe sessie een conflict geeft met een oude sessie wat alleen op te lossen is door een tijdje te wachten.

De suggestie was ook om logging van het Draytek Vigor 130 modem aan te zetten naar een syslog server zodat het zichtbaar werd wat er gebeurde. En dat gaf meer informatie wat inderdaad aangaf dat de PPPoE client op de Draytek Vigor 130 modem storing gaf.

Based on A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog I switched the gps to a configuration optimized for timing. The default settings are optimized for location services, but I want an NTP server.

I used gpsctl to configure the ublox chip in the GPS/RTC Hat:

$ gpsctl -a -B 115200 --configure_for_timing -vv
Serial port ("/dev/ttyAMA0") open...
Serial port open and configured...
Automatically determining baud rate...
Trying 230400 baud...
Trying 115200 baud...
Trying 57600 baud...
Trying 38400 baud...
Trying 19200 baud...
Trying 9600 baud...
Synchronized on 9600 baud...
Changing baud rate to 115200...
Successfully changed baud rate to 115200...

After that I got location data at a high speed. I changed the /etc/ntp.conf parameters to use the GPS_NMEA and PPS drivers, with:

# PPS reference
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS

# GPS NMEA driver
server 127.127.20.0 mode 89 minpoll 4 maxpoll 4 iburst prefer
fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 time2 0.043 refid GPS

And now I get much better numbers:

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l   14   16  377    0.000   -1.656   0.134
*GPS_NMEA(0)     .GPS.            2 l   13   16  377    0.000  -11.730   0.517
+ntpritchie.idef 131.211.8.244    3 u   44   64  377    4.263    1.436  62.373
+metronoom.dmz.c 192.87.106.3     2 u   44   64  377   12.141   -2.250  49.247
koos@henkp:~ $ ntpdc -c kern
pll offset:           -0.00142676 s
pll frequency:        7.468 ppm
maximum error:        4.934e-06 s
estimated error:      3.372e-06 s
status:               2001  pll nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  500 ppm

The time offset factors still need work, but I'm getting close!

I remembered the junkbox contains an active GPS antenna which I bought together with the gpskit gps unit in 2003(!). And some other bits and pieces included a SMA to BNC adapter so I put the little GPS antenna outside and connected it to the GPS/RTC Hat.

Before I was back behind a computer it was showing a location and within a few minutes it had a PPS pulse. I was used to cold start taking at least 15 minutes with the gpskit!

So I tested with ntpd talking to gpsd via shared memory. This gave an interesting offset between local gps time and a nearby ntp server.

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*SHM(2)          .PPS.            0 l    6   64  377    0.000   -0.149   1.672
xSHM(0)          .GPS.            0 l    5   64  377    0.000  -104.51   1.943
+ntpritchie.idef 131.211.8.244    3 u  101   64  376    2.774    0.950  13.948
+metronoom.dmz.c 131.211.8.252    2 u   99   64  376   10.482   -0.844  10.638
$ ntpdc -c kern
pll offset:           -0.000136461 s
pll frequency:        -11.054 ppm
maximum error:        1.3748e-05 s
estimated error:      1.7071e-05 s
status:               2001  pll nano
pll time constant:    6
precision:            1e-09 s
frequency tolerance:  500 ppm

I'm not too happy about the fact that the GPS NMEA messages are seen as wrong, so I'm going to stop using gpsd and go for a setup optimized for timing.

With most of the hardware in, it is time to configure the Raspberry Pi to allow the GPS/RTC board to be installed. One tip was to do this before installing the board to avoid serial conflicts.

First steps based on Building a GPS Time Server with the Raspberry Pi 3 which uses a different GPS board.

Disabling tty service on the UART:

# systemctl stop serial-getty@ttyAMA0.service
# systemctl disable serial-getty@ttyAMA0.service

And make changes to /boot/cmdline.txt to disable serial console, removing the console=serial0,115200 part.

Also needed is to disable the use of the hardware uart for bluetooth. This device does not need to do bluetooth at all, so I disable the software.

sudo systemctl disable hciuart

And add the lines to disable the bluetooth uart to /boot/config.txt:

dtoverlay=pi3-disable-bt

And with that the UART is completely free to use for GPS and PPS messages. I made all these changes and only added the GPS/RTC hat to the Pi after these changes were done.

Next steps were to add the i2c settings according to the GPS/RTC manual. For this I added

dtoverlay=i2c-rtc,rv3028
dtoverlay=pps-gpio

And indeed the i2c bus appears as the manual says:

# apt-get install python-smbus i2c-tools
[..]
# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- 42 -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

I removed the fake-hwclock package and tested operation. On the commandline it works, but in a reboot I still see weird times in the log.

After that I did the changes to /lib/udev/hwclock-set, now it looks like:

dev=$1

#if [ -e /run/systemd/system ] ; then
#    exit 0
#fi
if [ -e /run/udev/hwclock-set ]; then
    exit 0
fi

if [ -f /etc/default/rcS ] ; then
    . /etc/default/rcS
fi

# These defaults are user-overridable in /etc/default/hwclock
BADYEAR=no
HWCLOCKACCESS=yes
HWCLOCKPARS=
HCTOSYS_DEVICE=rtc0
if [ -f /etc/default/hwclock ] ; then
    . /etc/default/hwclock
fi

if [ yes = "$BADYEAR" ] ; then
#    /sbin/hwclock --rtc=$dev --systz --badyear
    /sbin/hwclock --rtc=$dev --hctosys --badyear
else
#    /sbin/hwclock --rtc=$dev --systz
    /sbin/hwclock --rtc=$dev --hctosys
fi

# Note 'touch' may not be available in initramfs
> /run/udev/hwclock-set

The rtc has to be configured correctly, I used information from A Raspberry Pi Stratum 1 NTP Server - Phil's Occasional Blog to configure the rv3028 chip. Get the gpsctl tool and use configure-rv3208.sh to set up the chip. Now the rtc is correct and used at boot time.

I'm seeing NMEA messages when I run gpsd or ask the serial port for data. The NMEA messages are very limited because there is no GPS antenna connected yet.

Social media is a nice and easy way to interact with people. There was and is a lot of choice in social media. Ages ago I started with fidonet echomail groups, later with usenet and recently with web-based social media.

But that's also a development from volunteer-run systems to commercially run systems. Companies like twitter, google and facebook are in the world to make a profit. With echomail and usenet the protocols and software were not linked to the operator of the service, someone else was able to run the same service and allow access to the network again. When google+ stopped the ties to people I knew were broken and I had to find them again on other networks.

I am somewhat active on twitter. My 'main' twitter account is twitter.com/khoos but I was getting a lot of negative messages about world politics which got depressing. Since twitter has made it a lot easier to manage more than one twitter account from the twitter web interface I decided to add a specific account for amateur radio with the predictable name twitter.com/PE4KH. Amateur radio twitter is not completely free of politics, but it's a lot more sane view of twitter.

The Raspberry Pi GPS/RTC Expansion Board from uputronics came in today (thanks mailman!).

Next part needed: a gps antenna. But that's on backorder with another supplier.

Also needed: time to install raspbian on the Pi and start testing.

Some time ago I saw announcements of an igate build project from PI4RAZ, the amateur radio club in Zoetermeer. An igate is a system that receives APRS messages and forwards them to the Internet aprs servers.

There is a distinct lack of APRS coverage here in Utrecht, so more places that receive those messages and pass them to the Internet are a good idea. A specialized repeater to repeat them on the air would be even better, but that needs a special radio license which is one step too far and expensive at the moment for me.

The electronics came in months ago, but time to pick up the soldering iron and start with the hard part wasn't available. I started this monday with that hard part: soldering a VHF module on top using something close to surface mounting. Just with a lot more space between the soldering islands than real surface mount. Still needed good light and a magnifying glass to check my work constantly. I only had to desolder one small blob of solder which went in the wrong direction.

After that I soldered the resistors. That went fine. After that my eyes were too tired, but the first step has been made.

As I mentioned before I have some future cycling goals which include some form of long-distance cycling journey, with serious influences from the book Computing Across America. Naturally amateur radio will play a part in such a cycling journey, just as Steven K. Roberts had on his trips.

Via the german amateur radio club DARC I found this bit in the "Deutschland-Rundspruch 24/2020":

DK3JB erreicht erstes Ziel auf seiner Funk-Fahrrad-Reise

Hans-Gerhard Maiwald, DK3JB, hat nach mühsamer und beschwerlicher Fahrt, teilweise auch wegen schlechter Radwege, am 15. Juni gegen 21 Uhr sein erstes Ziel, Kappel im Hochschwarzwald, erreicht. Dabei legte er ohne E-Unterstützung 580 km mit seinem 40 kg schweren Radanhänger zurück. Dem 72-jährigen OM geht es gesundheitlich gut. Hans-Gerhard gelang es, den weitaus größten Teil der Strecke permanent mit seinem TH-D74 in APRS aufzuzeichnen. Dabei hat sich der 1200 g schwere 12 V/20-Ah-Lithium-Ionen-Akku sehr bewährt. DK3JB hat zahlreiche Verbindungen in FM und D-Star vom Fahrrad aus getätigt. Durch Ludwigshafen wurde er von mehreren Funkamateuren gelotst und seine Route mitverfolgt. Hans-Gerhard bleibt bis Sonntag in Kappel und radelt danach vorerst an den Bodensee weiter.

And I found out more about the cycling tours between Siegen and Friedrichshafen in Germany via Funk-Fahrradtouren of DK3JB and it is very inspiring to me. There is also an article DK3JB wieder mit dem Fahrrad unterwegs nach Friedrichshafen - funkamateur.de with information about this tour in 2020 (all in German, which I can read but not really write). He has done this tour several years already, I found an article from the June 2008 trip: Mit Fahrrad, Zelft und FTM-10SE durch Süddeutschland (pdf).

After having read a book about cycling through Europe with the Rhine as one possible route, this confirms my earlier thoughts. Combining recumbent cycling, amateur radio and a nice ride through Europe is the direction I'm thinking.

I wanted to do some things in the shed with cabling, some things were not ideal after the solar power installation.

One of the things was that I had a temperature sensor to measure the temperature above the roof, but with all things that happened with cables it ended up hanging below the roof. I moved it back up in the ventilation pipe and with the current temperatures it started measuring 4 degrees Celcius higher immediately.

And yet another Raspberry Pi is showing up for my home network. This will become the GPS-based timeserver. I may add it to the NTP Pool when I'm satisfied enough with it.

It will probably also replace the 'shed' weather station computer in the long run, to save on power use.

I added an extra USB-based wifi adapter to the Pi. The shed has no wired network and my experience with the other computer there is that dual-band (2.4 GHz and 5 GHz) wifi support is the best way to have a chance to get working network.

I also ordered the Raspberry Pi GPS/RTC Expansion Board directly from uputronics.

After earlier tries to have a nice GPS-based timeserver for my home network I noticed a simple but very effective GPS 'hat' for the Raspberry Pi, the Raspberry Pi GPS Hat from Uputronix. While the Pi's are already taking over the home network just one more could be a nice addition. In the longer run this will probably replace the shed computer.

So I ordered a Pi with an added dual-band WiFi adapter, a case, the GPS hat and a GPS antenna. The GPS hat has PPS support so I will get the time correct. With the instructions from 5 minute guide to making a GPS Locked Stratum 1 NTP Server with a Raspberry Pi it should be easy. If this all works I may even add the resulting Pi to the IPv6 NTP Pool.

Update 2020-06-16: SOS Solutions came back with some bad news: the uputronix Pi GPS Hat isn't available anymore. I'm now looking at the comparable adafruit hardware which is somewhat more expensive, but offers the same options.

Update 2020-06-18: And the adafruit hardware is also not available soon. I cancelled the GPS unit part of the order and I'm looking at sourcing a GPS module for the Pi from another source. The GPS hat which sossolutions no longer sells is originally from uputronics where a newer version of the Raspberry Pi GPS/RTC Expansion Board is listed as available on the site. Based on a ublox chipset which allows me access to a lot of the GPS data.

Friday evening I had a contact with PI4AA via the PI2NOS repeater. So I logged the contact with those parameters in CQRLOG.

After a number of other contacts I wanted to upload my new contacts to LoTW. In an upload, CQRLOG creates an ADIF file of the contacts and lets tqsl sign the resulting file before sending the signed file to LoTW. But tqsl doesn't want to include repeater contacts (those aren't valid for LoTW, so it interprets the rules correctly) and it gives a return status 9 meaning "some QSOs suppressed" which CQRLOG displays correctly. But as a result of that return code it doesn't allow for the other contacts to be uploaded at all, leaving me with a growing number of contacts not uploaded to LoTW.

I reported the bug to the CQRLOG forums: Propagation type RPT (repeater) should not be uploaded to LoTW - Forums » CQRLOG » CQRLOG - bugs with a suggestion for a program fix. From my experience, good bugreports for CQRLOG will be acted upon fast.

In the mean time as a workaround I mark all contacts with propagation type 'repeater' as already uploaded to LoTW to skip them. MySQL statement:

$ mysql -S /home/koos/.config/cqrlog/database/sock cqrlog002
mysql> update cqrlog_main set lotw_qslsdate=curdate() where prop_mode='RPT' AND lotw_qslsdate is NULL;
Query OK, 1 row affected (0.03 sec)
Rows matched: 1  Changed: 1  Warnings: 0

and now other contacts can be uploaded fine.

Yet another import from our snowboard holiday in Austria.

The beer today is a Frastanzer s'dunkle. As the name suggests, a dark beer. With a good head of foam when poured correctly. The taste has a bit of a sweet note and has hops, but not as strong as other beers. A nice beer, good to bring from Austria or find at a store with lots of choice in beers.

The beer details

Company	Frastanz
Beer name	s'dunkle
Beer style	Pilsener
Alcohol by volume	5.8 %

But I forgot to write about it, because I made a very minimal number of contacts: 6. I wanted to get the Veron A08 contest group using call PA0AA in the log and added some others. And on submitting the log I didn't set the category to 'checklog' so there is a result with a ranking.

I got reminded today because our friendly mail delivery person brought an envelope with the token of merit (het vaantje) which is very special for this contest.

The good part is all 6 contacts were valid, so 6 contacts, 6 points, 3 multipliers making a stunning score of 18, and not the last in my category! Ranking 117 (out of 122) in single operator all band low power ssb only.

Ik heb een paar keer de afgelopen dagen een vrij lange onderbreking van het Internet thuis gehad, die eigenlijk leken te komen door een hik in de PPP sessie zonder dat de DSL sessie wegviel. Vervolgens probeert pppd met PPPoE (PPP over Ethernet) erg enthousiast de verbinding weer aan de gang te krijgen wat niet lukt. Netto resultaat: een langdurige uitval tot ik een keer met de hand het modem herstart (en dus de DSL sessie ook laat wegvallen).

Na wat navraag in xs4all.adsl lijkt dit een gevolg te zijn van het hardnekkig en snel weer opbouwen van de sessie terwijl er nog 'state' is van de oude sessie. En er is misschien wel een hik geweest in het transportnetwerk tussen de straatkast hier en de xs4all routers maar de sessie was nog niet weg.

After a number of recent morse contacts with special event stations I decided to participate in the CQ WPX CW contest during the weekend. Not for getting a big score, but to get experience with morse contesting.

Morse speeds in a contest like this are 25-30 words per minute which I can't decode, so I used fldigi to decode most of the morse. This means I have to enter my results as 'assisted'. And 'most' of the morse is the correct description because the important detail to decode are callsigns and serial numbers. The signal report is always 599 or 5NN which is usually sent faster than the rest of the conversation because it's a specific pattern a trained morse operator hears anyway.

I really didn't participate very long and still made 65 contacts. I'm not sure they all went correct, but it's a start. If I make 10 errors each of those is only 1 error for the other station. It's interesting how this approach to morse contesting gets me 65 contacts when serious participation in a digital mode contest will get me about 120 contacts.

But high numbers of contacts are quite normal in a morse contest. I have received serial numbers over 2000.

Logs are processed and the first confirmations via ARRL Logbook of the world are already coming in.

Update 2021-04-10: Checking on the results of contests, I find the result for this one: 60 valid contacts, 55 prefixes logged, score 2860 points. Resulting rank in the 'Single operator assisted low power 20 meter band' category: #2 the Netherlands. Not a lot of entries in this category!

It's been a very long time since I was busy with pure radio frequency scanning. Being active on the sending side too has made me less interested in frequencies where I can only listen.

But recently I was looking at what is available, and noticed the marine VHF channels. I could program them all in a scanner, but I decided to use software defined radio to see if anything is active in that band. Late in the evening there is currently no activity.

But I set a scanner to scan all known channels and heard some chatter on PMR channels. On one channel was a remark that there was interference and they should switch to channel 14.

In my memory analog PMR had 8 channels. So I looked it up and found out analog PMR was expanded to 16 channels on 1 January 2018. There is also DMR446 (same frequencies but with time division multiple access) on the same frequencies and dPMR446 with 32 possible frequencies in the same range.

So now the scanner is updated with the new analog frequencies and I can hear a baby monitor, motorcycle driving lessons and a building site.

Sometimes hobby and work intertwine when I'm not expecting it.

I set up a domainname and added a dummy website for something related to amateur radio. I have no idea if it will go anywhere, but I thought I'd get the web configuration right. The domain name isn't published anywhere.

But, to my surprise:

178.174.174.11 - - [20/May/2020:09:14:35 +0200] "GET /.git/HEAD HTTP/1.0" 404 594 "-" "-"
178.174.174.11 - - [20/May/2020:09:14:35 +0200] "GET /.git/HEAD HTTP/1.0" 404 594 "-" "-"
178.174.174.11 - - [20/May/2020:09:14:53 +0200] "GET /.git/HEAD HTTP/1.0" 404 594 "-" "-"
178.174.174.11 - - [20/May/2020:09:14:53 +0200] "GET /.git/HEAD HTTP/1.0" 404 594 "-" "-"
81.92.203.216 - - [20/May/2020:09:15:12 +0200] "GET /.git/HEAD HTTP/1.0" 404 594 "-" "-"
2a00:d680:30:50::67 - - [24/May/2020:16:54:36 +0200] "GET /wp-login.php HTTP/1.1" 404 594 "http://******.*******.**/wp-login.php" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

I added the domain name and requested a LetsEncrypt certificate on 11 May 2020, I set up the webserver correctly on 19 May 2020. The only 'publication' of the name is via the certificate transparancy log. Somehow this is enough for the first probes for possible security issues.

Looking in the haproxy logs finds even more requests on 15 and 18 May 2020. Part of the requests are via http, not https.

In the past few days I used the long-wire antenna with tuner to get on 'other' amateur bands. I added contacts on the 17 and 15 meter bands to several countries around my country. Some of those countries were new on those bands, so that's nice.

No spectaculair new distances or countries, but a good flow of new contacts.

As a radio amateur I like sending and receiving QSL cards. QSL is the Q-code for "I confirm reception" and a QSL card is the way to confirm a contact. I have my own QSL card design and a big box of cards to send out.

With contacts I usually do a check if a fellow amateur mentions the wish for cards via the QSL bureau on her/his qrz.com page, because I only want to send cards to interested amateurs. Due to the way I process my cards I can put up to 4 contacts on one card, so it's a simple optimization that if I have one contact that I want to send a card for I also check for other contacts with the same callsign. The qslmaximizer.pl script does this for the CQRLOG database.

Keeping encryption settings correct needs a lot of testing to make sure things are right. With external-facing webservices this is easy with the Qualys SSL scan, but for other services than https or services not facing outward a local tester is needed. This local tester is sslscan, a commandline tool but which depends on the shared openssl libraries which have insecure protocols disabled to helps disabling those deprecated protocols.

But to test services the client needs to support those old protocols to do the test correctly.

So I built a static version of sslscan with static openssl using the instructions at https://github.com/rbsec/sslscan. And that works for the full testing range!

Two new countries in the log, now the wait is for the amateurs on the other side to confirm the contact via Logbook of the World. Or maybe not, but both seemed solid contacts.

First was to the island of Curacao, part of the Netherlands Antilles. A lot of Dutch stations will have Curacao in the log because the Americas are the 'easy' DX but with my antenna position it has always been easier to get to the east.

Second one was to Kenia, which was a sort of surprise contact, I suddenly saw signals from a station there without any other indication that there was an opening towards Africa.

In other amateur radio experiences I've also had some really nice 10 meter openings recently. This is remarkable at the bottom of the sunspot cycle, but I guess sporadic E and other special propagation modes help. So I got some new countries on 10 meter. Earlier North Macedonia and today Albania.

Microsoft Windows does fall straight into the "does not work well with others" category for me, but today Windows 10 on my work laptop managed to give me a positive surprise.

I wanted to print something at home, and my home network is set up to publish CUPS printers via multicast DNS, both via IPv4 and IPv6 so Linux devices on the network see the printer right away. On selecting "Add a printer" in Windows 10 it just showed me the main home printer as an option and sending something to the printer worked the first time. I did notice the default paper size was still Letter although I have set up A4 everywhere, so that was the only thing left to adjust.

Now for the screenshot I removed the printer and tried to add it again and I notice the availability isn't very consistent. I do see a lot of mdns traffic when I start adding a printer!

A special feature I realized when working with the CSS grids is that I can change the order in which objects are displayed based on screen width. Or whether they appear at all on small screens.

So now I'm working on stylesheets that change the grid to what works better on a mobile device. Which is what a lot of the visitors to Camp Wireless use!

On a small screen I want the important content to come first. There is not enough space for the extras at the top, and a mobile visitor wants fast answers to the question "where can I find a campsite".

In my todo-list is a rewrite of Camp Wireless to stop maintaining PHP and make it more mobile-device friendly.

The reason to stop maintaining php is because I don't like it anymore which gives me a risk of having insecure code, which would be really bad for me. I'm rewriting it in Perl which isn't todays choice in web development either but it is what I can program good enough to avoid security errors.

The reason to make it more mobile-device friendly is that over half of the visitors to the site are using mobile devices. They want to find a campsite while travelling with a smartphone or other mobile device.

I was already using a media selector CSS, with variations for printer, I'm now looking at CSS grids which allows me to device the page into regions that move place depending on the available screensize. This makes separating content from page layout even easier.

A few times I had to lookup something again about the way things work in my setups. I made a remark before that I should set up a documentation wiki at home to keep this information somewhere central.

Right before I started with the homeserver conway I set up Mediawiki on a webserver. First on the previous homeserver greenblatt but as soon as web production was migrated to the new server I ran it on the web production server virtual machine.

So for a lot of 'how did I' questions there are answers, and some future plans. Also for plans on the house and on amateur radio related things.

People who know me from work will just say this is an extension of the trail of MediaWiki based documentation systems I left behind, and they are right.

I have a Synology NAS at home running DSM, so I had a look at the certificate options. According to the documentation it can get a LetsEncrypt certificate so I tried that. And it worked... which wasn't what I expected.

Some testing later found out port 80 tcp was open for every IPv6 address at home. That's now fixed and limited to those few IPv6 addresses that need to be reachable from the outside world.

Browsing the opinions about allowing outside access to the webserver on the Synology versus not allowing it showed me some differing opinions, but an article listening some malware and ransomware targetting Synology systems made me decide to close the system. Looking at the nginx configuration on the Synology gives me the idea some of the web-accessible functionality is available via port 80.

In my earlier activity on the 60 meter band I had a "maybe" contact to St. Lucia. This is one of the islands in the West Indies in the Eastern Carribian Sea.

But in the end the "maybe" contact was no contact. Ok, fine with me, on to the next chance. That happened Friday evening in a 10 meter opening: I came to the radio with the computer decoding FT8 signals ready to go to bed, but I saw J68HZ active as only non-European station, answering European stations. So I had to try!

After a number of tries I got a reply with a very weak signal report, so I kept my fingers crossed for the next exchange and it came, closing the contact. And the next evening the contact was confirmed, giving me a new DXCC entity.

Time for a new plot of the number of radio contacts. As usual contest months are quite visible and January is for me the month with the most contests.

But April 2020 is also quite visible. This last week I had a lot of time for radio due to holiday and not going anywhere. And other radio amateurs also had the time to be active, so there were a lot of new calls to get in the log. Combined with a good 10 meter band opening this added to a high number of contacts for a month with only one contest.

Today I "chased" the special amateur radio call for the Bulgarian Saint of this month, LZ177GL.

The Bulgarian Saints are a set of special amateur radio calls each month, organized in Bulgaria by Bulgarian Radio Club BLAGOVESTNIK LZ1KCP. The callsigns are in honour of saints from the orthodox church.

LZ177GL was calling CQ at a rate of about 28 words per minute. My current rate is 12-13 words per minute, so that's quite a lot faster. But it doesn't intimidate me anymore, I can hear the callsign on a few repeats, I can hear when the return is with my full callsign and a 5NN (signal report) or a part of my callsign and a question mark. Or when the answer is for another station. And that's enough to make the contact with the absolute minimum information, exchanging callsigns and signal reports. When I'm convinced my callsign got across I send '5NN TU 73' to finish the contact.

I also made some other contacts in morse because I could hear CQ calls and was able to decode them by ear together with some help from fldigi. So my conclusion is that morse isn't "intimidating" anymore. I can understand enough to get an idea what is going on and use it.

Today I noticed weird problems with the network in a desktop computer. It kept losing packets on the local network, with other computers in the same switch having no problems. In the end I switched to a different networkcard in the same computer to get rid of the problem. And that solved the problem.

The most probable reason is a lightning storm that came very close yesterday evening.

Update: The original 'suspect' was an Intel E1000 network card which had the first problems so I changed to a different card in the same computer. A week or so later similar problems started happening with a different computer on the same switch. I changed the switch which made the problem go away.

On opening the suspect switch I saw a capacitor with a big bulge on the top so the internal power is probably unstable, which can be the root cause of really weird problems.

Update: The replacement switch has only 5 ports, so I ordered an 8-port switch (my home office needs enough ports). After putting the 8-port switch in place I tested with the Intel E1000 again and it worked fine.

This month is somewhere near the absolute minimum of the solar cycle but today FT8 is active on the 10 meter band. I listened to other things on the 10 meter band but when I heard some morse I soon found out it was a beacon from Italy. It would have been nice to do some other mode than ft8 on the band.

But I made the possible FT8 contacts and got bigger distances than yesterday. In the evening I got Asiatic Russia and Belarus in the log.

I have an aged laserjet 4100 DTN printer at home and it sometimes takes a while to print something. The logs from cups will state that it has been sent to the printer but the printer will still show processing.

Solution: ask the printer for the active pagecounter. This will be updated after the page has really been output, so it will only change when the printer is done with the page.

$ snmpget -v1 -c internal laserjet 1.3.6.1.2.1.43.16.5.1.2.1.1
iso.3.6.1.2.1.43.10.2.1.4.1.1 = Counter32: 738042

I'm at home at the moment with a few days off from work. Time to play some radio, and with the current stay at home measures there are a lot of stations active.

I spun the dial to the 10 meter band this afternoon and heard signals. There was a nice E-skip opening to Spain and I even decoded some signals from Brazil. With normal ionospheric propagation South-America isn't that hard for most of the Dutch HF amateurs, but it's usually my difficult corner. I made several contacts with stations in Southern Europe, including AM2WARD so that's a new slot in the IARU 95th anniversary stations as organized by the Spanish radio amateurs.

In the weekend I had contacts with other stations part of that activity, including several in morse. Those stations are using fast computer-generated morse so I can't decode everything 'live' but by now I do know what 'PE4KH 5NN' sounds like at rather high speeds.

For all of my FT8 contacts from home until now I used the vertical diamond X-300N antenna on the roof. Most 2 meter DX stations will use a directional horizontal antenna, so I lose some signal when I try to communicate with them.

So last weekend I put the Arrow satellite antenna in the attic pointing out the window with the 2 meter elements in horizontal mode. Pointing out this window means southeast direction so I hoped to make some DX contacts into Germany or beyond.

Beyond did not happen, there was no special propagation on the 2 meter band. But the furthest contact was with DJ5FI with a distance of 360 kilometers. I'll try this again when there is special propagation in that direction.

Today I had time to work on the transistor switching to make the morse oscillator work. As I noticed before the Kent Morse practise oscillator kit is powered directly via the key which draws more current than the nanokeyer I built can handle.

So I had to calculate a transistor switch. That's something I learned a long time ago when I did electronics trade school from 1985 to 1989. In Dutch: MTS electronica. That knowledge had to be dug up again when I did the advanced radio amateur course but since I didn't have to use that knowledge it all sunk away.

But, google to the rescue and I found lots of examples, but the easiest one was at Transistor as a Switch - ElectronicsTutorials which explained exactly what I wanted. The next item was 'which transistor'. The default NPN transistor is the BC547B, but the theoretical current through the oscillator is a bit more than this transistor can handle. But a fellow amateur had a few BC337 transistors spare in his junkbox, so I could continue with this project.

Today I did the drawing and the calculations. I looked up the specifications for the BC337 in full saturation, at which time the Vbe is 1.2 Volt, Vce is 0.7 volt and Ibase is 1 milliAmpere. So I ended up with a resistor of 6800 Ohm at the input (which is (9 Volt - 1.2 Volt)/1 millAmpere rounded) and after building it on a breadboard it went beep with an input current of somewhat over 1.0 milliAmpere.

Update: Second test was with the nanokeyer, which first gave no sound, but that was due to me turning the volume down on the practise oscillator. Turning it back up fixed the problem, and I now have loud morse!

In the end this is giving me a good feeling. I had a kind of problem I haven't had to solve in ages so I had to relearn how to solve this, I found the solution method and was able to apply it in theory, practice followed the theory and it all worked as designed.

Not imported from very far, just from the local supermarket.

Again an Indian Pale Ale. There is something about that taste that I like. This one doesn't have a very 'hoppy' taste like some other IPA beers. I would describe the color as a light amber. Almost blonde.

The beer details

Company	Brand
Beer name	IPA
Beer style	IPA - India Pale Ale
Alcohol by volume	7.0 %

Last weekend was the EA RTTY Contest 2020 edition. I decided to participate beforehand so I set up radio, antenna and macros in time before the start. There was quite some time for the contest available since we're not going anywhere.

Things started slow, I couldn't get as much contacts in the log on Saturday as I had in the EAPSK63 contest 2020 on Saturday.

But on Sunday the contacts started happening and I ended with 143 contacts in the contest. 110 on the 20 meter band and 33 on the 40 meter band. I logged 26 unique provinces in Spain.

A recurring theme in rants here: link request spam written to look like a serious and personal request to improve an article on my site.

Troy Hunt seems to get a lot of those too, so he wrote No, I Won't Link to Your Spammy Article.

So we can now all stop doing stupid 'search engine optimization' and go back to sharing actual good content.

I think I found the most probable reason of the earlier problem with DNSSEC signed subzones. I was trying this with a domain for which I don't have control over one of the secondary nameservers.

In one of my showerthought moments I decided to try another domain where I have that full control (just less nameservers) and was able to make it all validate correctly after some tries. Forgetting one or more of all the steps needed to correctly create a domain with DNSSEC and getting the delegation right will give errors.

So I guess running a nameserver with all DNSSEC options disabled hinders validation.

There is a new 'activity' promoting digital modes on the 2 meter band. It's short, which is probably why it's called an activity rather than a contest. And it's on a weekday evening. Information in Vanaf nu elke maand een VHF-UHF Digitale Mode Activiteitscontest - VHF en hoger Veron (in Dutch). On the first Wednesday evening of the Month it will be on the 2 meter band, on the second Wednesday evening of the Month it will be on the 70 centimeter band.

I participated 1 April 2020 and made 22 contacts within the activity. Several new calls for me in the log, so that's always good. The contestlog processing website generates a map with locators after submitting a log, so I use that map in this newsitem.

The preferred mode is FT8, and some participants were using the FT8 software in 'EU-VHF mode' exchanging serial numbers and 6-character maidenhead locators. My wsjt-x decided to switch on receiving such an exchange. The interesting part was that in a few of the next contacts the software also switched but other contacts failed with that information so I switched back to normal FT8 with the 'EU-VHF mode' disabled.

The Kent morse practise oscillator built

To practise my morse at the radioclub I looked for a simple morse practise oscillator and found Morse practise oscillator kit - Kent and ordered it at the beginning of Februari. It took a while for it to arrive, but it arrived and I built it in one evening.

It's a quite simple kit. Which means the power for the whole circuit runs via the morse key, in theory about 120 mA. And that is more than the octocoupler on the CW output of the nanokeyer I built is willing to deliver (50 mA). So I can't use the practise oscillator straight away, there will need to be a small amplifier in between.

Some searching suggests I can use a transistor as 'power amplifier'. Time to look at what I may have (which is not a lot) or find a transistor somewhere.

Solution: order a bunch of transistors in a collection so I have some in the junkbox.

Oh and: The dashes and dots in the title are the word 'MORSE' in morse.

Gisteren op een wandeling een kleine ergernis: het verkeerslicht voor voetgangers bleef op rood staan ondanks dat ik op de juiste knop drukte. En dit was op het Robert Kochplein waar dan uit twee richtingen verkeer blijft komen zodat 'even tussendoor oversteken' niet echt veilig zou worden. Uiteindelijk bleek de verkeerslichtinstallatie wel te reageren toen ik op de knop bij het fietspad drukte. Melding gedaan via Slim Melden Utrecht maar daar is het wat lastig om precies aan te geven welke knop het niet doet. En deze knoppen hebben ook geen zichtbaar nummer zoals verkeerslichten boven de rijbanen.

Ik werd dus teruggebeld met het verzoek om precies uit te leggen welke knop en toen dat duidelijk was is de programmering van de verkeerslichteninstallatie direct aangepast zodat de voetgangers aan de beurt komen ook zonder op de knop gedrukt te hebben en er is toegezegd dat er een onderhoudsbedrijf naar kijkt.

Update: Op een volgende wandeling kwam ik toevallig weer langs hetzelfde punt en ik zag dat het verkeerslicht voor voetgangers regelmatig ook groen werd, dus die aanpassing van de programmering is actief.

Several of the machines here at home have IPv4 to the outside world disabled, simply to find every ancient service or program that still lives in the old world. Today I found one of those while installing dehydrated to automatically renew Let's Encrypt certificates.

Indeed, github has no IPv6 support. It tries to be a modern service, but lacks an AAAA record.

The solution is simple: use a webproxy to solve this. The only reason I still have a squid webproxy running is to be able to access IPv4-only http/https services from those hosts, so setting the http proxy in the global git config helped. I'm just surprised github doesn't support IPv6.

Update: After some searching I found Github users have been asking about IPv6 connectivity since at least 2018 and the "solution" is that they currently don't support IPv6 and the request is on some list.

Yet another import from our snowboard holiday in Austria.

This time I'm drinking Frastanzer Gold Spezial. When poured correctly it looks very German with a big foamy head. Not too pronounced taste, a good beer to drink.

The beer details

Company	Frastanz
Beer name	Gold Spezial
Beer style	Pilsener
Alcohol by volume	5.5 %

Last weekend was the EAPSK63 contest and I participated on Saturday. Lots of stations from Spain active and I managed to work 29 unique Spanish provinces. A total of 82 contacts. I could only participate Saturday afternoon and evening so that limited my time in the contest.

I bought a few Frastanzer beers on our snowboard holiday in Austria.

The first one to try is "Frastanzer s'honig" which is a beer made from biological ingredients with indeed a bit of added honey. Not too much, it's not too sweet for my taste. The honey gives the beer a soft side in taste without losing the strength from hops completely.

The beer details

Company	Frastanz
Beer name	s'honig
Beer style	Honey beer/spiced beer
Alcohol by volume	5.1 %

I did some more testing with the HP power supply I bought last November. In previous tests the output voltage seemed to be limited at 13 volts and it seems limited to 13.10 volt at the moment. The RM Italy HLA300V plus amplifier I have will only output about 55 watts maximum in digital modes so that's less than I expect. A higher input voltage may fix this, but I'm not sure how to get the power supply to deliver this and keep running. The previous power supply gave up in a busy weekend but before that the HF linear amplifier delivered more power. I have seen it go over a 100 watt on digital modes. The difference in output from the linear amplifier with 13.10 or 13.27 volt power is quite large, which surprises me.

A while ago I noticed a mention of new firmware for the Fritz!box 7360v1. As I want a separate PPPoE process to have full control of my Internet connection I hoped the PPPoE passthrough option would become available, since this would be a firmware version later than 6.30, but no.

At least the upgrade went fine without having to use the recovery options. So the 'in case of emergency' settings have been kept forwarding the necessary ports via IPv4.

Sometimes the Dutch special beers need attention too. And there are other beers than IPA beers. Really.

This is a special beer from the Dutch Grolsch brewery. A blonde beer, with a somewhat bitter taste for a blonde. Not too hoppy, a nice tasty beer.

The beer details

Company	Grolsch
Beer name	Klassieke blond
Beer style	Blond
Alcohol by volume	6.7 %

I noticed the news about LetsEncrypt revoking a lot of certificates on 4 March 2020 and did some checking to find out eventually that one of my certificates is in that set. Users have been notified of this problem... when their account had a contact e-mail address. By default dehydrated doesn't set an e-mail address so none of my instances used one. I do like to get informed so I searched how to update the contact info. The data is in /etc/dehydrated/config field CONTACT_EMAIL but I needed some searching before I found the method to get the update passed on to LetsEncrypt.

Some searching later found Update registration email address - Issue #425 dehydrated which shows that a simple dehydrated --account does the magic.

During our wintersport holiday in Austria I also brought my Arrow antenna and handheld radios along to try a satellite contact.

Before the holiday I read on twitter that Peter Goodhall 2M0SQL has unconfirmed gridsquares which included the place I was going on holiday. So I prepared for trying to make the contact during the holiday. In the preparation I got a theory why I had problems with the satellites with a 2 meter downlink frequency.

During the holiday I soon figured out there wasn't a lot of time for contacts, during the day we were on the pistes and we went to bed early because we had a lot of physical activity. And the place we stayed was between the mountains so for satellite passes I was limited to high passes.

In the end I did listen to one Fox-1D pass which was high and long enough. In a serious amount of falling snow so that was a new experience in amateur radio: trying to make contacts in the snow. Reception of Fox-1D was quite good on the Baofeng UV-5R radio, but transmitting back up didn't work out, I never made a contact.

I did not hear Peter on that pass, so that did not work out at all. But I learned several things, including the fact that the theory about the 2 meter downlink frequencies and the Wouxun KG-UVD1P was correct so the result is positive anyway.

Last week we were on a wintersport holiday in the Montafon region of Austria. I went snowboarding and had fun. There was enough snow at higher levels when the week started and later in the week it started snowing giving fresh snow which I really like for snowboarding.

Driving to Austria and back home through Germany went fine, no huge traffic jams or really bad weather. There is still a lot of work on the German Autobahns but less than one or two years ago. The lane departure warning system in our car still doesn't like the mix of orange and white lines on the road when lanes are shifted for work.

I was preparing for trying some satellite contacts and noticed the Fox-1B and Fox-1D had nicer opportunities for a contact. But I always have problems receiving any signal from those satellites on the handheld radio that I use for satellite contacts, which is the Wouxun KG-UVD1P I got for Christmas in 2012. Not the ideal radio for amateur satellites, but easy to bring along and to program with split frequencies.

A while ago I noticed that radio was constantly receiving noise on the 2 meter band and I had to set the squelch level quite high to stop it. I thought it was some local overload or local noise in the 2 meter band. But today while working on the preparations for some satellite contact possibilities I figured the problem is with the radio and something is actually wrong on the 2 meter receive side.

I have two other handheld radios. One is a Kenwood TH-D7 where I can't change the squelch level so it's not really usable for satellite contacts and the other is a Baofeng UV-5R which can't be programmed via the computer.

So I spent a lot of time entering all the possible doppler-shifted frequencies of both satellites on the keypad of the Baofeng UV-5R. I hope that gives me a working radio for Fox-1B/Fox-1D and I can get a few new contacts in the log.

Update 2020-02-27: I was correct! I tried a Fox-1D pass with the Baofeng UV-5R radio and I had easy reception of the satellite. Trying to get my signal over the satellite didn't work, but at least I know what the reception problem was.

A few days ago I changed the configuration of haproxy to stop accepting TLSv1.0 and TLSv1.1. With the upcoming deprecation of TLSv1.0 and TLSv1.1 this seemed the right SSL configuration. Today I remembered there is one directly reachable Apache server, so I had a look at the settings there and checked the results with the Qualys SSL Labs SSL Server test where I noticed some ciphers listed as 'weak'. And seeing different results between my haproxy and apache servers, which I did not expect as I used the same settings for SSLCipherSuite in Apache and ssl-default-bind-ciphers in haproxy.

The last issue was caused by the fact that Apache2.4.25 in Devuan ascii uses libssl 1.0.2 and haproxy 1.7.5 uses libssl 1.1.0. I'm not sure that's an ideal configuration but it's what I work with.

With the output of openssl ciphers -v I get a list of cipher names. But this is with libssl1.1.0 so the output lists ciphers that Apache doesn't have access to (yet). The good part is that Apache ignores ciphers that aren't available, so the net result is a running and working configuration.

The current result is for Apache 2.4.25:

SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256

And for haproxy 1.7.5:

ssl-default-bind-options force-tlsv12 no-tls-tickets
ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256

The fun part is that I can test the SSL negotiation with sslscan locally but sslscan is linked against openssl 1.0.2 so it misses some of the newer options. And I also test with the Qualys SSL Labs ssl test but that takes a while.

The too long; didn't read version of finding the right configuration options

And later I found I could have saved a lot of time researching options using the Mozilla SSL Configuration Generator. I don't completely agree with the suggestions there because I want to generate my own dhparams. Using 'well-known Diffie-Hellman paramaters' has security risks. But otherwise all the suggestions for ciphers are very usable and save me a lot of time.

For years and years I've been doing a lot of data gathering and storing the data using rrdtool. Data such as temperatures from lots of places, from mainboard CPU sensors to an outside weather station, other weather data, web traffic data, house electricy and gas usage, solar power. I started doing this with mrtg in 2001 and switched to rrdtool.

There are some improvements to this system, such as maintaining the rrd files on one machine and doing measurements on other machines in the form of timestamped files to be transported to the machine with rrd via rsync-over-ssh. This allows the central database to do a catch-up of decentrally gathered data after an interruption.

All in all there are two disadvantages at the moment: the system isn't very flexible, adding a datasource means making the big decision about how much data to keep how long and what I want to look at.

Diskspace isn't as constrained as it once was, I may want to keep some data forever and I may want to zoom in to a period a bit longer ago. So I'm looking at different solutions. For one dataset I already added an alternate datastore: the electricity and gas meter readings get copied to a postgres database once a day so I can look at the daily readings forever.

So the search is on for the ideal solution. For gathering and transporting data I am looking at mqtt, a lightweight protocol to gather and transmit data. This also makes it easier to have multiple data collectors look at one source so I can test with a few things first before I make a real switch to any new system.

I had one whole contact on the 60 meter band a few years ago with a German station. This band is supposed to be outside of the reach of my longwire, but with a lot of tuning it can work.

This weekend the longwire and the tuner absolutely did not want to get to a workable state on the 80 meter band so I tried the 60 meter band again. In FT8 mode, as that is what gets me the most result from home outside of contests.

This got me a number of contacts. Also one new country already confirmed: Tajikistan. And a new country with a questionable contact, so I'm waiting to see whether the other side will confirm or not. Formally 60 meter doesn't count for ARRL DXCC, but to me every contact counts in some way. I even got stations responding to me before I called CQ, I guess some amateurs are keen on getting a new callsign in the log.

I took down the wire antenna Saturday early in the evening because the winds were picking up for another storm.

In 2020 the support for TLSv1.0 and TLSv1.1 will end so the famous qualys SSL test is giving capped grades. I decided to get with the times and limit my outside web ports to TLSv1.2 so now I am back at an A+ grade.

Eventually this will start to cause problems as Devuan stable doesn't have an openssl with TLSv1.3 support yet.

Ook in 2020 gaat inktbestellen.be vrolijk verder met spam sturen naar adressen van een illegaal verzamelde adressenlijst. Maar spam van inktbestellen.be hadden we al gezien in de spam voor een Belg in 2019.

Eerder, Eerder, Eerder, eerder, eerder, eerder, eerder, eerder.

I decided to look for some special beers while shopping and I found this one: Lagunitas India Pale Ale. Sounded good, so I bought it.

The first taste is mostly hoppy, as expected from an IPA. Stronger than I've seen in some other IPA beers. In general it has a strong hop influence in the tast and reminds me of English bitter beers.

Reading the label shows me Lagunitas is from Petaluma, California and Chicago, Illinois. I guess Chicago has a serious beer culture with multiple breweries.

The beer details

Company	Lagunitas
Beer name	India Pale Ale
Beer style	IPA - India Pale Ale
Alcohol by volume	6.2 %

I'm still working on learning morse code. Sending morse code with the paddle is going ok at about 10-12 words per minute. Receiving is also somewhere around that rate, but I make more errors receiving.

I practise receiving morse with G4FON (Windows), xcwcp (Linux) and IZ2UUF morse trainer (Android). G4FON offers Farnsworth timing, where the letters are transmitted at a higher rate but there is extra spacing between letters to lower the rate of transmission. In xcwcp I can add extra dots between letters and in IZ2UUF morse trainer I can set extra length as a factor of the letter length. Three somewhat different methods to help learn morse at a reasonable speed.

To practise sending morse I use either the FT-857 radio or the control unit of the remote radio as expensive morse sounders. For the morse training at the radio club this is somewhat bulky and the internal buzzer of the nanokeyer is not loud enough so I ordered a practise oscillator kit from Kent morse equipment in the UK.

I also joined The Less Involved Data Society where I hope to meet newcomers to morse on the air. So I am now LIDS member number 414.

And for the rest: practice, practice, practice. Changing between modes of practice such as whole words in English or Dutch or back to random characters or groups of 5 letters helps improving speed and accuracy.

This weekend I had some random radio time so I made a number of contacts. By numbers mainly in FT4 and FT8 but also some SSB and CW via the remote radio.

I activated HamAlert triggers and used that to get a few countries in the log that I wanted confirmed via LoTW. This worked for Corsica and San Marino. I got an alert for a San Marino call on Saturday and worked it reasonably fast after an FT8 CQ from that station.

On Sunday I saw a notification for a Corsican call on FT8. When I saw the activity I noticed the station was just calling other stations. So I just started answering the callsign in the hope of getting the contact and after a few tries the hint came across and I got the contact in the log.

This is an area where an alerting system that uses more sources than just the DX cluster network works better: the station from Corsica never showed up on the DX cluster, but the activity was seen by PSKreporter and filtered by HamAlert into a notification to me.

The contact with Corsica is already confirmed on LoTW.

I found a completely different option for transferring files from linux to a remote webdav filesystem: fusedav. Mounting the remote 'cloud' disk with fusedav and synchronizing files with rsync is starting to work.

I decided to split my backups into two categories: first there are file collections that usually only grow, like digital camera pictures and audio project files. This takes the most diskspace and doesn't really need versioning.

The second category is configuration files, homedirs, mail and other things that change and where I may need an older version. This is where backups based on amanda work better.

I mount the filesystem with:

$ fusedav -u koos -p topsecret https://webdav.cloudprovider/remote.php/webdav/ /home/koos/webdavmount/

And the rsync command to backup to this mount:

$ rsync -av --progress --bwlimit=512K --size-only --timeout=30 /camera/2003/ webdavmount/camera/2003/

This looks scriptable so it can run on a regular basis with just a status update to me.

Update:
Reliability is still an issue. I added the --timeout=30 parameter to make rsync abort when the bytes stop flowing.

Trying to get devuan updates, I see:

Err:5 http://nl.mirror.devuan.org/merged ascii Release
  404  Not Found [IP: 2001:878:346::116 80]
Err:6 http://nl.mirror.devuan.org/merged ascii-security Release
  404  Not Found [IP: 2001:878:346::116 80]
Err:7 http://nl.mirror.devuan.org/merged ascii-updates Release
  404  Not Found [IP: 2001:878:346::116 80]

While nl.mirror.devuan.org has no shortage of IPv6 and IPv4 addresses:

;; ANSWER SECTION:
nl.mirror.devuan.org.   78083   IN      CNAME   deb.devuan.org.
deb.devuan.org.         78083   IN      CNAME   deb.roundr.devuan.org.
deb.roundr.devuan.org.  845     IN      AAAA    2001:638:a000:1021:21::1
deb.roundr.devuan.org.  845     IN      AAAA    2a01:4f8:140:1102:2b76:955d:b48f:bdf3
deb.roundr.devuan.org.  845     IN      AAAA    2001:878:346::116
deb.roundr.devuan.org.  845     IN      AAAA    2a01:4f8:162:7293::14
deb.roundr.devuan.org.  845     IN      AAAA    2800:a8:c001::a
deb.roundr.devuan.org.  845     IN      AAAA    2a01:4f9:2a:fa9::2
deb.roundr.devuan.org.  845     IN      AAAA    2001:590:3803::31:151
deb.roundr.devuan.org.  845     IN      AAAA    2001:4ca0:4300::1:19
deb.roundr.devuan.org.  845     IN      AAAA    2a02:2a38:1:400:422a:422a:422a:422a
deb.roundr.devuan.org.  845     IN      AAAA    2a0a:e5c0:2:2:400:c8ff:fe68:bef3

;; ANSWER SECTION:
nl.mirror.devuan.org.   78063   IN      CNAME   deb.devuan.org.
deb.devuan.org.         78063   IN      CNAME   deb.roundr.devuan.org.
deb.roundr.devuan.org.  824     IN      A       46.4.50.2
deb.roundr.devuan.org.  824     IN      A       130.225.254.116
deb.roundr.devuan.org.  824     IN      A       190.64.49.124
deb.roundr.devuan.org.  824     IN      A       31.220.0.151
deb.roundr.devuan.org.  824     IN      A       200.236.31.1
deb.roundr.devuan.org.  824     IN      A       131.188.12.211
deb.roundr.devuan.org.  824     IN      A       141.84.43.19
deb.roundr.devuan.org.  824     IN      A       37.187.111.86
deb.roundr.devuan.org.  824     IN      A       5.196.38.18
deb.roundr.devuan.org.  824     IN      A       95.216.15.86
deb.roundr.devuan.org.  824     IN      A       185.38.15.81

I always get the error for 2001:878:346::116 when connecting. This site seems to have a problem with the devuan mirror at the moment, so I'd like to use another one, but apt keeps going back to the same source. This has to do with IPv6 address destination selection (RFC 3484 / RFC 6724).

A good explanation at IPv6 Destination Address Selection – what, why, how - Karl Auer with:

Rule 9, “use longest matching prefix“, will prefer the candidate destination address that shares the greatest number of contiguous leading bits with the source address that would be chosen for it. Such an address is likely to be topologically closer to the source address.

Indeed that address is close to my home network addresses:

2001:0878:0346:0000:0000:0000:0000:0116
2001:0980:14ca:0001::/64

So the "roundr" round robin isn't very round for IPv6 users.

Workaround: reject the address that is giving me problems:

# ip -6 route add unreachable 2001:878:346::116
# apt update
Get:1 http://nl.mirror.devuan.org/merged ascii InRelease [25.6 kB]
Get:2 http://nl.mirror.devuan.org/merged ascii-security InRelease [25.6 kB]
Get:3 http://nl.mirror.devuan.org/merged ascii-updates InRelease [25.6 kB]
Get:5 http://nl.mirror.devuan.org/merged ascii-security/main Sources [185 kB]
Hit:4 http://packages.roundr.devuan.org/merged ascii InRelease
Get:6 http://nl.mirror.devuan.org/merged ascii-security/main amd64 Packages [480 kB]

Suricata is running and detecting attacks, but it was causing a 100% cpu load after a restart of the ppp connection (the DSL here uses PPP over Ethernet).

The errors point at the problem starting when the ppp connection restarts:

21/1/2020 -- 00:59:36 - <Error> - [ERRCODE: SC_ERR_AFP_READ(191)] - Error reading data from iface 'ppp0': (100u) Network is down
21/1/2020 -- 00:59:37 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't set fanout mode, error Invalid argument

Which also starts to fill the system log with:

Jan 21 00:59:42 xxxxxxxx kernel: [11347441.726755] device ppp0 left promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.055712] device ppp0 entered promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.071533] device ppp0 left promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.091653] device ppp0 entered promiscuous mode

The interesting part is that this causes higher power usage about five and a half hours later.

Solution: restart suricata in an /etc/ppp/ip-up.d/ script.

With very little javascript programming experience I managed to program a version of the IPv6 inline test that is what I wanted for a while: a simple IPv6 check in the right hand column of my homepage. With credit to the IPv6 test by Iljitsch van Beijnum. A needed test, because we really ran out of IPv4 addresses.

It took a lot of tries and debugging because I have absolutely zero javascript experience. But I learned slowly and managed to get what I want.

This is where I like having test environments. There were a lot of broken versions of the test on a separate minimal test page, then I implemented it on the developer version of my homepage and fixed the last errors in that combination and after that I committed the change to the versioning system and updated the production version which showed the update without problems in one go.

Like in previous years I participated in the UBA PSK63 Prefix Contest in the weekend.

Overall it was a nice contest, with 111 contacts in total which makes this a good contest score. I started in the 20 meter band on Saturday, moved to the 40 meter band after propagation died down due to the sun going down.

On Sunday morning I started on the 40 meter band but soon gave up, there was a lot of interference on that band. I switched to 20 meters and made some more contacts. In the end: 38 contacts in the 20 meter band and 73 in the 40 meter band.

I turned on the remote radio today and saw in the DX cluster that the ZC4UW dxpedition was still active although 7 January was the last day.

The signals were never good enough to make the contact, but this made me rethink the DX alerting options I have. I used 'DX Alert' on Android before, but this program had some difficulties and I can't find it anymore on the google play store which suggests it's really going out of support.

The new suggestion is HamAlert which processes data from the DX Cluster network, PSKreporter, Reverse Beacon network and Sotawatch, allows the user to set triggers and report via push notification to a Android/Iphone when the HamAlert android app or equivalent iPhone app is installed.

I created an account, installed the app and set up my first triggers: countries in and around Europe I don't yet have confirmed in bands/modes that I can use. It's a lot easier in HamAlert to set these up compared to DX Alert because it can all be done on the HamAlert website and can be customized more easily.

Update 2020-01-12: First score: I activated the alerts today because I had some time to get on the radio between other things. I saw alerts for E44RU which is in Palestine on a non-standard FT8 frequency. I spun the dial, adjusted a bit and made the contact. And that's a new country for me.

This weekend was the ARRL RTTY Roundup edition 2020 and I participated. Late Saturday evening I saw a few US stations come up on 40 meters. Sunday afternoon I made a lot of contacts to mostly European stations on 20 meters. In the evening after dark the contacts from Europe seemed to stop after the first 24 hours were over but when I checked again late in the evening more US and some Canadian stations were decoded on my end and I worked them.

In the end 110 contacts, a nice score for this contest. Claimed score: 110 qso points * 33 multipliers = 3630.

The one that got away: I saw a station from California calling and giving state 'CA' in contacts, but he never heard me. That's the first time I heard or saw anything from one of the western US states.

Update 2021-04-10: Checking on several contests and finding the score for this one: 109 qso points and 33 multipliers = 3597 points. I entered in the 'single operator unlimited, low power' category and ranked #10 for the Netherlands.

Today I needed blocks of random letters to practise sending morse. What better tool to create those blocks than good old pwgen with the right settings:

$ pwgen -0 -A 5 12
ahhud eizaa kuoku ahyoo aequi epiis eiwei eimap sohsh papai ikeit oucho

And the trick for generating groups of five digits is a bit longer:

$ pwgen -r abcdefghijklmnopqrstuvwxyz -A 5 12
97228 85996 98876 38451 06091 98556 53369 73632 29509 29032 89601 16078

Or both letters and digits:

$ pwgen -A 5 12
sa7la oc7ko an5ne axae6 vohz6 aez5i eh3qu sha5m inai8 eor3a fuv1o ro6ha

Use better parameters with pwgen to generate actual passwords.

I received a message from amazon that The Virtual Bookcase no longer qualifies as an amazon.com associate. That was no big surprise as I haven't done a lot of maintenance on the site and haven't added a lot of content in the last years.

The only serious maintenance was for the migration to the new web server where php 7.0 is the standard version. I wish to some day migrate to perl but haven't found time yet.

So I removed all amazon affiliate links I could find. This also means I can't use the amazon.com API anymore.

Time for a new plot of the number of radio contacts. Months with contests are quite visible. After the peak in number of contacts in July there was first a holday and after that no big peaks in number of contacts. December 2019 jumps out a bit again due to the FT8 roundup on 8/9 December in which I made 66 contacts and later in the month the troposperic ducting allowing contacts over interesting distances in the 70 centimeter and 2 meter band added to a sprint at the end. In 2019 I made a few more contacts than in the previous record year 2017.

Looking back at my amateur radio resolutions for 2019 I think most came true.

If I look at them one by one:

• Keep learning morse! - I'm still working on my morse, but there is measurable improvement. I have learned the full set for the Belgian CW exam and I'm working on accuracy and speed.
• Get more countries on more HF bands in the log - More countries and more slots on HF are in the log. I also use the club station to achieve that goal. The ARRL DXCC Award shows that I'm getting somewhere.
• Moonbounce on 2 meter - I've listened on the right frequencies to the moon on 2 meter. Nothing heard.
• Those digimode contests, and maybe a few phone contests - I participated in two phone contests and a number of digimode contests. No serious improvement in scores.
• Operate HF outside - I operated HF outside. Not as much as I would like.
• At least one satellite contact - Multiple satellite contacts have been made!

Now I have to think about 2020, but the year is still young.