News items for tag linux - Koos van den Hout

2020-05-19 Testing encryption with sslscan including deprecated TLS versions 1 week ago
Encrypt all the things meme 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!
Read the rest of Testing encryption with sslscan including deprecated TLS versions

Tags: , ,
2020-05-14 After years of rants, Windows can still surprise me in a positive way 2 weeks ago
Windows 10 discovering CUPS printers 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!

Tags: , ,
2020-05-04 A fault in my firewall 3 weeks ago
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.

Tags: , ,
2020-05-01 Probable lightning damage to an Intel E1000 networkcard 4 weeks ago
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.

Tags: , , ,
2020-04-29 Seeing when it's time to walk to the laserjet printer 1 month ago
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

Tags: , ,
2020-03-03 Adding contact e-mail addresses to letsencrypt accounts via dehydrated 2 months ago
Encrypt all the things meme 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.

Tags: , ,
2020-02-17 Tweaking the SSL cipher settings for 2020 3 months ago
Encrypt all the things meme 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.

Tags: , , ,
2020-02-10 Getting with the times and limiting the webserver to TLSv1.2 3 months ago
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.

Tags: , , ,
2020-01-30 Backup to a remote webdav server, first success! 4 months ago
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.
Read the rest of Backup to a remote webdav server, first success!

Tags: , ,
2020-01-24 Longest matching IPv6 address selection biting me 4 months ago
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]

Tags: , ,
2020-01-21 Suricata and ppp: restart of suricata needed after ppp down/up 4 months ago
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.

Tags: , , ,
2019-12-01 Better audio for learning morse 6 months ago
I installed xcwcp from the unixcw packages on a different system and noticed it did not use PulseAudio. It said it could not find PulseAudio and skipped to ALSA. The downside of ALSA in xcwcp is that it pushes audio 10 characters ahead, with PulseAudio the buffer is smaller.

Some searching using strace found that xcwcp tries to open libpulse-simple.so which wasn't found on that system. It is available on my laptop, as part of:
$ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so
libpulse-dev:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.so
while the files linked to a part of the runtime package:
$ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0
libpulse0:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0
$ dpkg -S /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.1
libpulse0:amd64: /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.1
But I don't have package libpulse-dev on that other system.

Solution: make the symlink by hand in /usr/lib/x86_64-linux-gnu with:
user@system:/usr/lib/x86_64-linux-gnu$ sudo ln -sf libpulse-simple.so.0 libpulse-simple.so
And I reported it as a bug for ubuntu: Bug #1854630: xcwcp doesn't use pulseaudio but given the list of bugs in Ubuntu I reported or commented on before with a lot of 'undecided' and not a lot of progress I'm not sure anything will happen.

Back to practising morse after this diversion!

Tags: , ,
2019-11-21 First setup of the remoterig interfaces 6 months ago
The remoterig set I ordered arrived.

At first I found the box somewhat empty: no manuals. But the entire manual can be found on-line: User manuals - RemoteRig. The manual is about 200 pages so printing it would be a bad idea. The remoterig site is somewhat slow so I downloaded the PDF manual to my computer.

Most of the setup is done via a webinterface, but the initial network setup needs either the right IP addresses hardcoded or a USB connection and the Microbit setup software which is only available for Windows. I did try to see whether one of the four com-ports via USB that showed up would allow me to do a minimal setup via a terminal program but that wasn't true. So I booted Windows to change the units to DHCP. For the radio-side I made an address allocation in the DHCP server, for the client side it is fine to have any usable address.

And for my next minor issue: they only use IPv4. So my inner linux and networking geek is a bit dissapointed, but my inner radio geek will do just fine.

After that bit I went back to Linux, the rest of the software setup is via a webbrowser. For the hardware setup, which is how it connects to the radio (which pin has audio, which pin has power) it needs a number of internal jumpers and jumper wires connected.

Tags: , , ,
2019-10-25 Slow(ish) syn floods getting more complicated to filter 7 months ago
Cybercriminal I'm seeing lots of sockets in state SYN_RECV again and noticed this time my earlier iptables rules to not respond to tcp syn packets that don't build up a connection aren't working. Between two syn packets from the same source there is 5 minutes, so my system responds to all of them. Ranges of addresses in the same block are used as source IPv4 addresses. For one address the traffic is very minimal:
22:40:51.600077 IP 112.175.120.39.58275 > 82.95.196.202.22: Flags [S], seq 720891004, win 29200, length 0
22:40:51.600392 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:52.612035 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:54.628048 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:40:58.660031 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:41:06.851865 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:41:22.980000 IP 82.95.196.202.22 > 112.175.120.39.58275: Flags [S.], seq 1729897232, ack 720891005, win 29200, options [mss 1460], length 0
22:45:18.565999 IP 112.175.120.39.41767 > 82.95.196.202.465: Flags [S], seq 910623633, win 29200, length 0
22:45:18.566415 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:19.588000 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:21.604022 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:25.667936 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:33.860000 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
22:45:49.987965 IP 82.95.196.202.465 > 112.175.120.39.41767: Flags [S.], seq 3977721413, ack 910623634, win 29200, options [mss 1460], length 0
But multiply this with several source IPs in the same IPv4 /24 block and a lot of open servers in the world and suddenly you get a lot of return traffic.

Tags: , ,
2019-10-16 The signatures for the first DNSSEC signed zone expired, and I signed the rest 7 months ago
Today I was reminded of the first zone I signed with DNSSEC and did the check again with DNSViz. And I saw a lot of error messages. Some searching found that I let all the signatures expire (after the default time of 30 days).

Solution: re-sign the zone and have a careful look at when I need to sign the zones again. Officially just in time for expiry time of the signature (default 30 days) minus TTL of the record.

Obviously this process has to be automated. In the first go I decided to force new signatures after 21 days. But I tested some things later and decided to go for more regular checks of the ages of the signatures and refresh the signatures that are about to expire. This is usually reserved for 'big' zones with lots of resolvers querying them but I decided to implement this myself to avoid problems, and learn more about DNSSEC.

The magic signing command is now:
-zone-signedserial:
    named-checkzone $* $^
    ./SOA.pl $^
    dnssec-signzone -S -K /etc/bind/keys -g -a -r /dev/random -D -S -e +2592000 -i 604800 -j 86400 -o $* $^
    rndc reload $*
    touch $@
The expiry is set with -e at 30 days, the checkinterval with -i at 7 days and the jitter factor with -j at 1 day.

Now there is a special part in the Makefile to be called from cron on a regular basis. It won't produce any output when there is nothing to update.
agecheck:
    @for zone in $(SIGNEDZONES); do if [ `find $${zone}-signedserial -mtime +7 -print` ]; then touch $${zone}-zone ; $(MAKE) --no-print-directory $${zone}-signedserial; fi ;done
The Make variable SIGNEDZONES is filled with the zonenames of the zones that have to be kept DNSSEC signed. File structure for each forward zone is as listed in first zone with valid DNSSEC signatures.

So now almost all my domains are DNSSEC signed. A learning experience and a good level of security.

Tags: , , ,
2019-09-11 First zone with valid DNSSEC signatures 8 months ago
My previous test with DNSSEC zone signing showed a problem with entropy in virtual machines. Today I had time to reboot the home server running the virtual machines including the virtual machine with the nameserver, based on bind9.

Now I can create DNSSEC signatures for zonefiles at high speed (0.028 seconds) with enough entropy available. My first test is with camp-wireless.com which is a domainname for redirecting to Camp Wireless but since that variant was mentioned somewhere I had to generate the redirects to the right version.

The next step was to upload the DS records for the zone to my registrar and get them entered into the top level domain. This failed on the first attempt, the DS records have to be entered very carefully at the registrar.

I tested the result with dnsviz for camp-wireless.com and found an error in the first try: I updated the serial after signing the zone. So the soa record wasn't signed correctly anymore.

I updated my zonefile Makefile to do the steps in the right order:
-zone-signedserial:
        named-checkzone $* $^
        ./SOA.pl $^
        dnssec-signzone -S -K /etc/bind/keys -g -a -r /dev/random -D -S -o $* $^
        rndc reload $*
        touch $@
For the zone camp-wireless.com the original data is in camp-wireless.com-zone, the DNSSEC signatures in camp-wireless.com-zone.signed. And make will abort when one of the commands gives an error level, so it will for example stop completely when I make a typo in the zonefile which will make named-checkzone fail. The -D option creates a file to be used with $INCLUDE in the original zonefile. This does create a circular dependency: named-checkzone will fail when the -signedserial file isn't available on the first run. So the first run will have to be manually.

So now the zone is signed correctly. The next developments will be to find out how to monitor this extensively so I won't be surprised by problems and to redo the signing from time to time to make DNSSEC zone walking very hard.

And when I trust all of this I will implement it on other domain names that I manage.
Read the rest of First zone with valid DNSSEC signatures

Tags: , , ,
2019-09-08 A thumbs up for robust scripts 8 months ago
Encrypt all the things meme Today some of the letsencrypt certificates were older than 60 days, so the renewal script started to kick in. Last year I completely automated the certificate renewal of letsencrypt certificates with dehydrated and wrote some scripts around the renewal process with hopefully enough error handling.

Today some of the error handling got tested, one renewal gave an error:
  + ERROR: An error occurred while sending post-request to https://acme-v02.api.letsencrypt.org/acme/new-order (Status 500)
And indeed the dehydrated script gave an error level, the resulting (empty!) .crt file wasn't copied and nothing happened. On the next run of the renewal script this certificate will still be older than 60 days and therefore the renewal will be tried again.

Tags: , , ,
2019-09-06 The morse keyer is working with cqrlog 8 months ago
Next step was linking the morse keyer with the Linux radio logging and operating software cqrlog. A simple search gave me Nanokeyer with cqrlog - CQRLOG and indeed the suggested option 'WinKeyer USB' works. The option 'K3NG keyer' always stopped after a few characters of morse.

Now to get other software like fldigi and tlf working. And not have conflicts with both of them running.

Update: In the tlf manual I found a link to N0NB/winkeydaemon on github which works great too. I changed the default port /dev/ttyUSB0 to /dev/ttywinkey because USB0 is where my radio CAT control usually ends up, and two applications trying to use that serial port confuses the radio. The /dev/ttywinkey link is maintained by udev, with a rule in /etc/udev/rules.d/99-usb-serial.rules :
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttywinkey"
I can't select on a serial number or anything more specific so devices with a QinHeng Electronics HL-340 USB-Serial adapter will probably all try to get a symlink to /dev/winkeyer.

I tested the result with cqrlog (selecting the cwdaemon option in cqrlog cw settings) and it works fine too. Next step will be to test with tlf.

Tags: , ,
2019-09-06 The nanoKeyer morse keyer is working 8 months ago
nanoKeyer morse keyer and morse paddle key
The nanoKeyer and the morse paddle key. Connections to the nanoKeyer from left to right: cw to radio, input from paddle and usb to the computer
After a few hours of thoroughly soldering and checking the results the nanoKeyer is done. I did find an error in my work so I had to get out the desoldering iron to fix it: I put the wrong resistor in one place.

Next step was to get the arduino that is the core of the nanoKeyer tested. There was an arduino nano included with the kit preprogrammed with the nanoKeyer software, but it still needed the print headers soldered: two rows of 15 pins and very secure soldering work. I did put the small tip on my soldering station for this work and used a magnifying glass to check my results. It seemed to work fine but I noticed soon the speed control potentiometer and the menu buttons gave no response. Both those functions use an analog input of the Arduino in the nanoKeyer. I had bought an arduino at a previous radio parts market so I tried that one. This one already had the print headers installed so there was less chance of causing a defect.

That one had to be programmed first, so I dove into getting the Arduino integrated development environment installed. After a few tries it seemed the only way to have working USB communications is to run the whole Arduino IDE as root (using sudo). Not very secure but at least I could continue my work. The right settings were made according to the nanoKeyer Firmware Upload Guide 2 and the Arduino nano I bought myself works fine. The result: sending morse code, changing settings with the menu button all worked fine.

The ultimate step was to get software controlled CW generation working. I soon found Winkey USB works in Linux - OK1RR which has a driver binary (no source unfortunately) which communicates fine with the nanoKeyer. The network UDP protocol is somewhat very binary so I used one of the cwdaemon test programs to get actual morse code sent from the computer.

Now for the (for me) hard part: making the right holes in the case. I'll try to find some help at my radio club.

Earlier steps: starting with the nanoKeyer kit.

Tags: , , ,
2019-08-21 Comparing yfktest and tlf for linux-based amateur radio contesting 9 months ago
Episode 295 of Linux in the Ham Shack is about the TLF Contest Logger. I wrote to Linux in the Ham Shack about my experiences with both programs. In 2017 I participated in the IARU-HF contest using yfktest and in 2019 I participated in the IARU-HF contest using TLF.
My opionion about both is clearly formed by my style of contesting. Phone contesting is rare for me, and I am a very casual contester. I operate in search and pounce mode, where I search for other stations calling CQ.

My experiences:

Both are textmode programs, which try to mimic DOS-based contest programs. No dragging around windows, you'll have to deal with how the makers decided to set up the screen. Also, on a graphical system, try to find the biggest and baddest monospace font to fill as much of your screen with the contesting software as possible.

The role of contest logging software is making it easier to log contacts in a contest. It does this by automating a lot of the tasks in a CW contest, by keeping the log and showing the outgoing serial number (if needed). It's a plus when contest logger can keep the live claimed score in the contest and when it can connect to a DX-cluster and show possible contacts being spotted. Both packages can do the basic contesting and scorekeeping, tlf is the only one that supports DX clusters

yfktest is written in Perl, tlf in C. For adding a new contest to yfktest you will soon have to do some programming in perl to handle the score calculations. For a new contest in tlf you may have to do some C programming.

yfktest has no cluster support, but tlf does have it. This is a huge difference to me. With tlf I could open a cluster window showing me where new calls were spotted and on what frequencies recent contacts were, so I could hunt for interesting new calls and multipliers

Specific to the IARU-HF contest and my use of the packages: yfktest supports the IARU-HF contest out of the box, so it gets the multipliers right. When I did the IARU-HF contest with tlf, I asked about it on the list and someone shared a configuration right at the beginning of the contest so it worked. Mostly: It did not count the multipliers correctly, so I had no idea of the claimed score during the contest.

Both are open source and welcome any additions. Looking at the commit history tlf is somewhat more active recently.

If you want to really add a contest to either of them you'll probably have to start thinking about that months before the contest and take your time to debug your rules/scoring configuration if you want good scoring during the contest.

I will probably stick with tlf because of the cluster support.
Linux in the Ham Shack took my shallow dive a lot further and went into a deep dive with installing, configuring and running TLF. Awesome episode, I really enjoyed it!

Links to all the stuff: Show Notes #295: TLF Contest Logger Deep Dive - Linux in the Ham Shack
yfktest linux based ham radio contest logger, TLF, a linux based ham radio contest logger.

Tags: , , ,
  Older news items for tag linux ⇒
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews