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.

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.

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.