Bitaxe – DHCP Lease Expired / Random Disconnects

Reserve a static DHCP lease for every Bitaxe MAC. Open your router admin UI -> LAN -> DHCP Server -> Address Reservation. Source the MAC from the AxeOS dashboard's network info or the current router lease list. Bind to an IP outside the dynamic pool (if pool is 192.168.1.100-200, use 192.168.1.50 upward). Save. Reboot the Bitaxe to force lease re-acquisition. Verify the new IP in the dashboard. Static reservation eliminates every failure path described in Root Cause in one move — this is the single most-effective fix.

Increase the DHCP lease time to 7 days (604800 seconds) or longer. In the same DHCP settings page find Lease Time and change from the default 86400. Some routers want minutes (10080) or hours (168). On 7-day leases the T1 renewal fires every 3.5 days instead of every 12 hours, dramatically reducing the number of renewal events where the bug can fire. Reboot router, observe 72 hours. Combine with Step 1 for belt-and-suspenders.

Move the Bitaxe to an IP outside the dynamic pool via direct static IP. AxeOS Settings -> Network -> Static IP — enter address, gateway, subnet mask, and DNS (1.1.1.1 + 8.8.8.8). ESP32 lwIP supports static IP cleanly and bypasses DHCP entirely. Trade-off: requires manual update if you change subnets. For a stable home-rack address scheme the trade is worth it, especially as a fallback when router admin access is constrained.

Disable router smart-reclaim features for the Bitaxe MAC: Asus AiMesh, TP-Link Archer Active Client Detection, Netgear Orbi Smart Connect, and ISP-gateway QoS / Active Devices toggles. These prune leases on heuristics that misclassify low-traffic devices. Whitelist per-MAC where supported, or globally disable. The Bitaxe's stratum + share submission traffic is small in bytes-per-minute by design — every smart-reclaim feature mistakenly flags it as inactive.

Verify your DHCP pool is not exhausted. Count active clients in the router's lease list. If above ~75% of the pool size (default 100 for consumer routers), expand the pool. Expanding from 192.168.1.100-200 to 192.168.1.50-250 is two field edits on most routers. Reboot router. Non-negotiable in households with 50+ smart devices and a multi-Bitaxe rack on the same subnet.

Schedule a keepalive ping to each Bitaxe IP every 2 minutes from an always-on LAN device (NAS, Raspberry Pi, always-on desktop). Cron entry: `*/2 * * * * /bin/ping -c 1 192.168.1.50 >/dev/null 2>&1`. This keeps the router's ARP entry fresh, which keeps the unicast DHCP renewal path alive, sidestepping failure path #1. Negligible bandwidth cost. Five-minute setup.

Enable detailed DHCP logging on the router. OpenWrt: `logread -e dnsmasq`. pfSense / OPNsense: System -> Settings -> Logging -> enable DHCP logs. Consumer routers: usually a system-log toggle in admin UI. Once enabled, you'll see DHCPACK / DHCPNAK / DHCPDISCOVER lines for each Bitaxe at every renewal cycle. Confirm static reservations are honoured and no DHCPNAK events appear for the Bitaxe MACs.

Move multi-Bitaxe rack to a dedicated VLAN. On any router supporting VLANs (OpenWrt, pfSense, Ubiquiti, eero Pro, Asus Merlin), create a MINING VLAN with its own DHCP pool sized to your rack + 50% headroom. Isolates Bitaxes from household DHCP scope pressure, IoT churn, and guest-network multicast storms. Right architecture for any rack of more than 4 Bitaxes.

Run a Pi-based DHCP / ARP monitor. Raspberry Pi Zero 2W ($25 with SD card) on the same subnet running `arp-scan` once per minute and logging to a file gives ground-truth visibility into which Bitaxes are present. Combine with the keepalive ping in Step 6 for full state observability with zero touch. Cron: `* * * * * /usr/sbin/arp-scan -l >> /var/log/lan-scan.log`.

Stand up a watchdog that alerts on Bitaxe disappearance. Same Pi: poll /api/system/info on each Bitaxe every 5 minutes; alert via Discord webhook / Pushover / NTFY when any Bitaxe stops responding for 10+ minutes. Integrates cleanly with the smart-plug power-cycle pattern from Stratum Stuck After WiFi Timeout — same monitoring infrastructure covers both bugs.

Replace consumer router with OpenWrt, pfSense, or OPNsense. Long-term answer for any serious home-rack operator. OpenWrt on a Linksys WRT3200ACM, GL.iNet Flint, or Mikrotik gives proper dnsmasq DHCP behavior with no aggressive-reclaim heuristics, full ARP-aging control, real DHCP logs, and trivial VLAN setup. Cost: $80-300 one-time. Eliminates an entire class of consumer-router pathology bugs across your whole network.

Build ESP-Miner from source with longer DHCP timeout knobs. ESP-IDF exposes CONFIG_LWIP_DHCP_RESTORE_LAST_IP and DHCP option timing through menuconfig. Building AxeOS from source with longer renewal-retry timeouts reduces the likelihood of a transient renewal-failure cascade. Requires ESP-IDF v5.1+ and basic C familiarity. Document changes; submit upstream as a PR if you find a knob that materially helps.

Wire a smart-plug watchdog (Kasa HS103 / Shelly Plus Plug S) scheduled to power-cycle every 12-24 hours as the final safety net. Bounds your worst-case lost hashing window even when DHCP, WiFi, and stratum all conspire. $15 per Bitaxe. Same hardware investment that covers the stratum-stuck bug, OTA-bricked bug, and brownout bug — covers DHCP-lease-expired too.

Audit ESP32 WiFi power-save mode. AxeOS Settings -> Advanced -> WiFi Power Save: set to off for any rig that has seen this bug. Power-save can interact poorly with multicast / broadcast DHCP frames during the renewal window. Cost: ~50 mW per Bitaxe — negligible vs lost hashing during disconnect events. Reboot to apply. Verify via serial log that `wifi:set ps_type:0` is being applied at boot.

Audit the subnet for DHCP server conflicts. A second DHCP server on the same broadcast domain (ISP modem in router mode + separate WiFi router both serving DHCP, or a Pi-hole misconfigured as DHCP) produces unpredictable DHCPACK/DHCPNAK races identical to BITAXE_DHCP_LEASE. Run `nmap --script broadcast-dhcp-discover` from any LAN client. Exactly one DHCP server should answer. If two answer, fix that first — every other diagnosis is contaminated until you do.

Suspect hardware not network when: disconnect events happen on initial boot (not 12-24h later), or coincide with `Brownout detector was triggered` in serial log, or the Bitaxe never successfully acquires an initial DHCP lease at all. ESP32-S3 RF front-end damage, antenna trace cracks, undersized PSU causing brownout-adjacent boot, or NVS corruption present similarly. Tier 1-3 fixes will not help. The bench is the next step.

Ship to D-Central for bench diagnostic. Pioneer Bitaxe shop — manufactured the original Bitaxe Mesh Stand, built first heatsinks for both Bitaxe and Bitaxe Hex, stock every variant. Bench process for suspected DHCP-clocked issues: USB-C serial log capture under load over 48 hours on a controlled DHCP fixture, RF spectrum scan of 2.4 GHz front end, antenna-trace continuity check, PSU rail logging during renewal-cycle windows, full firmware reflash via JTAG if NVS corruption suspected. Include serial log dumps, router make/model and firmware, observed disconnect cadence. Canada/US/international shipping. 5-8 business-day turnaround.