Martin – Page 4 – WirelessMoves

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.

UPS Battery Replacement for My Cloud

The electricity system in Germany is quite reliable but I always like a plan B. Thus, I run my cloud infrastructure behind a battery backup. As my two small NUC servers, a Fritzbox VDSL / Wi-Fi hub, a Raspberry Pi, an external hard drive and a cellular modem for backup connectivity have a relatively low power consumption of around 40 Watts, I can live with a relatively small uninterruptible power supply. 10 years ago I bought an ‘APC Back UPS ES 700‘ and could get around an hour’s worth of autonomy out of it for my setup. But batteries do not last forever, and 5 years have passed again since I last replaced the battery. When recently running a battery test, it reached 11.5 volts after only about 20 minutes. 11.5 volts is the voltage after which the battery starts to suffer when further discharged. That leaves 20% of the capacity unused, but I think it’s a good point to stop. As 20 minutes is a bit short, and the battery was definitely not getting any better, it was time to exchange it.

Analyzing Packet Loss in Starlink

As I’ve already noticed last year, there is quite a bit of packet loss over Starlink connections that has a significant impact on TCP performance. Also, I was wondering if and how much packet loss occurs in cellular networks during a handover. Recently, I picked up this topic again and was looking for a way to detect, measure and analyze packet loss. One idea I came up with was to run a continuous iperf3 UDP stream at a relatively slow 1 Mbps and see what would happen. While iperf is running, it shows when and how many packets were lost, but I wanted to dig a bit deeper. So I used Wireshark / tcpdump to record the data transfers and then wrote a Python script to analyze the iperf packet counters to get more details. Here’s a link to the source code.

Fritzbox Brain Transplant

I like redundancy, so I have ‘cold standby’ devices for critical hardware. My Fritzbox 7590 DSL router is one such piece of equipment (yes, still no Fiber in Cologne…) and I recently put it to good use: Incredible, but true, I’ve been using my current Fritzbox 7590 since 2018, i.e. for 6 years! Despite its age, it’s still an incredibly cool device and gets frequent software updates. However, the box seems to be aging, as it recently started to emit a low volume but high pitched coil whine. So while it was still working, the sound was getting a bit on my nerves. So I decided to swap the active 7590 with my spare device and was hoping that the promised ‘easy’ configuration backup / restore would save me a lot of manual work.