Whatsminer – Network Configuration Reset

Press the `IPFOUND` button on the miner chassis and record the IPv4 address displayed on the front LED/LCD. If it's a DHCP-assigned address in your DHCP scope, the miner is alive and waiting for re-provisioning — proceed to Step 2. If it displays `0.0.0.0` or `169.254.x.x` link-local, DHCP did not answer; check the router and retry in 60 seconds. No response to the button at all points at a wedged control board — skip to Tier 3 recovery.

Log into the web UI at `http://<miner_ip>` using factory defaults `admin` / `admin`. If that succeeds, the config reset is confirmed. Note the firmware version on the dashboard — if it differs from your last-known build, a firmware upgrade is the likely root cause. Screenshot every field in the Network and Miner Configuration tabs before you change anything; this becomes your baseline for the runbook update.

Re-apply the static IP, netmask, gateway, and DNS from your ops runbook. Use the exact IP the miner had before so your monitoring stack (Prometheus, Grafana, Uptime Kuma, pool-side dashboards) finds the miner without any scrape-target edit. Save, let the miner reboot its network stack for roughly 30 seconds, and verify the IP holds by pinging from the workstation.

Re-apply pool URLs, worker names, and pool passwords. Pool 0 = primary, Pool 1 = backup on a different operator (never the same pool's secondary URL — if their DNS dies you want a different operator altogether), Pool 2 = solo-mining or D-Central internal pool for lottery runs. Use `stratum+tcp://` for broad compatibility; use `stratum+ssl://` only if the pool documents support and you've verified the cert chain against MicroBT's firmware.

Reset the admin password away from factory `admin` to a value tracked in your password manager. Document the change in the ops wiki alongside the miner's serial and physical location. Never leave a Whatsminer on `admin` / `admin` in any environment where more than one person has network access — pool-hijacking botnets scan for this default on TCP `4028` continuously.

Re-apply power-limit, frequency/voltage tuning, and timezone. If you were running a custom power-limit profile (e.g. `2700 W` on an M30S++ to fit a 15 A residential circuit), re-apply it before the miner hashes at factory-default wide-open power and trips your breaker. Set the timezone to match the site's physical location for sensible log timestamps and scheduled-reboot windows.

Use WhatsminerTool's batch config workflow (Remote Ctrl → Batch Config) to push a saved XML template across the affected unit and any fleet siblings. WhatsminerTool V9.0.1 exports a known-good miner's config to XML and imports onto others — the correct way to re-provision more than a couple of units. Never hand-type config across 10+ miners; use the batch path every time.

Pull a full config snapshot via the TCP `4028` API immediately after re-provisioning: `echo '{"command":"summary+pools+devs"}' | nc <miner_ip> 4028`. Output returns pool URLs, worker names, per-chain hashrate, and firmware state. Store the JSON in your ops repo (timestamped, per-miner) — it becomes the canonical last-known-good snapshot for the next incident.

Set a DHCP reservation at the router (MAC → IP mapping) for this miner, even if you're also running a miner-side static IP. A reservation lives on the router and survives any miner-side config wipe — the next factory reset still hands the miner the same IP. This single move roughly halves the operational frequency of 'where did the miner go?' incidents across any fleet we manage.

Verify the API switch state (should be ON for WhatsminerTool), pool fallback order (`0→1→2` — factory default is correct), and DNS servers (set explicit `1.1.1.1`+`1.0.0.1` or `8.8.8.8`+`8.8.4.4`, not 'automatic' — ISP DNS outages manifest as apparent pool-connection failures). Save and reboot the miner; confirm all four fields persist across reboot.

SSH into the miner (`ssh admin@<miner_ip>` — stock MicroBT firmware accepts SSH with the admin password) and run `cat /config/network.conf` plus `cat /config/pool.conf`. Output should match what you just entered in the web UI. If `/config/` is empty, the files are zero bytes, or they revert after reboot, the write did not persist — the eMMC is failing or a firmware bug is clobbering `/config/` on boot. Proceed to Tier 3.

Reflash stock firmware from a signed `.bin` obtained from `support.whatsminer.com` — open the web UI → Upgrade Firmware → upload the signed image, let the progress bar complete, allow reboot. Many MicroBT builds wipe `/config/` on install, so record config before flashing, re-provision afterwards from the saved snapshot. Never flash an unsigned image or cross-model `.bin` — wrong firmware for the wrong hardware revision bricks the control board and lands you in Tier 4.

If the miner runs custom firmware (Vnish, Asicdip, HiveOS) and the config reset was triggered by a firmware-version boundary, understand the tradeoff: custom firmware delivers better per-chip visibility and tuning but breaks MicroBT stock tooling (WhatsminerTool V9.x refuses to enumerate custom builds via anti-tamper codes `100001` / `100002` / `100003`). Either stay on custom and use that firmware's native dashboard / config workflow, or reflash stock and accept MicroBT's autotuning ceiling.

Write a scripted batch re-provisioning workflow for fleets. A shell / Python script iterates miner inventory, opens TCP `4028` on each, sends `{"command":"update_pools","pool1":"stratum+tcp://...","worker1":"...",...}` (encrypted-command token required — consult Whatsminer API V2.0.4 for the exact format), and logs success/failure per unit. This is the professional answer to 'all 47 miners reset to factory after a firmware push' — never hand-enter config on more than 2-3 units in a row.

eMMC health check via SSH: `cat /proc/mtd` to see the flash partition layout; `dmesg | grep mmc` to look for `bad block`, `ecc error`, or `mmc0: write failure`. Any of those lines means the eMMC is physically failing — the control board needs to be replaced or re-programmed on a bench fixture. Do not re-provision repeatedly on a dying eMMC; each rewrite can accelerate additional bad-block development.

Attempt firmware rollback only with signed MicroBT images. Some builds refuse to downgrade via bootloader version-pinning. If rollback through the web UI fails, use the model-specific IPFOUND-button-plus-power-cycle recovery sequence (M30 / M50 / M60 each have a slightly different procedure — consult your model's recovery doc). Recovery mode exposes a bootloader shell capable of flashing any signed image.

Stop DIY when the config wipe repeats after clean re-provisioning, `dmesg` shows eMMC errors, the miner is stuck in recovery mode and rejects stock reflash, or the unit is silent on the wire with PSU live. Book a D-Central ASIC repair slot — we stock replacement control boards for M20 through M66 series and re-provision on a bench fixture with a known-good PSU, a signed-firmware image, and a post-repair 24 h burn-in at nameplate.

Ship the miner (or just the control board if you're comfortable pulling it) in an anti-static bag, double-boxed with minimum 5 cm of foam on every side. Include a note with the miner's serial, last-known firmware version, observed symptoms, and the Tier 1-3 steps you already tried. This cuts D-Central's diagnostic time in half and directly saves you money on the repair bill. Canada-wide shipping standard; US and international welcomed.