Bitaxe – Won’t Connect to hostapd / Linux-Generated Hotspots

Back up your current `hostapd.conf` before editing anything. `sudo cp /etc/hostapd/hostapd.conf /etc/hostapd/hostapd.conf.bak-$(date +%F)`. Always keep the working copy — rolling back to a known-good config is faster than retyping when an edit goes sideways. On OpenWrt, snapshot `/etc/config/wireless` the same way.

Edit `hostapd.conf` to a Bitaxe-compatible WPA2 baseline. Reference block: `ssid=YourIoTNetwork`, `hw_mode=g`, `channel=6`, `country_code=CA`, `wpa=2`, `wpa_key_mgmt=WPA-PSK`, `wpa_pairwise=CCMP`, `rsn_pairwise=CCMP`, `wpa_passphrase=ChangeMeNow`, `ieee80211w=0`, `wmm_enabled=1`. Drop `ieee80211w=2`. Drop `sae_pwe=1`. Drop any `OWE` AKM. This is the dialect every `ESP32-S3` understands cleanly.

Restart `hostapd`. On systemd distros: `sudo systemctl restart hostapd`. On OpenWrt: `wifi reload` then `/etc/init.d/hostapd restart`. Wait 30 seconds for the radio to re-broadcast the new config before you scan from the Bitaxe.

Verify the SSID is up at the OS level with `sudo iw dev wlan0 info` (substitute your interface name). It should report `type AP`. If `type managed`, the AP didn't start cleanly — re-read `journalctl -u hostapd -f` for the exact line that's failing parse.

Power-cycle the Bitaxe. Connect to the `Bitaxe_XXXX` AP, browse to `http://192.168.4.1/`, refresh the SSID scan, enter your new SSID and password, save. OLED should transition from `WIFI: CONNECTING…` to `IP: 192.168.x.x` within 30 seconds. From a LAN device, browse to that IP to confirm the AxeOS dashboard renders.

If you want WPA3 for laptops AND WPA2 for the Bitaxe, run two SSIDs on the same `hostapd` instance. Add a second `bss=wlan0_1` block: `ssid=HomeNet-IoT`, `wpa=2`, `wpa_key_mgmt=WPA-PSK`, `wpa_pairwise=CCMP`, `rsn_pairwise=CCMP`, `wpa_passphrase=DifferentPassphrase`, `ieee80211w=0`. Restart `hostapd`. Modern devices stay on WPA3 main; Bitaxe joins the IoT SSID.

Or use WPA2/WPA3 transition mode on a single SSID. Set `wpa_key_mgmt=WPA-PSK SAE` (both, space-separated), `ieee80211w=1` (PMF capable but not required), `sae_pwe=2` (both methods). Bitaxe negotiates WPA2-PSK; modern devices negotiate WPA3-SAE. Same SSID, both worlds, no parallel network needed.

On NetworkManager hotspots (`nmcli device wifi hotspot`), force WPA2 explicitly: `nmcli connection modify Hotspot 802-11-wireless-security.key-mgmt wpa-psk`, `nmcli connection modify Hotspot 802-11-wireless-security.proto rsn`, `nmcli connection modify Hotspot 802-11-wireless-security.pairwise ccmp`, `nmcli connection modify Hotspot 802-11-wireless-security.group ccmp`, `nmcli connection modify Hotspot 802-11-wireless-security.pmf 1` (capable, not required), then `nmcli connection up Hotspot`.

On OpenWrt LuCI: Network → Wireless → Edit → Wireless Security → Encryption: `WPA2-PSK (strong security)`, NOT `WPA3-SAE`, NOT `WPA2-PSK/WPA3-SAE Mixed Mode` if you can avoid mixed. Cipher: `Force CCMP (AES)`. `802.11w Management Frame Protection: Disabled` or `Optional`. Save & Apply. Equivalent UCI: `option encryption 'psk2+ccmp'`, `option ieee80211w '0'`.

If your AP runs OpenWrt 23.05+ and stopped working after an upgrade, rebuild the wireless block: `option encryption 'sae'` or `option encryption 'sae-mixed'` with `option ieee80211w '2'` is the failure pattern. Switch to `option encryption 'psk2+ccmp'` and `option ieee80211w '0'` for the IoT SSID specifically. `wifi reload`. Bitaxe rejoins immediately.

Run a dedicated 2.4 GHz radio for IoT separate from your 5 GHz / 6 GHz home network. Raspberry Pi 4 / 5 build: stock onboard Wi-Fi adapter as the IoT 2.4 GHz AP via `hostapd`, USB Wi-Fi 6 adapter for the 5 GHz home network with WPA3-SAE. Two radios, two SSIDs, two AKM policies, zero conflict. This is how the D-Central bench is wired.

If you run RADIUS / 802.1X (WPA2-Enterprise), the Bitaxe likely won't authenticate cleanly. The `ESP32-S3` supports WPA2-Enterprise but `ESP-Miner` doesn't expose certificate / EAP UI. Either put the Bitaxe on a parallel WPA2-Personal SSID, or MAC-bypass the Bitaxe's MAC on your RADIUS policy and run it on the open / PSK fallback VLAN.

If `hostapd.conf` has `hw_mode=b` (legacy 802.11b), this is the [`bitaxeorg/ESP-Miner` issue #339](https://github.com/bitaxeorg/ESP-Miner/issues/339) reproducer. Modern `hostapd` 2.10+ has stricter frame validation; `hw_mode=b` plus tightened defaults breaks the Bitaxe handshake. Switch to `hw_mode=g` (802.11g) or `hw_mode=n` (802.11n). Channel 1, 6, or 11. Restart `hostapd`.

Build a minimal `hostapd` test harness to isolate the offending directive. `sudo hostapd /tmp/test.conf` in foreground / verbose. Strip `test.conf` to: `interface=wlan0`, `ssid=BitaxeTest`, `hw_mode=g`, `channel=6`, `wpa=2`, `wpa_key_mgmt=WPA-PSK`, `wpa_pairwise=CCMP`, `wpa_passphrase=test12345`. If the Bitaxe joins this minimal AP, your prod config has an incompatible directive — diff line by line until you find it.

Cross-check `ESP-Miner` firmware version. Use the Bitaxe Web Flasher at `https://bitaxeorg.github.io/bitaxe-web-flasher/` over USB-C to flash the current release. Recent `ESP-Miner` builds pull in newer Espressif IDF Wi-Fi stack with improved PMF + SAE handling. Use a USB-C data cable (not charge-only). A factory image wipes saved SSID and pool config — re-enter on first boot after flash.

Stop DIY when you've reduced `hostapd.conf` to a vanilla WPA2-PSK CCMP baseline, restarted, watched `journalctl`, confirmed the SSID is broadcasting on `hw_mode=g` channel 1/6/11 with `country_code` set correctly, tested with a phone hotspot in WPA2 mode (failed there too), reflashed `ESP-Miner` to current. The Bitaxe radio path is now suspect. Ship the Bitaxe to D-Central.

D-Central bench process: USB-C serial monitor with a known-good 2.4 GHz `hostapd` reference AP at 1 m range. If the `ESP32-S3` won't associate at 1 m on a vanilla WPA2-PSK SSID, we measure antenna-feed resistance (50 Ω characteristic impedance, antenna path < 1 Ω resistance), inspect the antenna feed trace under microscope for solder defects or impact damage, and reflow or replace the antenna or `ESP32-S3` module via hot-air rework as needed.

Ship the Bitaxe in an anti-static bag, double-boxed with at least 3 cm foam padding. Include: the failing `hostapd.conf`, the serial-console capture from your diagnostic step, your current `ESP-Miner` firmware version, and a list of which networks (phone hotspot, friend's house, OpenWrt build) you've already tested. We use that data to skip 30 minutes of redundant diagnostic and pass the savings back to you on the invoice.