In two older posts in this blog, one about a Second SPI chipselect for Orange-Pi Zero, one about a Hitachi HD44780 text display under Linux, I talked about trying to get changes into the Linux Kernel.

In case of the Orange-Pi it was a bug-fix to the SPI-Driver of the Allwinner sun6i architecture. Thanks at this point to the author Mirko of that patch who let me submit the patch in his name. The patch is in the kernel since shortly before 5.13. Since it has been marked as a bug-fix, it was backported to various stable series of the kernel as far back as the 4.4 stable series.

In case of the Hitachi display it was a documentation update that should allow people to find out how to connect such a display with the necessary device tree magic but without any software change. This patch has finally been accepted into the Linux Kernel in time for the 5.15 release.

WARNING: In the following I'm going to describe how to modify a power supply. Power supplies contain high voltages – even after removing the power plug they can still have high charges in capacitors. In some countries devices with mains power may be modified only by or under supervision of certified persons. So you should know what you're doing and be authorized to modify a power supply.

PC power supplies are cheap and readily available but the tend to produce the correct voltages only when the drawn current from all different voltages are within the minimum/maximum specs of the power supply. Drawing high current (but within the specs of the power supply) only from a single voltage lets this voltage drop below specification.

One example is the heat-bed of my 3D-printer: It used to have a PC power supply for the heat bed. The heat bed draws about 12A but only from the 12V line. The result was a voltage of about 10V when the heat-bed was heating.

Another use-case is the supply of several ARM based single-board computers (e.g. Raspberry-Pi or Orange-Pi) from a single 5V line. When using a PC-Power supply for this (without drawing current from the 12V lines) the nominal 5V voltage may drop below a value where the single-board computer works reliably.

A third example is the use of a power supply for powering the radio of a ham-radio operator: These radios typically don't output full power when powered with 12V or less, they typically need 13.6-13.8V for full power operation.

In all these cases a modification of the power supply that keeps the chosen voltage stable or even allows to modify the chosen voltage slightly (from 12V to 13.8V for hamradio operation) would be nice. How can we achieve that?

Many PC power supplies are based on the power regulator integrated circuits TL494 or KA7500 (they are pin-compatible). If you have one of those they can usually be modified for the purposes outlined above.

One schematic details of those supplies is a feedback-circuit that feeds back the 5V and the 12V voltage to the regulator IC. You can find a lot of power supply schematics on Dan's PC power supply page. Take the second of the TL494 or KA7500 based supplies, it has several resistors in parallel from pin 1 of the TL494 to ground, a 27kΩ-resistor from 12V to pin 1 and a 4.7kΩ-resistor from 5V to the same pin.

We can modify the voltage regulation by changing the feedback pins. Note that every power supply usually has different resistors to ground and different feedback resistors from 5V and 12V. As an example we replace the two feedback resistors to make the power supply provide stable 5V without caring for the 12V supply.

WARNING: When modifying a power supply for a stable 5V or 12V source, the other voltages will no longer be stable and may become too high for use in a PC. You should never use such a modified power supply in a PC.

So the first step is to identify the two resistors in the power supply. Once found we verify that the side of the resistor not connected to pin 1 of the regulator IC has 0Ω to the correct (5V or 12V) power supply output. We unsolder both resistors. Now before computing the new resistor to be placed between 5V output and pin 1 we measure the resistance between pin 1 and ground: Because we have now unsoldered the two resistors to 12V and 5V the resistor can be measured. It is good to be sure that the measured resistance matches the computed resistance from the three resistors connected in parallel: In the example we have 100kΩ, 390kΩ, and 10kΩ in parallel which should measure as

When recently modifying a power supply the resistors to ground were 470kΩ, 100kΩ, and what I thought was 8.9kΩ: I interpreted the colors of the last resistor as grey-white-black-brown-brown. When measuring the three parallel resistors I measured it as 4.61kΩ instead of the expected 8033Ω. It turns out (after viewing the resistor in sunlight) that what I had interpreted as grey was really yellow-ish. So the resistor was really a 4.9kΩ resistor and the computed resulting resistance was 4625Ω.

To make the power supply regulate only for 5V we connect a new resistor from pin 1 of the regulator IC to 5V and leave the 12V feedback line unconnected. But how do we chose the new resistor? To find out we need to solve a set of equations: We know from Ohms law the relation of the voltages, resistors, and currents. We know from Kirchhoff that the current through the 12V feedback resistor and the current through the 5V feedback resistor must add up to the current through the resistors to ground. These relationships are given in this maxima spreadsheet.

We compute the reference voltage V_ref at pin 1 when both, the resistor from 5V and from 12V are connected. Then we chose the new resistor to 5V so that the voltage on pin1 stays the same.

For the example in Dan's second schematic we get 1800Ω for R_new. For the power supply I recently modified I've already given the resistors to ground. The resistor to 12V was 39kΩ and the resistor to 5V was 9.1kΩ. The resulting R_new for that power supply was 4865Ω which I realized by connecting a 4.7kΩ and a 150Ω resistor in series which was close enought to get a good 5V output. The computation is given as the second example in the spreadsheet.

A word of caution: When modifying the 5V power regulation or modifying a power supply for higher voltages (more than 12V) you should be aware that most PC power supplies have capacitors rated for 16V in the 12V output circuit. So when drawing high currents from the power supply modified for 5V the voltage on the 12V line may become too high for these capacitors. To be on the safe side the capacitors should be changed to types rated for 25V.

When modifying the 12V supply we use basically the same procedure, except that we now connect the 12V feedback resistor and leave the 5V feedback open. How to compute the resistor for the 12V feedback line is left as an exercise.

I recently have provided a customer with a link to a firewall image (using the Turris MOX router with a variant of OpenWRT) hosted on my own webserver. The image included keys material for an OpenVPN connection. The image file was in a hidden directory on my projects webserver. I monitored closely if there would be any downloads besides the one I expected from my customer.

I am aware providing key material via an unsecured channel is not the best security practice. And in the end I had to revoke the VPN key material in the image and provide my customer with a new key via a secure channel.

Now I said I monitored the downloads. About an hour (!) after my customer downloaded the image (at 21/Mar/2021:17:35:50 to be precise), it was accessed from another IP:

77.74.177.4 - - [21/Mar/2021:18:43:51 +0100] "GET /turris-image-XXXXXXX.zip HTTP/1.1" 200 77244886 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36"

Looking up this IP via whois yields:

> whois 77.74.177.4
% This is the RIPE Database query service.
...
netname:        KL-NET3
descr:          Kaspersky Lab Internet
country:        RU
...
source:         RIPE
organisation:   ORG-KL28-RIPE
org-name:       Kaspersky Lab AO
country:        RU

My customer is using Kaspersky antivirus software. So the link was probably leaked to Kaspersky via the installed software. On the one hand it may well be that the purpose of Kaspersky downloading that link is a benign service (they may scan things for viruses) but in my case it means that non-public information was leaked. On the other hand it may well be that information gleaned that way is used for other purposes, too – we do not know.

So consider that your Antivirus product may look over your shoulder when you are downloading things from the web.

I'm teaching at the University of Applied Science Burgenland in Eisenstadt (Austria). We recently had a lab (which took place in the lab in Eisenstadt but students were working from home due to Covid reasons) where the task is to set everything up for virtualisation and then live-migrate a running virtual machine to another server using libvirt (we're using the command-line with virsh).

For just one group out of several – with identical initial Debian installations, migration failed with an error message. The migration command was:

virsh -c qemu+ssh://root@primary/system migrate --live --unsafe \
    debian-1 qemu+ssh://root@secondary/system

For the lab we're using NFS because setting up a more advanced filesystem would take too much time, that's why we're using the --unsafe option. The following error message resulted (error message broken to several lines, this was all in a single line):

error: internal error: Process exited prior to exec:
libvirt:  error : unable to set AppArmor profile
'libvirt-d22db7ca-50ca-43bd-b6da-1ccecf5a83e7' for '/usr/bin/kvm':
No such file or directory

It turned out that this group had managed to fill up the /var partition with logfiles but after cleanup this still did produce the same message. So the hunch here is that some files that AppArmor and/or libvirt create dynamically could not be created and that was the reason why this failed. It also turned out that some AppArmor files that were correctly installed on the first machine were missing on the second.

Trying to reinstall AppArmor and related files using apt-get with the --reinstall option did not work, the missing config files in /etc/apparmor.d were not re-created. So removing the packages with the purge command (which removes all config files) and then reinstalling everything fixed the installed AppArmor files and made the migration finally work. I have no idea which files were missing.

When googling for the error message above I found a debian bug-report Where one of the dynamically generated files in /etc/apparmor.d/libvirt was zero length. This, however was not the problem in our case but indicates that AppArmor isn't very good at checking errors when a filesystem is full. So there are probably other files that are dynamically generated that were the problem in our case.

The following sequence of deinstall and reinstall commands fixed the problem in our case, note that just removing files as in the debian bug-report did not fix the issue in our case:

dpkg --purge apparmor-utils apparmor-profiles
dpkg --purge apparmor
rm -rf /var/cache/apparmor
apt-get install apparmor apparmor-utils apparmor-profiles
dpkg --purge libvirt-daemon-system
apt-get install libvirt-daemon-system
systemctl restart libvirtd.service
systemctl restart virtlogd.service
systemctl restart virtlogd.socket

I'm not sure restarting the services is really necessary but there was another issue that libvirt could not connect to the virtlog socket and this was fixed by restarting the virtlog.{service,socket}.

The popular DNS server bind allows to have a configuration that enables clients to change DNS entries remotely. Since some of the public dynamic DNS services have moved to a pay-only subscription model and since I'm running my own mail and web server at a hosting site I was searching for a way to roll my own dynamic DNS service. This already is back some years now but since the Howto I used at the time seems to be gone (at least from my google bubble) I'm documenting here how it was done.

I'm running this on a Debian buster server at the time of this writing, so if you're on a different system some details may change. I'm calling the domain for the dynamic services dyn.example.com in the following.

The top-level config file of bind needs to include an additional config file for the dynamic domain. In my configuration this file is named.conf.handedited. In this file you need an entry for each dynamic DNS client as follows:

zone "dyn.example.com" {
        type master;
        allow-transfer {none;};
        file "/etc/bind/slave/pri.dyn.example.com";
        update-policy {
            grant h1.dyn.example.com. name h1.dyn.example.com. A TXT;
            grant h2.dyn.example.com. name h2.dyn.example.com. A TXT;
            [...]
        };
};

In this example the hosts h1 and h2 and possibly more may edit their own DNS entry. I'm allowing them to change their A and TXT records. You may want to add AAAA for IPv6.

Then the config-file /etc/bind/slave/pri.dyn.example.com contains:

dyn.example.com         IN SOA  ns1.example.com. admin.example.com. (
                                2020080100 ; serial
                                120      ; refresh (2 minutes)
                                120      ; retry (2 minutes)
                                120      ; expire (2 minutes)
                                120      ; minimum (2 minutes)
                                )
                        NS      ns1.example.com.
h1                      A       127.0.0.1
                        KEY     512 3 10 (
                                AwEAAdEvnGmGO4ku+xms4w1c5RWh5BvugiZ4ty9tkIes
                                <more gibberish lines>
                                ); alg = RSASHA512 ; key id = <number>

The values in angle brackets are comments and should be replaced by the correct values in your installation. The entries A and KEY are inserted by hand for each new host allowed to set its own IP address. The KEY is the public key created below. In my experience an A-record has to be present for it to work, I'm setting the localhost address here because the client will later rewrite this IP anyway. It's customary to have the admin email address (where the @ is replaced with a dot) in the SOA record where I've put admin.example.com..

To create a new host:

• Create a new public/private key pair (preferrably the client does that and sends only the public key to the DNS admin for security reasons):

  dnssec-keygen -T key -a RSASHA512 -b 2048 -n HOST newhost.dyn.example.com
  

• This creates a private and a public key. Note that on the client you need both, the public and the private key although in the command line for the dynamic DNS client you will only specify the private key!

• Last time I created a new key the command did not support keys longer than 2048 bit although the hash algorithm is SHA2 with a high bit-length.

• You need to freeze (and make bind write the current in-memory DB to a file) bind for your dynamic domain:

  rndc freeze dyn.example.com
  

• Now you may edit the config file, you want to add a stanza for the new host and increment the serial number:

  $EDITOR /etc/bind/slave/pri.dyn.example.com
  

• Then don't forget to thaw the domain:

  rndc unfreeze dyn.example.com
  

• Do not forget to give the new host the necessary permissions in named.conf.handedited

• You probably need to reload bind:

  systemctl reload bind9.service
  

On the client side the utility we use to tell bind about a new IP address of our client is called nsupdate. You can probably find this program for many client operating systems.

I'm using a simple script that detects a change of a dynamic IP address and performs a bind update in case the address changed. Since you're running your own DNS server, chances are that you also have a webserver at your disposal. The following simple script allows any client to detect its own IP-address (clients are often behind a NAT firewall and we don't want to use another public service when we just got rid of public dynamic DNS services, right?):

#!/bin/sh
echo Content-Type: text/plain
echo ""
echo $REMOTE_ADDR

This script is put into a cgi-bin directory of a web server and will echo the client IP address (in text form) back to the client. I name this script ip.cgi and it is available via the URL http://example.com/cgi-bin/ip.cgi in our example, see below in the client script where you need to change that URL.

My bind update script (you need to change some variables) looks as follows (note that this asumes the script above runs on the top-level domain example.com, otherwise change the URL of the cgi-bin program):

#!/bin/sh
ZONE=dyn.example.com
DOMAIN=h1.dyn.example.com
DNSKEY=/etc/nsupdate/Kh1.dyn.example.com.+010+04711.private
NS="ns1.example.com"

registered=$(host $DOMAIN $NS 2> /dev/null | grep 'has address' | tail -n1 | cut -d' '  -f4)
current=$(wget -q -O- http://example.com/cgi-bin/ip.cgi)
[ -n "$current" \
-a "(" "$current" != "$registered" ")" \
] && {
 nsupdate -d -v -k $DNSKEY << EOF
server $NS
zone $ZONE
update delete $DOMAIN A
update add $DOMAIN 60 A $current
send
EOF
 logger -t dyndns -p daemon.notice "Updated dyndns: $registered -> $current"
} > /dev/null 2>&1

exit 0

It should be noted again that the private key (in /etc/nsupdate/Kh1.dyn.example.com.+010+04711.private in the example above) is not enough, nsupdate also needs the public key in the same directory as the private key.

For a project I'm using a text display containing the Hitachi HD44780 chip. These displays come in different sizes, common are 2 lines with 16 characters or 4 lines with 20 characters. The latter is also sold under the name 2004a. These displays use 5V. So these days with most CPUs and microcontrollers running with 3.3V or lower, the display is often connected to an I²C bus via a GPIO extender based on the PCF8574. The GPIO extenders are usually soldered to the display connector. You can buy the display and the GPIO extender separately or packaged together. You will always have to solder the GPIO extender to the display.

Now the correct way to connect the display to a 3.3V I²C-bus would be with a level-converter. But there is a hardware-hack to remove the pullup resistors on the PCF8574 breakout board (they're connected to +5V) which makes the device compatible with 3.3V installations: The minimum high logic level tolerated by the PCF8574 is given as 0.7 * VCC (which would mean 3.5V) but works in practice when driven with 3.3V. Note that the numbers of the resistors (R5/R6 in the hardware-hack link) may vary in different PCF8574 boards, I've seen R8, R9 for these resistors as well as no number at all. The resistors are 4.7 kΩ, usually labelled 472 in the SMD variant.

I investigated if there is a Linux driver for these displays and discovered one in drivers/auxdisplay/hd44780.c. On first glance the driver does not support I²C via the PCF8574 I/O expander. So I wrote a driver and submitted it to the kernel.

In the discussion (thanks, Geert) it turned out that there is a driver for the PCF8574 in the kernel (I had discovered so much) and that the HD44780 driver in the kernel can can be configured via appropriate device tree magic to use the I/O expander. The following device tree incantations define an overlay that configures the PCF8574 on its default I²C address 0x27 and then uses the I/O expander for configuring the I/Os for the hd44780 driver:

// Note that on most boards another fragment must enable the I2C-1 Bus

/dts-v1/;
/plugin/;

/ {
        fragment@0 {
                target = <&i2c1>;
                __overlay__ {
                        #address-cells = <1>;
                        #size-cells = <0>;

                        pcf8574: pcf8574@27 {
                                compatible = "nxp,pcf8574";
                                reg = <0x27>;
                                gpio-controller;
                                #gpio-cells = <2>;
                        };

                };
        };

        fragment@1 {
                target-path = "/";
                __overlay__ {
                        hd44780 {
                                compatible = "hit,hd44780";
                                display-height-chars = <2>;
                                display-width-chars  = <16>;
                                data-gpios = <&pcf8574 4 0>,
                                             <&pcf8574 5 0>,
                                             <&pcf8574 6 0>,
                                             <&pcf8574 7 0>;
                                enable-gpios = <&pcf8574 2 0>;
                                rs-gpios = <&pcf8574 0 0>;
                                rw-gpios = <&pcf8574 1 0>;
                                backlight-gpios = <&pcf8574 3 0>;
                        };
                };
        };
};

Since this is non-obvious not just to me (in my research I've discovered at least two out-of-tree Linux driver implementations of drivers for the HD44780 with the PCF8574 I/O expander) I've submitted a documentation patch to make this better documented for others searching a Linux driver.

Note that the driver for this display uses escape sequences to access the various special functions of the display (e.g. turning the backlight on and off, clearing the screen or defining user-defined character bitmaps). I think those are documented only in the source-code in drivers/auxdisplay/charlcd.c.