IT

Most people seem to use qemu together with libvirt. I saw two drawbacks for my limited use-case: a) on Gentoo, libvirt rakes in tons of dependencies when emerged, b) I would like to have a low-level understanding of how to configure qemu. So I went ahead and the result is this: Continue reading "Complex example for qemu" »

After a fresh install of Windows (and Steam, of course), Citites:Skylines would not start. In fact, it was the Paradox Launcher which wouldn't start. The internet was not really helpful. This Paradox Support Article outlines what you have to do to completely uninstall and reinstall the Paradox V2 Launcher. These steps can be found all over Steam and Reddit.

What the article omits, however, is one important pre-requisite to be able to run the launcher: The Microsoft VC++ Runtime in the x64 Version (on an x64 PC, at least). You can get it here. After installing the VC++ Runtime, the launcher started working for me. Have fun!

A long time ago I had set the supervisor password of my wifes Acer Aspire V Laptop and I couldn't remember it now, when I needed it. I was so grateful about https://www.biosbug.com, where you can calculate an interim password to get access to the BIOS settings menu using a recovery code shown after three unsuccessful login attempts.

What is not clearly documented there, however, is that you can use this interim password as the "current" supervisor password to permanently remove or re-set it.

According to this source, the FSC Celsius M740 with a D3348-A1x mainboard is supposed to have a so called "Teutates" BMC.

A driver is part of recent standard linux kernels (e.g. 6.6.47) in drivers/hwmon/ftsteutates.c.

The BMC is, however, not recognized by the lm-sensors package, at least not on my two M740's.

On my systems, it returns a value of 0x22 in FTS_DEVICE_REVISION_REG and 0 in the three registers FTS_DEVICE_DETECT_REG_{1,2,3}. It returns values for the fan, temperature and voltage sensors. The format differs from the format described in the aforementioned source. Some experimenting led to the following patch:
Continue reading "Reading sensor data on a Fujitsu Celsius M740..." »

I was compiling LineageOS on a server rented solely for this purpose on an hourly basis, so I could not be bothered to set up an additional user besides "root". The build hung at the very end, when assembling the compilation results into the zip-file. The "zip" process was following symlinks into /sys instead of just storing them.

Apparently, this is only a problem when executed by "root" and not by a non-priviliged user.

The following patch instructs zip to not follow the symlinks, but to just store them as-is:

diff --git a/tools/releasetools/non_ab_ota.py b/tools/releasetools/non_ab_ota.py
index 6cd01e401a..bbc5000f10 100644
--- a/tools/releasetools/non_ab_ota.py
+++ b/tools/releasetools/non_ab_ota.py
@@ -605,7 +605,7 @@ def GenerateNonAbOtaPackage(target_file, output_file, source_file=None):
tmpfile = common.MakeTempFile(suffix=".zip")
os.unlink(tmpfile)
common.RunAndCheckOutput(
- ["zip", tmpfile, "-r", ".", "-0"], cwd=target_file)
+ ["zip", tmpfile, "-y", "-r", ".", "-0"], cwd=target_file)
assert zipfile.is_zipfile(tmpfile)
target_file = tmpfile


I am using a very old Linksys router as a WLAN-AP and a switch for older 100 MBit devices. When I changed my network layout (due to swtiching rooms for my home office), this router was no longer connected directly to my Fritz!Box (Internet router) but via another switch (which is not IGMP V3 ready).

When I now watched TV on my PC (T-Entertain, using vlc) the multicast IP-TV-traffic went all over my switch, all ports, the Linksys router and was finally flooding the WLAN. I can perfectly live with the 10 Mbit or so IP-TV traffic flowing over my cable ethernet - for the WLAN, however I needed to find a solution.

[1] outlines two solutions, one via "unbridging" the WLAN and the other using ebtables to filter the multicast traffic. I did not like the former, because that meant that the Linksys router would need to take over DHCP tasks for the unbridged WLAN segment (DHCP needs broadcasts).

The latter variant turned out not to work, because the ebt_pkttype kernel module is not included in any stable release of dd-wrt for this old router. I have no idea why, and [2] has a lengthy discussion about possible workarounds, but this was a show-stopper for this variant as well.

But why do they use the pkttype plugin? One can specify source and destination MAC addresses using just the ebtables and ebtable_filter modules (which are available on my router) and there are even broadcast and multicast aliases for this command, see the man page at [3].

Admittedly, the way these aliases are defined, the multicast alias does also match broadcast packets, which is not what we desire (see above). Nothing prevents us, however, from using a hand-crafted multicast filter which just filters out the IPTV packets. This turns out to be 01:00:5e:00:00:00/01:00:5e:00:00:00. For further information refer to [4].

The only necessary configuration change is thus to insert the following commands into the startup commands at Administration->Commands:

insmod ebtables
insmod ebtable_filter
ebtables -A FORWARD -o eth1 -p IPv4 -d 01:00:5e:00:00:00/01:00:5e:00:00:00 -j DROP

Note that this does only filter on the eth1 interface (WLAN, see [5]) and the multicast packets are not filtered on the cable-based ports 1-4, but this is perfectly fine for me.