WiFi never auto-activates at boot on generic-x86-64

[it-happens-nl]

Describe the issue you are experiencing

After restoring a full backup onto a new hard drive in an Intel NUC (generic-x86-64), the built-in WiFi connection stops auto-connecting on boot. The WiFi device sits in disconnected state indefinitely after every reboot — it never times out, never shows an error, it simply never attempts to activate.

Key observations from extensive debugging (full detail below):

• The NetworkManager connection profile (Supervisor wlp0s20f3) is present, correctly configured, and persists across reboots.
• The configured SSID is clearly visible in nmcli device wifi list with strong signal (75–85%) from the exact same physical location where the boot test is performed.
• Running nmcli connection up "Supervisor wlp0s20f3" manually always connects instantly and reliably, both right after boot and later — this rules out any credential, security, or hardware issue.
• Despite this, NetworkManager's policy engine never logs an autoconnect attempt for this connection. Comparing journalctl -u NetworkManager -b:
  • The wired connection gets: policy: auto-activating connection 'Supervisor eno1' (...)
  • The WiFi connection never gets an equivalent policy: auto-activating connection 'Supervisor wlp0s20f3' line — not once, across many reboots, with or without Ethernet connected, and after waiting 15+ minutes.
• This was confirmed with nmcli general logging level DEBUG domains WIFI,DEVICE,CORE: the device correctly reaches disconnected (reason 'supplicant-available'), periodic WiFi scans succeed and see nearby APs (including the target SSID with strong signal), but the autoactivate pending-action is added and removed each cycle without ever resulting in an activation attempt.

Two secondary issues were also found along the way, which may be related or may be separate bugs worth splitting out:

1. Connection profiles created via ha network update <iface> --wifi-ssid ... --wifi-psk ... had wifi.hidden=true set by default, even though the target network is not a hidden/non-broadcast SSID. This forces NetworkManager into active-scan mode for that profile. Removing hidden manually (it isn't exposed as a flag in ha network update) did not resolve the core autoconnect issue, but seems like unintended default behavior on its own.
2. Freshly Supervisor-managed connection profiles do not set connection.autoconnect-retries explicitly, so it inherits NetworkManager's global default (effectively ~4 attempts) rather than unlimited retries — meaning even if the policy engine did attempt autoconnect, a slow-to-initialize WiFi driver at boot could exhaust the retry budget before succeeding. Setting autoconnect-retries=0 (unlimited) via nmcli connection modify did persist correctly across reboots, but again did not fix the core issue of zero autoconnect attempts being made in the first place.

As a workaround, I built a local Supervisor app (with host_dbus: true) that runs a small watchdog script calling nmcli connection up ~45 seconds after boot and every 60 seconds thereafter. This reliably restores connectivity but is a workaround, not a fix — the underlying autoconnect policy issue remains. Full source for this workaround app is included at the bottom of this report in case it's useful to others or to maintainers for testing.

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

18.2

Did the problem occur after upgrading the Operating System?

No

Hardware details

• Intel NUC, bare-metal x86_64 install (not a VM)
• Built-in WiFi, driver iwlwifi, interface name wlp0s20f3, PCI path pci-0000:00:14.3
• Also has onboard wired Ethernet, interface eno1 — Ethernet auto-connects (Supervisor eno1) correctly and reliably every boot; only WiFi is affected
• No USB WiFi adapter — this is the NUC's built-in WiFi hardware

Steps to reproduce the issue

1. On a generic-x86-64 (NUC) HAOS install, configure the built-in WiFi interface: ha network update wlp0s20f3 --ipv4-method auto --wifi-auth wpa-psk --wifi-mode infrastructure --wifi-ssid "<SSID>" --wifi-psk "<PSK>"
2. Confirm the connection profile is written correctly to /etc/NetworkManager/system-connections/Supervisor wlp0s20f3.nmconnection
3. Reboot the host (reboot from the host console/SSH, or a full power cycle)
4. After boot, check nmcli device status — wlp0s20f3 remains disconnected indefinitely, with CONNECTION: --
5. Confirm the SSID is actually visible and strong: nmcli device wifi list shows the configured SSID with good signal
6. Manually run nmcli connection up "Supervisor wlp0s20f3" — connects immediately without issue
7. Reboot again — step 4 repeats; WiFi never autoconnects on its own regardless of how long you wait (tested up to 15+ minutes) or whether Ethernet is also connected/disconnected

Anything in the Supervisor logs that might be useful for us?

Nothing WiFi-specific appears in the Supervisor log at INFO level around boot — `ha supervisor logs` shows normal resolution checks, store/repository updates, etc., with no warnings or errors related to the network interface. Happy to gather more if a specific log level/component is useful.

Anything in the Host logs that might be useful for us?

At default (INFO) log level, `journalctl -u NetworkManager -b | grep -i wlp0s20f3` shows only:


device (wlp0s20f3): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
device (wlp0s20f3): supplicant interface state: internal-starting -> disconnected
device (wlp0s20f3): state change: unavailable -> disconnected (reason 'supplicant-available', managed-type: 'full')


...and then nothing further — no scan, no activation attempt, ever, for the rest of that boot session.

With `nmcli general logging level DEBUG domains WIFI,DEVICE,CORE` enabled live (to avoid needing to edit the read-only `NetworkManager.conf`), and the device forced through the same readiness transition via `nmcli device set wlp0s20f3 managed no/yes`, the fuller picture emerges:


device (wlp0s20f3): state change: unavailable -> disconnected (reason 'supplicant-available', managed-type: 'assume')
device[...] (wlp0s20f3): wifi-scan: start periodic scan (0 SSIDs to probe scan)
device[...] (wlp0s20f3): wifi-scan: scanning-state: scanning
device[...] (wlp0s20f3): failed to match hidden AP XX:XX:XX:XX:XX:XX
device[...] (wlp0s20f3): failed to match hidden AP XX:XX:XX:XX:XX:XX
device[...] (wlp0s20f3): wifi-scan: scanning-state: idle (notify last-scan)
device[...] (wlp0s20f3): add_pending_action (2): 'autoactivate'
device[...] (wlp0s20f3): remove_pending_action (1): 'wifi-scan'
device[...] (wlp0s20f3): remove_pending_action (0): 'autoactivate'


This scan → autoactivate-added → autoactivate-removed cycle repeats every 5–15 seconds indefinitely, and `nmcli device wifi list` run at the same time confirms the target SSID is clearly visible with 75–85% signal — but no activation is ever attempted against it.

For comparison, the equivalent successful sequence for the wired connection on the same boot:

policy: auto-activating connection 'Supervisor eno1' (...)
policy: set 'Supervisor eno1' (eno1) as default for IPv4 routing and DNS


No equivalent `policy: auto-activating connection 'Supervisor wlp0s20f3'` line ever appears for the WiFi connection, in any boot or forced-recheck we captured.

System information

System Information

version | core-2026.8.0
installation_type | Home Assistant OS
dev | false
hassio | true
docker | true
container_arch | amd64
user | root
virtualenv | false
python_version | 3.14.6
os_name | Linux
os_version | 6.18.39-haos
arch | x86_64
timezone | Europe/Amsterdam
config_dir | /config

Home Assistant Cloud
logged_in | true
subscription_expiration | November 8, 2026 at 1:00 AM
relayer_connected | true
relayer_region | eu-central-1
remote_enabled | true
remote_connected | true
remote_server | [redacted]
alexa_enabled | false
google_enabled | true
cloud_ice_servers_enabled | true
certificate_status | ready
instance_id | [redacted]
iot_state | connected
iot_tries | 0
certificate_expire_date | October 9, 2026 at 11:41 PM
certificate_fingerprint | [redacted]
certificate_alternative_names | undefined
can_reach_cert_server | ok
can_reach_cloud_auth | ok
can_reach_cloud | ok

HACS
GitHub API | ok
GitHub Content | ok
GitHub Web | ok
HACS Data | ok
GitHub API Calls Remaining | 5000
Installed Version | 2.0.5
Stage | running
Available Repositories | 3941
Downloaded Repositories | 10

Home Assistant Supervisor
host_os | Home Assistant OS 18.2
update_channel | stable
supervisor_version | supervisor-2026.07.5
agent_version | 1.10.0
docker_version | 29.6.2
disk_total | 468.7 GB
disk_used | 26.7 GB
healthy | true
supported | true
host_connectivity | true
supervisor_connectivity | true
ntp_synchronized | true
virtualization |
board | generic-x86-64
disk_life_time | 0 %
supervisor_api | ok
version_api | ok
installed_addons | eufy-security-ws (3.1.0), RTSP Simple Server Add-on (v0.17.6), Dnsmasq (2.1.0), Let's Encrypt (6.4.0), NGINX Home Assistant SSL proxy (4.5.1), Z-Wave JS (1.6.0), chrony (6.0.1), InfluxDB (5.0.2), Studio Code Server (6.0.1), Glances (0.22.0), Grafana (12.1.0), ESPHome Device Builder (2026.7.4), Zigbee2MQTT (2.13.0-1), Node-RED (22.0.1), AirSonos (5.1.1), Mosquitto broker (7.1.0), Terminal & SSH (10.3.0), WiFi Autoconnect Kick (1.0.0)

Dashboards
dashboards | 3
resources | 2
views | 3
mode | storage

Recorder
oldest_recorder_run | July 1, 2026 at 4:34 PM
current_recorder_run | August 7, 2026 at 4:07 PM
estimated_db_size | 2670.67 MiB
database_engine | sqlite
database_version | 3.53.2

Additional information

Connection profile

/etc/NetworkManager/system-connections/Supervisor wlp0s20f3.nmconnection — stable and correct across reboots (verified via stat/cat before and after reboot):

[connection]
id=Supervisor wlp0s20f3
type=wifi
autoconnect-retries=0
interface-name=wlp0s20f3

[wifi]
cloned-mac-address=preserve
mode=infrastructure
ssid=<SSID>

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=********

[match]
path=pci-0000:00:14.3;

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=link-local

NetworkManager.conf

No unusual overrides relevant to autoconnect:

[main]
dns=default
plugins=keyfile
autoconnect-retries-default=0
rc-manager=file

[keyfile]
unmanaged-devices=type:bridge;type:tun;driver:veth

[logging]
backend=journal

[connection]
connection.mdns=2
connection.llmnr=2
wifi.powersave=2

[connectivity]
uri=http://checkonline.home-assistant.io/online.txt
interval=600

[device]
wifi.scan-rand-mac-address=no

/etc/NetworkManager/conf.d/ is empty.

What was ruled out

Signal strength/range (confirmed 75–85% at the exact test location), Ethernet-priority suppression (reproduced identically with Ethernet fully disconnected), stale/conflicting connection profiles (reproduced after a clean ha network update targeting the correct interface name), hidden-network active-scan interference (reproduced after removing wifi.hidden), and retry-count exhaustion (reproduced after setting autoconnect-retries=0).

Workaround: local app source

For anyone hitting the same issue, or for maintainers wanting to reproduce/test, here's the local Supervisor app I'm using to force the connection up after boot. It requires host_dbus: true to reach the host's NetworkManager over D-Bus.

config.yaml:

name: WiFi Autoconnect Kick
version: "1.0.0"
slug: wifi_kick
description: Forces the WiFi connection up after boot and watches it stays connected
arch:
  - amd64
startup: services
boot: auto
host_dbus: true
init: false

Dockerfile:

FROM ghcr.io/home-assistant/base:latest
RUN apk add --no-cache networkmanager-cli
COPY run.sh /
RUN chmod a+x /run.sh
CMD [ "/run.sh" ]

run.sh:

#!/usr/bin/with-contenv bashio
sleep 45
while true; do
  STATE=$(nmcli -g GENERAL.STATE device show wlp0s20f3 | cut -d' ' -f1)
  if [ "$STATE" != "100" ]; then
    bashio::log.info "wlp0s20f3 not connected (state ${STATE}), bringing it up..."
    nmcli connection up "Supervisor wlp0s20f3" || true
  fi
  sleep 60
done

Installed as a local app under /mnt/data/supervisor/apps/local/wifi_kick/ and started via ha apps install local_wifi_kick && ha apps start local_wifi_kick. Two notes for anyone reusing this: the Alpine package providing nmcli is networkmanager-cli, not networkmanager; and init: false is required or the s6-overlay-based base image fails with s6-overlay-suexec: fatal: can only run as pid 1.