Hacker's ramblings

With this Nightcafe-created image of Santa Claus' "cloud service" I'd like to wish you all Merry Christmas!

It seems AI took the cloud-part very literally. Totally understandable. How would one draw such an abstract concept.

Last weekend, I had the chance of visiting Superfest 2024. It's an eSports event organized by Supercell. Championship of three games were played:

1. Clash of Clans World Championship Finals
2. Clash Royale Leagure World Finals
3. Brawl Stars World Finals

When entering the event, lounge:

Sunday finals schedule poster:

Saturday game of Clash of Clans. STMN players Darkstar, Fluxxy, Ninj, Synthé and VAD Hawk playing against Millesime MG players KingsMan, Natchoa, Teemper, TryHard and Max:

Sunday game of Clash Royale from lounge, two players from SKCalalas Sub vs Ryley. Ryley became 2nd:

Brawl Stars champions HMBLE players Symantec, BosS and Lukii after their victory:

Well organized event. I wish I would have understood the games bit better. Those games are pretty unknown to me.
Still: GG!

As scheduled to end of October 2024: Announcing Fedora 41 from Red Hat.

Such distro has mechanism to do in-place upgrade: Upgrading Fedora Linux Using DNF System Plugin. It is based on DNF System Upgrade.

Priciple is to run dnf system-upgrade download --releasever=41, tap Yes couple times and then dnf system-upgrade reboot. It works (mostly) and I have used such in-place upgrade many times on a VM running in Hetzner.

If you haven't read between the lines yet, let's state the obvious: I'm posting this in a scenario where everyhing didn't go as planned.

Imagine a virtual machine running in a data center far far away. There is interaction via SSH or if needed, a browser-based console can be used for dire needs. A failed update was indeed such.

41 Upgrade Begins - And Fails

Simultaneously with dnf system-upgrade reboot, I start sending ICMP echo requests to my VM to see the point in time when it begins pinging me back. This is a clear indication of upgrade being finished. I waited roughly 20 minutes without a response. Such a long time is an obvious indicator of a problem. Subsequently I logged in Hetzner's portal to pop open a console. Console showed me an upgraded system in the middle of a reboot-cycle. Stuck doing nothing.

That being unexpected, I chose to go for a Ctrl-Alt-Del. My wish came trough, a request to reboot nicely recycled the stuck system and a login-prompt greeted me on the console. Still, ping didn't. On the console, the only single keyboard layout made available is hard-coded ANSI US. On hardware, all my keyboards have layout ISO Finnish. That makes those elusive often used characters like dash (-), slash (/), pipe (|) or colon (:) be in very very different places slowing the entire process.

On the Console - Missing Package

Poking around the system on console indicated an upgraded VM. Everything else on the system was nice & peachy besides networking. There was no IP-addresses assigned. Actually entire NetworkManager was missing from the system. It did not exist. At all! Also every single bit of configuration at /etc/NetworkManager/ was absent.

Transferrring the muich-needed RPM-package NetworkManager-1.50.0-1.fc41 by eyeballing a rather dumb virtual console is fruitless. A quick analysis of the thing ended with a harsh one: it doesn't support any sensible means of transmitting files. Receiving any sent data with copy/paste or any other low-level means was absent. Something else was needed.

The Fix - Scraping

I opted to fix the network by hand. ip-command was installed in the system and it worked perfectly. That's all I needed. Or, almost all.

In my infinite wisdom, I didn't have any of the IP-details at hand. I reasoned to myself the system upgrade having worked flawlessly multiple times before this. I didn't NEED to save IPv4 or IPv6 -addresses, their routing setup or DNS-resolvers. I knew from tinkering with these boxes that on x86-64 architecture Hetzner VMs  all those details are static, manually set to Hetzner-assigned values. Their modern setup on Arm v8 does utilize DHCP for IPv4. My box was on a traditional rack and I couldn't count on automation to assist on this one.

Scraping all the bits and pieces of information was surprisingly easy. My own DNS-records helped. After the fact, I realized a shortcoming, if I would have looked at the bottom of the web-console, those IP-addresses would have been shown there. At the time I didn't. Routing defaults can be found from documentation such as Static IP configuration.

Now I knew what to set for the values.

The Fix - Manual Labor

Now the "fun" begun. I need to setup IPv4 address complete with routing to restore functionality of dnf-command. This would make it possible to install NetworkManager to get nmcli-command back.

Sequence is as follows:

ip addr add 192.0.2.1/32 dev eth0
ip route add 172.31.1.1 dev eth0 src 192.0.2.1
ip route add default via 173.31.1.1 src 192.0.2.1

Btw. see RFC5737 for IPv4-addresses and RFC3849 for IPv6-addresses reserved for documentation. I'm not going to post my box's coordinates here.

Fedora DNS-setup is via systemd-resolved, checking file /etc/systemd/resolved.conf. File had survived the update intact. It still had the content of:

DNS=185.12.64.1 185.12.64.2 2a01:4ff:ff00::add:1

A perfect & valid solution.

The Fix - Managing Network

Ta-daaa! Ping worked. dnf worked! Everything worked! The joy!

At this point running dnf install NetworkManager wasn't much. Trying to figure out what was wrong proved to be a headache.

On initial glance nmcli conn show:

NAME  UUID                                  TYPE      DEVICE
eth0  12345678-1234-1234-1234-123456789abc  ethernet  --

What!? Why isn't my eth0-connection associated with a device! No amount of attempts, tinkering, cursing nor yelling helped. I could not associate a device with the connection. My only option was to drop the hammer on the thing: nmcli conn del eth0

Now my eth0 didn't work as it didn't exist. A delete made sure of it. Next, getting it back:

nmcli conn add type ethernet ifname eth0 con-name eth0 ipv4.method manual ipv4.addr 192.0.2.1
nmcli conn modify eth0 ipv4.gateway 172.31.1.1
nmcli conn modify eth0 ipv6.addr 2001:db8::1/64
nmcli conn modify eth0 ipv6.gateway fe80::1

Final twist was to make those changes effective: nmcli device reapply eth0

IPv6 begun operating, IPv4 was unchanged. Everything was where it should have been after the upgrade.
That was it for NetworkManager, moving on.

Outcome

The only true measure of a possible success is a system reboot. If my tinkering survived a normal cycle, then all was good. Nothing special to report on that. Everything stuck and survived a rinse-cycle. File eth0.nmconnection stored NetworkManager configs as expected.

Why this thing exploded remains unknown. Missing any critical pieces of a system is always a disaster. Surviving this one with very little damage was lucky. I may need to increase my odds and re-image the VM. My guess is, this box survives only so-and-so many upgrades. I may have used all of the lives it has.

My employer opted to host a meetup. As they needed somebody to give a presentation there, obviously, I stepped up.

Thanks for all the participants!

For those interested, my presentation on Microsoft Fabric Real-Time Intelligence.

On 26th of September, PostgreSQL Global Development Group announced the release of version 17.

Here is an easy one: Can you guess at which point I made the upgrade?

The slope is a maintenance break. Datadog wasn't measuring HTTP-performance while I was tinkering to make the actual upgrade.

What worries me is the performance being itsy-bitsy worse with version 17. Graph is smooth as silk. However, crunching the numbers to smooth the zig-zag, 16 seems to have better performance on average. Difference isn't big, but it is there. Maybe I'm missing a new setting to improve cache performance or something?

It took "couple" iterations on Apple to realize they'll must add a password manager to their mobile operating system.

Next Monday, iOS 18 will be released with one. It's called "Passwords":

As I already have a password manager, this isn't a big deal. However, this new password-thingie extends functionality beyond passwords and has something The World has never seen: Possibility to edit Passkeys. (Anti-climatic, huh!)

Taking a closer look, this is what the password-app contains:

Further dill-down on (the never-seen-before) Passkeys:

See how many dupes I have for https://webauthn.io/!
Three years back, I wrote a piece about Passkeys and it required a lot of research, testing and snooping around. Toying around throw-away Passkeys resulted in lot of junk, it seems.

While muttering "my precious", Yubico declared all information on existing passkeys a state secret. After the first one's example all other major Passkeys-providers like Appe and Google followed suit. They hid Passkeys well out of your reach.
I really never got the logic behind that. Why is it not allowed to see your own passkeys? Maybe if your security device is lost, also the criminals can see the list of your passkeys? Puzzling.

Finally I can get rid of all test junk. It took unbelievebly long to get this feature. However, I love the fact it is there.

My previous post was about 10+ year old laptops. At that time Broadcom ruled the chipset Wifi chipset market.

Since those days balance has shifted. Today, most common chipset for Wifi is Realtek. I also have couple Mediatek Wi-Fi chips working perfectly with Linux.  To repeat what I said previously: These guys have their Linux support via open-source drivers. Broadcom doesn't. Hm. I dunno, maybe that's what made them decline and the other guy thrive? Most certainly, I wish it was their open-source support. 😁

So, my old laptop lost wireless connecitivy and I needed SOMETHING, to get the thing going to The Internet. I happened to have a brand new USB-stick on a test drive. As there aren't many Linux-supported chipsets, most USB-sticks won't work with 802.11ax / Wi-Fi 6 and you have to settle for slower speeds combined with less security. This product is supposed to beat compeition on that.

Spoiler: I doesn't! (yet)

The product is BrosTrend AX1. The speed rating is AX1800 and it's supposed to be WiFi 6 Linux Compatible WiFi Adapter:

lsusb information:

Bus 001 Device 013: ID 0bda:b832 Realtek Semiconductor Corp. 802.11ac WLAN Adapter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0xb832 802.11ac WLAN Adapter
  bcdDevice            0.00
  iManufacturer           1 Realtek
  iProduct                2 802.11ac WLAN Adapter

Btw. See how USB-idenfication is for 802.11ac. Confusing, that.

At this point, there is no pre-baked Linux kernel module. You can build one in a jiffy. Source code is at https://github.com/morrownr/rtl8852bu. Getting that C-code to work in your favor, after git clone, you need to run ./install-driver.sh. This script does a lot for you. At end, the script even stealthily copies the kernel module into proper directory to make loading the driver very easy. This is confusing and not all module builds do the install without asking.

When I modprobe 8852bu on Fedora 40, module does little bit of whining, but comes up. For the crash I sent some information to author: https://github.com/morrownr/rtl8852bu/issues/38

On my laptop, connection to 802.11ac / Wi-Fi 5 works ok. I suspect, there is something off with WPA3 as connections to 802.11ax / Wi-Fi 6 simply keep asking for network password in a forever loop. But hey! It worked. I got to The Net and was able to fix things. The thought of 802.11ax support is left unanswered. If USB-information doesn't state 802.11ax either, does the stick really support it or not? I dunno.

I'm hoping, WPA3-issue would be fixed one day, so that I'd be able to join any network of my choosing, not the one the device is capable of going.

Is that combo really impossible?

I've been running Linux in multiple old/oldish laptops. Broadcom is such a popular chip vendor, it is the most typical choice regardless of the laptop manufacturer. As Broadcom is full of idiots, their device drivers are proprietary. In their infinte wisdom, they pre-build Linux binaries and hand them out. This, obviously, is much better than not having the closed-source driver package at all. However, they really don't care. Every once in a while something happens in Linux kernel and their driver becomes less-than-operational.

Also, by lack of one official source, there are number of packages made out of the binary distribution. Key naming convention will include letters W and L in them, so you as an end user have to know wl stands for Broadcom BCM4311, BCM4312, BCM4313, BCM4321, BCM4322, BCM43224, BCM43225, BCM43227, BCM43228, BCM43142, BCM4331, BCM4352, BCM4360 devices. Simple! (No, not simple)
As an example: Fedora doesn't support Broadcom at all (as default), Arch Linux has packages brcm80211, b43 and broadcom-wl, Debian has  broadcom-wl as non-free package.

Recently my Fedora 40 refused to find a working Wifi. It all started on from 6.9.10 up to 6.10.5. Oh, I forgot to mention, altough Fedora doesn't have the support, there exist number of alternative RPM-repos for Fedora carrying Broadcom. An example, RPM Fusion., non-free package of broadcom-wl. To make this mess even messier, RPM Fusion also has kmod-wl and akmod-wl.

Ok, many packages, back to the problem: my laptop lost Wifi and I really struggled to figure out why, which kernel module caused the problem and for what reason. At the time both broadcom-wl and kmod-wl were installed.

This is VERY confusing! You have to be super-smart to understand much of my less-than-coherent story above. Unfortunately, that is the reality. Everything gets convoluted, confusing and chaos.

In RPM Fusion Bugzilla, there is a bug #6991 Kernel hangs due to broadcom wifi driver. This bug report is specifically for akmod-wl, which was not installed in my laptop. Using an USB-dongle, uninstalling both broadcom-wl and kmod-wl, followed by installing akmod-wl did not solve the problem either. Unlike with original packages, with akmod-wl there was no kernel crash on modprobe. With this package NetworkManager didn't work either. Weird.

When I wrote comments to bug report and Mr. Vieville, author of akmod-wl, replied with a suggestion. There existed an unreleased version of 6.30.223.271-53. Little bit of dnf installing and testing ... it works! Now my laptop had native Wifi-connectivity and I could un-plug the USB-dongle.

This incident left me really confused and happy.

I love gaming. I've played all kinds of video games nearly my entire life.

Recently, I've been playing Gray Zone Warfare.

After 200+ hours, final mission is finally completed!

The last mission is brutal. The mission is to go to three worst possible places, locate and bring back mission items in each. To make things even more difficult, you don't simply sneak in/out, there is a minimum kill count that has to be completed at the worst possible locations. Brutal!

This immensly difficult and realistic game is a Escape from Tarkov -clone. In this game there are three factions of PMC and the idea is not to "escape". Your faction's home base is safe, base cannot be raided by other players. According to game studio, the idea is geared towards co-op, leave base to complete a mission -style rather than  player vs. player. Both game modes exist. You absolutely can play a lone wolf game too, but given the punishing nature of this game where a single shot by enemy can kill you on the spot, having more eyes to spot enemies and more firepower to kill enemies makes avoiding death so much easier.

One last noteworthy thing is: There's going to be ~6 month cycle in the game. Everything will be wiped clean. All players are back to level 1 with not much gear in their lockers. At the time of writing, first (public) wipe is about to happen soon. That way those experienced players who have been playing this early-access game as it was made publicly available @ Steam won't necessarily benefit against newer players.

I cannot wait for the next version! We'll get day/night cycle and more missions and ... oh yes!

Few years ago I got interested in hieroglyphs ... erhm. SD-card markings. My piece about them is here.

Now that we have established the fact that I have too many SD-cards, where do I store them? Well. I didn't. They where around equipment, desk and shelves all around the clutter. There was a point in time, I decided to do something about it.

This is my recent storage solution:

This type of case isn't available easily. It took me a while to hunt down such an item from a Chinese on-line shop. I wanted one with enough capacity for the future. Also, I wanted one that won't break or get lost easily.

This one meets the spec. Also, I went further and pimped it with appropriate labels:

There is a tiny piece of paper to translate the numbers into real-life meanings. It's simply omitted from the pic.

Now I know where my RasPi OS-images and photos are. No need to go finding the cards anymore!

Remember this one?

My new utility meter has an RJ-12 in the bottom of the unit. Naming of this port is really weird as it is called HAN, P1, HAN/P1 or P1/HAN. In Norway the port is RJ-45 and they call it HAN, for Home Area Network.Original RJ-12 from Netherlands was called P1, which is short for ... P1? I dunno! Just to be safe, manufacturers combine those two. In reality they just add to confusion.

Assuming, one wanted to see in detail how much energy is created by solar panels on the roof and combine that information with data from electricity utility meter, it would be possible to see how much money is being saved with the panels. Having detailed information on how regular household utilized electricity is a nice side effect of that.

Now that we're in Finland (not Norway, not Nethernalds), the regulation is from SESKO and in section 4.6 Physical Interface is as follows:

The RJ12 connector (6P6C connector) is used as the physical interface and the interface meets the requirements of "P1 Companion Standard".

Further, the mentioned document is from Netherlands and describes the physical interface:

Now two things need to happen:

1. Utility company needs to enable the P1/HAN -port. The port is disabled by default. Utility company needs to pay license money for each open port to Landis+Gyr.
2. Data pouring from the port needs to be read with a suitable piece of hardware. Protocol is M-Bus, a TTL signal.

Given Internet has tons of possibilities, a suitable open-source reader exists: P1IB. All the necessary data is freely available at https://github.com/remne/p1ib. Software, hardware and 3D-printer models for the case. Obviously, there is an option to go buy one pre-built.

After tinkering with hardware, enabling a MQTT data-pump on both solar panels and utility meter. Setting up a MQTT-broker to receive the published data and a Home Assistant software to have a cherry on top. Final result looks like this:

In Energy-section of Home Assistant, there are number of data visualizations. Top-left bar diagram indicates how much electricity is being consumed by the household. Blue is electricity purhcase from grid with money. Yellow is electricity produced by solar panels. Bottom side, purple, is electricity sold to utility company's grid from solar panels.

Bracket with time 12:00 has hours 11, 12 and 13 in it. As an example, during hour 12 house consumed 0.8 kWh of electricity. Of that 0.61 kWh was solar power (yay! free!) and 0.18 kWh was purchased from utility company (uff! €). However, during that hour solar production was 1,74 kWh, of which 1,13 kWh was returned back to grid. Funny how averages work, there must have been clouds or spike in consumption for the need to purchase more. On the other hand, there were plenty of times where excess energy was available. In theory, I'll get some money out of that excess. Practically: I don't. Transfer in and out costs money to me and all my potential proceeds go to transfer.

Looking at other parts of the visualizations: Obviously, the good thing is I do consume 50% of my own production, making it 42% of all my consumption. What happened after taking the screenshot was the obvious sunset. My solar panels are unable to produce anything, so all my consumed electricyt was from the grid. As a daily record, after sunset hours did increase daily net consumption by couple kWh.

Next up: Now that we know what electricity costs and the rate it flows in and out, it is easy to apply money on top of all this. It should be possible to estimate correctness of initial payback time of solar panel investment.

DLMS/COSEM or Device Language Message Specification / Companion Specification for Energy Metering is something IEC 62056 set of standards define. The use case is to enable a consumer to access readings of a smart meter. Technology is robust, it was introduced in Netherlands nearly 30 years ago. Accessing data is also very straightforward, DLMS.dev has instructions for this.

Port and magnet-attaching reader look like these:

Simple & robust. Then there is the but -part. (there always is one)

My electricity meter (let's state the obvious: provided by my utility company) looks like this:

Unit is a Landis+Gyr E450 and it has the port ... aaand the port doesn't work. In my books "work" would indicate some sort of data flow. To sort this out, I contacted tech support with questions. The reply I got was astonishing! DLMS is disabled for all units because of expensive license fee. The greedy bastards at Landis+Gyr want more money for (EU) 2019/944 given consumer rights. As the price is steep, my provider chose not to comply, which translates into no data for me.

Given EU laws and regulations, the story does not end there. In their infinite wisdom, L+G license fee for HAN P1 interface makes commercial sense, so:

Now I'm running a Landis+Gyr E360.

Obviously, the HAN P1 doesn't work yet. It needs to be enabled from network control. For the mentioned license fee. I'll get back to this when I have any data.

Last month I bumped into an incompatible DisplayPort -cable. There are many different speeds and DP 2.0 requires so much more on your cable to achieve those speeds 4K, 5K and 8K monitors require.

A famous phrase states "Go big or go home!" So I did that. Went big:

These two cables with 8K and 10K spec should have the oompf required to run any of my future monitors.

Color-coding is puzzling to me:

No matter how much I do looking & searching, there isn't anything I can find on those colors. My obvious assumption is for the manufacturer Deltaco to mark 8K with a red connector and 10K with a blue. Exactly what cable speed that translates into, I dunno. My speculation is with UHBR13.5 and UHBR20, but that's only my guess.

In my previous post on the topic I did complain on lacking markings. The boxes have semi-reasonable markings, cables have none. Besides the undocumented color coding.

I you'd compare USB-A -connectors:

Or USB4-connectors:

Both have well documented system. DisplayPort, not so much.

According to this, not.
(Ref.: What does the public in six countries think of generative AI in news? survey)

AI is still in its infancy. Those who lived the IT-bubble of 2000 can relate.

British newspaper Daily Mail wrote in its December 5th 2000 issue about Internet. At that point, it was obvious: Internet wasn't a passing fad. Publishing that article back in -95 might have been sane. Just before the bubble was about to burst, not so much.

Let's dig up more examples. When we're faced with technology leap, our reactions can be surprising.

On hindsight (that's always 20/20), it would have made sense to see the vastly improved user experience on communications. Spoken word versus written word isn't a fair fight. Spoken word wins when communication target is time-sensitive and message is brief. Today, most of use don't use our pocket computers for phoning, we use them for writing and reading messages.

How about transportation?

If I had asked people what they wanted, they would have said faster horses.

A phrase Henry Ford did not say. There is a Harvard Business Review story about this.

Not that the line makes sense in any case.
Because “faster” wasn’t the selling point of cars over horses.
Speed wasn’t the problem.
Spending huge amounts of money, time, and space on keeping horses alive and dealing with the literal horse shit was the problem.

So, yes. We will use AI. We are already using AI. It's just like with Internet, telephone or cars. We're learning how to use them. Gartner seems to place generative AI on top of their Hype Cycle for Emerging Technologies 2023:

That translates into falling flat with most ridiculous use-cases of AI and sane ones remaining. Before that happens I'll keep using AI, chuckling when it makes a silly mistake and nodding in acceptance when it speeds up my task-at-hand.

I spend lot of time doing stuff with a computer or computers to be exact. As a heavy-duty user, I love to have good displays to do the computing with. As every thing in consumer electronics, also monitor technology has improved a lot.

One of these days, I wanted a new monitor with really good spec.
Delivery guy brought me one, I installed it into my VESA monitor arm and then everything turned sour.

My expensive monitor "kinda" worked. Picture was there, it was crisp, backlight was really good, HDR-colors were really vivid until the monitor chose to flicker a bit and black out. This unfortunate blackout was a totally random event. It could occur three times per minute, or alternatively there could easily be 20 minutes without problems. Such random problems are very difficult to troubleshoot. In any easy case, reproducability is the key. No such joy here.

When in doubt - Google the problem!

Obviously, I went online with a description of the symptoms. Quite soon, this is what I found from Reddit: I'm having screen flickering/blackout via Displayport on my new 1440p 144 hz monitor. The suggestions pointed towards testing different cables and discussion about DisplayPort versions. Good ideas!

GPU

From GPU spec:

Confirmed GPU DisplayPort to be at version 1.4.

Previous Monitor

Spec says:

Confirmed old monitor DisplayPort to be at version 1.2. Hm. Everything worked at 4K resolution, no 144Hz though.

New Monitor

Spec:

Confirmed monitor DisplayPort to be at version 1.4. Equal to GPU.

Maybe the problem IS with the cable as suggested in Reddit!

Theory: DisplayPort Cable

Doing research on DisplayPort: DisplayPort 1.4 vs. 1.2: What's the Difference?

DisplayPort 1.2, originally released in 2010, offers more bandwidth than all but the latest HDMI standards.
DisplayPort 1.4 is a much more capable standard, with limited competition from even the latest and greatest

DisplayPort 1.4 supports resolutions of up to 8K at 60Hz or 4K at 240Hz
DisplayPort 1.2 supports resolutions of up to 4K at 60Hz

Doing research on cabling: How to Tell the Difference Between Display Port 1.2 and 1.4 Cables

Just to be clear, DisplayPort cables are not classified by version, they are classified by the amount of bandwidth they can handle.

Good thing there was a DisplayPort cable with the monitor. Changed it into use and oh yes! Flickering was gone.

Wikipedia says in DisplayPort -article:

There are seven (7) different specs for a cable. Well, that's a surprise.

Practice: DisplayPort Cable

Let's look at those cables bit closer. This is the non-functioning one:

There are zero clues on cable spec. Nothing! It has WEEE label and CE marking, that's all. Given reality, I'm guessing it is HBR / HBR2 -spec.

This is the good cable:

Still no idea of cable details. DisplayPort-logo with 8K suggests spec to be at least HBR3.

Reality Check

There is really no way of telling how fast a DisplayPort-cable is by hooking it into a computer or eyeballing it.

Beware: Most DisplayPort cables aren't sold with correct information
Aow come on! This is horrible.

Good thing is my money wasn't wasted on a faulty unit.