But, really, what is this idiocy with hardware vendors injecting ads into the system? Qualcomm has 37 packages on the system, according to a pm list packages | grep qualcomm. I'm not inclined to trust them very much, but unfortunately there's little to no documentation on this kind of vendor crap on Android.

I took the opportunity to disable another obvious one, ''com.qualcomm.qti.haven.telemetry.service".

Last night, my 2.4GHz FRITZ!WLAN Repeater 310 upgraded to the new FritzOS release 7.01. The repeater is configured as FRITZ Mesh device (connected to a FRITZ!Box 7490 as mesh master). I'm currently tinkering with a Blackberry Key2 LE that I bought to replace the aging S4 mini that I used up to now (more on that later, maybe). After upgrading the repeater, the Key2 LE couldn't connect to the wifi network anymore. In an area only covered by the repeater, it didn't even see the SSID anymore. It was still possible to connect directly to the base station though, when moving into range. All the other devices I had available had no problems connecting through the repeater either.

As AVM doesn't currently provide downgrade images for the Repeater 310, I tried a factory reset and re-establishing the mesh connection, to no avail.

I then started playing with wifi network settings, and as it turns out, there's a simple fix: Don't use channel 13 on the repeater.

After excluding channels 12 and 13 from the wifi channel selection on the FRITZ!Box, the system switched down to channel 11, and suddenly the network appeard back in view on the Blackberry device. Also tried manually setting channel 6, which worked too.

Not sure what to make of that. Channel 13 was fine with this device before the FritzOS upgrade (yes, I know using it is not recommended, but this is the first time that created a problem for me).

I was not aware that RFC6762(cache) reserves the ".local" TLD for exclusive use for Link-Local addresses with Multicast DNS:

RFC6762 wrote:

This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate.

The punchline is that the AES key is just MD5(password || IV:8). .. MD5 is very cheap to compute. The only thing this design has going for it is that the salt goes after the password, so you can’t just compute the intermediate state of MD5(IV8:) and try passwords from there. That’s faint praise, especially in a world where I can rent a machine that tries billions of MD5 calls per second.

Ssh keypairs for Ed25519 use a new format to encrypt the passphrase. Since 2013, it's been possible to create RSA keys with new-format passphrase encryption using ssh_keygen -o, but since that's not been the default, I don't assume anyone has ever used that (I haven't).

Might be worth replacing all RSA keypairs for pubkey authentication (and remove the corresponding public key from any authorized_keys files on all destination systems) - and all Ed25519 keys that use the same passphrase. Unless you're absolutely certain no one ever had access to the private key, in which case just upgrading the passphrase encryption using ssh-keygen -p -o -f <PRIVATEKEY> might be good enough.

I've been pulling in some posts from my Mastodon instance to the blog, using iframes to directly show the embed view provided my Mastodon.

There's two problems with that:

One is, that someone who is using a content blocker like uBlock Origin or uMatrix likely won't see anything in these posts when they're blocking third party content by default. The other is - what happens when my Mastodon instance is down?

So I've now added direct links to each of the embedded posts, serving a dual purpose: There's first party content (the link), and also the Tiki engine creates a cache entry that can be accessed when the Mastodon server is unreachable.

I've also tagged all affected posts as mastodon embed, so I can easily find them and replace the content should I ever plan to shut down my Mastodon system.

First is that the mobile hotspot function (sharing a cellular data connection to other devices via Wifi) has been gimped, and trying to activate it just results in an "To share your connection, you need to add this feature to your cellular data plan first." - message:

Information around this is very scarce at this time - just a handful of search engine hits. From a post on the italian Microsoft forums, it seems you now need a Store app published by your mobile phone provider to use this feature. WTF, really? I've been tinkering for quite some time to find out where Windows looks up if using the hotspot is allowed or not, to no avail. Also see over here on Mastodon.

The other problem is that powersaving for the first gen switchable graphics in my old notebook doesn't seem to work anymore. In previous versions of W10, the integrated Intel graphics would be used on battery, using a lot less power than the AMD graphics chip.

As for minor niggles, it's not possible anymore to unconditionally set a network connection as "metered" to restrict Windows updates and background data - you'll have to set a daily or monthly data limit for the network, and then tell the system to always restrict background data (instead of within 10% of reaching the limit).

It really seems that W10 1709 was the sweet spot for this old notebook, but after I didn't see any immediate problems with the new version in the week directly after upgrading, I already deleted to rollback version...

Today I learned(cache) that USRobotics(cache) still exists (as a division of another company), and they still make a version of the classic Courier 56k modem(cache). Not that I need one of those. But I'm surprised it's still possible to buy them (and they look just the same as 20 years ago).

I'm converting them using the all-singing all-dancing image-and-video resizer that I wrote, resize.pl, which uses ImageMagick to extract each frame as a PNG then constructs an incredibly hairy ffmpeg command to put it all back together with the proper frame timing.

I'm still using the same Acer Aspire 3820G laptop that I bought over six years ago, though I've switched to Windows 10 during the "free upgrade" time. Mostly everything works, despite missing vendor drivers. The function keys (sleep, sound volume, etc.) have basic support, but I recently noticed that the wireless switch only toggles through a handful of states, none of which have both Wifi and Cellular modem enabled.

After some experimentation it turns out that just starting the Launch Manager Setup.exe in compatibility mode for Windows 7 (right-click, select "Troubleshoot compatibility") surprisingly does the trick - installer completes, and after a reboot the wireless function key actually starts Launch Manager instead of driving the Win10 builtin toggle.

...so now I can use the Cellular modem and provide a Wifi hotspot at the same time.

Ever since upgrading to OpenBSD 6.1 (and newer ports of everything), the web server seems to run out of file descriptors after some time, even though I have moved some of the older PHP applications over to a web hosting service.

Somehow I managed to lose the p5-Time-TimeDate package on the OpenBSD web server, which in turn made vlogger fail to start up, and that resulted in all kinds of followup problems for the web service.

Unfortunately I have no memory of removing the package, so I'm not quite sure what happened there (but the date matches a day where I started moving some web sites off this server, so maybe I did some misguided cleanup)...

To find out more, we turn to ktrace’s little cousin, ltrace. It works almost exactly like ktrace (the output is even viewed with kdump), but it traces ld.so, the dynamic linker, instead of system calls.

Not yet sure if I'll move posting from this blog over there - probably I'll want to push posts from here into my Mastodon timeline instead. Since I'm running my own instance, it's the first service I'm relative comfortable to use via an app on my phone, so it's possible that I use the Mastodon account some more in the near future.

I'm generally sympathetic towards PaX and grsecurity developers, who have been developing innovative mitigations against several classes of attacks on the Linux kernel and applications over a long time - and I've personally been using their work on my own machines for ages. But really, communication is not their thing. Ok, they're in excellent company in the open source world with that, but it really harms their cause.

PaX Team wrote:

Upstream's goal is protecting as many people as possible.

the KSPP's goal is to further the agenda of the companies behind
it (which is extracting profits for shareholders). that has nothing
to do with "protecting as many people as possible" but everything
to do with business goals du jour. if what you claim was true,
they would have done it since the beginning and in a way that is
not restricted to only linux users.

(KSPP = Kernel Self Protection Project, sponsored by Google and the Linux Foundation, which tries to upstream select parts of the grsecurity patches into mainline Linux.)

Not sure if a microblogging service like Mastodon is what I'm actually looking for (I've never really warmed up to Twitter either), but it seems at least worth looking at. Or maybe I should have another go at running my own Diaspora pod (though I didn't use the last one I set up a whole lot).

I've not yet found a whole lot of interesting people, and the TrendingBot isn't much of a help, seeing as the most stable trending thing is #nsfw - I guess the porn sharing crowd is one of the early adopters again, unfortunately.