News archive April 2023 - Koos van den Hout

I was looking for an opportunity for morse contacts and saw the UK/EI DX Contest CW 2023 in the calender for this weekend. So I participated, with some last minute additions to my contest logger.

My original idea for this contest was that this would make stations from all parts of the United Kingdom active in Morse, including entities I still want to get in the log. From the parts of the UK I don't have Guernsey and Jersey in morse and I'd like to get Northern Ireland confirmed.

That plan did not work out, from the UK I only heard stations from England and Schotland. Checking the Reverse Beacon Network confirmed this, very little activity from those parts of the UK. I made 68 contacts total, 48 on the 20 meter band and 20 on the 40 meter band.

What did work out is that all the practising I did in morse at contest speeds seems to help, I had less trouble decoding callsigns and serial numbers. I regularly practise contest morse with the Contest trainer by Hanz YL3JD.

I recently bought a Digitus Gigabit Ethernet adapter USB-C, mainly because my work laptop has no wired ethernet connection which I really want sometimes.

As I don't like having Windows-only hardware I did check before ordering that it can also be used with Linux. It contains a Realtek r8152 chip so I searched and found Fixing performance issues with Realtek RTL8156B 2.5GbE USB dongle in Ubuntu - CNX Software which mentions that loading the listed udev rules makes Linux select the right driver and improves performance.

And indeed the 'wrong' driver was chosen initially. I fetched r8152/50-usb-realtek-net.rules at master · bb-qq/r8152 · GitHub like:

root@moore:~# cd /etc/udev/rules.d/
root@moore:/etc/udev/rules.d# wget https://raw.githubusercontent.com/bb-qq/r8152/master/50-usb-realtek-net.rules
root@moore:/etc/udev/rules.d# cd
root@moore:~# udevadm control --reload-rules
root@moore:~# udevadm trigger

And now things are as I wish, the right driver is loaded:

  Device-3: Realtek USB 10/100/1G/2.5G LAN type: USB driver: r8152
  IF: enx3c49deadbeef state: down mac: 3c:49:de:ad:be:ef

One of the wishes we have for the home network is good wifi coverage in the back garden so we can sit outside on nice days to work without running UTP cables. The access-point in the central place in the house doesn't cover the back garden. Ideally I would also like a separate 'guest' wireless network at home.

These wishes was taken into consideration when upgrading the fiber to the shed network with a Netgear GS310TP switch. This switch has Power over Ethernet (PoE) support so it can power an acccess-point. The next step was to find an access-point supporting VLANs and multiple SSIDs.

Recently I borrowed a Mikrotik Wap.AC to test the options. It took me a bit to get used to the RouterOS userinterface but I managed to get it all working in an ideal configuration: Management via one VLAN, a 2.4 GHz wireless network bridged to the trusted wireless network, a 2.4 GHz wireless network bridged to the guest wireless, a 5 GHz wireless network bridged to the trusted wireless network and a 5 GHz wireless network bridged to the guest wireless.

The final test was with the Mikrotik Wap.AC in the shed with power over the network cable. This worked!

Ideally the wireless network in the backyard is 'on demand' because we only use it when working from home or sitting in the backyard and we can save the power at other times. So the idea of a button 'wifi in backyard' and an automatic shutdown in the evening is nice. I searched and it is indeed possible to control the Power over Ethernet in the Netgear GS310TP switch with snmp. Based on GS110TP deactivate PoE over SNMP for specific Ports I soon had working snmpset commands to disable/enable power to a specific port, and the Mikrotik followed nicely. Value '1' is PoE on and value '2' is PoE off:

$ # switch PoE on for port 8
$ snmpset -v2c -c ******** ******* 1.3.6.1.2.1.105.1.1.1.3.1.8 integer 1
iso.3.6.1.2.1.105.1.1.1.3.1.8 = INTEGER: 1

$ # switch PoE off for port 8
$ snmpset -v2c -c ******** ******* 1.3.6.1.2.1.105.1.1.1.3.1.8 integer 2
iso.3.6.1.2.1.105.1.1.1.3.1.8 = INTEGER: 2

Ideally there would be a button (zigbee?) near the backdoor to request "On" and a scheduled task every day to switch it off in the evening.

My PGP key expired, but I reset the expiry date. I do this so I have to actively update the key every few years. Should I ever lose access to the private key, it will go away by itself.

But this also means I have to ask the users of my key to refresh it by hand because the simple refresh doesn't "see" the update (even though this adds new signatures to the key).

So please use the command to receive my key:

$ gpg --keyserver pgp.surf.nl --receive-keys 0x5BA9368BE6F334E4

This updates the expiry date(s) and the uids. If you have my key and it looks expired and/or still has an old e-mail address with kzdoos in it please do this now. Complete data at pgp.surf.nl: Search results for '0x5BA9368BE6F334E4' where you can see all the details including the revoked bits. Those revoked bits won't show up in normal use.

A discussion on irc about how hard it is to set TLS options in some programs made me recall I still wanted courier-imap-ssl to give me the right SSL settings (Only TLS 1.2 and 1.3, and no weak algorithms). This has bothered me for a while but I couldn't find the right answers. Most documentation assumes courier-imap-ssl is compiled with OpenSSL. In Debian/Ubuntu/Devuan it is compiled with GnuTLS.

Searching this time found me Bug #1808649 “TLS_CIPHER_LIST and TLS_PROTOCOL Ignored” : Bugs : courier package : Ubuntu which points at debian-server-tools/mail/courier-check at master · szepeviktor/debian-server-tools · GitHub which lists the right parameter TLS_PRIORITY. And that page has usable answers for up to TLS v1.2, with some reading of the output of gnutls-cli --list I can imagine TLS v1.3 settings.

So with a minor adjustment to the given example to allow for TLS v1.3 I set this in /etc/courier/imapd-ssl:

##NAME: TLS_PRIORITY:0
#
# GnuTLS setting only
#
# Set TLS protocol priority settings (GnuTLS only)
#
# DEFAULT: NORMAL:-CTYPE-OPENPGP
#
# This setting is also used to select the available ciphers.
#
# The actual list of available ciphers depend on the options GnuTLS was
# compiled against. The possible ciphers are:
#
# AES256, 3DES, AES128, ARC128, ARC40, RC2, DES, NULL
#
# Also, the following aliases:
#
# HIGH -- all ciphers that use more than a 128 bit key size
# MEDIUM -- all ciphers that use a 128 bit key size
# LOW -- all ciphers that use fewer than a 128 bit key size, the NULL cipher
#        is not included
# ALL -- all ciphers except the NULL cipher
#
# See GnuTLS documentation, gnutls_priority_init(3) for additional
# documentation.

TLS_PRIORITY="NONE:+CHACHA20-POLY1305:+AES-128-GCM:+AES-256-GCM:+AES-128-CBC:+AES-256-CBC:+ECDHE-ECDSA:+ECDHE-RSA:+SHA256:+SHA384:+AEAD:+COMP-NULL:+VERS-TLS1.2:+VERS-TLS1.3:+SIGN-ALL:+CURVE-SECP521R1:+CURVE-SECP384R1:+CURVE-SECP256R1:+CTYPE-X509"

And now things are good! All green in sslscan:

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve P-256 DHE 256
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve P-256 DHE 256
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve P-256 DHE 256
Preferred TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA384     Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA256     Curve P-256 DHE 256

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  260 bits  secp521r1 (NIST P-521)
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  192 bits  secp384r1 (NIST P-384)
TLSv1.2  260 bits  secp521r1 (NIST P-521)

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
ECC Curve Name:      secp384r1
ECC Key Strength:    192

This year I participated in the EA RTTY Contest again. This is a contest organized by the Spanish Amateur Radio Club Unión de Radioaficionados Españoles and they organize nice contests!

I participated Saturday afternoon and Sunday end of the morning. Other things needed my attention in the weekend too. I ended with 56 contacts, 53 on the 20 meter amateur band and 3 on the 40 meter amateur band. The 40 meter amateur band was mostly unusuable during the daytime due to interference. I thought I was going to end the contest with less than 50 contacts, but calling CQ I had a last minute sprint with 11 contacts in 10 minutes.