Bitaxe – Stratum API Stuck After WiFi Timeout

Cold power-cycle for 10 full seconds: unplug the 5V barrel jack (Supra/Ultra/Gamma) or 12V XT30 (GT/Hex). Do not use the AxeOS soft-restart button — it can clear FreeRTOS scheduler state but does not reliably tear down an orphaned stratum TCP socket because the dead descriptor lives below the application layer. 10 seconds unplugged guarantees lwIP, the WiFi driver, and the FreeRTOS heap restart clean. Repower, wait 90 seconds, watch your pool dashboard for the share counter to resume incrementing.

Update AxeOS to the latest stable release from the ESP-Miner releases page. Download the correct .bin for your chip family (BM1366 for Ultra, BM1368 for Supra and Hex, BM1370 for Gamma and GT) and OTA-flash via AxeOS Settings -> Firmware Update. Builds shipped after the stratum-watchdog landing carry an explicit hung-socket detector that closes the dead TCP connection and re-runs mining.subscribe and mining.authorize automatically. Record your current version first; if OTA fails, recover via the Bitaxe Web Flasher (Chrome-based).

Reposition for stronger 2.4 GHz signal — target RSSI >= -65 dBm in AxeOS dashboard. The ESP32-S3 is 2.4 GHz only; if your router uses band-steering on a combined SSID, create a dedicated 2.4 GHz SSID and bind the Bitaxe to it. Band-steering confusion on combined SSIDs causes silent disconnect/reconnect cycles that pile beacon timeouts faster than any firmware can recover from. WiFi beacon timeouts are the single most-reported trigger of BITAXE_STRATUM_HUNG events.

Reserve a static DHCP lease for the Bitaxe MAC and pin DNS to 1.1.1.1 or 8.8.8.8. Static DHCP prevents 3 AM lease-renewal disconnects that have been correlated with stratum-stuck events on residential networks. Pinned DNS avoids ISP resolver timeouts when re-resolving stratum hostnames after a reconnect — those timeouts present identically to a stuck stratum task from the dashboard.

Disable router smart-WiFi features for the Bitaxe MAC: Asus AiMesh band-steering, TP-Link OneMesh client-steering, Orbi Smart Connect, and any client-power-saving or AI-WiFi toggle. Consumer routers can deem the Bitaxe's small stratum keepalive traffic 'inactive' and throttle or disconnect the client. Whitelist the MAC against these features. Rigs on stock OpenWrt or pfSense rarely encounter this — the bug is largely a consumer-router pathology.

Install a scheduled smart-plug watchdog (Kasa HS103, Shelly Plus Plug S, or Athom plug) in front of the Bitaxe PSU. Configure a 30-second power-cycle every 6-12 hours. Until every Bitaxe in the field is on watchdog-equipped firmware, this bounds your worst-case lost hashing window to half the cycle interval. A $15 plug pays for itself within a month on any rig that's seen even one stuck-stratum event. Confirm 24/7 always-on rating and PSU inrush handling.

Verify PSU output rail under load with a multimeter. Probe the barrel jack (Supra/Ultra/Gamma) or XT30 (GT/Hex) while the Bitaxe is hashing at full load. Target: 5.10-5.25 V on Supra/Ultra/Gamma, 12.0-12.3 V on GT/Hex. Brownout-adjacent rails cause ESP32 transient resets that the WiFi driver papers over but that leave the stratum task in a half-initialized state. Swap to a correctly-rated PSU (60 W+ for Gamma, 20 W+ for Supra/Ultra, 200 W+ for Hex) and observe for 24 hours.

Open a serial terminal at 115200 baud over USB-C and scan recent log history for `Brownout detector was triggered`. Any occurrence is a smoking gun that your PSU cannot sustain load — fix the power before chasing firmware. The brownout detector is an ESP32 hardware feature; its messages are unambiguous. Combine with the verbose-log capture in Tier 3 if you need to triangulate WiFi vs PSU as the trigger.

Add a $10 ferrite clamp to the PSU output cable and consider a UPS with active power-factor correction. RF interference from a microwave, fluorescent ballast, or shared-circuit appliance can swing the Bitaxe RSSI by 5-10 dB — the difference between stable WiFi and frequent beacon timeouts. Esoteric-sounding, real in practice on shared residential outlets. Negligible cost, measurable downstream effect on stratum-hang frequency.

Configure stratum failover on AxeOS v2.5.x or later. Set primary (Solo CK, Public Pool, Ocean, or Braiins) and a backup pool on a different upstream path. When stratum desyncs, failover can re-home the connection before the ASIC task starts piling unsubmitted nonces. Zero-downside change — configure it whether or not you have seen the bug. Test failover by temporarily blocking the primary pool at the router for 30 seconds; AxeOS should switch to the backup automatically.

Build ESP-Miner from source with CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y and flash. Run until the next stuck-stratum event (hours to days). Capture the last 5 minutes of serial log. Pattern identifies the path: `wifi:bcn_timeout` followed by no further `asic_result` activity = path #1 (orphan socket). `unhandled method in stratum message` after a WiFi reconnect = path #2 (pool client.reconnect ignored). No WiFi activity but `mining.submit` piling unanswered = path #3 (silent NAT drop). Post the log to ESP-Miner issue #252.

Build and flash a watchdog PR branch from the skot/ESP-Miner repo. Check open PRs tagged stratum, watchdog, or keepalive. As of 2026-04 there are multiple in-flight candidates adding hung-task detection to stratum_task and explicit SO_KEEPALIVE enablement on the stratum socket with sub-minute probe intervals. Requires ESP-IDF v5.1+ and basic C familiarity. Test rigs on watchdog-PR builds show order-of-magnitude reduction in stuck-stratum frequency.

Wire an external hardware watchdog: Adafruit TPL5110 (P/N 2858) or repurposed Witty Pi Mini, configured to monitor a heartbeat GPIO pulse from the ESP32-S3 and hard-cut PSU power if the pulse stops. Bitaxe debug header exposes unused GPIOs that can drive the heartbeat. Overkill for a single miner; correct architecture for a 10+ Bitaxe home farm where bulk smart-plug cycles would chew aggregate uptime.

A/B test pool implementations. Switch from current pool to a different stratum implementation for one week (Solo CK, Public Pool, Ocean, Braiins all behave differently around client.reconnect and idle-TCP). If hang frequency changes meaningfully, you have narrowed the failure to path #2 (pool-side reconnect handling). Report findings to ESP-Miner issue #252 — A/B data is gold for upstream debugging and helps land deterministic fixes faster.

Stand up a Raspberry Pi Zero 2W (or any always-on machine on the same LAN) running a 5-minute cron. Poll /api/system/info for live hashrate and your pool API for last-share timestamp. If AxeOS reports hashing for >15 minutes without a pool-side share, fire a Shelly or Kasa smart-plug API call to power-cycle. Open-source scripts exist on GitHub — search 'bitaxe watchdog raspberry pi'. About $25 in parts (Pi + plug). Full DIY SRE loop, zero touch once running.

Suspect hardware, not firmware, when: stuck-stratum recurs within 60 seconds of every boot (deterministic, not intermittent), or System Info shows ASIC: None during the hang, or nominal power draw drops sharply during the event. BM1366/1368/1370 UART contact issues, ESP32-S3 flash corruption, TPS546 regulator faults on Gamma/GT, and damaged 2.4 GHz front-end matching networks all present similarly. None of these clear with firmware updates or smart-plug watchdogs — they need bench diagnostics.

Ship to D-Central for bench diagnostic. We have been in this ecosystem since the first Bitaxe shipped — manufactured the original Bitaxe Mesh Stand, built the first Bitaxe and Hex heatsinks, and stock every variant in the lineup. Bench process: USB-C serial capture under load, RF spectrum scan of the 2.4 GHz front end, PSU rail logging, full firmware reflash via JTAG if OTA path is corrupted. Include serial log dump, firmware version, pool name, event-frequency notes — saves 30-60 minutes of bench time. Canada-wide, US, international shipping. Turnaround 5-8 business days.