Wi-Fi configuration rejected with HTTP 400 on Home Assistant OS 18.2

Sebastien78 · August 16, 2026, 1:20pm

I installed Home Assistant OS 18.2 / Home Assistant Core 2026.8.2 and I am unable to configure the Wi-Fi connection.

The Wi-Fi adapter itself appears to be working correctly. The wlan0 interface detects nearby Wi-Fi networks and I can see the available SSIDs.

However, whenever I try to activate Wi-Fi through the Home Assistant interface, the connection is rejected.

I have tested with several different Wi-Fi networks and configurations, with exactly the same result.

I have tried:

Different Wi-Fi SSIDs and networks
WPA2-PSK / AES
WPA/WPA2 mixed mode
WPA
IPv4 enabled
IPv6 enabled
IPv4 and IPv6 enabled

Nothing works.

Error from the Home Assistant interface

I get the following error:

Logger: homeassistant.components.hassio
Source: components/hassio/websocket_api.py:156
Integration: Home Assistant Supervisor
First occurred: 12:44:25
Last logged: 12:44:25

There is no useful additional information displayed in the interface.

Error from the Home Assistant CLI

I also tried configuring the Wi-Fi directly from the Home Assistant console:

ha > network update wlan0 --wifi-ssid Bondalen --wifi-psk [REDACTED] \
     --wifi-auth wpa-psk --wifi-mode infrastructure --log-level 1

The command generates the following debug information:

2026/08/14 21:19:31 DEBUG Adding homedir to searchpath homedir=/root
2026/08/14 21:19:31 INFO No config file found
2026/08/14 21:19:31 DEBUG Debug flags api-token=[REDACTED]
2026/08/14 21:19:31 DEBUG network update args=[wlan0]
2026/08/14 21:19:31 DEBUG [Generator] base=supervisor section=network command=interface/update
2026/08/14 21:19:31 DEBUG [GeneratorURI] Result uri=http://supervisor/network/interface/{interface}/update
2026/08/14 21:19:31 DEBUG Request body options="enabled=true wifi-ssid=Bondalen wifi-psk=[REDACTED] wifi-auth=wpa-psk wifi-mode=infrastructure psk=[REDACTED] ssid=Bondalen"

2026/08/14 21:19:57 DEBUG Response statuscode=400 status="400 Bad Request"

HTTP/1.1 400 Bad Request

{
  "result": "error",
  "message": "Invalid data: ..."
}

Error: Failed, check connection settings.
Error activating connection failed, check connection settings.

The important point is that the request actually reaches the Supervisor, but the Supervisor returns:

HTTP 400 Bad Request
Invalid data

The request also takes approximately 25 seconds before returning the HTTP 400 error.

I have repeated the test with different Wi-Fi networks, so I do not believe that the problem is related to a particular SSID or Wi-Fi router.

Additional information

The Wi-Fi adapter is detected correctly and is able to scan for nearby networks. Therefore, the hardware and basic Wi-Fi detection appear to be working.

The problem occurs both:

When configuring Wi-Fi through the Home Assistant UI.
When configuring the exact same interface directly through the ha network update command.

Could this be a NetworkManager / Supervisor / Home Assistant OS 18.2 issue with Wi-Fi configuration?

Is there a way to obtain the complete Invalid data message returned by the Supervisor, or additional logs that could identify exactly which parameter is being rejected?

Any help would be greatly appreciated, because at the moment I am completely unable to activate Wi-Fi on this installation despite the adapter detecting the available networks correctly.

Sir_Goodenough · August 16, 2026, 2:37pm

Running a server on WIFI is a bad idea. Continuous uninterrupted connections work the best, and WIFI doesn’t run that way.
That said, you did not mention the hardware. RasPi based? If so…
I do not suggest doing that, it is often the root of other problems, but that said…

If When you come back for help here, please let the person helping know your server is on WIFI.

Sebastien78 · August 16, 2026, 7:16pm

Thank you for your answer. That’s insane! I’ve just done a test with the 5 GHz version of my Wi-Fi router, using exactly the same settings, but connecting via 5 GHz Wi-Fi. It works!!

Regarding the hardware, it’s a Raspberry Pi 4B with 4 GB of RAM.

Sir_Goodenough · August 16, 2026, 10:53pm

If that was a solution, would you be so kind as to mark it as such to help others?

Baxxy13 · August 17, 2026, 8:35am

Maybe related:

github.com/home-assistant/operating-system

2.4 GHz Wi-Fi association fails on CM4 (ASSOC-REJECT status_code=16) where Raspberry Pi OS succeeds on identical hardware and firmware

opened 05:08AM - 15 Aug 26 UTC

01dCod3r

## Description On a Raspberry Pi Compute Module 4, Home Assistant OS cannot ass…ociate with any 2.4 GHz access point, while 5 GHz association on the same radio works reliably. Raspberry Pi OS on the **same hardware** associates on 2.4 GHz immediately, with **identical Wi-Fi firmware and identical `brcmfmac` module options**. Every association attempt on 2.4 GHz fails the same way: ``` wlan0: Trying to associate with <BSSID> (SSID='<ssid>' freq=2462 MHz) wlan0: CTRL-EVENT-ASSOC-REJECT bssid=<varies> status_code=16 wlan0: CTRL-EVENT-SSID-TEMP-DISABLED ... auth_failures=1 reason=CONN_FAILED ``` NetworkManager surfaces this as `Activation: (wifi) association took too long`, then `failed (reason 'no-secrets')` — which is misleading, as credentials are not involved. The same passphrase associates on the 5 GHz SSID of the same router. The AP is visible in scans at strong signal (85–100 in `nmcli`, roughly −40 dBm) immediately before each failed attempt, so this is not a scanning or visibility problem. Receive works; association does not. The `bssid=` value reported in the reject event is unreliable — it has variously reported the 5 GHz BSSID of the same router while targeting the 2.4 GHz radio, and `00:00:00:00:00:00` — suggesting the rejection may be generated locally rather than received from the AP. ## The key comparison Booting **Raspberry Pi OS Lite (64-bit)** from SD on the *same* Compute Module — verified by `wlan0` MAC — associates with the 2.4 GHz SSID immediately and holds a stable link: ``` IN-USE SSID CHAN FREQ SIGNAL RATE SECURITY * <ssid> 11 2462 MHz 80 260 Mbit/s WPA2 ``` `/proc/net/wireless`: quality 70, level −40 dBm, **zero** discarded packets, **zero** missed beacons. | | Raspberry Pi OS — works | Home Assistant OS — fails | |---|---|---| | Wi-Fi firmware | `BCM4345/6 wl0 ... version 7.45.265 (28bca26 CY)` | **identical** | | `brcmfmac` options (`modprobe -c`) | `roamoff=1 feature_disable=0x282000` | **identical** | | `roamoff` in `/sys` | `1` | `1` | | `brcmfmac_cyw` loaded | yes | yes | | Driver bound to `wlan0` | `brcmfmac` | `brcmfmac` | | `cfg80211` regulatory domain | `US` | `US` (after setting it explicitly; default was `00`) | | Kernel | `6.18.34+rpt-rpi-v8` | `6.18.34-haos-raspi` | | **2.4 GHz association** | **works** | **fails** | | 5 GHz association | works | works | Same upstream kernel version, different build. ## Environment - **Home Assistant OS**: 18.2 (`rpi4-64`) - **Supervisor**: 2026.07.5 - **Kernel**: `6.18.34-haos-raspi` - **wpa_supplicant**: v2.11 - **NetworkManager**: 1.50.2 - **Hardware**: Raspberry Pi Compute Module 4 Rev 1.1, 8 GB, wireless variant (`CM4108000`), on a third-party carrier board, booting from NVMe - **Wi-Fi firmware**: `BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b` - **AP**: consumer router, WPA2-Personal/AES, 2.4 GHz on channel 11 ## Steps to reproduce 1. Install Home Assistant OS on a CM4 with onboard wireless. 2. Configure a Wi-Fi connection for a 2.4 GHz WPA2-PSK SSID. 3. Attempt to activate it. Association fails with `status_code=16` while the SSID is visible at strong signal. A 5 GHz SSID on the same router activates normally. ## What has been ruled out Each of these was tested and eliminated experimentally, not assumed: - **Access point** — reproduced against a second, unrelated AP (a phone hotspot on 2.4 GHz). - **Compute Module** — reproduced on two different CM4s of the same part number, different serials. - **Antenna** — reproduced on both the external u.FL antenna (`dtparam=ant2`) and the on-board PCB antenna (`dtparam=ant1`). Raspberry Pi OS associates using the on-board antenna in the same enclosure. - **Wi-Fi firmware version** — identical on both systems; this is also the current build shipped in `RPi-Distro/firmware-nonfree`. - **`brcmfmac` module options** — identical on both systems, verified with `modprobe -c`. Several other `feature_disable` values were also tried. - **Regulatory domain** — setting `cfg80211.ieee80211_regdom=US` on the kernel command line changed the domain (confirmed in `/sys` and `/proc/cmdline`) but had no effect. - **`brcmfmac_cyw`** — loaded identically on both systems. - **NVMe/PCIe interference** — a sustained raw read of 6000 MiB at 407 MB/s (verified against `/sys/block/nvme0n1/stat`) produced no measurable change in 2.4 GHz link quality on the working system: quality 68–70, level −40 to −42 dBm, zero discards, zero missed beacons throughout. - **AP-side configuration** — security mode (WPA-Auto vs WPA2-Personal), channel, channel width (20 vs 20/40 MHz), modulation scheme, band steering (confirmed off), MAC filtering (disabled), and the roaming block list (empty) were all varied or verified with no effect. ## Possibly related The Bluetooth half of this same combo chip appears to have a regression in the same OS and kernel generation: - home-assistant/operating-system#4934 — *"Onboard Bluetooth (BCM4345C0) fails to initialize on HA Yellow / CM4 in HAOS 18.2 — kernel 6.18.34 times out reading local name, firmware patch never loads"*. Reported as working on HAOS 17.3 (kernel `6.12.75-haos-raspi`) and broken on 18.2 (kernel `6.18.34-haos-raspi`), and described there as a kernel-side regression between the two releases. Closed as a duplicate of home-assistant/core#174436, which remains open. `BCM4345C0` (Bluetooth) and `BCM4345/6` (Wi-Fi) are the two halves of the same combo part. Given that both faults appear on HAOS 18.2 with kernel `6.18.34-haos-raspi`, and that the Bluetooth side is reported working on the earlier 17.3 / `6.12.75` combination, these may share a root cause. I have not yet tested an earlier Home Assistant OS release against the Wi-Fi symptom — that is the obvious next experiment and I am happy to run it. ## Additional notes The only variable left between a working and a failing system is the kernel build. I am happy to run further diagnostics, test a patched image, or provide additional logs — the hardware is available for testing and can be booted into either OS from SD.