system76-nm-restart restart NetworkManager causing inconsistent vpn interface state

[cavedon]

Distribution (run cat /etc/os-release):

 PRETTY_NAME="Ubuntu 22.04.4 LTS"

Related Application and/or Package Version (run apt policy $PACKAGE NAME):

system76-driver:
  Installed: 20.04.92~1719871568~22.04~efacd2f~dev
  Candidate: 20.04.92~1719871568~22.04~efacd2f~dev
  Version table:
 *** 20.04.92~1719871568~22.04~efacd2f~dev 1001
       1001 http://ppa.launchpad.net/system76-dev/stable/ubuntu jammy/main amd64 Packages
       1001 http://ppa.launchpad.net/system76-dev/stable/ubuntu jammy/main i386 Packages
        100 /var/lib/dpkg/status

Issue/Bug Description:
Upon resume from sleep, /lib/systemd/system-sleep/system76-nm-restart will restart NetworkManger, causing some interfaces to be left in an inconsistent state.

Steps to reproduce (if you know):

1. Connect to a VPN using NetworkManager and openconnect.
2. Send to system to sleep
3. Resume from sleep
4. The VPN will be disconnected, but the vpn0 interface will still be up with the old IP address assigned
5. Connect to the VPN again
6. Now the vpn0 interface will have two IP addresses and routing will be broken

The issue is caused by restarting NetworkManger while it is recovering from a sleep status.

Expected behavior:
Do not restart NetworkManager.

[pcwick]

Comment on Issue #298: Additional case — system76-nm-restart causes 1-2 minute WiFi reconnection delay on resume with Intel BE200 (Wi-Fi 7)

Claude AI helped me troubleshoot this. I would not ordinarily have had the time or patience to troubleshoot this. With Claude it took about 90 minutes and the fix has worked across several suspend and resume cycles.

Hardware

• Machine: Darter Pro
• WiFi chip: Intel Wi-Fi 7 BE200 320MHz
• WiFi driver: iwlmld
• OS: Pop!_OS 24.04
• Kernel tested: 6.17.9-76061709-generic and 6.18.7-76061807-generic

Symptom

After every suspend/resume cycle, WiFi fails to reconnect for approximately 1-2 minutes. During this window:

• The Cosmic top bar WiFi icon shows disabled (slash through it)
• Cosmic Network Settings shows WiFi disabled or connected with no SSIDs available
• The network is genuinely unreachable — browsers fail to load pages and ping returns "Network is unreachable"
• After 1-2 minutes, WiFi reconnects without intervention

The symptom is consistent across both kernel versions tested and is reproducible on every suspend/resume cycle.

When This Started

The issue began approximately mid-to-late February 2026. Prior to that, resume had worked reliably. The specific update that triggered the change in behavior cannot be identified from available package logs — NM does not appear in dpkg upgrade history, suggesting it may have been installed before log rotation. The currently installed version is NM 1.46.0-1ubuntu2.5 from noble-updates.

The script itself predates the problem — its file timestamp is October 28, 2024 — so the script alone is not the cause. Something changed in the environment that made what was previously a fast, unnoticed NM restart into a 1-2 minute delay. The most likely candidate is a NM update that changed how long the cold restart takes on BE200/iwlmld hardware, but this is [INFERRED] not verified from logs.

Root Cause

The script /usr/lib/systemd/system-sleep/system76-nm-restart unconditionally restarts NetworkManager on every suspend/resume cycle on all System76 hardware, regardless of WiFi chip generation:

post) sleep 1 && sudo systemctl restart NetworkManager

This causes NM to perform a full cold start on every resume — shutting down, reinitializing, rediscovering all network devices, scanning for networks, authenticating, and obtaining a DHCP lease from scratch. On the Intel BE200 with the iwlmld driver under NM 1.46.0, this process takes 1-2 minutes.

This was confirmed by NM journal logs captured during the failure window:

NetworkManager[1445]: caught SIGTERM, shutting down normally.
NetworkManager[1445]: exiting (success)
systemd[1]: Stopped NetworkManager.service
systemd[1]: Starting NetworkManager.service
NetworkManager[6604]: NetworkManager (version 1.46.0) is starting...

The WiFi interface does not exist at the kernel level during this restart window:

$ sudo iw dev wlp46s0f0 link
command failed: No such device (-19)

The Script's Own Comment Identifies the Problem

The script's header comment explicitly states it was written for a specific, older hardware generation:

# Starting with 16.04, there are WiFi reliability issues when resuming from
# suspend, at least with certain WiFi cards. In particular, this problem seems
# to effect Haswell generation cards like the 7260. It does not seem to effect
# Skylake generation cards like the 3165, 8260.

The Intel BE200 is a Wi-Fi 7 card released in 2023, several generations beyond the Haswell/7260 hardware this script was designed to address. The script contains no hardware detection logic and runs unconditionally on all System76 machines regardless of WiFi chip.

Verification

Removing the execute bit from the script:

sudo chmod -x /lib/systemd/system-sleep/system76-nm-restart
sudo chmod -x /usr/lib/systemd/system-sleep/system76-nm-restart

After reboot, three consecutive suspend/resume cycles all reconnected within 1-2 seconds of the GUI appearing. The 1-2 minute delay is completely eliminated.

Suggested Fix

Add hardware or driver detection logic to the script so it only restarts NetworkManager on hardware where it is necessary. For example, skipping the restart when the active WiFi driver is iwlmld (the Wi-Fi 7 driver):

post)
    driver=$(cat /sys/class/net/wl*/device/driver/module/drivers 2>/dev/null | grep -o 'iwlmld' || true)
    if [ "$driver" != "iwlmld" ]; then
        sleep 1 && sudo systemctl restart NetworkManager
    fi
    ;;

Or more broadly, detecting the driver family and only running the restart for the specific Haswell-era cards it was designed for.

Impact

Confirmed on: Darter Pro with Intel BE200 (iwlmld driver), NM 1.46.0-1ubuntu2.5, Pop!_OS 24.04, kernels 6.17.9 and 6.18.7. The scope beyond this configuration is unknown — other users may experience the same delay but attribute it to normal resume behavior without tracing it to this script.

Additional Finding: system76-driver Package Version

The installed system76-driver package on this machine is from the 22.04 (Jammy) PPA, not a Noble-native package:

system76-driver:
  Installed: 20.04.92~1719871568~22.04~efacd2f~dev
  (from ppa.launchpad.net/system76-dev/stable/ubuntu jammy)

This means there is no upgrade path that would deliver a fix to this machine unless the Jammy PPA package is updated or a Noble-native package is published. The chmod workaround is therefore necessary to persist until an upstream fix is available.

[lastmac]

Confirmed on Intel AX211 (iwlmvm driver), same fix works.