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!