News archive 2019 - Koos van den Hout

I saw reports of special propagation on the 2 meter band and even on 70 centimeters today. Normally I can get something further than line of sight on 2 meter and line of sight is the hard limit on 70 centimeter. But with some propagation types it's different and signals can get further. So I tried FT8 on both bands and got Belgium, France, Germany and England in the log on 70cm and new callsigns on both bands.

Denmark still got away, I had an almost-contact with a Danish station on 70 centimeters but it stopped after the initial exchange.

This is all with the vertical antenna on the roof. I wonder what a beam or big wheel antenna for 70cm or 2meter could do.

At the same time I spun the dial on the remote HF radio so I also got some calls in the log on 20 meters.

Update: Current distance record on the 70 cm band is 803 kilometers to F8DBF in France and the first contact with Denmark has been made.

The main unit of the Kenwood TS-480SAT radio is now at a different location and the frontpanel is at home. With an OpenVPN connection between them so it's not exposed to the big bad internet.

And it's working! I currently have access to a 10/15/17/20 meter antenna and I have already heard stations I wouldn't dream of receiving at home. And the first country in SSB in the log that I only had in digital modes before: Ceuta and Melilla, the Spain enclaves in Africa.

Lag is minimal, audio is less delayed than listening to the utwente websdr to the same signal. Control works fine, so I can control the radio like I'm sitting behind it, including menu settings.

Comparing received signals on the local radio with the attic dipole and the remote radio is hell and heaven: local noise is S9+ and the remote location has almost no local noise (while still being in an urban environment) so I can hear even weak stations fine. I leave the noise blanker off most of the time because it's not needed to hear signals fine.

Not making loads and loads of contacts yet, propagation isn't cooperating very well and there aren't many people calling CQ. But when a somewhat special station calls CQ there are a lot of answers so there are numerous amateurs active. Or I guess they go to their set when they see an interesting callsign on the DX-cluster.

I also got morse keying by paddle working beforehand. Hearing the sidetone from the radio with just a bit of lag got annoying fast when doing morse at a bit of speed so the sidetone is now from the control unit and the sidetone in the radio is silent. It's still set to the same audio frequency as the sidetone in the control unit to allow for finding the zero beat frequency.

I tried adding subzones with DNSSEC by adding the DS record to the parent zone, but in both tries I got errors from DNSViz. Different errors even: in one case the signature on the DS record was seen as invalid and in another case there was no signature at all. The errors are reproducable, even after waiting for caches to empty.

I kept seeing warnings about an expired signature when running named-checkzone or dnssec-signzone and it took some searching before I found the reason.

Recently I removed the records with type SPF from my zones since the recommended approach is to use TXT records with SPF data. The RRSIG records for the SPF records were left in the signed zonefile, but not updated so they expired and started to give warnings.

The SPF records were for names that had other data too which seems to trigger this. Removing a record completely (no RRTYPEs left for the name) removes all signatures.

The things in DNSSEC I haven't tested yet are a signed subzone, a ZSK rollover and a KSK rollover. Those will eventually happen too.

The machine ns3.idefix.net moved so I had to do the whole update dance with the glue records again. Since the IPv6 glue records 'vanished' when I added DNSSEC to idefix.net I decided to move idefix.net to a different registrar where IPv6 glue records and DNSSEC are normal and don't require an extra support call.

Since I have an account with TransIP anyway for the stack storage service I just had to add (and pay for) domain services. Interesting bit is that TransIP says I have to pay again next year. According to the registry the domain is registered until 11 august 2024 at the moment.

Adding DNSSEC gave problems at first, the format they expect is from the public part of the key signing key, which is a different format from the dsset-idefix.net. file which gets generated by dnssec-signzone. After some tries and searching I found the right source and format. The error message was about the Key Tag which was confusing as that is a number where there isn't much to go wrong.

Now I have DNSSEC running ok on my domains I can start looking at security innovations that rely on DNSSEC.

The first one is DANE for the mailserver, in which the public key signature is published in DNS record secured with DNSSEC to give a separate path to verify the public key during the SMTP session.

The public key of the mailserver is also signed by LetsEncrypt as described in Automating Let's Encrypt certificates further and Automating Let's Encrypt certificates with DNS-01 protocol so there are two completely independent paths to verify the identity of the mail server.

To find the public key of the mailserver for a given domain:

$ dig +short idefix.net mx
10 postbox.idefix.net.
$ dig +short _25._tcp.postbox.idefix.net tlsa
3 1 2 2B55764A99A47AEC5B66D8EB4E741F2646BF6352CABC9BE3F37D2F42 0BD7EF56B5BE3058E7B10964BA963777364443057E45599E07A82375 7A812F1A7014356A

I found the tlsa tool from package hash-slinger by Paul Wouters to create these records. This can be both from the protocol which has certain risks (if that connection is intercepted) or from the public key file. Or via the web tool Generate TLSA Record by Shumon Huque.

TLSA records are generically linked to a TCP or UDP port. The next step will probably be to start adding records for other public services with TLS like https. There was a time that some people were convinced DANE was going to replace certificate authorities for https, but at this moment it is very limited. I have added TLSA records for https (tcp/443) for camp-wireless.com and www.camp-wireless.com for now and I'm testing with these. For now one of my favourite checkers isn't convinced.

This does increase the chances for things to go wrong. With the tlsa program it is possible to verify records too, so I can use this to verify TLSA records.

$ tlsa --verify -6 --starttls smtp --port 25 postbox.idefix.net
SUCCESS (Usage 3 [DANE-EE]): Certificate offered by the server matches the TLSA record (2001:980:14ca:1::23)

Although this certificate is a valid LetsEncrypt certificate, DNS-based Authentication of Named Entities (DANE) does not support usage 1 (check the certificate public key and verify certificate chain to a known root) for SMTP with STARTTLS, so it is usage 3 (just check the certificate public key). The tlsa program does not check this specifically, but the web checker at DANE TLSA Server checker found the issue, so I corrected that.

I use selector 1 to just check the public key because the complete certificate changes with every LetsEncrypt renewal. My choice for mtype 2 (sha512) is just a wish for a strong hashing algorithm.

This also makes the link between service configuration and DNS contents a lot stronger. Maybe this needs secure automated updates.

Met alle tips voor het maken van veilige wachtwoorden en die alleen beschikbaar hebben vanuit een wachtwoordmanager loop ik nu tegen websites aan die vragen om een wachtwoord maar vervolgens moet je dat wachtwoord ineens op een fysiek andere plek dan achter je eigen computer intikken.

De eerste keer dat ons dat overkwam was bij een camping van staatsbosbeheer op Ameland. We hadden ons via de website ingeschreven en bij het aanmelden op de camping zelf bleek er een aanmeldscherm te zijn waar je met e-mail adres en wachtwoord moest inloggen. Maar we gebruiken voor dat soort websites altijd gegenereerde wachtwoorden die we niet weten. Met veel zoeken naar de hoek van de camping met een beetje mobiele data dekking konden we bij onze wachtwoordkluis en konden we het wachtwoord opzoeken. Want het aanmeldscherm is omdat de beheerder van de camping er ook maar een uur per dag is.

De tweede keer was bij de bibliotheek in Utrecht. Als je daar in de bibliotheek zelf een reservering wilt maken moet je ook inloggen op een computer met gebruikersnaam en wachtwoord. En ook daar konden we het niet snel opzoeken, maar daar konden ze ons helpen aan de hand van de bibliotheekpas.

Based on the fact that RIPE has really run out of IPv4 addresses it is way overdue to start using IPv6.

To help that I wanted to have a way to show visitors to my site whether they can use the new protocol. The current box on the righthandside is based on the connection with the webserver and most browsers prefer the fastest connection to just give the user the best experience. The so-called 'happy eyeballs'.

But I want to show visitors whether their browser/system/network supports the new Internet protocol. So I'm looking into ways to check for IP versions with Javascript. Ages ago their was a test (mainly to test for systems with broken IPv6 connectivity) but that one is gone and not completely what I want.

So I asked around and Iljitsch van Beijnum responded with his version of the IP version test.

So my current version is at ipv6test.idefix.net. Plan is to add an option to have true/false values in javascript available and make updates to parts of the page using that.

I could imagine turning a page black-and-white if you only have 'old' Internet protocols. I just have to learn a lot more javascript to do that.

This week had an opportunity to receive ISS SSTV pictures. The Russian on the ISS were transmitting SSTV images as part of the Inter-MAI-75 project.

The pass had a partial first image, a nice decode of one full image and the start of a third image. Even the good receives are a bit noisy/unsharp, I'm not sure whether that's an artifact of the PD120 mode or some local noise ending up in the image.

This is one of the rare occasions where living close to Russia is a good thing: the Russians time the passes to optimize reception in Russia.

For a number of years between 1993 and 1997 I not only had a BBS running at home but also an IBM RT 6150 computer. It was a bigtower I got for free including the system floppy disks. I had to reinstall it because I had no idea of the root password and the only contact at the previous owners wasn't willing to give it up. So I swapped 1.2 megabyte 5.25 inch floppies for a while until I had a complete running system with AIX complete with graphical environment and a working TCP/IP stack.

The IBM RT 6150 I had came with 3 builtin harddisks (full-height). For as far as I remember those were 70 megabyte each. Eventually I had enough AIX installed to also have a working compiler.

One downside of this system was the powerusage. It used quite a lot of electricity.

The rest of BBS Koos z'n Doos also used a lot of power. When I moved out of my parents' house in a December month the effect on the electricity bill was remarkable. Next December my parents got a call about what changed because the electricity bill had halved. And I did put 'computers' on the form for the new electricity contract but that same december I received a bill because the electricity for that house was double what the electricity company expected.

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!

The next thing I want to get working is morse with the remoterig and the Kenwood TS-480. The good thing is that the remoterig has a built-in morse keyer to overcome jitter problems.

And that keyer has the option to make a winkeyer usb interface available. I did some minor testing with the winkeydaemon driver together with the paddle and it works. So I can use both the keyer from the computer and the paddle at the same time, just like with the nanokeyer and the FT-857 radio.

There is one strange thing though: this keyer responds somewhat different from the nanokeyer when I do a fast dah-dit. I expect the dit to follow after the dah even when I already stopped touching the left paddle (dit) before the dah ends.

I dug into the "why isn't remote CAT control not working" on the Kenwood TS-480SAT with the remoterig setup and as the debugging session progressed I found out it wasn't even working locally. The Kenwood TS-480 radios have a male db9 connector just like the PC had, and the non-intuitive part is that it needs a straight-through cable with data lines and hardware flow control.

I had a bunch of serial cables and adapters cobbled together to get from DB9 female to DB9 female with wires 2 and 3 coming out uncrossed, but it did not have hardware flow control and that had worked one evening before but now it decided to go on strike.

Thanks to the visit to the "Dag van de radio amateur" (DvdRA) ham convention and the extra parts ordered on-line from Conrad I had enough parts to make my own serial cable with the right wiring, including covers for the connectors with the cable coming out on the side.

So my skills in building right serial cables using a soldering iron, flexible wire and an amount of patience were recalled. I am very sure I haven't done that yet this century. Old CAT-5E cables are a good source of flexible cable with 8 wires.

When I had a finished cable with hardware flow control I first did a local test before I started putting the covers on the connectors and when that did work fine I put the covers on, redid the test and switched to testing over the remoterig connection. That also worked.

Update: And for the laptop which doesn't have serial ports I activated the COM port to USB translation on the control side. It took a bit of searching before I found that /dev/ttyACM0 was the active port, so now I can run CQRLOG on the laptop with full control of the radio.

I finished the setup of the remoterig system. The second part is with lots of wires, first setting jumper wires in the radio box and the control box and after that connecting lots of wires to radio, frontpanel, microphone and other parts.

It took a bit of browsing the manual, checking my jumper wires under good light and redoing the checks but eventually it got all connected.

After that it was setting the software parameters for the specific radio and the connection to the control panel. And the next step: pressing the power button on the frontpanel on the control box and seeing it become active and hearing audio from the radio.

So it's now working. The bit that doesn't work yet is CAT control of the radio (Computer Assisted Tuning, where I can read the status and give commands over the serial port). The forwarding of the CAT port to a USB serial port on the other side did not give me any communication on the connected computer. I'm sure I'll get that fixed.

Next step was to spin the dial and find someone searching for a contact. Not a lot of activity on the 40 meter band, but I heard a greek station calling, answered it and got into the log.

Aardige hoeveelheden spam vanaf dailyboxoffice.co. In het Nederlands. Voor een adres wat ik niet publiek gebruik, dus er is weer eens een hele oude spamlist of zo opgegraven.

Wat me opvalt is dat er niets over te vinden is, dus begin ik er zelf maar eens over.

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.

HF propagation has been really bad the last weeks. At least on the moments I had time to look at the radio. The maximum usable frequency was dropping below 14 MHz as soon as it started getting dark. This means that I can only make contacts on the lowest band (40 meters) with the endfed antenna set up outside and the experience from earlier weekends was that it was still a lot of work to get contacts on FT8.

So this weekend I did some 2 meter FT8 and made contacts with some new call signs. I was lucky: the 2 meter interference stopped after dark. My computer decoded one Danish callsign but I wasn't near it at that moment.

And I tried a pass of the SO-50 satellite. A pure southwest-northeast pas was coming up at the start of the evening, so I planned to be outside in the cold with antenna and handheld radio. I was hoping to get some country to the south of me in the log, but I ended up with a southeasterly contact: Croatia. I heard 9A2EY in a contact so I called him and made the contact.

I was tuning across the 70cm amateur band and heard lots of weird noises around 433.92 MHz. Which is logical: that's the ISM band (industrial, scientific and medical) so lots of unlicensed low-power signals there.

That triggered me to update rtl_433 and see what I could receive. The answer after some searching how to build a running version: a lot. Including tire pressure monitoring sensors (TPMS) on a nearby car:

time      : 2019-11-16 15:33:25
model     : Toyota       type      : TPMS          id        : fb8c8bf9
status    : 128          pressure_PSI: 38.500      temperature_C: 6.000
mic       : CRC

There is indeed a Toyota parked across the street. I see three different values for 'id' suggesting that three wheels are 'awake' and reporting tire pressure data about every two minutes. According to eavesdropping the wheels, a close look at TPMS signals the sensors should only activate when the car is going faster than 40 km/h or when a special LF signal is active.

Some things noticed by Suricata IDS are amusing to me. When looking at lines like:

11/15/2019-13:14:35.001691  [**] [1:2402000:5363] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 185.156.73.11:46843 -> 82.95.196.202:41505
11/15/2019-13:15:06.794357  [**] [1:2402000:5363] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 88.214.26.102:42131 -> 82.95.196.202:8703
11/15/2019-13:15:06.794357  [**] [1:2403384:53195] ET CINS Active Threat Intelligence Poor Reputation IP group 85 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 88.214.26.102:42131 -> 82.95.196.202:8703
11/15/2019-13:15:20.065796  [**] [1:2403393:53195] ET CINS Active Threat Intelligence Poor Reputation IP group 94 [**] [Classification: Misc Attack] [Priority: 2] {UDP} 93.174.95.106:27221 -> 82.95.196.202:7
11/15/2019-13:15:32.845110  [**] [1:2402000:5363] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 185.156.73.21:44503 -> 82.95.196.202:43935
11/15/2019-13:16:23.399397  [**] [1:2402000:5363] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 185.175.93.27:58989 -> 82.95.196.202:53166

All 'Dshield Block Listed' and 'Poor Reputation IP' traffic is port scans to ports that are blocked. So it's not a surprise those IPs have a poor reputation or a Dshield listing.

After hearing about intrusion detection systems a few times I decided to give one a try at home. Although a lot of attacks are blocked I sometimes see weird attacks and it would be nice to have a better idea of what exactly the attack was.

Yes, I have weird interests sometimes. I'm glad I have an ISP (xs4all) where I can select the option 'give me the completely unfiltered Internet connection' so I even see SMB protocol attempts.

I first tried 'snort' but that doesn't deal with PPP interfaces by default. It can be recompiled to accept those but I did not want that. The next option I heard about is 'Suricata' which is running at the moment.

I was amused by the reports of DDoS-like NTP traffic. Those are caused by the NTP statistics gathering. I know NTP can be abused for generating DDoS traffic but all security reports about NTP servers I manage have been false positives.

Anyway it's running and complaining a lot about the traffic it sees. For example the IPv6 port scan/network mapping attempts I noticed two months ago are still active.

11/13/2019-15:06:59.703451  [**] [1:2002911:6] ET SCAN Potential VNC Scan 5900-5920 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 240e:00f7:4f01:000c:0000:0000:0000:0003:6050 -> 2001:0980:14ca:0001:020d:56ff:fece:ffe1:5901
11/13/2019-15:08:39.645780  [**] [1:2002911:6] ET SCAN Potential VNC Scan 5900-5920 [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 240e:00f7:4f01:000c:0000:0000:0000:0003:5167 -> 2001:0980:14ca:0001:020d:56ff:fece:ffe6:5901

So the order for the remoterig duo to work on my remote HF operation plans is out the door. I ordered them with HamShop to get Dutch warranty rules.

I also ordered some other stuff from Conrad to be able to get everything cabled correctly. I may have missed something but I hope to have enough to get going and be able to have frontpanel and main radio hardware separated by Internet.

Powersupply with wires attached

I had time to do some soldering and I tested and wired the 12V server powersupply I bought last Saturday at the "Dag van de Radioamateur" ham convention.

The powersupply that I bought is an HP DPS-800GB A and it already had two wires to make it start up when input voltage is applied. I just soldered thick wires to the output terminals so I can connect it to the HF amplifier. Unlike the previous HP DPS-700 powersupply this one has two builtin fans so it won't overheat.

Time to test it with the HF amplifier is this weekend. I'll test the output power with the current output voltage left as-is. It's currently at 12.2 Volt when no load is applied. There are simple modifications to raise the voltage as described by Server supply DPS-800GB - PA0FRI.

Update: After some testing it's clear there are two problems: the output voltage of this power supply does not get very high before it switches off. About 13 volts. At that voltage the output power of the HF amplifier is limited. And when using the external amplifier I had a lot of problem with the connection between the computer and the radio. As soon as I started transmitting the computer started giving error messages about the communication with the radio.

So back to just the radio and its output power at the moment.

Today was the Dag voor de Radioamateur edition 2019, and I went there.

My main todo item was to deliver outgoing qsl cards to the Dutch QSL bureau and pick up the new ones for Region 08. So I walked in with a big shopping bag and after visiting the Dutch QSL bureau market stall I returned to the car right away with a new box full of cards. After that I walked in again and started looking around. I was looking for certain parts I needed recently such as RCA connectors, 2.5 mm stereo jack connectors. I also had some specific things in mind such as a newer high amperage 12V supply because the previous server power supply smoked itself and an antennaswitch and serial connectors for remote HF operation which I found. I found no USBaudio and USBserial interfaces so those will be picked up in the next electronics web order.

I attended a lecture on the QO-100 amateur satellite and the story behind the Patch of the Year antenna co-developed by Remco PA3FYM.

I also met a lot of amateur radio friends, more than I expected!

It seems the TCP reflective SYN attacks are continuing. In researching my options I saw the option to use a netmask with the iptables recent module.

This helps a bit with the attacks trying to flood an entire block. I've updated the filtering to work by the /24, start a check on a SYN from such a block, end when an ACK flies by and start dropping when the rate is over 10 per 2 minutes.

iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN -m recent --update --seconds 120 --hitcount 10 --name tcpsyn --mask 255.255.255.0 --rsource -j LOGDROP
iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN -m recent --set --name tcpsyn --mask 255.255.255.0 --rsource
iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,ACK ACK -m recent --remove --name tcpsyn --mask 255.255.255.0 --rsource

LOGDROP is a rule to drop packets and ratelimit the logging of dropped packets, to avoid turning a network attack into a disk attack.

But I have to be careful not to make services hard to reach for legitimate clients. The above is working, and during attacks I don't see a single SYN_RECV socket.

Sometimes you really wonder about the amount of errors made by noisy attacks. I noticed the following pattern in the system logs:

nnrpd[7029]: 189.243.177.73 unrecognized Accept-Encoding: identity
nnrpd[7029]: 189.243.177.73 unrecognized Content-Length: 586
nnrpd[7029]: 189.243.177.73 unrecognized Accept-Language: en-us
nnrpd[7029]: 189.243.177.73 unrecognized Host: 74.219.111.25
nnrpd[7029]: 189.243.177.73 unrecognized Accept: */*
nnrpd[7029]: 189.243.177.73 unrecognized User-Agent: ApiTool
nnrpd[7029]: 189.243.177.73 unrecognized Connection: close
nnrpd[7029]: 189.243.177.73 unrecognized Cache-Control: max-age=0
nnrpd[7029]: 189.243.177.73 unrecognized Content-Type: text/xml
nnrpd[7029]: 189.243.177.73 unrecognized Authorization: Basic YWRtaW46ezEyMjEzQkQ...

With some searching I eventually found exploit code for certain series of digital video recorders which can be anywhere on the wide Internet.

The whole protocol mismatch makes this a lot noisier via the nntp port than via http, but I also see some attempts via the http port.

Update: Suricata doesn't recognize the specific attack, but it does notice the HTTP basic auth in the traffic:

11/13/2019-20:12:33.772828  [**] [1:2006402:11] ET POLICY Incoming Basic Auth Base64 HTTP Password detected unencrypted [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 188.59.207.57:43753 -> 82.95.196.202:119

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.

Ik ontdekte dat de website van de HCC PCgg netwerkgroep nog prima draait maar wel als onveilig in een moderne browser werd aangemerkt omdat er invoervelden in zitten.

Ook al is de laatste activiteit op de site van Augustus 2012 wil ik toch deze site in de lucht houden omdat ik toen heel veel lol heb gehad met de netwerkgroep en het leuk was om daar presentaties te geven en dingen uit te zoeken.

Dus de site draait nu met een LetsEncrypt certificaat op https. En het was een mooi moment om gelijk de versie van serendipity zelf bij te werken.

Update: Ik zie nu ook browsers die alle http gewoon als onveilig melden. Het is denk ik tijd om de laatste sites ook over te zetten naar https.

I was looking at the overview of most requested but not available URLs and noticed there is still traffic to http://webcam.idefix.net/. For years that was the webcam site when I still had access to a reasonable location for putting up a webcam. First a good view at my previous house, and later a window with a good view from a server room at work.

So I dug up the archived images and scripts, cleaned them up and made them available again. There are no fresh images, just the aged archives.

I noticed some really unused records in one zone which is now DNSSEC signed. For example I still had gplus.idefix.net to point at my Google+ page.

So I removed them and did the signing after increasing the serial number. Indeed the records that had no update kept their original signature and the records that where changed (such as the SOA because of the serial number) were signed with new signatures.

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.

Since January 2015 I've been using CQRLOG as the main amateur radio logging program. So each contact that I make ends up in the databases of this program eventually.

Being the person I am I added some scripts of my own to export data from CQRLOG to the PE4KH amateur radio station website in several formats.

I've made a few of these scripts available for the public via KHoos/CQRLOG-scripts: A collection of scripts around the CQRLOG amateur radio logging software on github. I've set the license to GPLv2, but I may have to change this as one script contains a lot of imported code.

Anyway, share and enjoy. Maybe these are of use to someone. Or someone adds the enhancements I've been thinking about but never got around to.

While looking at some network issues at home I noticed some weird traffic coming in from the outside: forged SYN traffic. Fast enough to trigger my iptables rules to stop being part of tcp syn attacks so all traffic gets dropped. Searching for a bit finds Hell of a Handshake: Abusing TCP forReflective Amplification DDoS Attacks - usenix which discusses this kind of attack.

At the moment it's about 1 or 2 packets per second. The traffic itself isn't notable on my connection and even without the firewall rules it still wouldn't impact my system. But do this with a lot of systems on the Internet running some tcp service and quite some traffic will go to the targeted IP address.

I guess someone doesn't like some Maltese Casino website. I don't like casino websites either because they promote addictive behaviour but I'm not about to use a DDoS.

The last years I've been dealing with increasing levels of interference on the HF bands at home. One clear source is the rising numbers of solar panel installations, with a clear difference between hiring the cheapest installer versus hiring a good installer but paying more.

I don't want to start discussions with all neighbours about their solar installation and the latest news seems to be that the Dutch telecoms regulator takes the stance of solar panels being needed for our economy so radio amateurs have to accept the interference.

Moving house is not in our plans for the coming years so I started reading about the options for remote operations, where I can sit at home with the microphone and morse key looking at the display of the radio and hearing the audio while the receiving/sending part is at a remote site with a lot less interference.

I found out about RemoteRig which does just that, and with the right choice of radio allows complete remote operation over the Internet. With their offering I started looking at compatible HF radios and found a nice secondhand Kenwood TS-480SAT. This radio has better filtering options for SSB and morse than my Yaesu FT-857D.

The radio is now at home and I made the first few SSB contacts with it. The filtering already helped me understand stations better.

Now for the next steps, cables, remoterig units and other things. And a remote location. I have an offer from a fellow radio amateur to do the first tests at his house. When all that works out I'll go and find a nearby location to do the complete installation.

A search for the top 10 tried usernames for ssh gives a nice list:

     52 admin
     23 pi
     19 test
      7 oracle
      6 support
      6 nagios
      5 user
      5 ubnt
      4 ftpuser
      3 virtualbookcase

This weekend is the BARTG Sprint75 RTTY contest. I set up my endfed antenna on Friday evening. On Friday I listened around the band for any morse special event stations and found LZ304EW active. The station was calling with a morse speed of about 21 words per minute and I answered my callsign with 12 words per minute. And no, I can't decode morse at 21 words per minute, I used the computer (fldigi) to help me decode the morse and the nanoKeyer to help me send my callsign and the 5nn TU 73 to finish the 'contact'. I felt secure enough in hearing my own callsign in morse to be able to do this.

Most of Saturday I made a number of FT8 contacts all over Europe. Nothing really exciting, just trying to get a number of new calls in the log. I think I saw some new gridsquares.

The planned amateur radio activity was the British Amateur Radio Teledata Group Sprint75 contest on Sunday evening (17:00 utc to 20:59 utc which is 19:00 - 22:59 local time). I set up the radio Sunday afternoon and listened on 14.080 MHz, which is the default frequency for RTTY on the 20 meter band for as far as I know. I saw different signals, which turned out to be FT4 signals, the relatively new mode in WSJT-X. It's been around for a while, I just never got around to playing with it.

So I started WSJT-X and tried FT4. I made three contacts, one with an amateur in England, one with 4S6NCH in Sri Lanka which is a new country for me, and one with an amateur in India, which was a new 20 meter country for me. Not bad for trying a mode for the first time.

After dinner it was time for the contest and that was a misery. I made 17 contacts in total, 4 on the 20 meter band and 13 on the 40 meter band. Propagation was not cooperating at all, mostly just giving noise and sometimes signals faded in and I had to work hard to get a contact.

Update: The bartg sprint75 rtty contest was a weekend earlier! Only when I tried to submit my results and the website told me all my contacts were outside of the contest timeframe I noticed my error. I guess some more radio amateurs had the wrong date as I have seen 'CQ BART SPRINT75' calls. And 75 baud RTTY mode is also rare. I notified the BARTG contest manageress to let her know. Not to complain since it was my error, but to make her aware of the problem.

I noticed some interesting traffic in my home network this morning, an attempt at finding IPv6 systems. Since IPv6 privacy enhancements are enabled on most systems this is exactly like finding a needle in a haystack.

I noticed an amount of outgoing icmpv6 traffic, and looking at the destination addresses and the type of traffic found lots of 'unreachable route' messages to a few Chinese IPv6 addresses. Searching for the netblock '240e:f7:4f01:c' finds more reports of portscanning activity.

10:14:27.761704 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12980 > 2001:980:14ca:1:5054:ff:feae:17.902: Flags [S], cksum 0xd0a9 (correct), seq 3726392987, win 29200, options [mss 1460], length 0
10:14:28.278108 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.19933 > 2001:980:14ca:1:5054:ff:feae:8003.12587: Flags [S], cksum 0xe1cc (correct), seq 95632679, win 29200, options [mss 1460], length 0
10:14:29.219766 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.41487 > 2001:980:14ca:1:5054:ff:feae:fff2.902: Flags [S], cksum 0x3c31 (correct), seq 500442149, win 29200, options [mss 1460], length 0
10:14:33.637405 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.35832 > 2001:980:14ca:1:5054:ff:feae:15.902: Flags [S], cksum 0xa6ea (correct), seq 2324914849, win 29200, options [mss 1460], length 0
10:14:34.468975 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12470 > 2001:980:14ca:42::ffe8.16992: Flags [S], cksum 0x5a72 (correct), seq 3249792078, win 29200, options [mss 1460], length 0
10:14:34.469038 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::ffe8
10:14:35.230776 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.63145 > 2001:980:14ca:1:20d:56ff:fece:8006.19: Flags [S], cksum 0xb87b (correct), seq 4259180220, win 29200, options [mss 1460], length 0
10:14:35.952841 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.9056 > 2001:980:14ca:42::8013.16992: Flags [S], cksum 0xbb3b (correct), seq 2896438720, win 29200, options [mss 1460], length 0
10:14:35.952880 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::8013

The nanoKeyer morsekeyer in case

I found help at the radio club, Kees PA5Z made his metalworking skills available and now the nanoKeyer has a nice case and works fine in it.

Earlier steps: the nanoKeyer tested and working after assembling the electronics, starting with the nanoKeyer kit.

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.

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.

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.

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.

My learning morse is still ongoing and I'm taking the first steps in generating morse. I decided on a paddle as a first morse key to get the dot/dash (or better: Dit and Dah) timing correct automatically. Opinions on tbe best choice for first morse key differ: some say a straight key is the best, others say a paddle. I'm sticking with the paddle at the moment because I also have a tendency to develop RSI. Telegraph operators were the first profession to have cases of RSI so I hope to avoid that.

I recently bought a paddle: the uniHam UNI-730a which is a nice affordable paddle for a starting morse operator. With the built-in keyer in my Yaesu FT-857 radio it is possible to create good morse code. I use the option to create the morse tone on the radio without transmitting to practise sending morse. I check the results with the Android application Rx Morse.

But, I want to be able to participate in morse contests in the future. For those a cw keyer is necessary that can be controlled both from a paddle (or a straight key) and the computer. I was looking at options when a fellow club member mentioned he had a nanoKeyer morse keyer kit available that he wasn't going to build himself because his radio can do all that work. So I bought the kit from him, including case and I'm soldering the first parts.

Since all parts are through-hole, I am soldering with the components 'hanging' from the board. I want all components to be as close to the printed circuit board as possible so for some things that want to 'fall' I use rubber bands to make them stay close to the board for the first soldering connections. I do avoid warming up the rubber bands, they will probably break and/or burn causing a nasty smell.

Ook inktbestellen.be gebruikt het ondertussen antieke adressen spam bestand wat ik voor het eerst zag in 2012: Want to pay 199 Euro for a worthless spamlist? Email-Packs makes it possible.

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

En zelfs inktbestellen.be spamt met de aanhef Beste Maes-Swerts/A.. Dat was dus al fout in 2012.

Flag of Austria, cc-by-2.0 license James Cridland

We went on our summer holiday to the Montafon area in the Voralberg province of Austria. This is an area that can be reached within one day of driving.

We went camping and stayed at the Aktivcamping Montafon in Schruns-Tschagguns. This is one valley away from the campsite we visited in the Summer of 2018.

Activities included lots of walks in the mountains and a few "klettersteig" (also known as "via ferrata") routes. I tried climbing and abseiling with the right equipment last year and learned that it's something I can do.

We did a three day tour of mountain huts (sleeping in those huts for two nights). Staying in mountain huts makes more remote areas reachable.

I was just wondering about the number of newsitems on my homepage and did a check. An interesting value popped up: 3000.

Yes, a round 3000 items since I started writing more than 20 years ago (or rather: 7456 days ago) : I've created a virtual bookcase with an overview of books I like/read.

Graphic created with Retro Wave.

Hat tip to Wil Wheaton, who mentions 6584 days - Wil Wheaton dot net

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.

The authoritive nameserver on the homeserver 2017 is using bind9 version 9.10.3 (from Devuan packages). I wanted to look up something in a secondary zonefile and noticed it was a binary file.

Using 'file' to determine what to do next wasn't much help:

$ file secondary.domain-zone
secondary.domain-zone: data

But a search found an explanation at Reading a binary zone file from Bind - The Linux Page. With named-compilezone a zonefile can be 'uncompiled' to a readable file.

$ /usr/sbin/named-compilezone -f raw -F text -o /tmp/secondary.domain-zone.txt secondary.domain secondary.domain-zone
zone secondary.domain/IN: loaded serial 2018122523
dump zone to /tmp/secondary.domain-zone.txt...done
OK
$ file /tmp/secondary.domain-zone.txt
/tmp/secondary.domain-zone.txt: ASCII text

Which is a readable zonefile.

Time for a new plot of the number of radio contacts. Months with contest(s) stand out again as they elevate the number of contacts. In July 2019 I participated in the DL-DX RTTY Contest 2019 and the IARU-HF Championship 2019. That last one has added a few countries to my list of countries confirmed in phone modes.

IPv6 is growing up: I saw an ssh attempt to an inside machine, reachable only via IPv6. The source was a Chinese IPv6 address which had not tried anything on any other public service.

Jul 30 18:39:02 ritchie sshd[27454]: Bad protocol version identification '\026\003\001' from 240e:d9:d800:200::212 port 44926

This evening had scheduled Amateur Radio on the International Space Station slow-scan TV transmissions so I took Arrow antenna, the new FUNcube Dongle Pro+, cables and laptop outside.

I found out gqrx crashes when the dongle is on the righthandside USB port of the laptop, so that one is out. On the backside port everything was working, and audio routing worked routing the analog output audio (created by qgrx) to the recording by audacity and the image decoding with qsstv. Gpredict was set up to control the reception frequency in gqrx, and this whole setup was working ok.

But the signal from the ISS looked very very weak in gqrx, just a small rise in level above the noise when I pointed at the general direction of the ISS. No idea why. No images were decoded from it.

After the pass I tried receiving some other sources with this setup and receiving the PI2NOS repeater went fine. But that's on the 70 centimeters band. I saw no activity on PI3UTR which would have enabled a test on 2 meters.

This needs more testing. Maybe something to hold the antenna cables so they don't get pulled from the laptop/radio during a pass.

Update: Most likely culprit: interference in the 2 meter amateur band. With a handheld radio that has received ISS packet sounds before I could now only hear them very faint in the noise. The local 2 meter noise is killing weak signal reception.

I just noticed in Network Info II that my android phone does get an IPv6 address from t-mobile. The address is something like 2a02:498:1fe1:9a02:2:3:xxxx:xxxx which is indeed in IPv6 address space allocated to T-Mobile Netherlands.

% Information related to '2a02:498::/29'

inet6num:       2a02:498::/29
netname:        NL-T-MOBILE-20080609
country:        NL

So I tested directly whether I could make an IPv6 connection to my website, but it fell back to IPv4. Network Info II saw no IPv6 route on the phone, but in later checking I also saw no IPv6 route when connected to the wifi at home, where IPv6 works fine. And doing a traceroute to that address from home shows that a core router at xs4all says network unreachable:

 3  0.ae22.xr4.1d12.xs4all.net (2001:888:1:4032::1)  6.105 ms !N  6.063 ms !N *

So T-Mobile has activated some IPv6 address management in their network, but stopped at that point.

I was looking at some onewire temperature stats and noticed the first stats being aged out. I started monitoring temperatures with 1-wire sensors in January 2007 using rrdtool. I set up round robin archives with an expiry in 11 years, and those 11 years have passed now for the first measurements.

Another random find in the 'special beers' rack in the local supermarket. I usually like IPA beers, so this one sounded good to me.

Not as strong a taste as I would expect from an IPA. The influence of hop is just a mere touch, not as strong as some other IPA beers. On the grand scale of beers it's a tasty but not too complex.

The beer details

Company	BrewDog
Beer name	Indie Pale Ale
Beer style	IPA - India Pale Ale
Alcohol by volume	4.2 %

I saw a radio amateur offering a secondhand FUNcube Dongle Pro+ for a very reasonable price and remembered my work to get into linear satellites and the problems with the input filtering on an rtl-sdr while transmitting. So I checked the specifications for that dongle and saw a lot better filtering.

I decided to go for it and a few mails later the dongle was on the way to my letterbox. Literally, as it fitted in a small package that could be delivered in the letterbox. With tracking, so I received a notification from the package tracker app after the mailman put it in the letterbox.

There is good support for the FUNcube dongle Pro+ in gqrx so I tried that first. It does give some USB errors:

[46918.612090] usb 2-1: new full-speed USB device number 10 using xhci_hcd
[46918.762268] usb 2-1: New USB device found, idVendor=04d8, idProduct=fb31
[46918.762273] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[46918.762276] usb 2-1: Product: FUNcube Dongle V2.0  
[46918.762278] usb 2-1: Manufacturer: Hanlincrest Ltd.         
[46918.797477] usb 2-1: 1:1: cannot get freq at ep 0x81
[46918.803092] hid-generic 0003:04D8:FB31.0003: hiddev0,hidraw0: USB HID v1.11 Device [Hanlincrest Ltd.          FUNcube Dongle V2.0  ] on usb-0000:00:14.0-1/input2
[46918.917284] usb 2-1: 1:1: cannot get freq at ep 0x81
[46918.955162] usb 2-1: 1:1: cannot get freq at ep 0x81

It does show as a valid device in gqrx and I was soon decoding audio with it. The easiest decoding was in the VHF II FM broadcast band. After all the work with the 2 MHz wide spectrum from the rtl-sdr it takes a bit of adjusting to start working with 192 kHz spectrum from the FUNcube dongle but qgrx moves that bit nicely when needed.

To the computer, the dongle is an USB device with two subfunctions: an usbaudio device and a usbhid device. The audio device is used to deliver sampled radio spectrum and the hid device is used to control the dongle. This is why it's relatively easy to use softwarewise: modern operating systems have usbaudio support and usb hid control from a user application isn't too hard either.

One of the things I do want is a lot of interesting audio routing to be able to record both the downlink audio and my own audio. So I fired up pavucontrol and gqrx crashed. Restarting gqrx did not work until I closed pavucontrol. Some searching found gqrx crash with Funcube Pro+ which suggests to turn the device off for PulseAudio. Which may seem strange but PulseAudio is also using the alsa drivers which gqrx tries to use. I guess there is some conflict between gqrx and PulseAudio in dealing with the alsa drivers. After switching the FUNcube Dongle Pro+ in PulseAudio I could open the dongle in gqrx and play with audio settings for other channels in pavucontrol.

The setup with gpredict controlling the receive frequency of gqrx also worked fine, so this is looking good. Now to find out how things work on an FM or linear satellite.

A month later I'm still seeing SMTP floods from 185.222.211.11 and adjacent addresses. I activated the sendmail-reject filter ruleset in fail2ban which keeps several addresses in that range blocked most of the time.

Given reports like 185.222.211.238 | Cloud Core LP | AbuseIPDB and 185.222.211.243 | Cloud Core LP | AbuseIPDB I'm not the only one seeing abuse from this range.

This weekend I participated in the IARU HF Championship and made a nice number of contacts given the available time in which I could call out my callsign. Before the contest the radio propagation was a bit dissapointing and I did most of my preparation at the very last minute.

For the contest logging I used the TLF linux contest logger which does not support the IARU HF Championship out of the box. But someone posted about this contest to the TLF development mailing list and shared the configuration and initial exchange list, so it was minimal work to get going. With this configuration TLF worked as a logger, it just didn't calculate the multipliers in the contest correctly.

In the end I made 95 contacts, which is a nice improvement over the previous time I participated in this contest: IARU HF Championship PE4KH 2017. Of the 95 contacts, 19 were on the 40 meter band (Saturday evening) and 76 on the 20 meter band (Saturday afternoon and Sunday morning).

I did not participate in the 2018 edition because it was the weekend we left for our summer holiday. The 2018 IARU HF championship was also the World Radio Team Championship 2018 so I missed the chance to work one of those stations. I did follow the whole preparation for the WRTC 2018 and had a look at the developments in the scores during that weekend.

Op 9 Juli is de laatste omschakeling van DVB-T naar DVB-T2 geweest in Nederland, waarmee DVB-T ten einde gekomen is. In de ether is dus van 2 oktober 1951 tot 10 december 2006 analoog uitgezonden en van 10 december 2006 tot 2 oktober 2018 (eerste regio) - 9 juli 2019 (laatste regio) in DVB-T.

De Samsung televisie die we aangeschaft hebben in mei 2013 snapt er niets meer van bij een scan op het UHF spectrum. Vooraf had ik gezocht of deze televisie DVB-T2 en de gebruikte codec ondersteunde en dat was wat onduidelijk, het hing af van de taal van de handleiding. Uiteindelijk werkt het dus duidelijk niet, de scan voor digitale tv signalen levert helemaal geen resultaat op.

Dus we hebben geen NPO 1/2/3 meer free-to-air wat we gebruikten sinds de prijsverhogingen en wijzigingen van Ziggo in 2015. Bij een eerste test bleken de livestreams van de NPO applicatie met chromecast ook te werken. Alleen heeft een hapering van de internetverbinding ook gelijk het gevolg dat de televisie stopt.

Het voelt wel raar om voor 'broadcast' televisie een stream aan te zetten, maar dat zal wel liggen aan de geschiedenis die er voor mij achter zit.

This weekend was the DL-DX RTTY Contest 2019. In the category 'B': single operator, multiband, 6 hours. Not in the category for dipole or groundplane antenna since I used the endfed antenna.

I made 80 contacts, 37 on the 20 meter band and 43 on the 40 meter band. Propagation wasn't great and most of my contacts were search & pounce mode, answering calls from other contest stations. I did call CQ a few times, and one of those was spotted by the reverse beacon network instantly and gave me 3 contacts in short succession.

Operation in the contest was limited due to other things in the weekend so I fitted in the 6 hour category nicely. I did some other things on the radio on Sunday and somewhere in the afternoon I noticed a funny electronics smell and the output power from the amplifier had dropped. I found out the output voltage from the modified HP DPS-700 GB server power supply had dropped to about 10.6 volts. Time to find out whether this problem fixes itself or it's time to find another server power supply that will deliver over 40 ampere current at somewhere around 13 volt.

Doing some more reading on haveged made me decide to test the actual randomness of my setup with haveged and randomsound which I created to fix the lack of entropy for dnssec signing operations so I booted the same testing virtual machine which can tap from the host /dev/random. I ran rngtest until it was time to shut down the laptop which was showing the output. The result:

$ rngtest < /dev/random 
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
^Crngtest: bits received from input: 4999640
rngtest: FIPS 140-2 successes: 249
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=303.011; avg=543.701; max=5684.774)bits/s
rngtest: FIPS tests speed: (min=43.251; avg=64.587; max=84.771)Mibits/s
rngtest: Program run time: 9194254192 microseconds

I ratelimited the virtio-rng-pci driver from the host, so the test took a really long time. Given earlier tries with dnssec-signzone this is fast enough.

No need to buy a hardware random generator, although they are way cool and it would be an idea to have a source of correctness (NTP) next to a source of randomness.

Update: I ran rngtest on /dev/urandom and I had to ask for a really big load of blocks to get failures. The first test with 249 blocks gave the same result as above, just a lot higher bit rate. So now I know less about the correct randomness of my setup but at least the test shows that I can safely run dnssec-signzone which was the original idea.

I was looking at the options for implementing DNSSEC on the domains I have, and started doing this on a domain name that is just used for web redirects, so I won't break anything serious when I make an error. And I am looking at monitoring options at the same time.

Looking for usable documentation I found DNSSEC signatures in BIND named - sidn.nl which shows and explains a lot of the options for doing this with bind9, including full automation. I want to take steps I understand, so I will start with careful minimal automation on a domain name that I can 'break'.

Following that documentation I created a key-signing key (KSK) and a zone-signing key (ZSK). I used the /etc/bind/keys directory which is the standard location.

The first dnssec-signzone action took 54 minutes. After waiting for a bit I started wondering what was happening and it turned out to be a problem with entropy: the signing uses a lot of data from /dev/random. I have the virtio-rng module loaded but the host wasn't making randomness available to the guest operating system. The host server does run randomsound to get more entropy since there is no hardware random number generator available.

Documentation on how to 'forward' randomness from the host to the client virtual machine: Random number generator device - Domain XML format

So I did some tests with a test virtual machine with a similar configuration. The results:

• Just software kernel rng in the virtual machine: 54 minutes.
• Offering virtio-rng randomness from the host from /dev/urandom running randomsound: less than 1 second.
• Offering virtio-rng randomness from the host from /dev/random running randomsound: 11 minutes 10 seconds.
• Offering virtio-rng randomness from the host from /dev/random running randomsound and haveged: less than 1 second.

Installing haveged which gathers entropy from hardware processes fixes the whole problem.

Now to implement the same settings for the virtual machine running the production nameserver and I'll be able to take the next step.

My wife bought a new inkjet printer because the previous one was failing. The new one is a HP deskjet 2630, and it has wifi support. Out of the box it was playing access-point on the busy 2.4 GHz band making it even more crowded so I asked her to disable the wifi. She used the printer nicely with the USB cable and asked me to look into putting it on the network so it can be in a different room and not in the way.

Today I had a look into that. I hoped it could be a wifi client. Yes it can. The first two explanations on how to set that up started with 'using the windows HP software'. The third one had 'press and hold the wifi button to connect using wps'.

So I enabled wps on the wifi network, did the wps mating and saw arpwatch note the new IPv4 addres in use.

For a laugh I tried whether it has an IPP server running. It has. So adding it under linux should not be completely impossible. Search for 'linux hp deskjet 2630' and notice it needs the hplip package. Which is already installed in my recent Ubuntu.

So I just opened the cups printer browser, saw the HP deskjet show up, selected that and printed a test page. Which came out correctly.

Typing this took longer than the actual steps I took, and searching websites with explanations took most of the time.

I'm still in the "what just happened?" stage, remembering long fights with printer drivers, network printing and losing everything at upgrades.

Update: Adding the printer in Windows 10 was harder, we needed to use the HP software to add it which tried to sell us "HP instant ink" service before allowing the printer to be used in Windows.

I noticed a really big load of probes for names under idefix.net, maybe looking for possible ways to attack systems. Source is a resolver at a VPS hoster (linode). I can find websites that will do such a search for me (some even hosted at linode) but in a quick search I can't get the same pattern in names.

30-Jun-2019 03:53:24.538 client @0x7f578c0c7230 45.33.59.87#11197 (sync.idefix.net): query: sync.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.539 client @0x7f578c0c7230 45.33.59.87#9151 (bugzilla.idefix.net): query: bugzilla.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.540 client @0x7f578c0c7230 45.33.59.87#64181 (mailgw.idefix.net): query: mailgw.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.540 client @0x7f578c0c7230 45.33.59.87#46518 (se.idefix.net): query: se.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.542 client @0x7f578c0c7230 45.33.59.87#31554 (tw.idefix.net): query: tw.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.544 client @0x7f578c0c7230 45.33.59.87#56050 (origin-www.idefix.net): query: origin-www.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.547 client @0x7f578c0c7230 45.33.59.87#24795 (bugzilla.idefix.net): query: bugzilla.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.558 client @0x7f578c0c7230 45.33.59.87#60127 (log.idefix.net): query: log.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.564 client @0x7f578c0c7230 45.33.59.87#16816 (reseller.idefix.net): query: reseller.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.564 client @0x7f578c0c7230 45.33.59.87#46743 (cdn3.idefix.net): query: cdn3.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.567 client @0x7f578c0c7230 45.33.59.87#15593 (books.idefix.net): query: books.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.568 client @0x7f578c0c7230 45.33.59.87#23918 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.570 client @0x7f578c0c7230 45.33.59.87#24503 (srv1.idefix.net): query: srv1.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.570 client @0x7f578c0c7230 45.33.59.87#20759 (cacti.idefix.net): query: cacti.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#62846 (developer.idefix.net): query: developer.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#40156 (delta.idefix.net): query: delta.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#42375 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#25727 (delta.idefix.net): query: delta.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#19060 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#63258 (katalog.idefix.net): query: katalog.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#35848 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.574 client @0x7f578c0c7230 45.33.59.87#50079 (archives.idefix.net): query: archives.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.575 client @0x7f578c0c7230 45.33.59.87#18507 (pg.idefix.net): query: pg.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.577 client @0x7f578c0c7230 45.33.59.87#62479 (manager.idefix.net): query: manager.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.577 client @0x7f578c0c7230 45.33.59.87#41830 (wwwtest.idefix.net): query: wwwtest.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.578 client @0x7f578c0c7230 45.33.59.87#14914 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.581 client @0x7f578c0c7230 45.33.59.87#25754 (auction.idefix.net): query: auction.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.582 client @0x7f578c0c7230 45.33.59.87#42057 (students.idefix.net): query: students.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.729 client @0x7f578c0c7230 45.33.59.87#63617 (gosper.idefix.net): query: gosper.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.866 client @0x7f578c4feb30 45.33.59.87#57706 (books.idefix.net): query: books.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.870 client @0x7f578c0d59c0 45.33.59.87#57714 (delta.idefix.net): query: delta.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.872 client @0x7f578c51d780 45.33.59.87#57718 (delta.idefix.net): query: delta.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.874 client @0x7f578c0d59c0 45.33.59.87#57722 (archives.idefix.net): query: archives.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.874 client @0x7f578c4feb30 45.33.59.87#57726 (wwwtest.idefix.net): query: wwwtest.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.875 client @0x7f578c52bda0 45.33.59.87#57728 (auction.idefix.net): query: auction.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.876 client @0x7f578c51d780 45.33.59.87#57708 (katalog.idefix.net): query: katalog.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.879 client @0x7f578c0d59c0 45.33.59.87#57712 (srv1.idefix.net): query: srv1.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.943 client @0x7f578c0c7230 45.33.59.87#50168 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.945 client @0x7f578c0c7230 45.33.59.87#59186 (cacti.idefix.net): query: cacti.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.947 client @0x7f578c0c7230 45.33.59.87#30509 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.948 client @0x7f578c0c7230 45.33.59.87#25611 (manager.idefix.net): query: manager.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.948 client @0x7f578c0c7230 45.33.59.87#53201 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.950 client @0x7f578c0c7230 45.33.59.87#25331 (students.idefix.net): query: students.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.954 client @0x7f578c0c7230 45.33.59.87#44043 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.954 client @0x7f578c0c7230 45.33.59.87#9075 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.236 client @0x7f578c4feb30 45.33.59.87#57748 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.245 client @0x7f578c52bda0 45.33.59.87#57752 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.250 client @0x7f578c51d780 45.33.59.87#57750 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.257 client @0x7f578c0c7230 45.33.59.87#46992 (katalog.idefix.net): query: katalog.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.259 client @0x7f578c0d59c0 45.33.59.87#57754 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.263 client @0x7f578c0c7230 45.33.59.87#50662 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.264 client @0x7f578c0c7230 45.33.59.87#23392 (eu.idefix.net): query: eu.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.271 client @0x7f578c0c7230 45.33.59.87#62305 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.293 client @0x7f578c0c7230 45.33.48.143#45998 (sam.idefix.net): query: sam.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.293 client @0x7f578c0c7230 45.33.59.87#43255 (banners.idefix.net): query: banners.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.299 client @0x7f578c0c7230 45.33.59.87#29869 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.302 client @0x7f578c0c7230 45.33.59.87#36595 (customer.idefix.net): query: customer.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.322 client @0x7f578c0c7230 45.33.59.87#6272 (cgi.idefix.net): query: cgi.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.327 client @0x7f578c0c7230 45.33.59.87#23561 (awstats.idefix.net): query: awstats.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.331 client @0x7f578c0c7230 45.33.59.87#58477 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.334 client @0x7f578c0c7230 45.33.59.87#12998 (cgi.idefix.net): query: cgi.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.335 client @0x7f578c0c7230 45.33.59.87#41654 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.335 client @0x7f578c0c7230 45.33.59.87#36692 (hd.idefix.net): query: hd.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.337 client @0x7f578c0c7230 45.33.59.87#52048 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.471 client @0x7f578c0c7230 45.33.59.87#11817 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.479 client @0x7f578c0c7230 45.33.59.87#40723 (webgreenblatt.idefix.net): query: webgreenblatt.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.481 client @0x7f578c0c7230 45.33.59.87#57833 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.499 client @0x7f578c0c7230 45.33.59.87#26285 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.525 client @0x7f578c0c7230 45.33.59.87#51562 (cgi.idefix.net): query: cgi.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.533 client @0x7f578c0c7230 45.33.59.87#32101 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.534 client @0x7f578c0c7230 45.33.59.87#36210 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.543 client @0x7f578c0c7230 45.33.59.87#57693 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.568 client @0x7f578c53a3c0 45.33.59.87#57768 (katalog.idefix.net): query: katalog.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.569 client @0x7f578c565900 45.33.59.87#57772 (eu.idefix.net): query: eu.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.598 client @0x7f578c557170 45.33.59.87#57776 (banners.idefix.net): query: banners.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.617 client @0x7f578c590fb0 45.33.59.87#57780 (customer.idefix.net): query: customer.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.620 client @0x7f578c52bda0 45.33.59.87#57782 (awstats.idefix.net): query: awstats.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.630 client @0x7f578c0d59c0 45.33.59.87#57790 (hd.idefix.net): query: hd.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.637 client @0x7f578c5489e0 45.33.59.87#57788 (cgi.idefix.net): query: cgi.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.664 client @0x7f578c0c7230 45.33.59.87#35680 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.765 client @0x7f578c582820 45.33.59.87#57800 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.786 client @0x7f578c0c7230 45.33.59.87#59047 (sk.idefix.net): query: sk.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.805 client @0x7f578c565900 45.33.59.87#57802 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.825 client @0x7f578c590fb0 45.33.59.87#57804 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.840 client @0x7f578c0c7230 45.33.59.87#6873 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.843 client @0x7f578c0c7230 45.33.49.87#39819 (img4.idefix.net): query: img4.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.848 client @0x7f578c0c7230 45.33.49.87#35699 (registration.idefix.net): query: registration.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.856 client @0x7f578c0d59c0 45.33.59.87#57806 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.942 client @0x7f578c0c7230 45.33.49.87#49819 (registration.idefix.net): query: registration.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.081 client @0x7f578c51d780 45.33.59.87#57816 (sk.idefix.net): query: sk.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:26.288 client @0x7f578c0c7230 45.33.59.87#49749 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.309 client @0x7f578c0c7230 45.33.59.87#57344 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.399 client @0x7f578c0c7230 45.33.59.87#44649 (develop.idefix.net): query: develop.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.583 client @0x7f578c50d150 45.33.59.87#57826 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:26.634 client @0x7f578c0c7230 45.33.49.87#9259 (ares.idefix.net): query: ares.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.662 client @0x7f578c0c7230 45.33.59.87#9440 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.694 client @0x7f578c53a3c0 45.33.59.87#57830 (develop.idefix.net): query: develop.idefix.net IN A -E(0)TDC (194.145.201.42)

Ik was vandaag weer eens op de lokatie waar ik eerder tot de conclusie kwam Je draadloze microfoon is prima af te luisteren en dit keer heb ik die bewering gecontroleerd.

Niet eens met een scanner maar met een nog makkelijkere aanpak: een laptop met een rtl-sdr dongle er aan en gqrx er op.

De draadloze microfoons en de ontvangers op die lokatie zijn van Sennheiser, wat als voordeel heeft dat ze niet in kanalen denken maar dat de frequentie waar ze op staan gewoon op het display staat. Ik kon dus simpel aflezen van de ontvangers waar ik de microfoons moest 'zoeken'. In een testje kon ik inderdaad de draaggolf van de microfoon prima vinden na inschakelen en met een FM demodulator ook het geluid prima weergeven op de laptop.

Omdat dit een bijeenkomst was waar ook informatie besproken werd die niet vrij de wereld in mag was ik hier even alert op. Maar dankzij een toegevoegde ruimtemicrofoon aan het plafond werden de draadloze microfoons niet gebruikt tijdens de bespreking van gevoelige informatie. Na de besprekingen ben ik even aan de gang gegaan met de laptop en kon toen de ingeschakelde microfoon prima ontvangen.

Op zich is er niets mis met draadloze microfoons, maar er zijn dus situaties te bedenken waarin je denkt dat je stemgeluid alleen binnen een beperkte ruimte versterkt wordt maar wat er net buiten misschien ook opgevangen wordt.

This weekend I had time for the radio hobby and made some interesting new contacts. Friday evening was a bad start, with serious difficulties reaching other stations with FT8 on 20 or 40 meters. But Saturday daytime the 10 meter band was open and I even made contacts with two new countries on the 10 meter band: Lithuania and Montenegro. I guess it was an E-skip opening as I saw mostly "nearby" stations from Germany, England and other European countries. With ionospheric propagation those are usually "too close".

If you look at the map of 10 meter HF contacts by PD4KH there is a 'ring' with almost no contacts around my home location (I have made some really close contacts, but that would be via direct line of sight). Other contacts start in the south of France, the west of England and Poland. Nowadays ionospheric propagation on 10 meters doesn't happen very often so when I do make contacts it is via other forms of propagation that allow for shorter skip distances.

Later on Saturday the 10 meter band propagation stopped and 20 and 40 meters allowed nice amounts of contacts.

When I can make what contact on what frequency is still magical sometimes. I learn patterns that repeat themselves, but there are still enough surprises left.

Sinds april 1993 heb ik een xs4all login account (ja, van voor de start, mijn account is met de hand aangemaakt door Rop Gonggrijp). Sinds begin 1992 had ik al een xs4all uucp account voor kzdoos.xs4all.nl, tegenwoordig omgezet naar een bsmtp account (waarbij mail binnenkomt bij de xs4all mailservers en na de spamfiltering doorgestuurd wordt naar mijn server). Maar met de laatste plannen van KPN om het merk xs4all te gaan stoppen en zaken samen te voegen ben ik toch bang dat de unieke redenen om daar te blijven langzaam zullen vervallen.

Wat ik nodig heb is een plek met vast IPv4/IPv6 en een aardige uplink snelheid. Via xs4all kan dat gewoon thuis, maar misschien is op den duur een virtuele private server en een goedkope thuisaansluiting met daartussen een vorm van vpn ook een werkende oplossing.

Dus dan is het ook tijd om langzaam minder afhankelijk te worden van de bsmtp service voor kzdoos.xs4all.nl en langzaam maar zeker mijn eigen domeinnaam idefix.net voor e-mail in te voeren als primair adres. Wie weet heeft de bsmtp dienst bij KPN ook niet het eeuwige leven. De extra opties die van xs4all een goede provider maken voor een hobbyist zitten bij andere providers vaak in een zakelijk pakket of worden niet aangeboden.

Ik kon altijd beweren dat ik het e-mail adres wat ik gebruik gewoon ouder was dan spam e-mail.

Due to recent kernel updates I rebooted the home server and ran into only older kernels available. Some searching later I found out it booted from another disk than the disk the update manager was maintaining /boot on.

The solution was to mirror the /boot partition by hand and change the EFI boot setup to try a boot from both disks, so the machine will still boot when one half of the mirror is completely unavailable. I did buy mirrored disks to have the machine available with one disk unavailable.

Changing the EFI boot setup with efibootmgr was somewhat complicated, but I got it all done. How to add a second disk found via Partitioning EFI machine with two SSD disks in mirror - Unix & Linux stackexchange and understanding the numbers in the efibootmgr -v output via "efibootmgr -v" output question.

The ideal solution would be to have /boot and /boot/efi on mirrored partitions without metadata (so they are readable too from the efi loader as an unmirrored partition). According to what I read this is possible in Linux with devicemapper but there is not a lot of experience shared.

Checking how fail2ban was doing on a wordpress site I noticed the following error in the log:

46.105.99.163 - - [18/Jun/2019:09:03:46 +0200] "GET /wp-content/plugins/ungallery/source_vuln.php?pic=../../../../../wp-config.php HTTP/1.1" 404 15933 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0"

which is never going to work as an exploit. A full explanation in Hackers Will Try To Exploit Vulnerabilities in WordPress Plugins in Ways That Will Never Succeed - Plugin Vulnerabilities but this entire attempt is based on just the description of a vulnerability and can never ever have succeeded, not even on a system with the vulnerable version of the ungallery plugin.

After my earlier stories about amateur radio at the Trintelhaven location Kees PA5Z wanted to go there too to test a dipole antenna for 80 meters that wasn't going to fit in his garden. I felt like taking the fibermast again and the linked dipole on 40 meters, an endfed antenna and enough rope to be able to hang it in some tree.

So we loaded radios and antenna material in a car and drove over there. Weather was nice, not too hot. We were hoping to get on one of the grassy fields of the site, but most of the site was taken up by the trucks and equipment for the work going on.

Antenna at Checkpoint Charlie restaurant, picture by Kees PA5Z

So we settled for the far end of the parking lot, away from the restaurant Checkpoint Charlie. We saw that Checkpoint Charlie had a big antenna themselves, most likely an antenna for the 11 meter (27 MHz) band.

The 80 meter dipole set up by PA5Z, picture by Kees PA5Z

Kees soon found a frame around a garbage can which could hold the aluminum mast for the middle of the dipole. It all worked fine on the 80 meter band. The dipole antenna became a bit detuned when there was a big truck parked right next to it. We were at the edge of the parking lot so it could happen.

PE4KH behind the radio at Trintelhaven, picture by Kees PA5Z

I set up my fibermast and used the rubber strips to lock the elements, because it was windy. I set up the linked dipole for the 40 meter band. There wasn't a lot of room for the guy wires and after a while one came lose making the fiber mast fall over. Some damage: one corner of the balun broke and the antenna wire came lose. But with a simple fix it was up again. Later one element collapsed because one rubber strip wasn't tight enough.

I made only five contacts on the 40 meter band. Propagation wasn't cooperating a lot. Kees did not hear a lot on the 80 meter band until later in the day when some Dutch amateurs where in a conversation. Kees was able to report in and get some signal reports.

PE4KH with Arrow Antenna at Trintelhaven, picture by Kees PA5Z

I also took my Arrow Antenna and a handheld radio to try and receive a pass of the Fox-1D satellite. But I heard no signal. It did make for a nice picture, trying to receive the satellite standing on the dike.

Noticed in the recent logs, lots of variations on:

Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <mail@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <support@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <reply@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: srv-eml.info [185.222.211.11]: Possible SMTP RCPT flood, throttling.
Jun  6 19:15:41 gosper sm-mta[22466]: x56HFCbH022466: <financeiro@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22473]: x56HFVoi022473: <biuro@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22468]: x56HFItg022468: <michael@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22471]: x56HFPIC022471: <chris@some.domain>... No such user in domain 
Jun  6 19:16:51 gosper sm-mta[22466]: x56HFCbH022466: lost input channel from srv-eml.info [185.222.211.11] to MTA-v6 after rcpt
Jun  6 19:17:16 gosper sm-mta[22475]: x56HFc06022475: <jobs@some.domain>... No such user in domain 
Jun  6 19:17:17 gosper sm-mta[22475]: x56HFc06022475: <wh5gkoxp5wqk@some.domain>... No such user in domain 
Jun  6 19:17:18 gosper sm-mta[22475]: x56HFc06022475: lost input channel from srv-eml.info [185.222.211.11] to MTA-v6 after rcpt
Jun  6 19:17:18 gosper sm-mta[22475]: x56HFc06022475: from=<20tv13b4bu0h2107@europcar.ua>, size=0, class=0, nrcpts=1, proto=ESMTP, daemon=MTA-v6, relay=srv-eml.info [185.222.211.11]

All from the same IP, trying a lot of addresses (and failing), with a retry later trying all those addresses again.

After the migration to the new homeserver was finished I found out I had to run backups on a separate computer: misconfigured backups so the old idea of backups to a cloudservice is on my mind again. I've looked into this before: Backup to .. the cloud! and I still want to backup to a cloud-based service which has a webdav interface and is based on owncloud. With some searching I came across How to synchronize your files with TransIP’s STACK using the commandline.

I'd like the outgoing bandwidth to be limited so the VDSL uplink isn't completely filled with the backup traffic. Installing owncloud-client-cmd still has a lot of dependencies on graphical stuff, but doesn't install the GUI of the owncloud client. In owncloud-client-cmd I can't set the bandwidth limits, but I can set those in the graphical client. But after a test it shows that owncloud-client-cmd doesn't read .local/share/data/ownCloud/owncloud.cfg for the bandwidth settings.

At least with the VDSL uplink speed and the wondershaper active the responsiveness of other applications at home never suffered. Maybe specific rules for the IP addresses of the cloud service could ratelimit the uploads.

I saw some parts in a site that were creating errors and trying to maintain old PHP code was an annoyance again. So I set up the project to port it all to mod_perl to be able to support it again.

Not an easy project, and it will take a while. First work was on understanding the mod_perl registry which keeps scripts and perl interpreters running in Apache. I noticed I was getting old errors from scripts which is because the mod_perl registry doesn't automatically reload scripts (to save file actions). This is not ideal on a development server and can be confusing on a production server. Solution: enable Apache2::Reload with

        # enable perl
        AddHandler perl-script .pl
        PerlResponseHandler ModPerl::Registry
        PerlInitHandler Apache2::Reload

Now to write the right perl code...

After getting a satellite contact via SO-50 the next thing was to get it in the log correctly. I followed the instructions from Logging Satellite QSOs with Logbook of the World - Amsat, logging the contact in the tqsl program, uploading that log to Logbook of the World and importing the logfile (ADIF) into CQRLOG later.

But later I found out that CQRLOG now supports satellite logging after enabling it in the preferences. Since version 2.3.0 satellite support is included.

This evening I checked 'Sky at a glance' in gpredict and saw a nice SO-50 pass come up. It was a southwest - northeast pass with a very high maximum elevation. So a good chance to listen to the satellite for a while. I took the Arrow antenna together with the Wouxun handheld radio outside, which I programmed for the SO50 frequencies when I started with amateur satellites years ago.

I started hearing the satellite right after it got above the houses. I heard one familiair callsign: Peter 2M0SQL. In a silent moment I answered his call, he heard me fine and we had a contact.

My first satellite contact since August 2014 and directly someone in the log who I really wanted to get in the log.

Saudisat 1c / SO-50

Tuesday evening we had a good presentation at our radio club about getting active on the QO-100 geostationary amateur satellite. This was a very technical presentation by René Stevens PE1CMO. This amateur satellite is actually a transponder on the Es'Hail2 satellite. The transponder is active on amateur bands: 2.4 GHz up and 10 GHz down.

A very interesting and good presentation. And for now I find it very interesting but I'm not going to invest the time and money to get on that satellite.

This did remind me that I wanted to get back into amateur satellites as planned for several years. Looking back I see a clear moment when the satellite activity stopped: The last successful amateur satellite contact was 2014-08-10: Success with the new radio and the SO-50 amateur satellite and the first HF contact was 2014-08-29: First PSK31 on HF contacts. It's easier to make a lot more contacts on HF for the same amount of work as one satellite contact.

As a first step I took out the arrow antenna and a handheld radio just to listen to some passes. And that showed the well-known problem with satellite passes: They have to fit in your schedule or otherwise you will miss them completely. But there are a lot of amateur satellites to listen to. I had two Fox-1A (AO-85) passes not higher than 23 degrees elevation. And I heard nothing on those passes, but that wasn't a big surprise given earlier experiences and what people have shared. I had one pass of Saudisat (SO-50) which went up to 29 degrees elevation and I heard at least a few callsigns on that pass. And no really bad behaviour, but maybe a Wednesday daytime is better in that regard.

With all the automated updates of certificates as described in Enabling Server Name Indication (SNI) on my webserver and Automating Let's Encrypt certificates further I wondered about what would happen when some things got corrupt, most likely as a result of a full disk. And a simple test showed out that the checkcert utility would happily say two empty files are a match because the sha256sum of two empty public keys is the same.

Solution, do something with the errorlevel from openssl. New version of checkcert:

#!/bin/sh

# check ssl private key 1 with ssl pem encoded x509 certificate 2 public key

SUMPRIVPUBKEY=`openssl pkey -in $1 -pubout -outform pem || echo privkey | sha256sum`
SUMCERTPUBKEY=`openssl x509 -in $2 -noout -pubkey -outform pem || echo pubkey | sha256sum`

if [ "${SUMPRIVPUBKEY}" = "${SUMCERTPUBKEY}" ]; then
        exit 0
else
        exit 1
fi

And now:

koos@gosper:~$ /usr/local/bin/checkcert /dev/null /dev/null
unable to load key
139636148224064:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:686:Expecting: ANY PRIVATE KEY
unable to load certificate
139678825668672:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:686:Expecting: TRUSTED CERTIFICATE
koos@gosper:~$ echo $?
1

Just seen in an e-mail with a virus, looking like it's something from a bank:

Security tips

1. Install virus detection software and personal firewall on your computer. This software needs to be updated regularly to ensure you have the latest protection.
2. To prevent viruses or other unwanted problems, do not open attachments from unknown or non-trustworthy sources.
3. If you discover any unusual activity, please contact the remitter of this payment as soon as possible. 

But the attachment has malware.

While making a lot of my websites available via HTTPS I started wondering about enabling Server Name Indication (SNI) because the list of hostnames in the one certificate (subjectAltName parameter) keeps growing and they aren't all related.

So on a test system with haproxy I created two separate private keys, two separate certificate signing requests and requested two separate certificates. One for the variants of camp-wireless.org and one for most of the idefix.net names. The whole requesting procedure happened on the system where my automated renewal and deployment of LetsEncrypt certificates with dehydrated happens so the request went fine. For the configuration of haproxy I was following HAProxy SNI where 'terminating SSL on the haproxy with SNI' gets a short mention.

So I implemented the configuration as shown in that document and got greeted with an error:

haproxy[ALERT] 123/155523 (3435) : parsing [/etc/haproxy/haproxy.cfg:86] : 'bind :::443' unknown keyword '/etc/haproxy/ssl/webserver-idefix-main.pem'.

And found out that the crt keyword has to be repeated.

This is why I like having a test environment for things like this. Making errors in the certificate configuration on the 'production' server will give visitors scary and/or incomprehensible errors.

So the right configuration for my test is now:

frontend https-in
    bind :::443 v4v6 ssl crt /etc/haproxy/ssl/webserver-campwireless.pem crt /etc/haproxy/ssl/webserver-idefix-main.pem

And testing it shows the different certificates in use when I use the -servername parameter for openssl s_client to test things.

$ openssl s_client -connect testrouter.idefix.net:443 -servername idefix.net -showcerts -verify 3
..
Server certificate
subject=/CN=idefix.net
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK
$ openssl s_client -connect testrouter.idefix.net:443 -servername camp-wireless.org -showcerts -verify 3
..
Server certificate
subject=/CN=www.camp-wireless.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK

The certificates are quite separate. Generating the certificate signing requests with a separate private key for each request works fine.

So if I upgrade my certificate management to renew, transport, test and install multiple certificate for the main webserver it would work.

I participated in the British amateur radio teledata group RTTY Sprint75 contest 2019. The special thing with the 75 is that this is 75baud RTTY and not the normal 45baud RTTY.

This is a relatively short contest (4 hours) on a Sunday evening and I did not participate in the contest the whole time, I also watched some television with my family. All a matter of priorities.

I made 27 contacts on the 20 and 40 meter bands. Since I now have an RF power meter I was able to make sure my output power was right below 100 watts so I could enter in the '100 watts' category and not 'high power'.

We hebben nu net een regenachtige dag achter de rug, waarop we ook nog de oven gebruikt hebben voor zowel de lunch als het avondeten. Over deze dag hebben we nog steeds wel wat teruggeleverd, maar niet zo veel als op een echt zonnige dag, en het gebruik over de hele dag was ook relatief hoog.

Ondanks de regen was het niet echt donker overdag, dus dat kan nog voor minder opbrengst zorgen.

After upgrading to the new homeserver my old setup to allow two passwords for IMAPS logins so I can use a separate password for IMAPS access for those devices that insist on saving a password without asking.

I have the following PAM libraries:

ii  libpam-modules 1.1.8-3.6    amd64        Pluggable Authentication Modules

And I debugged the problem using the pamtester program which makes debugging this problem a lot easier than constantly changing the configuration and restarting the imap server.

The relevant configuration now is:

# PAM configuration file for Courier IMAP daemon

#@include common-auth
# here are the per-package modules (the "Primary" block)
auth    required    pam_succeed_if.so quiet user ingroup users
#auth   [success=1 default=ignore]      pam_unix.so nullok_secure
auth    sufficient      pam_unix.so nullok_secure
auth    sufficient  pam_userdb.so db=/etc/courier/extrausers crypt=crypt use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
@include common-account
@include common-password
@include common-session

And now both my unix login password and the extra password are accepted.

After getting to the magic number of getting contacts with 100 DXCC entities confirmed I applied for (and paid for) the ARRL DXCC award, the American Radio Relay League DX Century Club award.

So I guess I have to admit I'm a serious DX chaser!

After working on the URE 70 year anniversary special event I also made contact with two new countries: Egypt and Colombia. Egypt is not too far away but there aren't many active radio amateurs in Egypt so this one is harder. This evening SU9JG is active and I got the contact.

Right after that I got HK3C in the log from Colombia. Not a very rare country in Amateur radio, but with my current setup I have trouble reaching South America.

The definition of 'rare' or 'not so rare' countries (or rather: DX entities, but that's another story) in Amateur radio is based on the statistics gathered by Club Log and published as the DXCC Most Wanted List which is based on the assumption that every active Club Log member wants contacts with all available DXCC entities. Countries with lots of active amateurs such as the United States of America and Italy are at the bottom of the list, countries or entities that restrict amateur radio or are very hard to reach such as North Korea and Bouvet Island are at the top.

Update 2019-04-22: And both are already confirmed on Logbook of the World which gets the number of countries confirmed via electronic qsls on Logbook of the World to a round 100, the magic number for the DX Century Club. So, time to start checking my options to get an actual DXCC certificate! I also have three countries confirmed via QSL card which aren't confirmed electronically, so I have to look into the Dutch QSL card checker option one day.

We dachten er al een tijdje over na, en we zijn eind vorig jaar serieus gaan zoeken naar een kundige leverancier van zonnepanelen. We hebben eerder contact gehad met wat bedrijven maar die wilden er eigenlijk niet aan beginnen. Een leverancier wilde niets op vlakke plekken leggen en vond dat er dan te weinig panelen over bleven. Een ander reageerde ook moeilijk en gaf geen reactie meer toen we de offerte niet gelijk ondertekenden maar nog aanpassingen wilden. Blijkbaar zijn meerdere aanbieders van goedkope zonnepanelen er niet zo blij mee dat we graag wilden dat er echt iemand langs kwam om te kijken in plaats van dat de hele offerte gebaseerd was op wat er te zien is in de satellietbeelden op google maps.

Uiteindelijk wilde Radiair wel iemand langs sturen om een goede offerte te maken. Met die man de wensen besproken, de opties om ook op de uitbouw en de schuur panelen te leggen en dat ik graag de omvormers en optimizers goed wil ontstoren omdat ik zendamateur ben. Allemaal mogelijk. Na wat aanpassingen kwamen we op een offerte die volgens ons ook prima ging werken, dus die hebben we geaccepteerd. Het is vast duurder geworden dan andere aanbieders, maar hier werd er tenminste serieus naar de situatie gekeken en naar onze wensen geluisterd.

Ik had bij mijn acceptatie een bijlage bijgevoegd dat ik op alle optimizers ferrietkernen wilde installeren. Ook dat is prima gelukt en bij de overdracht van het project naar de uitvoerders was dat ook netjes overgedragen dus niemand keek er gek van op.

De monteur die het laatste werk kwam doen aan de aansluitingen is zelf ook zendamateur, dus die had alle aardingen en twists van kabels extra goed afgewerkt om te zorgen dat ik van mijn eigen panelen in ieder geval geen last zou krijgen.

Er zijn nu 11 panelen gelegd en die zijn sinds begin April in gebruik. De keuze van groepen waar de omvormers op terugleveren blijkt goed uit te vallen: de groepen met het meeste constante gebruik (koelkast, computers) hebben nu teruglevering dus een deel van het opgewekte vermogen wordt gelijk intern gebruikt. Maar daarna houden we bij goede zon zeker vermogen over, dus we leveren ook terug en de scriptjes die de stand van de slimme meter aflezen zien nu ook de tellers voor teruglevering oplopen.

Teruggeleverde energie wordt nu nog verrekend volgens de salderingsregeling, dus wat we terugleveren wordt weggestreept tegen wat we op andere momenten afnemen. Die salderingsregeling is natuurlijk niet eeuwig houdbaar: we leveren energie aan het net op een moment dat het net er niet perse behoefte aan heeft. Al zullen de netbeheerders en energieleveranciers tegenwoordig de zonsverwachting nauwkeurig in de gaten houden bij het plannen van de capaciteit. Een wolk voor de zon langs is bij mij al duidelijk zichtbaar in de teruggeleverde energie.

Tot nu toe hebben we alleen aardig zonnige dagen gehad. Ik ben benieuwd wat ze doen als het echt een hele dag bewolkt en regenachtig is.

I haven't made an amateur radio contact with a completely new country in a while, but I have worked on getting countries on new bands in the log. This weekend I had the 6-40m longwire antenna out. It did not want to tune on 12 meters but I made contacts on the 10, 15, 17, 30 and 40 meter bands.

Some new country/band combinations were added: Moldova, Montenegro, Japan and the Slovak Republic on 30 meters, Estonia on 17 meters, Latvia on 15 meters. I also made contacts with several stations in the URE 70 year anniversary special event.

Update 2019-04-15: Tuned the longwire for 80 meters and added Serbia and Norway as new 80 meter countries.

Another find in the local supermarket. This time no complicated backstory, it just looked and sounded nice.

It's a blonde beer. The color is lighter than I expected from a blonde, it's almost like Belgian white beer (Belgisch witbier). It has a higher alcohol level for a beer, but it didn't taste/feel like a strong beer to me.

A nice taste, not too complicated.

The beer details

Company	De Hoorn Brouwerij
Beer name	Cornet Oaked
Beer style	Blond beer
Alcohol by volume	8.5 %

It seems Corel graphics still exists and part of their continued existance is sending out spam to unverified e-mail addresses. With the included lie:

You are receiving this email because you requested to receive information regarding Corel products and special offers or you subscribe to a Corel e-newsletter.

No I haven't.

In an otherwise quite filled weekend there was also the EA RTTY Contest 2019. I participated for somewhat over an hour on Sunday and made 28 contacts, 24 on the 20 meter band and 4 on the 40 meter band.

Preliminary results: 28 valid contacts, 44 points, multiplier 23, total 1012 points.

I had a look at the beer on display in our local supermarket and noticed Goose IPA from Goose Island Beer company and I got reminded of Goose Island, Oregon which is mentioned in the Wargames movie. So I bought a bottle of the beer and did some research when I got home.

And everything about that link turned out to be wrong.

The Goose Island Beer company has nothing to do with Oregon, they are from Chicago, Illinois.

And according to Anderson Island (Washington) - Wikipedia English the scene around entering "Goose Island, Oregon" in the movie WarGames was actually filmed on Anderson Island in the state of Washington. There is a small island named "Goose Island" in the state of Oregon, it's an island in the Columbia river. Goose island measures almost 1000 meters by 680 meters. Goose Island Oregon USA on google maps.

Having left me with nothing of the link(s) I suspected when I saw the bottle there is only one thing to do: try the beer.

I would describe the colour as amber / dark amber. The smell and taste have a strong hop influence. I personally like IPA beers, but this one is a bit too bitter for me.

The beer details

Company	Goose Island Beer company
Beer name	Goose IPA
Beer style	IPA - India Pale Ale
Alcohol by volume	5.9 %

After a month with a holiday and a month with one contest I redid the QSO count plot to see the development.

before, before, before, before, before

Het viel me op in de grafieken van het invoer voltage volgens de UPS dat het voltage vanaf het stroomnet is gestegen tot 238 volt aan het eind van september 2018. Ik vraag me af wat de oorzaak is van deze wijziging. Het kan niet zijn door de toename van zonnepanelen in de omgeving, het gestegen voltage is zowel overdag als 's nachts.

Although FT8 does great work for weak signal reception on HF bands it's also nice for the 2 meter band and the 70 centimeter band. So after lots of tries with the 2 meter band I decided to give the 70 centimeter band another try. But, there is one thing: there aren't many stations active in FT8 on 70 centimeter and even when one is active in the nearby area that station may be on a different FT8 frequency. The real standard is not there yet.

Until now I've seen:

• 432.174 MHz
• 432.176 MHz
• 434.670 MHz

I check for activity via the PSKreporter site. My two FT8 on 70 centimeter contacts where on 432.174 and 432.176.

In the past week I made my second 70cm FT8 contact, and again with another amateur in the JO22 gridsquare. So the map for 70cm gridsquares contacted and confirmed isn't very spectacular yet, but I'm going to generate and maintain it anyway.

Now in the list of maps at pe4kh.idefix.net.

I noticed a lot of entries in my mail logging about aborted smtp transactions

Mar 22 21:04:04 gosper sm-mta[30180]: x2MK437r030180: [193.169.254.68] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:04:58 gosper sm-mta[30229]: x2MK4vv0030229: [185.234.217.222] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:05:25 gosper sm-mta[30307]: x2MK5Oas030307: [193.169.254.68] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:06:01 gosper sm-mta[30328]: x2MK5xAc030328: [185.234.217.222] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:06:02 gosper sm-mta[30331]: x2MK5xg5030331: [185.222.209.209] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v6

And I wondered what was going on, until I did a capture of the session and had a look:

    1   0.000000 185.234.217.222 → 82.95.196.202 TCP 68 55448 → 25 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
    2   0.000314 82.95.196.202 → 185.234.217.222 TCP 68 25 → 55448 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
    3   0.034751 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [ACK] Seq=1 Ack=1 Win=65536 Len=0
    4   6.038967 82.95.196.202 → 185.234.217.222 SMTP 395 S: 220-gosper.idefix.net ESMTP Sendmail 8.15.2/8.15.2/Debian-8; Fri, 22 Mar 2019 21:00:55 +0100; (No UCE/UBE) | 220-   This is a private SMTP server. | 220-   The use of this or any related system for the transmission of | 220-   Unsollicited Bulk E-mail (UBE) is prohibited. | 220 logging access from: [185.234.217.222](FAIL)-[185.234.217.222]
    5   6.072501 185.234.217.222 → 82.95.196.202 SMTP 76 C: EHLO 82.95.196.202
    6   6.072915 82.95.196.202 → 185.234.217.222 TCP 56 25 → 55448 [ACK] Seq=340 Ack=21 Win=29312 Len=0
    7   6.073011 82.95.196.202 → 185.234.217.222 SMTP 267 S: 250-gosper.idefix.net Hello [185.234.217.222], pleased to meet you | 250-ENHANCEDSTATUSCODES | 250-PIPELINING | 250-EXPN | 250-VERB | 250-8BITMIME | 250-SIZE | 250-DSN | 250-ETRN | 250-STARTTLS | 250-DELIVERBY | 250 HELP
    8   6.106154 185.234.217.222 → 82.95.196.202 SMTP 68 C: AUTH LOGIN
    9   6.106585 82.95.196.202 → 185.234.217.222 SMTP 86 S: 503 5.3.3 AUTH not available
   10   6.141445 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [FIN, ACK] Seq=33 Ack=581 Win=65024 Len=0
   11   6.141775 82.95.196.202 → 185.234.217.222 TCP 56 25 → 55448 [FIN, ACK] Seq=581 Ack=34 Win=29312 Len=0
   12   6.174430 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [ACK] Seq=34 Ack=582 Win=65024 Len=0

Each session starts ESMTP and even with the ESMTP reply not listing AUTH the next command is 'AUTH LOGIN' for authenticated smtp, and as soon as my server denies offering this the session gets aborted. This does mean no failed authentication attempt is logged which would trigger fail2ban.

This does look like a bit of a distributed attack, but without the network remembering that the attack is not going to work in this way and therefore trying it again and again.

Update: IPs active in this scanning attack sofar: 185.234.217.222 193.169.254.68 185.234.219.56 37.49.225.232 185.222.209.202 141.98.80.15 114.207.112.188 185.222.209.209 23.227.207.215 185.211.245.170 141.98.80.17 89.248.171.176 185.211.245.198 164.132.45.117 37.49.225.224 119.176.218.216 103.114.104.175 37.49.225.47 103.207.37.40 37.49.227.49 185.234.219.57

Update 2019-03-24: I noticed the incorrect EHLO above and looked at options for HELO/EHLO checking in sendmail. Searching did not show a lot of options, trying with the $&s delayed s macro did not fire on the given HELO/EHLO. So I kept searching and found the latest sendmail administration guide ('Bat book') with FEATURE(block_bad_helo). I activated this feature to see if it stops some of this traffic.

An interesting bit of news: SSH client gets patched after RSA key exchange memory vuln spotted.

The fixes implemented on PuTTY over the weekend include new features plugging a plethora of vulns in the Telnet and SSH client, most of which were uncovered as part of an EU-sponsored HackerOne bug bounty.

Get your updated putty at the PuTTY download page.

Update: Interesting visual change in putty: informational lines from the client are now prefixed by a putty logo. This could make it harder to mislead the user in certain attacks.

Every week there is an hour of morse training at my radio club, see article CW cursus op PI4UTR (Dutch). And I'm going there every week I can, as learning morse is an important part of my amateur radio resolutions for 2019.

We're training with the G4FON morse trainer which uses the Koch method (order of characters to learn) to learn morse and so-called Fairnsworth timing (playing the dits and dahs of the characters at the high speed but leaving room to think about what you just heard).

I am doing ok, now we're getting to the level of 37 characters I have a hard time remembering the newest characters. Constant exercise seems the only way to fix this a bit, making exercises with just the characters I keep making mistakes in, although I can go blank again on new characters when switching to testing the whole set. As soon as I get reasonable low amounts of errors I'll try to raise the speed (by raising the effective speed, the dits and dahs of a single letter still come at 15 words per minute).

I want to learn this, with the plan to pass the Belgian CW test some day, and get up to enough speed to be able to participate in morse parts of contests and DX contacts. But there will be a lot of practice before I'm at that level.

According to “FINAL WARNING” email – have they really hacked your webcam? - Naked Security there is a big flood the last day(s) of "Sextortion" scam mails going around. Don't fall for these. It's all fake.

I like hearing about other experiences in amateur radio from around the world. Podcasts are an easy way to hear experiences, news and opinions from other amateurs. And they fit nicely into my daily commute.

The list of amateur radio related podcasts I follow:

• 100 Watts and a wire
• Linux in the ham shack
• ICQ podcast
• QSO today
• ARRL The Doctor is in

A new level of stupid in the "I have you on video watching porn" extortion scams: the whole message embedded as an image, including the instructions to carefully cut and paste the bitcoin wallet address.

Links: Report history for 12Vso1cRX7zQovZG4wH7RAz2HqtdW1Lvek - Bitcoin Abuse Database, Bitcoin Address 12Vso1cRX7zQovZG4wH7RAz2HqtdW1Lvek.

Before, before, before.

This weekend was the EA PSK63 Contest and I participated Saturday evening, Sunday morning and a bit Sunday afternoon. I planned to participate in this contest so I set up the endfed antenna outside Friday evening because I would be away most of the Saturday daytime.

With the current radio propagation and a serious part of my participation after sunset I decided to enter in the single operator 40 meter category. I made 106 contacts, with 25 different spanish provinces in the log (out of 52 possible province codes). Spain by itself has 50 provinces with Ceuta and Melilla not counting as a province but they do count in the contest.

I also participated in the EA PSK63 contest 2016 with 60 contacts and EA PSK63 contest 2018 with 125 contacts (but only 79 in the 40 meter band).

In the inbox this morning, another attempt at extortion.

Subject: IMPORTANT! You have been recorded masturbating! I have Koos Website.mp4!

Hi there,

The last time you visited a porn website with teens,
you downloaded and installed the software I developed.

My program has turned on your camera and recorded
the process of your masturbation.

My software has also grabbed all your email contact lists
and a list of your friends on Facebook.

I have the - Koos Website.mp4 - with you jerking off to teens
as well as a file with all your contacts on my computer.

You are very perverted!

If you want me to delete both the files and keep the secret,
you must send me Bitcoin payment. I give you 72 hours for the payment.

If you don't know how to pay with Bitcoin, visit Google and search.

Send 2.000 USD to this Bitcoin address as soon as possible:

34vKT8SpK2zYAgJUDww9ih1o7Ky3JKmCdP
(copy and paste)

1 BTC = 3,850 USD right now, so send exactly 0.525386 BTC
to the address provided above.
Do not try to cheat me!
As soon as you open this Email I will know you opened it.
I am tracking all actions on your device.

This Bitcoin address is linked to you only,
so I will know when you send the correct amount.
When you pay in full, I will remove both files and deactivate my program.

If you don't send the payment, I will send your masturbation video
to ALL YOUR FRIENDS AND ASSOCIATES from your contact lists I hacked.

Here are the payment details again:

Send 0.525386 BTC to this Bitcoin address:

----------------------------------------
34vKT8SpK2zYAgJUDww9ih1o7Ky3JKmCdP
----------------------------------------


You саn visit police but nobody can help you. I know what I am doing.
I don't live in your country and I know how to stay anonymous.

Don't try to deceive me - I will know it immediately - my spy software is
recording all the websites you visit and all keys you press.
If you do - I will send this ugly recording to everyone you know,
including your family.

Don't cheat me! Don't forget the shame and if you ignore this message your
life will be ruined.

I am waiting for your Bitcoin payment.
You have 72 hours left.

Anonymous Hacker

Given the address it's clear someone managed to visit this website. Actually hacking my computer and removing the webcam cover or installing the webcam is harder!

Bitcoin links: Report history for 34vKT8SpK2zYAgJUDww9ih1o7Ky3JKmCdP - Bitcoin Abuse Database and Bitcoin Address 34vKT8SpK2zYAgJUDww9ih1o7Ky3JKmCdP.

Na mijn experimenten met RFID kaarten in 2011 heb ik er een tijd niets aan gedaan. Het afgelopen half jaar kwam het onderwerp weer op door wat beveiligingsvragen rond RFID kaarten en heb ik weer de software uitgezocht.

Naast de linux tools is RFID support onder Android nu ook normaal en ik heb ontdekt dat NFC TagInfo by NXP prima software is om snel een kaart te onderzoeken. Bij sommige MiFare classic kaarten geeft deze software dan al een melding dat er standaard bekende sleutels ('factory default keys') gebruikt worden.

In vergelijking met 2011 is het wel anders dat Mifare classic kaarten met een wijzigbare UID (uniek kaartnummer) gewoon te koop zijn (zoek op 'UID changeable card') en de wijziging kan met nfc-mfsetuid wat onderdeel is van libnfc en dus bij een moderne linux uit package libnfc-examples komt. Een complete clone van een mifare classic kaart is dus prima mogelijk, zie bijvoorbeeld deze beschrijving: Cloning Mifare 1K cards (engelstalig).

We zijn een week op wintersport vakantie geweest naar het gebied van Serfaus-Fiss-Ladis in Tirol. Ons onderdak was een leuk appartement in Ladis, vlak aan de piste en we hebben ons prima vermaakt met snowboarden en een dag bergwandelen. Na een onderbreking van een paar jaar kan ik nog goed snowboarden en heb me ook weer vermaakt met boardercross en mooie afdalingen.

Ineens is de haalbare VDSL upstream snelheid (engels 'attainable') gezakt naar wat daarvoor ongeveer de huidige VDSL upstream snelheid (engels 'current') was. Een opvallende hik in de grafieken. Ik heb geen idee wat de aanleiding is en of dit weer kan veranderen.

Dit is alleen te zien in het modem, de hele PPP sessie is gewoon in stand gebleven.

Sunday had less time to be at the radio for ISS passes but one pass was ok. It started with the end of one image, one full image and the start of the next image. The audio recording of the whole pass is included.

After hickups in recording audio from the radio on two previous passes I rebooted the whole system (it was nagging about a reboot anyway) and I received two more partial images.

Thanks to ARISS Russia team member Sergey Samburov, RV3DR for making this possible!

Second pass of the International space station gave me one partial picture and one complete (with some noise).

In this weekend there are extra slow scan tv (SSTV) transmissions from the international space station (ISS). The ISS moves across the sky when viewed from earth so I calculate beforehand when it will pass across the sky and what the trajectory will be.

I woke up in time to be outside for the first one. A low pass over the horizon and most of the pass matched a pause between transmissions, so not much image received.

Het blijft actueel: Nep-mail over hack en bezoek pornosite - Fraudehelpdesk.

Ik zie ze zelf ook op verschillende plekken. Trap hier niet in.

Dit keer een bitcoin adres waar nog geen transacties in zichtbaar zijn: 12PUa2SHjWAUEpZZUxQNvxa7epab7g2Ksb alleen is mij niet duidelijk of deze site het verschil tussen een echt aangemaakt adres zonder transacties of een willekeurig adres weet.

Toevoeging 2019-02-07: Een bedrag van 808 dollars in bitcoins staat nu in de wallet, in 2 transacties. Gegeven het bedrag in het originele mailtje zijn er dus 2 mensen ingetrapt.

Toevoeging 2019-02-11: Er is nu over de 3000 dollar in bitcoins binnen. Als ik zo naar de transacties kijk lijken er 7 mensen ingetrapt.

Nog meer informatie: Bitcoin Abuse Database for 12PUa2SHjWAUEpZZUxQNvxa7epab7g2Ksb (engelstalig).

I noticed something really weird in the kernel log of a virtual machine:

Feb  5 11:46:54 server kernel: [2936066.990621] Bluetooth: Core ver 2.22
Feb  5 11:46:54 server kernel: [2936067.005355] NET: Registered protocol family 31
Feb  5 11:46:54 server kernel: [2936067.005901] Bluetooth: HCI device and connection manager initialized
Feb  5 11:46:54 server kernel: [2936067.006404] Bluetooth: HCI socket layer initialized
Feb  5 11:46:54 server kernel: [2936067.006838] Bluetooth: L2CAP socket layer initialized
Feb  5 11:46:54 server kernel: [2936067.007280] Bluetooth: SCO socket layer initialized
Feb  5 11:46:54 server kernel: [2936067.009650] Netfilter messages via NETLINK v0.30.
Feb  5 11:46:54 server kernel: [2936067.056017] device eth0 entered promiscuous mode

The last two are the giveaway about what really happened: I started tcpdump to debug a problem. But I did not expect (and do not need) bluetooth drivers on a virtual machine, it will never have access to a bluetooth dongle.

After setting up /etc/modprobe.d/local-config.conf with

blacklist bluetooth

tcpdump still works fine and no bluetooth drivers are loaded.

Update: Most recommendations are to disable the bluetooth network family:

alias net-pf-31 off

After a month with three digimode radio contests I plotted the number of amateur radio contacts again. The number of contacts is clearly higher each January as a contest month, with this January a new peak.

The contests were the ARRL RTTY Roundup on 6 and 7 January, the UBA PSK63 prefix contest on 12 and 13 January and the BARTG RTTY Sprint Contest on 26 and 27 January.

Nicer looking font due to the upgrade of "radio workstation" thompson. I guess even gnuplot is coming along with the modern times.

before, before, before, before

I have "always" been running amanda for backups on linux. Or rather, I can't find any indication when I started doing that several homeserver versions ago, it's just still running.

Or it was running, but first I had to tackle a hardware problem: all SCSI controllers I have are PCI and the newest homeserver has no PCI slots. So I searched for a solution. The first solution was to try using the desktop system for the tapedrive, but the powersupply in that system has no 4-lead Molex connectors so I can't connect the tapedrive.

For now I use an old 'test' system with some software upgrades to run amanda and shut it down when all backups are done and flushed to tape. But amanda had a serious problem writing stuff to tape. With some debugging this turned out to be caused by the variable blocksize I used on the previous systems, with

# mt -f /dev/nst0 setblk 0

and I can't even find out why this seemed like a good idea years ago. But now amanda really wants to use 32768 byte blocks and filled a DDS-3 tape (12 Gb without compression) with about 1.8 Gb of data before reaching the end of the tape.

Why this default has changed isn't clear to me, but I found a way to re-initialize the tapes so the backups fit again. Based on block size mismatch - backup central I created a script to do this. I did not get the error about the blocksize, but I searched specifically for 'amanda 3.3.6 blocksize'.

#!/bin/sh

if [ "$1" = "" ]; then
        echo "Usage: $0 <tapename>"
fi

mt -f /dev/nst0 setblk 32768
mt -f /dev/nst0 compression 1
mt -f /dev/nst0 rewind
dd if=/dev/zero of=/dev/nst0 bs=32768 count=200
mt -f /dev/nst0 setblk 32768
mt -f /dev/nst0 compression 1
mt -f /dev/nst0 rewind
amlabel -f kzdoos $1

And now normal amounts of data fit on a tape again. I just have to initialize every tape before using it for the first time in this setup.

This weekend I participated in the BARTG (British Amateur Radio Teledata Group) RTTY Sprint Contest.

I went into this contest with the idea of maybe getting some contacts and things turned out somewhat better than that: I made 82 contacts. No new countries or anything else special. The one that got away was PJ4P, Bonaire. I saw that station calling and I kept answering but the contact did not happen.

I used the topendfed antenna outside and the amplifier. So I entered in the high power category.

As with other recent contests the propagation wasn't cooperating very well. When I started in HF at home (October 2014) I would switch from 10 to 20 meters after it got dark because of the changing propagation. Now I change from 20 to 40 meters as soon as it starts to get a bit dark.

Like in 2015, 2016, 2017 and 2018 I participated in the UBA PSK63 Prefix Contest in the past weekend. Before I really dove into the contest I first mounted a new end-fed 10/20/40 antenna which can handle more power and tested it.

It took a few tries to get the antenna tuned on the 40 meter band. I tested this with the amplifier which has proven to be really precise about the SWR of the antenna in the 40 meter band, as noted in my post about the ARRL RTTY roundup 2019. I had planned to get this antenna up and running before that contest but that did not work out.

After testing I switched back to 50 watts power without the amplifier because the rules of the UBA PSK63 prefix contest limit the power.

I made a total of 69 contacts as single operator 40 meter. I had a short look at PSK63 activity in the 20 meter band during daylight but it was completely none.

After the contest I tried some FT8 contacts on the 40 meter band with the amplifier active. The amplifier did not like this and went into SWR protection. I must have tuned it perfectly for 7.040 - 7.050 MHz but the SWR is already outside the limits for the amplifier at 7.074 MHz.

I received a "complaint" that a very old site on the webserver wasn't working anymore. I am not a person to just stop something without planning that so this was an oversight. It was one of the userdirs on idefix.net: Ivo van der Wijk who hasn't updated the page sinds 1994. No, really, not even the broken links.

In restoring this one and the others I found that php in userdirs is disabled by default nowadays, found via PHP not working in userdir (public_html) - devPlant. Maybe a good idea, but I only enable php on virtualhosts where I want it, so I disabled that rule. I hadn't missed it on my own webspace yet, but a site like Het online dagboek van hester (Renate) in Australie (en daar in de buurt) depend on PHP completely.

While I was looking for the reason the php failed I also noticed that /etc/apache2/mods-available/userdir.conf also has some configuration I do not appreciate, it enables userdirs globally when the module is loaded:

<IfModule mod_userdir.c>
        UserDir public_html
        UserDir disabled root

        <Directory /home/*/public_html>
                AllowOverride FileInfo AuthConfig Limit Indexes
                Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
                Require method GET POST OPTIONS
        </Directory>
</IfModule>

I disabled that part: I only want the userdir to work on specific virtual hosts.

The last time I did those was in 2017: Reviewing my 2016 amateur radio resolutions, and the new ones for 2017 and the hindsight results for 2017/2018 are:

• Improve the holiday/portable setup with solar power and a lightweight multiband inverted V
  No solar power (due to costs) but the portable setup is improved and tested: the fiber mast I bought for playing radio from several locations including amateur radio from a local park. Now to find more time to actually use it.
• Keep doing the digimode contests
  That part went better in 2017 and I had less time and/or energy for contests in 2018. Also in 2018 the interference situation got worse. So my net results in contests improved in 2017 and got worse in 2018.
• Maybe those satellites
  I tried at least receiving them a few times, but no contacts yet.
• Get a 2m/70cm vertical antenna on the roof of the dormer
  It's there, it has already been upgraded to a bigger antenna with higher gain and it's mostly used for 2 meter FT8. But also for actual talking to other radio amateurs sometimes.

The Sotabeams newsletter had an item "Setting your targets for 2019" which had some nice ideas and which triggered me to write this post. Things I want to try :

• Keep learning morse!
• Get more countries on more HF bands in the log
• Moonbounce on 2 meter
• Those digimode contests, and maybe a few phone contests
• Operate HF outside
• At least one satellite contact

Today I tried to follow a link to http://www.independentri.com/ but I got an error message:

451: Unavailable due to legal reasons

We recognize you are attempting to access this website from a country belonging to the European Economic Area (EEA) including the EU which enforces the General Data Protection Regulation (GDPR) and therefore access cannot be granted at this time

And indeed in the headers:

$ lynx -head -dump http://www.independentri.com/
HTTP/1.1 451 Unavailable For Legal Reasons

I see the real reason as 'not wanting to comply with European consumer protection laws'. I have no idea how many visitors the site is missing due to this regionblock but since it's a regional weekly newspaper in the United States of America: probably not a lot of the intended audience.

De spammers hebben geen goede voornemens, of voornemens die ik niet als goed zou benoemen, want ook in 2019 gaan ze vrolijk door. Nog steeds spam die gericht is aan een belgisch bedrijf op een .nl adres.

Hetzelfde patroon, nu van Ticket Restaurant Belgie. De advertentietekst is allemaal in het nederlands, de standaard leugens dat ik me geabonneerd zou hebben en dat ik me zo kan uitschrijven zijn in het frans en verwijzen naar NeoPro.

En ook van onlinevisa.eu krijg ik spam, zelfs met de naam "Maes-Swerts/A." er weer eens in. Die had ik een tijd niet gezien!

Ook King Oak VOF gebruikt blijkbaar het zelfde bestand om te spammen. Dat bestand is minstens 7 jaar oud.

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

As planned I participated in the ARRL RTTY Roundup contest this weekend. It was possible to participate in FT8 mode but since I had not prepared for that and had no duplicate checking between FT8 and RTTY I decided to use the mode I am familiair with for this contest: RTTY.

I operated on the 40 meter band Saturday and Sunday evening, and on the 20 meter band during the daylight hours of Sunday. Everything was search and pounce, no responses to calling CQ. I used the power amplifier on the 20 meter band which did help in getting the contacts to almost every station I could decode. The amplifier does not like the SWR from the antenna on 40 meters so I ran without the amplifier on that band.

I made 115 contacts. A number of US stations, already the first new US state confirmed via LoTW. Two more new US states in the log, hope I can get those confirmed too.

In between a few other not too far FT8 contacts I suddenly had a contact with 9M2TO in West Malaysia, a new country for me in amateur radio. I had seen the call before but I did not expect the contact to happen.

And it's already confirmed via Logbook of The World too.

More than a year after I started migrating from homeserver greenblatt to the new homeserver conway the last migration is done and the old server is switched off. The new server is in a good position in the rack, and the old server is still taking up space in there too. It has taken a lot of time, I decided to stop some websites and other unused services in the process and my energy levels haven't always been that great. I have improved several things in the process, which also caused delays.

One thing hasn't changed (which I did expect to change): the power usage of the new server isn't lower! The UPS tells me the output load is about the same. Ok, the new hardware has a lot more CPU power, a lot more memory and faster storage, but I expected the poweruse to go down a bit.

The new hardware for the homeserver has no external serial ports, so I could not use the old serial / 1-wire interface that has been doing the home monitoring for years. But I had a spare USB DS2490 interface. So I plugged this into the server and wanted to forward the USB device to the guest VM that runs all the monitoring.

First I had to blacklist all the loaded drivers to have the device available to kvm as-is. In /etc/modprobe.d/local-config.conf:

blacklist w1_smem
blacklist ds2490
blacklist wire

Next step was to attach the device to the right vm. I followed the hints at How to auto-hotplug usb devices to libvirt VMs (Update 1) and edited the definition for the vm to get the host device like:

    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x04fa'/>
        <product id='0x2490'/>
      </source>
    </hostdev>

But that did not get the usb device attached to the running VM and I did not feel like rebooting it. So I created an extra file with the above and did a

root@conway:~# virsh attach-device --live gosper /tmp/onewire.xml 
Device attached successfully

And then I had to do the same blacklisting as above in the virtual machine. After doing that I detached and attached it from the VM without touching it with simply:

root@conway:~# virsh detach-device --live gosper /tmp/onewire.xml 
Device detached successfully

root@conway:~# virsh attach-device --live gosper /tmp/onewire.xml 
Device attached successfully

After that I had to set up rules for the telemetry user to have enough access to the USB device:

#
SUBSYSTEMS=="usb", GOTO="usb_w1_start"
GOTO="usb_w1_end"
LABEL="usb_w1_start"
ATTRS{idVendor}=="04fa", ATTRS{idProduct}=="2490", GROUP="telemetry", MODE="0666"
LABEL="usb_w1_end"

And now it all works:

telemetry@gosper:~$ digitemp_DS2490 -a
DigiTemp v3.7.1 Copyright 1996-2015 by Brian C. Lane
GNU General Public License v2.0 - http://www.digitemp.com
Found DS2490 device #1 at 002/003
Jan 01 21:53:11 Sensor 10A8B16B0108005D C: 9.500000
Jan 01 21:53:12 Sensor 28627F560200002F C: 17.062500
Jan 01 21:53:14 Sensor 10BC428A010800F4 C: 19.562500
Jan 01 21:53:15 Sensor 1011756B010800F1 C: 11.937500
Jan 01 21:53:16 Sensor 10B59F6B01080016 C: 16.312500
Jan 01 21:53:17 Sensor 1073B06B010800AC C: 18.687500
Jan 01 21:53:18 Sensor 102B2E8A010800F0 C: 29.250000
Jan 01 21:53:20 Sensor 28EF71560200002D C: 16.687500

Working house temperatures again!