WirelessMoves – Page 4 – My Thoughts on the Evolution of Wireless, FOSS and the Past, Present and Future of Computing

Power and Fan Management With Ubuntu on Notebooks

When you look back a decade or so, one of the things that sometimes was a bit of a hassle when installing Linux on a notebook was to get fan control working correctly. And correctly means that the fan doesn’t run all the time, or on full speed for just a few seconds when the temperature rises, just to stop again and then repeating this every few seconds. Also, I noticed in the past that power control, which is a related topic, was sometimes not working well with older Linux kernels. As soon as the temperature started to rise, the CPU clock frequency went to the lowest possible setting and just remained there for a long time. In other words, the notebook would run fine, but was seriously lacking performance. Fortunately, this seems to be something of the past, and I didn’t have to tweak anything in that regard on the Lenovo and HP notebooks I installed Ubuntu on in the past two years. That being said, there are some interesting differences how power and heat management is handled on different notebooks with the same Ubuntu Linux (22.04), and I thought I’d document this here for my and your reference.

A Small Ubuntu in a Docker Container

Recently, I wanted to try out a few things around networking in a Docker container environment. What I wanted to have was a simple container I could open a Bash shell in. Turns out that it’s actually quite easy to do. As I wanted to play around with some options, I decided to use a docker-compose yaml file instead of instantiating the container from the command line. So here’s the docker-compose.yml content:

Ntfy and Keep-Alives…

To monitor my personal cloud and get instant notifications of events of various sorts on my smartphone, I’ve been using Gotify for many years. As it is based on TCP, keepalive packets have to be sent to keep NAT gateways happy. At the beginning, Gotify did so at a rate of 10 seconds. Far too much to be power efficient on cellular networks, the radio channel remained active all the time. Based on my feedback, the the keepalive timer was made configurable. With some trial and error, I then established that the NAT gateways between my server and my smartphone can easily cope with TCP keepalives of 7 to 8 minutes. So that is my setting for many years now, and things work very reliably and efficiently.

So far so good. For a recent project I also needed an instant notification solution. Gotify could not do the job for this project, however, because messages being pushed out should be delivered to many anonymous recipients that should only have read-access to the queue, i.e. they must not be able to send messages themselves. Gotify is a personal messaging server and all clients require a login and can not only read but also write to queues. So I started looking for something else and came across Ntfy, another great open source messaging solution. It is far more feature rich than Gotify, which is both good and bad. For my project, however, it does offer read-only anonymous queue access, so I’m strongly considering it as an option. It’s easy to set-up in a Docker container behind a reverse web-proxy and the documentation is outstanding!

So while I was happy at first, I soon noticed that the TCP keepalive time is set to 45 seconds. Due to timeouts and other things happening in cellular networks, this means that the radio connection is also pretty much active for most of the time while the Android app is running, it only goes idle (LTE RRC Release) for a few seconds, before the next paging comes in due to the next keepalive packet. Not ideal at all. The screenshot on the left shows what is happening on the LTE air interface.

While I was glad to see an option to configure the keepalive timer (keepalive-interval), the documentation notes that the app will only tolerate keepalive periods of up to 77 seconds.

# Note that the Android app has a hardcoded timeout at 77s, 
# so it should be less than that.
#
# keepalive-interval: "45s"

Perhaps better than nothing but still far away from where I would like it to be, i.e. 7 to 8 minutes. Not sure if a ticket with the project to ask them to offer settings to change this would have a chance of success, but perhaps I should do it anyway?

Wi-Fi Replacement – Lenovo E14 AMD Gen 5

In the previous post, I’ve been looking at how well Ubuntu 22.04 runs on a Lenovo E14 AMD Gen 5 notebook that was released in 2023. It turned out that apart from a low volume microphone, the only other thing that didn’t work well out of the box is the Realtek Wi-Fi chip. I was hoping that in 2024 the Realtek drivers had matured and connectivity would be stable. And indeed, at first everything looked fine. However, after a few hours I moved the notebook to a new location in the house and the Wi-Fi dropped a few minutes later. A coincidence? Probably not. And by dropping, it wasn’t only dropping the connection, the PCI card completely vanished from the bus. The issue is known on the net, so it is not a local hardware issue, and there are no fixes suggested. Also, I wasn’t really in the mood to go bug hunting. So, I thought, let’s swap the Wi-Fi card.

Review: Lenovo E14 AMD Gen 5 and Ubuntu 22.04

Recently I got myself a new ‘spare’ notebook from the entry range of the Lenovo Thinkpad series, a Lenovo E14 AMD Gen 5 for 600 euros (21JS-SOP500, production date 2024/05). Notebookcheck already reviewed the device about a year ago and there’s already the Gen 6 version of the E14 on the market. In other words, it’s not the latest model. While the price difference to the latest model is still around 150-200 euros, the specs look pretty similar. So I don’t think I’m missing much here. In previous years, buying a relatively new notebook and running Linux on it was always a bit of a gamble and sometimes required manual driver installation or replacement of a cheap and not very well supported Wi-Fi PCI card for something with better performance and Linux support. So how about this time around?

Spoiler: To my great pleasure, everything worked straight out of the box with Ubuntu 22.04 and a Linux 6.8 kernel. Even the low end Realtek Wi-Fi PCI card worked, at least at first… But there were two quirks I’m not quite happy about, so read on for the details.

The Virtualbox Wayland Freeze?

When I started upgrading my first Ubuntu 20.04 Virtualbox Virtual Machine to 22.04, I noticed that every now and then the graphical user interface just froze and I had to perform a forceful shutdown. Quite an annoying thing. At the time I played around a bit and noticed that switching to a non-recommended virtual graphics card fixed the issue. When I recently upgraded another virtual machine from 20.04 to 22.04 the same issue popped up again, but this time around, changing the graphics adapter did not help much. So what to do?

An Access Network Plateau Reached?

I’m on vacation at the moment and I’ve been thinking a bit about how network technology has evolved over the past few years and where we are headed. At least for the moment, it seems to be that we have reached an access network tech plateau, at least as far as infrastructure is concerned. Let me explain…

Ubuntu 24.04: Changing the SSH Port Now Requires a Reboot

And yet another thing that changed in recent years: When I instantiate a new VM, I usually change the SSH server port. I know, it doesn’t help when it comes to security, but it reduces the number of bots knocking on my door and leaving an entry in /var/log/auth.log. When I recently installed a new VM running Ubuntu 24.04, I noticed that changing the port number in ‘/etc/ssh/sshd_config‘ and then reloading ssh with ‘sudo service ssh restart‘ does not change the port number. A full reboot is required for the change to take effect. WHY???

Forcing SSH Password Authentication

A short post today about a subtle change of ssh that must have happened over the years. Previously, when I wanted to check if SSH password authentication was disabled on a server, I would remove my public key from the authorized_hosts file on the server and then use a second terminal to establish another SSH session to the server. This would then either result in a reject or a password prompt. When I recently tried this with a server on which password authentication was not yet disabled, I go a reject instead of the password prompt. Hm…

Macvtap is even Cooler than I Thought

Two years ago, I migrated a lot of my services running on virtual machines in the cloud to VMs on a bare metal server, which was also running in the cloud. The main reason: A significant cost reduction while at the same time having significantly more dedicated processing power and storage available. While I put most of those VMs behind a NAT and a single IP address, I had a BBB video conferencing server running in a VM that required it’s own IP address. Fortunately, my hoster could assign more than one IP address to a bare metal server. In the meantime, I have 3 VMs on that bare metal server that use their own public IP address.

For those VMs, I don’t use a NAT interface, but a macvtap interface. At the time, I thought that macvtap just maps a public IP address to a VM and that’s it. For the details have a look at my blog entry that describes the setup. However, it turned out that macvtap can do a bit more, which is particularly useful when a bare metal server hosts several VMs with their own public IP addresses. Read on for the details.