I wanted to get an idea whether the network over the fiber optic transceivers is reliable. So at the moment our dining room table looks like a network lab.

For testing networks there is iperf. I found out the Raspberry Pi 3B+ can't keep up with 100 Mbit/second UDP packets, so I searched for a speed where the Pi performs ok. This turns out to be 30 mbit, at higher speeds there is packet loss. I also had to reduce packet size to avoid fragmentation which costs CPU. I use IPv6 because that's what I'm used to. It turned out later the maximum speed without loss is higher with IPv4 than with IPv6.

Server on the raspberry pi:

koos@raspberrypi:~ $ iperf --version
iperf version 2.0.9 (1 June 2016) pthreads
koos@raspberrypi:~ $ iperf -s -V -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------

Test without fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - raspberry pi

koos@wozniak:~$ iperf --version
iperf version 2.0.9 (1 June 2016) pthreads
koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c ..
------------------------------------------------------------
Client connecting to .., UDP port 5001
Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust)
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
..
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec
[  3] Sent 321430 datagrams
[  3] Server Report:
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec   0.004 ms    0/321430 (0%)

Test with fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - fiber optic transceiver - fiber - fiber optic transceiver - utp - raspberry pi

koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c ..
------------------------------------------------------------
Client connecting to .., UDP port 5001
Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust)
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec
[  3] Sent 321430 datagrams
[  3] Server Report:
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec   0.007 ms    0/321430 (0%)

Trying with IPv4 shows that packet loss starts to occur above 45 mbit. This is an interesting difference.

But the important conclusion is that there is no packet loss over the fiber path. There may be a bit more latency, but that's not a surprise. As a last test I looked at purely ping traffic using IPv6.

Without fiber in the path:

koos@wozniak:~$ ping -c 100 -i 0.2 -q ..
PING ..(.. (2001:xxxx)) 56 data bytes

--- .. ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20192ms
rtt min/avg/max/mdev = 0.567/0.680/0.866/0.063 ms

With fiber in the path:

koos@wozniak:~$ ping -c 100 -i 0.2 -q ..
PING ..(.. (2001:xxxx)) 56 data bytes

--- .. ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20191ms
rtt min/avg/max/mdev = 0.625/0.738/0.828/0.046 ms

This also shows a bit more latency over fiber.

The extra latency is probably due to the fiber optic transceivers containing a network switch.

Buttcoins have had some interesting price changes recently and while I normally only associate bitcoin with sextortion scams I'm now receiving spam about 'getting rich from bitcoin'. Most notably from the mails:

Don't like these emails? Unsubscribe. a Company or Organization Name | Latvia

Wahnsinnig reich werden Wahnsinnig reich werden Don't like these emails? Unsubscribe. a Organization Name | France Unsubscribe {recipient's email} Update Profile | About our service provider

I guess they are abusing some cheap spam provider (probably known to themselves as "e-mail marketing company").

There is no fiber to our home in the near future but I am working on laying another fiber route: from the switch in the cupboard downstairs to the shed. This is because the NTP server in the shed still has intermittent connectivity issues when using 2.4 GHz wifi due to the 2.4 GHz wifi channels being very crowded. The wifi dongle has no 5 GHz support and I don't think I would get it very reliable. But other options are also not ideal. As a radio amateur I can't go back to using powerline (network over power cables) and I wouldn't feel safe with a network cable running that far should a lightning strike ever occur. I should write "occur again" since I have had a network switch with probable lightning damage before.

The only option left is what you guessed from the title of this post: fiberoptic cable. No interference to my radio reception and a lot less chance of lightning blowing up parts of the network and connected computers. But a whole new world of fiber types, fiber lengths, wavelengths, connector types and interface types opened up to me. The switch in the cupboard downstairs has SFP ports, but how to get beyond that.

The raspberry Pi 3B+ that I use is 100 mbit only and I wasn't sure how to handle that. So I asked someone who is very good with fiber networks to explain to me what options are available and that person dug up some lengths of fiber that are no longer used and some 100 mbit fiberoptic transverters that were also a wrong purchase. So I already have the connectivity hardware available.

Now all I need is a physical route between the shed and the rest of the network. There is an old plastic pipe from the shed to the crawlspace of our house that was once used for heating will probably do the trick once I figure out how to remove the old heating pipes from it. I guess there is some real dirty work below the floor of our house and in the shed in my near future. I will also need to buy plastic tubing to safely guide the vulnerable fiber. And some hooks to hang this tube and other cables from the floor instead of having them lie in the sand in the crawlspace.

Since there is also an old gas pipe in the plastic pipe I will make really really sure first that one isn't connected somewhere.

This was all triggered by adding the ntp server in the shed to the NTP pool and having the pool monitoring system gripe about the server becoming unreachable as soon as I have wifi problems. The things I will do for serving the right time!

The contest that started radio contests in digital modes for me was again last weekend: the UBA PSK63 Prefix Contest. This is the 7th year in a row that I participated in that contest.

Conditions weren't very good. Especially Saturday the 20 meter band 'dried up' as soon as it got a bit dark and later in the evening I stopped trying on the 40 meter band and decided to call it a night. Sunday morning after I woke up I tried again and got a good number of new stations both on 20 and 40 meters.

In the end I made 78 contacts.

Last weekend was the ARRL RTTY Roundup 2020 and I participated. I made sure beforehand to have a separate logging file for just this contest, with the plan to be able to switch from RTTY in fldigi to FT8/FT4 in wsjt-x and back.

Propagation on the 40 meter band during the dark hours wasn't very good, I never got outside of Europe on that band. On Sunday afternoon I tried the 20 meter band for a while with not much better results. I switched back to 40 meter and worked some new stations. I did switch back to the 20 meter band just before sunset and got one US station in the log: W0PR which also sounds like a reference to the WarGames movie (to me).

I did switch to wsjt-x on Sunday evening. I saw absolutely no calls for the contest on 40 meter FT8, and only a few on 40 meter FT4 so I tried making those contacts. I saw several US stations calling but none heard my answer.

In the end I made 89 contacts. I did transpant the log from fldigi to wsjt-x but wsjt-x did not see the earlier contest contacts so I increased the outgoing serial counter to start at 86. I've had better years in the ARRL RTTY Roundup.

I forked the github repository GitHub - jgarff/rpi_ws281x: Userspace Raspberry Pi PWM library for WS281X LEDs into my own GitHub - KHoos/rpi_ws281x: Userspace Raspberry Pi PWM library for WS281X LEDs and committed my code for using the 120 led ledstrip as christmas tree lights including morse code.

It's my first actual python code.

Looking for some special beers for new year's eve I found this at the local supermarket. I know 'standard' Guinness since we used to drink that on holidays in England, but I had no idea what to expect from this beer. Time for the experiment.

In taste it's a reminder of Guinness, but not as 'creamy' as Guinness. A bit more nuance in taste.

The beer details

Company	Guinness
Beer name	Guinness West Indies Porter
Beer style	Porter
Alcohol by volume	6.0 %

The bitcoin sextortion scams continue in this year. The one I got today tries to avoid spam filters that trigger on bitcoin addresses:

Ok! So.. to get some coins go and search on Google for "Buy BIT C0lN instantly"
and send to this address:

Address: 1 L 2 U a v M T r h p C X W n 9 L v q h C q R S v x Y z f Q s B w 4
Amount: 0.027

The address 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4 is valid according to 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4 - blockchain explorer but not yet known at BitcoinAbuse.

I hope some day one of these scammers is brought to justice.

Update 2021-01-10: More of the same, with reasonably good Dutch language writing. New bitcoin addresses: 1Emh6CsbF4eo425ph3sSCNZ2aGCWerRB7w 1JakpfFpX4HFyiuv7WKviV5xAanMwknArV 1Emh6CsbF4eo425ph3sSCNZ2aGCWerRB7w and the criminal wants 1500 US Dollar in buttcoins to not publish the videos.

Update 2021-01-13: More good Dutch although I am sure it's a translation because of the familiairity in the writing style. Bitcoin address Eu8sHWG2Uzvd1ukxumae5ctfSNWWtsFkS. The amount has changed to 1400 Euro in buttcoins.

I also note bitcoin address 1JakpfFpX4HFyiuv7WKviV5xAanMwknArV has received 2 incoming transactions of somewhat above 1500 dollars so it seems this crime pays.

Time to plot the number of contacts in 2020 and a review. I made no specific resolutions for 2020 but looking back there were positive developments.

• The Kenwood TS480-SAT is at a remote location with good antennas for most of the HF bands. This enabled me to work new countries and get more voice and morse contacts in the log.
• I was active on amateur satellites a few times, including from Austria.
• The morse speed improved and I got on the air more with morse. Including a few morse contests.
• I tried to follow the Bulgarian Saints 2020 stations and I had at least one contact with one of the stations in 10 out of the 12 months of 2020. In 8 months I had at least one contact in morse with the station of that month. So I earned the Bulgarian Saints diploma 2020.
• In general I made more contacts in this year than in any other year. The endfed antenna is now mounted outside in such a way I can leave it there, which makes getting on the radio for a few contacts easier. There were also more special event stations active this year.
• I had radio contacts with several new countries.
• The box with outgoing QSL cards is now empty!
• I'm active as QSL manager for my local club, this is fun and my part of keeping the club running.

Plans for 2021:

• Keep practising morse, try to pass the morse exam.
• More satellite contacts. Weather permitting...
• Morse and phone in contests.
• Order new QSL cards and keep on sending them.

Since the igate build was finished and the first packets were received I left it running. I did switch to a 5 volt power supply: it works fine on a USB charger powering the whole circuit board via the USB connector for the ESP32.

Packets are received from a large area around the city as shown. I'm glad it is all working and I hope to improve the APRS network coverage here locally a bit.

It's the christmas holiday and that gives me some time to fix things that have been on the wishlist for a while. This includes some parts of the scripts that make up my homepage.

The update was a learning process, I found out getting caching right is still very hard and I learned about preformatted text and the CSS grid which worked differently than expected. All fixed now.

This is now fixed, and I may find more things to fix in the (near) future.

Changes include:

• The pages are now using a CSS grid
• Pages have a usable righthandside
• Updates to the footer have been made on all pages
• The history function of the newstag page has been fixed to give usable permanent urls
• The IPv6 check is active on more pages

I found out the mobile version of my homepage was a lot wider than the desktop version (which tries to fit on the screen). This didn't show when I learned about the CSS grid for Camp Wireless.

The difference is that my homepage regularly uses log samples which are displayed as preformatted text. I used the grid width 1fr which allows for the full width of <pre> items. Changing this to 100% fixed it. The desktop version uses two columns and those are already split using percentages of the full screen width.

I haven't written anything about wardriving since I noticed I fell out of the WiGLE top 100 but I still do it from time to time. At the same rate as I wrote back then, switching on the WiGLE app on an Android phone when I realize I may be in an 'interesting' area for finding networks and I have the time. I don't go out on wardriving trips on purpose, but there are enough networks to be found.

By now I have dropped to the number 312 rank in the WiGLE user statistics. I guess there are other wardrivers a lot more active and plotting every day wardriving expeditions.

WiGLE also logs found bluetooth devices and there are a lot of those out there.

After switching my websites to https I found out caching works differently on https (for good reasons) and files included by lots of pages got reloaded a lot.

So I added some caching hints. I especially did not want the stylesheet to be reloaded constantly. So I added an ExpiresByType directive to cache stylesheets for a week.

But on the change of camp-wireless to a new stylesheet and programming language I got bitten by this: some browsers had the old css code cached and saw no reason to check for updates. The site looked strange (but wasn't really broken).

I recently made some changes to parts of my homepage too, also going to the CSS grid model, just like the changes in Camp Wireless to the CSS grid model. And I had the same problems with the CSS in the production version. It took a bit of searching to find the source of the Expires statement, it was in the .htaccess file.

Now fixed to a much shorter cache time, it is quite possible to have versions of the pagecode and CSS differ in the browser.

I acquired a Blaupunkt BLP6100 Bluetooth speaker. Which turns out to support the following services via bluetooth:

• Headset (audio for phone calls)
• Handsfree operation (use buttons to accept, hangup or reject calls)
• Audio sink (the main function of a bluetooth speaker)
• Serial port

That last one I did not expect. I have tried opening the port with minicom and it will say carrier detect but sofar trying to wake it at 115200 or 9600 hasn't resulted in anything.

As a linux audio device it works fine. Or as a bluetooth speaker for my phone so I can listen to podcasts while walking around at home.

But the serial port makes me wonder!

On Sunday I wanted to do some cycling and deliver something in another part of the city of Utrecht. Those two can be combined! After finding the right part to do my delivery I cycled out of the city in north-west direction and returned via the northern ringway.

I like participating in radio contests. Not to win them, but to improve my own score and have the fun of making a high number of structured radio contacts in a short time.

There is also the factor that radio contests bring out participants in places that are normally hard to reach for radio amateurs. Last weekend I was tuning on the 20 meter band looking for phone contacts and I heard a Canadian station giving out the abbreviation Quebec Charly (QC) as an exchange. I looked it up and found out the RAC Canada Winter contest was running. I made the contacts and spun the dial looking for other Canadian stations, because I never had a confirmed voice contact with a Canadian station.

That doesn't mean I haven't talked to Canadians over amateur radio, I had a really nice chat with a Canadian who knows the area where I grew up a few months ago. That's totally different from a contest contact and also very nice to have.

In total I got 3 different Canadian stations in the log and I entered my log. It won't be the winner in the DX category, but I appreciate the fact that the Radio Amateurs of/du Canada organize this so I do my part in making the scoring possible.

And yes the first LoTW confirmation already came in, so I now have Canada confirmed on phone.

Other DX update: Patience helps, I now have the earlier contact with Cuba confirmed.

Interesting find in the logs: SMTP authentication brute force.

Dec 20 20:57:22 gosper saslauthd[1616]:                 : auth failure: [user=iknidcam1974] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 20:57:26 gosper saslauthd[1613]:                 : auth failure: [user=iknidcam1974] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Dec 20 21:54:42 gosper saslauthd[1615]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 21:54:47 gosper saslauthd[1617]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Dec 20 21:57:14 gosper saslauthd[1614]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 21:57:23 gosper saslauthd[1615]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

With lots more for different names. The last one is probably this session:

Dec 20 21:57:16 gosper sm-mta[15854]: STARTTLS=server, relay=[5.188.206.203], version=TLSv1.2, verify=NOT, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Dec 20 21:57:24 gosper sm-mta[15854]: 0BKKvEuN015854: [5.188.206.203] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-SSL

Due to the fact that they abort the session when they can't log in the IP is seen as annoying by fail2ban and added to the deny list. But that list grows (suggesting a distributed attack) and is at this moment at 142 currently blocked hosts.