AIC8800D80: 2.4 GHz AP mode is broken by a stale firmware blob

TL;DR — if hostapd says AP-ENABLED but nobody can see your 2.4 GHz SSID on an AIC8800D80 (SDIO), your distro is probably shipping firmware from November 2023. Replace it with the December 2025 build and it works.

Affected devices

Found and fixed on an Orange Pi 4 Pro (Allwinner A733 / sun60iw2) running Armbian.

This is a firmware issue, not a board issue — it should affect any Linux device using the AIC8800D80 over SDIO with the same blob. Other hardware known to use this chip includes the Radxa ROCK 5C and various AX900/AX1800-class adapters and TV boxes.

Confirmed affected	Orange Pi 4 Pro (Armbian, kernel 6.6.98-vendor-sun60iw2)
Likely affected	any AIC8800D80 SDIO device whose distro ships the Nov-2023 fmacfw
How to check yours	strings /lib/firmware/aic8800d80/fmacfw_8800d80_u02.bin | grep -oE 'g[0-9a-f]{7,}' — if it reports g6a92fae (Nov 2023), you have the broken blob

If you hit this on other hardware, please open an issue with your board and the version string — that is exactly the data needed to push a fix upstream.

Firmware	2.4 GHz AP	5 GHz AP
fmacfw_8800d80_u02.bin — mi Nov 01 2023 - g6a92fae (Armbian)	0 / 26 fresh scans — no beacons at all	works
fmacfw_8800d80_u02.bin — la Dec 05 2025 - g586bc1e8 (Radxa)	works	works

Measured through the fixed AP (phone speedtest): 2.4 GHz 49.7 / 29.7 Mbit/s, 5 GHz 50.5 Mbit/s.

The symptom

Everything reports success and nothing is on the air:

$ systemctl is-active hostapd
active
$ hostapd_cli -i wlan0 status
state=ENABLED
freq=2462
ssid[0]=myap
$ iw dev wlan0 info
        type AP
        channel 11 (2462 MHz), width: 20 MHz

…yet no client, phone or laptop, ever sees the SSID. Move the same config to hw_mode=a / channel=36 and it appears instantly.

The driver is not at fault. kprobes on the loaded module show it building a valid beacon and the firmware acknowledging it — see docs/how-this-was-diagnosed.md.

The fix

./firmware/fetch-firmware.sh      # downloads from radxa-pkg/aic8800, verifies md5
sudo ./scripts/install-firmware.sh   # backs up stock, installs, reloads the driver

Then bring your AP up as usual. The change survives a cold boot.

⚠️ The firmware blobs are NOT redistributed here. They are proprietary AICSemi binaries with unclear redistribution terms — the mainline driver submission notes that "firmware redistribution permission ... [is] not yet available". fetch-firmware.sh downloads them from radxa-pkg/aic8800 and verifies checksums.

What changes

Swap the whole SDIO set — they are a coherent group, and mixing a 2025 fmacfw with 2023 patch tables is asking for trouble.

File	Armbian (Nov 2023)	Radxa (Dec 2025)
fmacfw_8800d80_u02.bin	315,273	341,200
fw_patch_8800d80_u02.bin	23,796	32,700
fw_patch_table_8800d80_u02.bin	960	1,384
lmacfw_rf_8800d80_u02.bin	206,987	266,902
aic_userconfig_8800d80.txt	2,448	2,724
fw_patch_8800d80_u02_ext0.bin	absent	16,136
aic_powerlimit_8800d80.txt	absent	3,688
fw_adid_8800d80_u02.bin	1,708	1,708 (identical)

Rollback is pre-installed

install-firmware.sh backs the stock set up to /root/fw-orig and installs fw-trial-revert.service, which runs Before=systemd-udev-trigger — i.e. before udev loads the Wi-Fi module. If a firmware ever hangs the chip at boot, a power-cycle recovers by itself. It is inert unless /root/FW_TRIAL exists. That unit is reusable for any risky firmware trial on any device.

Other things worth knowing about this chip

• ieee80211n=1 is worth 4× on 2.4 GHz. Without it the AP silently falls back to 802.11g: 12.2 / 17.3 Mbit/s vs 49.7 / 29.7 with it. Nothing warns you — hostapd reports ENABLED either way and iw only hints with 20 MHz (no HT).
• A wedged AP state does not clear on systemctl restart hostapd. If clients associate but never complete the 4-way handshake, reload the driver: rmmod aic8800_fdrv aic8800_bsp && modprobe aic8800_bsp && modprobe aic8800_fdrv. Repeated hostapd restarts and a full config revert did not recover it; a module reload did.
• One AP interface only — #{ AP } <= 1 in iw phy info. No simultaneous dual-band; one band at a time on a single radio.
• country_code stalls hostapd in COUNTRY_UPDATE, but only when the requested country differs from the current regulatory domain (from iw reg set 00: never reached AP-ENABLED in 90 s; already-matching domain: 1 s). Because the domain persists, the second boot works — so it looks intermittent.
• After a module reload the phy renumbers (phy0 → phy1), and iw phy0 info then returns empty output rather than an error.

Verifying a Wi-Fi AP correctly

Three checks that look authoritative and prove nothing on a fullMAC radio:

Don't	Why
systemctl is-active hostapd	Reports active while stuck in COUNTRY_UPDATE, and while enabled-but-silent
tx_packets on the AP interface	Beacons are generated in firmware and never touch the host stack. A working AP with 3 clients also shows a delta of 0
iw dev wlan0 scan without flush	Re-reads the cached BSS table; produces phantom "intermittent" sightings of an AP emitting nothing

Only a scan from a second radio counts, and it must be iw dev wlan0 scan flush.

Contents

firmware/fetch-firmware.sh   download + verify (no blobs committed)
firmware/checksums.md5       md5s for both the stock and the fixed set
scripts/install-firmware.sh  back up, install, reload driver
scripts/fw-restore.sh        restore stock firmware
scripts/fw-trial-revert.service   early-boot rollback (before udev)
configs/                     working hostapd / dnsmasq / netplan / NAT
docs/how-this-was-diagnosed.md    kprobe tracing, A/B/A method
docs/what-didnt-work.md      the dead ends, so you can skip them

Status

Reported upstream to Armbian — see armbian-firmware-issue.md.

Credits

Firmware is AICSemi's, redistributed by radxa-pkg/aic8800 for Radxa boards (the ROCK 5C uses the same chip). This repo contains only the finding, the verification tooling and configuration.