Whatsminer – DHCP IP Not Assigned

Hard-power the miner for 60 full seconds at the breaker — not a soft reboot via WhatsMinerTool, an actual breaker-off cycle. Wait the full 60 seconds so the PSU rails fully drop and the controller's RAM clears completely. Plug back in and let it boot for 5 minutes before checking DHCP. Roughly 15% of `no IP` reports clear with a clean cold boot — the controller wedged on a transient PHY auto-negotiation failure during a brownout earlier and is happy to retry from a clean state.

Replace the Ethernet cable with a different known-good Cat5e or Cat6 patch cable. Test the replacement on a laptop or another miner first to confirm it actually carries traffic. Don't reuse the cable that came in the box on a secondhand miner — those have lived rough lives. Damaged cables are the #1 cause of `link LED solid, DHCP fails` on bench intakes — about 40% of cases on D-Central's repair queue.

Move the Whatsminer to a different switch port — ideally a port directly on the router that hands out DHCP, bypassing every managed switch, PoE injector, or unmanaged switch in the current path. If DHCP completes there, the problem is in your switching path (port config, VLAN, or a failing switch), not the miner.

Confirm the link LED on the controller is solid or blinking with activity. Dark link LED = layer-1 problem (cable / port / PHY), not a DHCP problem. If the link LED won't light on any cable or any port, skip ahead to Tier 3 PHY diagnostics — the PHY chip is dead or the magnetics are damaged.

Plug a laptop into the exact same cable and switch port the miner is using. Does the laptop get an IP under 30 seconds? If yes, the LAN is fine and the problem is the miner. If no, the LAN is the problem — fix DHCP scope, switch port, or VLAN config before blaming the controller. This is the single highest-yield 30-second diagnostic on the whole troubleshooting tree.

Open your router admin and verify the DHCP scope has free leases. Look at the IP range, lease time, and active leases. Scope at 254/254 = full, no new device can lease. Extend the range to a /24 with 200+ free IPs, or purge stale leases. While you're there, set lease time to 24 hours minimum so dead-device IPs don't churn the table.

Run `WhatsMinerTool` `Detect` scan from a Windows machine on the same LAN. The tool broadcasts a discovery packet on UDP `4028`; any Whatsminer that has booted, leased, and started the BTMiner API responds with its IP and serial. If your miner doesn't appear in the scan results, either it hasn't completed DHCP (continue troubleshooting) or the BTMiner API hasn't started (boot-loop / firmware problem — different page).

Run `nmap -sn <your-subnet>/24` from a laptop on the same LAN. This pings every host in the subnet and lists who responds. Compare to the router's DHCP table. Look for new MAC addresses that match MicroBT-typical OUIs via `arp -a`. A MAC that's new but doesn't appear in the DHCP table = controller is broadcasting, but the lease isn't completing — usually a VLAN mismatch or a DHCP filter on the router side.

Disable any managed-switch VLAN tagging on the port the miner is using. Set the port to `access` mode on the same VLAN as your DHCP server. Don't use `trunk`, don't use a VLAN that doesn't have a DHCP server attached. If you're in a hosting environment, ask the operator to confirm the port's access VLAN ID before troubleshooting further. The Whatsminer's stock firmware sends untagged frames only.

Reset the controller's network config to factory via the recessed button on the back of the controller (most M30S+ / M50S generations have one — hold for 5–10 seconds with a paperclip while the miner is powered, until the LED pattern changes). This wipes any static-IP residue from a previous owner and forces the controller back into DHCP-client mode. Particularly important for any used / secondhand miner that's never appeared on your LAN.

Re-flash BTMiner via SD card if the factory reset doesn't clear it. Download the matching firmware for your model from `support.whatsminer.com`, write it to a microSD card per their docs, insert into the controller's SD slot, power on, and wait for the auto-flash sequence (typically 5–8 minutes; LED indicates flash state). This rewrites the OS partition and the network config, killing any wedged DHCP client state.

Capture a UART serial console log. Open the controller chassis. Find the four-pin UART header (silkscreened `TX RX GND VCC`, 0.1` pitch, near the SoC). Connect a 3.3 V USB-to-UART adapter — ground first, then crossover RX/TX. Do not connect VCC. Open a serial terminal at `115200 8N1`. Power-cycle the miner, watch the boot log for `eth0` link state, `udhcpc discover/offer/request/ack` lines, kernel panics, or watchdog resets. The log answers the next question authoritatively.

Set a temporary static IP via UART once the miner is at the BTMiner / Linux prompt. The exact command varies by firmware: M30S / M50S generations expose `btminer set network` style commands or accept a `network.conf` edit; M60S+ uses the newer `btminer-cli`. Goal: get the miner reachable on the LAN at any IP so you can SSH in, log full diagnostics, then re-enable DHCP from a known-working baseline.

Continuity-check the Ethernet PHY with a multimeter. Power off, probe between the RJ45 jack pins and the corresponding PHY chip pins (datasheet for `RTL8211` or your specific PHY is on Realtek's site). Open circuit on TX± or RX± = trace damage, cold solder joint at the magnetics, or a dead transformer. Reflow the magnetics or replace the PHY chip depending on what you find.

Replace the controller wholesale. Whatsminer controllers are not as freely cross-compatible as Bitmain's — match the exact model family (M30S vs M30S+ vs M30S++ have subtle differences). D-Central stocks recovered + tested controllers for the common M-series. Swap the controller, factory-reset, re-test DHCP. ~95% of confirmed `PHY dead` cases fix at this step.

Reflow the PHY chip on a hot-air station if you're confident with QFN/QFP rework. Set bottom preheat to 150 °C, top-side hot air at 300–320 °C for 30–45 seconds, let cool naturally, retest. This is a Hail-Mary on a controller otherwise headed for the bin — works ~30% of the time. Cheaper than a controller swap if you have the bench equipment and the patience.

Stop DIY and book D-Central ASIC Repair when UART log shows persistent `eth0: link is not ready` or `phy not found` even with a known-good cable on a known-good port, when replacing the controller with a known-good unit fixes the symptom (meaning the original controller is dead and you want a refurb), when you've reflowed the PHY and DHCP still fails, or when the controller is bricked at boot. Ship in an anti-static bag, double-boxed with foam, with a note describing the symptom history, firmware version, and your contact info.