Persistent WiFi failure on Ubuntu 24.04

Recent updates to Ubuntu 24.04 led me to regular lose my wifi connection. There was no pattern to time of day, machine workload, or anything like that - it was seemingly completely at random. The wifi connection would vanish, and even after restarting it, my previous wifi network would no longer appear, and no other networks could be joined. This typically took a hard reboot to resolve. As ever with Ubuntu, there are about 3,928 possible solutions to any given problem. Here's the path which ultimately worked for me!

Restart NetworkManager

sudo systemctl restart NetworkManager

Maybe 1 in 10 times, this would resolve the issue. It's worth trying, but it's not a reliable fix, so we go deeper into the root cause

The logs for the Network Manager can be found by calling journalctl -u NetworkManager.

Sep 18 20:10:59 NetworkManager[1584]: device (wlp5s0): state change: activated -> unmanaged (reason 'removed', sys-iface-state: 'removed')
Sep 18 20:10:59 NetworkManager[1584]: radio killswitch /sys/devices/.../rfkill0 disappeared
Sep 18 20:11:00 NetworkManager[1584]: rfkill1: found Wi-Fi radio killswitch (driver brcmfmac)
Sep 18 20:10:59 NetworkManager[1584]: dhcp4 (wlp5s0): canceled DHCP transaction
Sep 18 20:11:20 NetworkManager[1584]: supplicant interface state: associating -> disconnected
Sep 18 20:11:26 systemd[1]: Stopping NetworkManager.service - Network Manager...

This group of messages shows that:

  • Network device unmanaged: First the Wi-Fi device is becoming unmanaged, likely indicating a disruption.
  • Radio Kill Switch Disappeared: The Wi-Fi adapter seems to be impacted by the rfkill radio kill switch. This implies possible interference from power management or hardware controls.
  • Wi-Fi Radio Kill Switch Detected: The system then detects the Wi-Fi radio kill switch, possibly being toggled by hardware or power management.
  • DHCP Transaction Canceled: The DHCP process is cancelled abruptly, which suggests a problem with the network configuration or the state of the interface.
  • Supplicant Interface States: These logs show repeated attempts to connect to the Wi-Fi, followed by disconnections, showing the instability of the connection process.
  • Stopping NetworkManager: The NetworkManager is shutting down via a system signal.

We know that the network device has become unmanaged, so next we check what exactly rfkill is doing.

Radio Kill Switch

First, check if rfkill is blocking the wifi:

rfkill list

This will produce an output along these lines:

0: phy0: Wireless LAN
    Soft blocked: yes|no
    Hard blocked: yes|no

If yes is appearing in this output, the wifi can be unblocked by running sudo rfkill unblock wifi.

In my case, both answers were already no, so this wasn't the root cause of the issue.

Power Management

Next, check the power management settings for the wifi card:

iwconfig

This will produce an output like this:

wlp5s0    IEEE 802.11  ESSID:"mywifi"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:00:00:00:00:00
          Bit Rate=72.2 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=70/70  Signal level=-40 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

The key line here is Power Management:on. This means that the wifi card is being put into a low power state when not in use. This can cause issues with the connection, and is apparently a common cause of wifi dropouts.

To disable power management for the wifi card, run sudo iwconfig wlp5s0 power off. Replace wlp5s0 with the name of your wifi card, if it's different.

This will disable power management for the wifi card, and should prevent the card from being put into a low power state when not in use. This should help to stop wifi dropouts in the future.

Again, in my case, power management was already off, so this wasn't the real root of the issue.

(Power)saving the day

Create or edit the file /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf and add the following:

[connection]
wifi.powersave = 2

In my case, it looks like wifi.powersave was set to 3. The different values for wifi.powersave are:

0: Disabled – Wi-Fi power-saving is turned off completely. This provides maximum performance but may consume more power.

1: Enabled (default) – Wi-Fi power-saving is enabled. This allows the Wi-Fi adapter to enter low-power states when not actively transmitting or receiving data, potentially reducing power usage but may affect performance.

2: Ignore – NetworkManager will not touch the Wi-Fi power-saving setting, meaning the Wi-Fi adapter's current state is left as-is (as set by the system or the driver).

3: Aggressive power-saving – This forces more aggressive power-saving modes. While it conserves more energy, it may cause unstable connections or delays in Wi-Fi performance.

"Aggressive power-saving" certainly sounds like what was happening, although why Ubuntu would regularly decide to aggressively power-save in the middle of video calls will remain a mystery to me.

I changed this value from 3 to 2, saved the file, and restarted NetworkManager:

sudo systemctl restart NetworkManager

This resolved the issue for me, and the wifi connection has been stable since making this change. Ultimately the default setting of 1 should probably be good enough, but for the time being I'm happy to trade a little extra power usage for a stable wifi connection!


CyberWiseCon 2025 Speaker

CyberWiseCon 2025

In May 2025, I'll be giving a talk at CyberWiseCon 2025 in Vilnius, Lithuania. From selling 10 Downing St, to moving the Eiffel Tower to Dublin, this talk covers real-world examples of unconventional ways to stop scrapers, phishers, and content thieves. You'll gain practical insights to protect assets, outsmart bad actors, and avoid the mistakes we made along the way!

Get your ticket now and I'll see you there!


Share This Article

Related Articles


Lazy loading background images to improve load time performance

Lazy loading of images helps to radically speed up initial page load. Rich site designs often call for background images, which can't be lazily loaded in the same way. How can we keep our designs, while optimising for a fast initial load?

Using Google Sheets as a RESTful JSON API

Save time by not building backends for simple CRUD apps. Use Google Sheets as both a free backend and JSON API endpoint!

Serverless caching and proxying with Cloudflare Workers

Using Cloudflare Workers we can quickly build an effective API proxy, without spinning up any additional hardware. Whether its needing a CORS proxy, speeding up slow APIs via caching, or rate limit management on stingy APIs, this serverless tech is as easy to set up as it is powerful.

Idempotency - what is it, and how can it help our Laravel APIs?

Idempotency is a critical concept to be aware of when building robust APIs, and is baked into the SDKs of companies like Stripe, Paypal, Shopify, and Amazon. But what exactly is idempotency? And how can we easily add support for it to our Laravel APIs?

Calculating rolling averages with Laravel Collections

Rolling averages are perfect for smoothing out time-series data, helping you to gain insight from noisy graphs and tables. This new package adds first-class support to Laravel Collections for rolling average calculation.

More