ASIC Miner – Network Not Found / No IP
Warning — Should be addressed soon
Symptoms
- Miner powered on, fans spinning, hashboards audibly working — but no entry in the router's DHCP client table for the miner's MAC
- Vendor discovery tools (IP Reporter, WhatsminerTool, AvalonMaster, IMiner Tool) and Angry IP Scanner all return nothing
- `arp -a` on a PC on the same subnet shows no entry for the miner's MAC
- RJ45 link LED on the miner is dark despite a known-good cable in a known-good port
- RJ45 link LED is lit but the port is negotiating at 10 Mbps instead of 100 Mbps
- Miner briefly appears on the network after a cold-boot, then vanishes within minutes
- IP Report button produces no audible chirp, or chirps but no address is announced on the LAN
- Web UI fails to load at any IP in the router's scope or at the miner's factory default
- Router logs show the miner's MAC requesting `DHCPDISCOVER` in a loop with no `DHCPACK` back
- Fault appeared immediately after an ISP router swap, firmware update, or a new device joining the LAN
- Neighbouring miners on the same switch are hashing fine — only this one is offline
- `ssh: connect to host X.X.X.X port 22: No route to host` when previously configured
Step-by-Step Fix
Cold-boot the router at the wall for 60 seconds, then cold-boot the miner at the PDU for 60 seconds. Bring the router up first, wait 2 minutes for DHCP to initialize, then power the miner. This clears stale DHCP leases, frozen ARP entries, and wedged NAT tables — the single most common Tier-1 fix and it costs zero dollars. Give it 5 minutes after the miner boots before declaring failure; some controllers retry DHCP with exponential backoff and need the full window to grab a lease.
Swap the Ethernet cable with a known-good `cat5e` or `cat6`, straight-through, under 10 m. Route it away from high-voltage conduit and motor windings. Watch the RJ45 link LED on both ends — a healthy miner shows steady or slow-blinking green within 5 seconds of insertion. Avoid `cat5` (obsolete, fragile) and runs over 10 m on unshielded cable. If the link LED returns on a fresh cable, you had a silent cable failure — label and retire the old cable, it won't get better.
Move the miner's cable to a different switch or router port. Consumer gateways develop dead ports over time from brownouts and transients; the other ports usually work fine. If the link returns on a different port, mark the dead one, move on, and plan to replace that router before it takes out more ports. Don't accept a 'works on port 3 only' gateway in a production rack — it's telling you the PHY silicon is halfway dead already.
Widen the DHCP scope in your router's admin UI from the default ~50 addresses to at least `/23` (`192.168.0.0 – 192.168.1.255`) or reduce the lease time to 2 hours. Scope exhaustion is silent — the router doesn't warn you, it just stops handing out leases. A 24-miner rack plus typical household devices will exhaust a factory default. This setting lives under 'LAN Settings' or 'DHCP Server' on most consumer routers and takes about 90 seconds to change.
Check MAC filter, VLAN, parental controls, and captive portal in the router admin UI. ISP routers frequently ship with 'new device approval' enabled or block unknown MACs for parental-control purposes. Confirm the miner's MAC isn't on a deny list or quarantined on a guest VLAN with no internet egress. Add the MAC to the allowlist, move it to the primary VLAN, disable captive-portal enforcement for mining subnets. Cold-boot the miner after each change.
Factory-reset the miner's network config. On Antminer: hold the `IP Report` button for 10 seconds until you hear a long beep, then cold-boot. On Whatsminer: hold the reset pin for 5 seconds. On Avalon: power-cycle while holding the reset button for 10 seconds. This clears any stuck static-IP config in non-volatile memory and forces DHCP on next boot. If the button itself doesn't respond (no beep, no LED change), jump to Step 7 — the control board is likely the issue, not the config.
Flash factory firmware via SD card (Antminer: 16 GB FAT32 micro-SD with image from service.bitmain.com/support/download) or USB (MicroBT, Canaan, Innosilicon recovery utilities from their respective vendor portals). Insert, boot, wait for the full flash cycle (~5-10 minutes), remove media, cold-boot. Resets any corrupted network config in non-volatile storage — this is the #1 Tier-2 fix after a failed firmware update bricked the network stack. Verify the image matches your board revision before flashing; wrong image bricks the board.
Static-IP bypass test. Assign a laptop `192.168.1.99/24` with gateway `192.168.1.1`, plug it directly into the miner with a known-good `cat5e+` cable. Modern PHYs handle the crossover via auto-MDIX. Try browsing `http://192.168.1.1`, `http://10.10.10.1` (Whatsminer default), and the miner's last-known IP. If the UI answers on a direct connection, the miner is healthy and your network — router, switch, wiring — is the problem. Rebuild from the router outward.
Inspect the RJ45 connector mechanically. Power off and unplug. Flashlight into the jack — look for bent internal pins, corrosion on contacts, cracked plastic, missing spring-loaded retention tab. Gently seat a clean cable, confirm the click-lock. Wiggle the cable lightly while watching the link LED — a healthy jack shows zero flicker. A visibly damaged jack needs replacement with SMD rework, which is Tier 4 for most operators. Document with a photo before shipping.
Test the switch or router port with a second device. Plug a laptop or phone into the exact port and cable combination that the miner was using. If the laptop gets a DHCP lease immediately, the problem is miner-side and you can skip to Tier 3. If the laptop also gets nothing, the port, cable, or the upstream subnet is the problem — fix that before spending more time on the miner.
Pin a static DHCP lease in the router once you have the miner working. Reserve its MAC to a fixed IP in the router's DHCP reservation table, outside the dynamic scope. Convention: `192.168.1.X` where `X` is outside the DHCP pool range. Prevents scope-exhaustion-at-3am disappearances, makes the miner findable forever, and gives you a stable target for monitoring scripts. Do this for every miner before deployment — not after it goes missing.
Open the control board and inspect the PHY and magnetics with a 10× loupe or USB microscope. Remove the control board from the chassis. Look within 2 cm of the RJ45 jack for: dark scorch marks on the PHY package (`RTL8201F`, `KSZ8081`, or similar — varies by model), bulging or cracked electrolytic caps, broken solder joints on the RJ45 pins (fractures have a shiny-ring signature), blackened PCB traces between the jack and the magnetics. Any visible damage ends DIY — ship to D-Central for bench rework.
Multimeter continuity test across the magnetics. Power off, disconnect. Probe from each RJ45 pin back to the PHY-side pads on the control board. A healthy differential pair shows low-ohm continuity through the magnetics transformer (typically under 10 Ω). Open circuit on one or more pairs = magnetics-block dead, usually from a lightning-adjacent surge or ground loop. Mag-jack replacement requires hot-air SMD rework and a pin-compatible part (Pulse JXD0 or Bel 0826 family) — Tier 4.
Flash DCENT_OS — D-Central's open-source Antminer firmware — for deeper network diagnostics on Antminer hardware. DCENT_OS exposes raw `eth0` / PHY logs including `phy reset` loops, `MDIO read failed`, `eth0: watchdog timeout`, and negotiated-speed lines that stock Bitmain firmware hides. Source on GitHub (github.com/DCentralTech/DCENT_OS), install from d-central.tech/dcent-os. Alternatives: Braiins OS+, LuxOS, Vnish. Not applicable to MicroBT / Canaan / Innosilicon — those have their own native firmware paths.
SSH in (if the miner partially responds on a direct cable, even transiently) and tail `kern.log` during a cold-boot. Look for `phy reset` loops, `MDIO read failed`, `eth0: watchdog timeout`, `dhclient: DHCPDISCOVER sent, no DHCPOFFER received`. Each points at a distinct failure class: PHY vs magnetics vs firmware vs upstream. SSH defaults: Antminer `root`/`admin` stock, MicroBT `admin`/blank, Canaan `root`/`root`, Innosilicon `admin`/`admin`. Change defaults in production before moving on.
Re-flash firmware from the last-known-good version for your specific hardware revision. Wrong firmware for a late-revision control board bricks the Ethernet stack or the entire board. Verify your board revision against the vendor's hardware compatibility table before flashing. Document the previous and target version strings before you flash so you can roll back if the new one is worse. This is the last software-side move before committing to a bench repair.
Stop DIY when: visible burn damage on the control board, PMIC suspected, continuity test opens on the magnetics, the PHY is stuck at 10 Mbps, or a known-good replacement controller in the same chassis also fails to see the LAN. You are now in test-fixture-and-hot-air territory — book a D-Central ASIC Repair slot at d-central.tech/services/asic-repair/. Don't keep hot-air-ing blind; each reflow adds thermal stress to the surrounding components.
D-Central bench process for `ERR_NETWORK` tickets: control board on a test fixture with a known-good hashboard harness, scope + TDR on the Ethernet differential pairs to identify broken traces or damaged magnetics, PHY chip replacement (`RTL8201F` / `KSZ8081` / `DP83848` sourced new or graded), mag-jack replacement (Pulse or Bel family matched to the board revision), full re-flow of the RJ45 pins, 24-hour post-repair burn-in at nameplate with a live pool connection. Typical turnaround 5-10 business days, Canada-wide and international.
Ship safely. Anti-static bag for the control board, double-box with at least 5 cm of foam on every side, include a printed note with observed symptoms, firmware version, miner serial, and contact info. The more upfront diagnostic context you give us, the lower your bench time — which is the main driver of your bill. Photos of any visible damage attached to the inbound ticket save another 20 minutes of triage. Track the package and insure appropriately — hashboards and control boards are not cheap to replace if lost in transit.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
