Bitaxe – AxeOS Connection Issues

Power-cycle the Bitaxe with a full 30-second unplug and scan for Wi-Fi networks with a phone after each retry. A fresh or NVS-wiped Bitaxe emits an AP named `Bitaxe_XXXX` where the last four hex characters are part of the MAC. If you see the AP, proceed to step 3. If you do not, your provisioning already completed and the device is trying to join your home Wi-Fi - go to step 5. If nothing happens and the OLED is blank, you are not in the right playbook; move to the Bitaxe ESP32 Crash Loop page.

On your router, expose the `2.4 GHz` band as its own dedicated SSID. Log in at `192.168.1.1` or `192.168.0.1`, find Wireless / Wi-Fi Settings, disable `Smart Connect` / `Band Steering` / `AiMesh Smart Connect`, and create a separate SSID for the `2.4 GHz` radio - e.g. `HomeNet-2.4G`. Save, wait 60 seconds for the AP to come back up, then re-provision the Bitaxe onto that SSID. This single fix resolves the majority of AxeOS connection tickets. ESP32-S3 does not speak `5 GHz` - do not fight this.

Connect your phone or laptop to the `Bitaxe_XXXX` AP and load `http://192.168.4.1` in the browser. The captive portal shows the Wi-Fi provisioning form. Enter your dedicated `2.4 GHz` SSID and the password exactly - case matters. Click Save. The Bitaxe reboots, joins your LAN, and the `Bitaxe_XXXX` AP disappears from the airwaves. If the portal will not load even while your phone shows connected to the AP, disable auto-join on your phone's primary Wi-Fi so the phone does not race back to it.

Look up the Bitaxe in your router's DHCP client list. The hostname will be `bitaxe` or similar; the MAC prefix is Espressif. Bookmark the raw IP (`http://192.168.x.x`) in your browser. Use this raw IP as your canonical AxeOS URL from now on - it is faster and more reliable than `http://bitaxe.local`, which depends on multicast DNS being passed through your router. On most modern routers you can also pin a DHCP reservation to the Bitaxe's MAC so its IP never changes across reboots - do that now.

Hold the `BOOT` button on the Bitaxe PCB for 10+ seconds during power-on to wipe NVS Wi-Fi credentials. Release. Wait for the `Bitaxe_XXXX` AP to reappear. This factory-resets the stored SSID and PSK without touching the firmware. The NVS partition is where ESP-IDF caches Wi-Fi state; corrupted or stale credentials from a previous network are the second-most-common cause of join failures. Return to step 3 and re-provision from scratch.

Move the Bitaxe closer to the router. ESP32-S3 Wi-Fi power output is nominal and the Bitaxe chassis is small metal + PCB; signal attenuation through walls, concrete, and metal is significant. For the duration of provisioning, park the Bitaxe on the same table or room as the router. Once associated, you can move it back - but if the miner repeatedly drops after re-association, you have a signal problem and need a `2.4 GHz` AP closer to the Bitaxe's final home.

Change your router's `2.4 GHz` channel from `Auto` to channel `1`, `6`, or `11` explicitly. These are the only non-overlapping channels in the `2.4 GHz` band in North America, and `Auto` often parks on a congested mid-channel. Pick the channel with the fewest neighbouring APs by running a Wi-Fi analyzer app on your phone. Reboot the router after changing. This fixes the specific class of `associates-then-drops-every-30s` symptom where the logs show `beacon timeout`.

Set your router's DNS to `1.1.1.1` (Cloudflare) as primary and `8.8.8.8` (Google) as secondary. Navigate to WAN / Internet settings in the router admin, find the DNS override, paste both, save, reboot the router. ISP DNS is the #1 reason a Bitaxe shows `Wi-Fi connected` but `Pool: Not Connected`. The stratum hostname fails to resolve and AxeOS cannot distinguish DNS failure from pool failure in the UI. This one change fixes hundreds of tickets D-Central sees every year.

Disable `AP Isolation` / `Client Isolation` / `Guest Network Isolation` on the SSID the Bitaxe is using. This setting is the reason `http://bitaxe.local` fails but `http://192.168.x.x` works - isolation blocks mDNS multicast. On Canadian ISP gateways (Bell Hub 4000, Videotron Helix, Rogers Ignite) this is often on by default; on ASUS / TP-Link / Netgear consumer routers it is usually off but check the Wireless > Professional tab. Save, reboot the router, retry `.local`.

If you are on an ASUS router, disable `AiProtection` entirely for testing - or at minimum whitelist the Bitaxe's static IP. AiProtection's `Infected Device Prevention` silently drops outbound connections to stratum ports `3333 / 4444` and does not surface the block in any user log. This is documented across the Facebook Bitaxe Worldwide group but absent from ASUS's own support pages. After disabling, reboot the Bitaxe. If the pool connects instantly, you have found your culprit - whitelist the Bitaxe's reserved DHCP IP and re-enable AiProtection for the rest of your network.

If outbound stratum ports are firewalled (hotel Wi-Fi, corporate LAN, university, some ISPs), switch to a pool that exposes port `443`. Public Pool (`https://web.public-pool.io/`) is the go-to solo mining option with a `443` endpoint. Port `443` is HTTPS and is almost never blocked by any firewall. In AxeOS, update `Stratum URL` to the new hostname and `Stratum Port` to `443`, save, reboot the miner. Verify shares landing on the pool dashboard within 5-10 minutes.

Verify your wallet address in AxeOS is exactly correct - a Bitcoin address typo manifests as `Pool: Connected` but `zero accepted shares forever`. Copy-paste from your hardware wallet or from a trusted source, never retype. Some pools (solo.ckpool, Public Pool) accept legacy `1...`, SegWit `bc1q...`, and Taproot `bc1p...` addresses; others are stricter. Double-check the exact format the pool expects, match it, save, reboot the miner. This is the #3 cause of 'miner shows connected but pool shows no shares' across D-Central tickets.

Check the Bitaxe firmware version against the known-bad list. Skip `v2.1.5` (reboot regression, fixed in `v2.1.6` - [GitHub #182](https://github.com/bitaxeorg/ESP-Miner/issues/182)). Skip `v2.14.0b1` (swarm broken, [#1658](https://github.com/bitaxeorg/ESP-Miner/issues/1658)). The `stratum_api` stuck bug from [#252](https://github.com/bitaxeorg/ESP-Miner/issues/252) affects various `v2.x` builds where a Wi-Fi blip leaves the pool socket in a broken state and the firmware does not reset it. Update to the latest stable release via `Settings > Firmware Update` (OTA) if the version is suspicious.

If DNS and AiProtection are both clean and the pool still will not connect, set up a packet capture on your router or a mirror port to watch the Bitaxe's traffic. Look for outbound `SYN` packets to the stratum host on the configured port. If you see `SYN` with no `SYN-ACK` reply, the pool server or the intervening firewall is dropping the connection. If you see `SYN` and `SYN-ACK` but no sustained data flow, the stratum handshake is failing - check the pool status page, that pool may be down. This is the last diagnostic before hardware / firmware territory.

Put the Bitaxe into USB-C bootloader mode. Press and hold `BOOT` on the PCB, tap `RESET` while still holding `BOOT`, release `BOOT`. The ESP32-S3 is now in ROM bootloader mode, which is mask-ROM and cannot be damaged by any firmware event. On Windows, check Device Manager for a new `COM` port; on macOS `ls /dev/cu.*` will show a new `usbserial`; on Linux `dmesg | tail` will show a new ttyACM / ttyUSB. If the host OS sees the device, the ESP32-S3 is alive and you can proceed to Web Flasher recovery.

Open the Bitaxe Web Flasher at `https://bitaxeorg.github.io/bitaxe-web-flasher/` in Chrome or Microsoft Edge. Firefox and Safari do not support WebSerial and will not work. Select the EXACT factory image for your Bitaxe board revision - Ultra `202/204/205/207`, Supra `401`, Gamma `601/602`, Hex `v303/v304`, Max each have different images. Flashing the wrong one will not physically damage the board but will prevent correct boot until re-flashed correctly. Click Flash and wait - a full factory flash takes ~60-90 seconds over a good USB-C data cable.

After flashing, disconnect USB-C, reconnect main PSU, wait 60 seconds. The Bitaxe should emit a fresh `Bitaxe_XXXX` AP because the factory image wipes NVS. Return to step 3 and re-provision Wi-Fi from scratch. This recovers any AxeOS connection failure caused by corrupted NVS, bad firmware partition, failed OTA, or a firmware version regression. The ROM bootloader guarantees this path works if the ESP32-S3 is electrically alive - confirmed across OSMU Discord and Solo Satoshi's unbricking guide.

If the Web Flasher fails mid-flight (common over slow Wi-Fi-connected laptops or flaky cables), try a different USB-C cable - one you know passes data, not just power. Cheap charging cables often omit the data lines. A good test: does the host OS enumerate the Bitaxe as a serial device when you plug in? If not, bad cable. Try a different USB-C port on the host, ideally a directly-connected USB 3 port, not a hub. Retry the flash.

Use the ESP32-S3 serial console for deeper debugging. Connect USB-C and open a serial terminal (PuTTY, minicom, screen) at `115200 baud, 8N1`. Reset the Bitaxe - the boot log scrolls. Look for `wifi:sta: beacon timeout`, `wifi_disconnect reason: N`, `AUTH_EXPIRE`, `brownout_det: detected`, or `Guru Meditation Error`. Each gives a specific direction. Beacon timeout = signal / band / channel issue. Auth expire = wrong PSK. Brownout = PSU. Guru Meditation = crash - go to the ESP32 Crash Loop page instead.

Roll back firmware via USB-C Web Flasher if you are on a known-bad build. Download the last-known-good factory image from the [bitaxeorg/ESP-Miner releases page](https://github.com/bitaxeorg/ESP-Miner/releases) - not the latest, but the release before the regression. Use the Web Flasher in ESP tool mode with a custom image URL. Re-flash, re-provision. This is the fix for `v2.1.5` reboot regression and for devices stuck on betas that broke networking.

If Wi-Fi works on a phone hotspot but fails on your home network across all steps above, isolate the router feature-by-feature. Temporarily put your router in bridge mode and use a second router (known-good) in front. Or, if you own a Canadian ISP gateway (Bell, Videotron, Rogers), buy or borrow a consumer router like an ASUS RT-AX58U, put the ISP gateway in bridge mode, connect your own router, and re-provision the Bitaxe onto the new SSID. This is the long-term fix D-Central recommends for Canadian home miners stuck on restrictive ISP hardware.

Open a D-Central support ticket at `https://d-central.tech/contact/` or join the OSMU Discord (`https://discord.com/invite/osmu`) and post in the Bitaxe help channel. Include: Bitaxe model + board revision, current firmware version, full serial boot log from step 19, a list of everything you have already tried (tiers 1-3), your router model, your ISP, and whether the device works on a phone hotspot. A good ticket gets a fix inside a day; a vague ticket takes a week of back-and-forth.

If D-Central support confirms hardware-level Wi-Fi damage (ESD on USB-C, PSU overvoltage that took out the ESP32-S3 radio die while leaving the MCU core alive), we quote a repair. Depending on the board revision, this is a component-level rework - desolder the ESP32-S3 module, replace, re-program bootloader. Typical cost `CAD $75-$150` plus return shipping. For a `CAD $150-$300` Bitaxe, repair makes sense on rare or discontinued boards; for current-shipping Ultra / Gamma, a replacement is often equal cost.

Swarm-mode coordination failures after a firmware update are a special case. All Bitaxes in the swarm must run the same firmware version. Roll every member back to the last release where swarm worked - typically the stable before `v2.14.0b1`. Re-provision each one individually, then re-add to the swarm via the AxeOS Swarm tab. Do not run mixed versions. File any reproducible swarm bug on the bitaxeorg/ESP-Miner repo with logs - the maintainers are responsive to reproducible reports.

If all four tiers fail and you are ready to replace the Bitaxe, D-Central stocks every variant - Supra, Ultra, Hex, Gamma, GT, Max - plus spare ESP32-S3 modules, replacement OLEDs, and every heatsink / stand / PSU that ships with them. We have been a pioneer in the Bitaxe ecosystem since the beginning: we manufactured the original Bitaxe Mesh Stand, the first Bitaxe and Bitaxe Hex heatsinks, and we will help you pick a replacement board that will not repeat the same problem. Browse at `https://d-central.tech/product-category/open-source-miners/`.