Bitaxe – Stuck in WiFi Config AP Mode / Won’t Join Network

Log into your router at `192.168.1.1` / `192.168.0.1` / `10.0.0.1` and expose the `2.4 GHz` band as its own dedicated SSID. Disable Smart Connect, Band Steering, or AiMesh Smart Connect. Create a separate SSID like `HomeNet-IoT-2.4G`. Save, wait 60 s for the AP to come back, then reconnect your phone to `Bitaxe_XXXX` at `http://192.168.4.1` and provision against the new 2.4 GHz SSID. This single change resolves the majority of AP-stuck tickets - ESP32-S3 is 2.4 GHz only and cannot speak 5 GHz.

Verify SSID and password on a second phone before entering them on the Bitaxe. Type the exact SSID and password into a phone's Wi-Fi settings. If the phone cannot join, credentials are wrong - fix at the router. If the phone joins, copy the credentials character-by-character into the Bitaxe portal. Watch for case (`Smith-Home` vs `smith-home`), trailing whitespace from password-manager pastes, and smart-quotes from iOS autocorrect - all silent AUTH_FAIL causes. Type manually if any doubt.

Reset NVS by holding `BOOT` for 10+ seconds during power-up. Disconnect USB-C. Press and hold the `BOOT` button on the Bitaxe PCB. Reconnect USB-C / barrel jack while still holding. Continue holding a full 10 seconds after power is applied. Release. The device emits a completely fresh `Bitaxe_XXXX` AP with no stored credentials. Re-provision from scratch. Clears any corrupted NVS entries from prior failed attempts - especially useful after interrupted OTA updates.

Re-provision against a `2.4 GHz` phone hotspot to confirm hardware is fine. Turn on a mobile hotspot set to `2.4 GHz` only, WPA2 (iPhone: Settings > Personal Hotspot > Maximize Compatibility = ON). Simple SSID, simple password, no special characters. Provision the Bitaxe against the hotspot. If it joins cleanly: hardware is fine, stay in Tier 1/2 to fix the home network. If it fails here too: advance to Tier 3.

Move the Bitaxe within 3 m of the router during provisioning. ESP32-S3 is not winning distance records - first-boot association needs clean RSSI. Provision close to the router, let it join, then move to the permanent location. Target RSSI `-60 dBm` or better in the AxeOS dashboard after it joins. Below `-75 dBm` at the permanent spot means intermittent AUTH_TIMEOUT (reason `202`) will kick it back to AP mode.

Temporarily unhide your SSID for provisioning. If the target `2.4 GHz` SSID is hidden (non-broadcasting), unhide it in the router admin, provision the Bitaxe, re-hide after. AxeOS versions before `v2.7.0` have spotty hidden-SSID support and return `NO_AP_FOUND` (reason `201`) even with correct credentials. Upgrade AxeOS first if you want to stay on a hidden SSID long-term.

Switch SSID security to WPA2-Personal (AES/CCMP) or WPA2/WPA3 Transition. Avoid `WPA3-Personal Only`. Set the `2.4 GHz` SSID to `WPA2-Personal (AES)` or `WPA2/WPA3 Transition Mode` if available. Save. Wait 60 s. Re-provision. WPA3-only interop with Bitaxe ESP-IDF builds is still inconsistent across router firmwares - WPA2 or transition mode is the safe choice for any IoT SSID.

Disable AP isolation, client isolation, and guest-mode on the target SSID. Look for `AP Isolation`, `Client Isolation`, `Wireless Isolation`, `Prevent LAN Access`, or `Guest Network Mode` in router admin. Turn them off on the SSID the Bitaxe uses. Save and re-provision. These features block Bitaxe frames at the AP before DHCP can complete. If your network segregates IoT to a separate VLAN, pick the SSID where isolation is off, knowing you will need explicit firewall rules to reach the Bitaxe from other VLANs.

Check for MAC filtering or device-approval on the router. On UniFi, Bell Gigahub, Videotron Helix, Xfinity xFi, and similar, find `Device Approval` or `MAC Address Filter` in security settings. Look up the Bitaxe MAC (printed on the device, or in the serial-console boot log). Add it to the allow-list. Save, re-provision. Without this step, the AP associates then immediately de-authenticates - serial log shows `wifi_disconnect reason: 8` (`ASSOC_LEAVE`).

Connect USB-C and read the serial console at `115200 baud` to see the real failure reason. Use PuTTY, Tera Term, Arduino IDE serial monitor, or `screen /dev/tty.usbmodem* 115200`. Power-cycle the Bitaxe and watch the boot log. The key line is `wifi_disconnect reason: N` - `15 = AUTH_FAIL` (password), `201 = NO_AP_FOUND` (SSID / band issue), `8 = ASSOC_LEAVE` (AP kicked client), `202 = AUTH_TIMEOUT` (weak signal / WPA3 neg fail), `6 = NOT_AUTHED` (rare). Match the code to a root cause and target the specific fix rather than shotgunning.

Set router DNS to `1.1.1.1` (Cloudflare) or `8.8.8.8` (Google). Not strictly AP-stuck but AxeOS with broken DNS after join can present symptoms that look similar - long `CONNECTING...` state with fallback to AP in some builds. Setting known-good public DNS at the router level eliminates this as a diagnostic variable.

Reflash the exact correct AxeOS image via USB-C Web Flasher. Hold `BOOT`, tap `RESET`, release `BOOT` to enter bootloader mode. Go to `https://bitaxe.org/` in Chrome, Edge, or Opera (WebSerial required - not Firefox, not Safari). Pick the *exact* firmware image for your board revision: Supra `401`, Ultra `202/204/205/207`, Gamma `601/602`, Hex `v303/v304`, GT have different images. Flashing wrong images bricks the device or leaves Wi-Fi provisioning broken. After clean reflash, factory AP should come up and provisioning should work against a proper `2.4 GHz` WPA2 SSID.

Downgrade AxeOS if you upgraded to a known-buggy beta. Check your version against `https://github.com/bitaxeorg/ESP-Miner/releases`. Beta tags (`-b1`, `-rc`) have shipped Wi-Fi regressions - `v2.14.0b1` and similar had reports of AP-fallback issues against specific router families. Roll back to the most recent tagged stable (`v2.7.x` or `v2.8.x` as of writing - verify against the repo). Production miners stay on stable.

Capture a full boot log and file or reference a GitHub issue. With serial console running at `115200 baud`, capture the entire boot log from power-on through the AP-stuck loop. Include firmware version, board revision, router model, router firmware version. Search `https://github.com/bitaxeorg/ESP-Miner/issues` for your reason code + router family - frequent matches. If no open issue matches, file one with your capture attached. AxeOS maintainers are responsive - and D-Central's repair queue has contributed reproducers in that tracker.

Hardware sanity-check: swap Bitaxe to a known-good PSU. Ultra / Supra / Gamma run `5 V / 3 A` USB-C. Hex and GT run `12 V / 2.5 A+` on barrel jack or XT30. A marginal PSU that sags under the Wi-Fi radio's TX bursts causes association to fail at exactly the Wi-Fi handshake - radio browns out mid-authentication, AP drops client, AxeOS falls back to AP mode. Swap to a rated PSU with at least 1.5x margin over max draw and re-provision. A bargain `12 V / 1 A` brick will never provision a Hex reliably.

When to stop DIY. If you have walked Tier 1-3 - dedicated 2.4 GHz WPA2 SSID, credential re-verify, NVS wipe, Web Flasher reflash of the exact correct image, known-good PSU, phone-hotspot test - and the device still loops in AP mode on your home network, open a D-Central support ticket or drop into Discord `#bitaxe-help` with your serial log. If provisioning fails on every network including a fresh phone hotspot, you have ESP32-S3 radio damage (ESD, reversed polarity, surge) - warranty territory.

D-Central bench process: intake log review, known-good network test, Web Flasher baseline reflash, serial-console reason-code capture, NVS dump for corruption analysis, ESP32-S3 radio sanity check via controlled association sweep, burn-in on a stable pool for 24 h before return. Flat bench-diagnostic fee applied to repair if hardware. D-Central honours Bitaxe warranty on units purchased through our store; units from elsewhere we diagnose for a modest fee.

Ship safely if the Bitaxe is heading to the bench. Anti-static bag, 5 cm foam on every side of the outer box. Include a note with board revision (printed on the PCB), current AxeOS version, your router model and firmware version, observed symptoms, and your contact. Context saves triage time, which saves you bench-hour dollars. D-Central Canada-wide turnaround 3-7 business days for Bitaxe-class work.