Volcminer D1 Network Disconnect and Ethernet Not Connecting

Cold-cycle the miner. Pull power at the PSU for 30 seconds, then power back on — not a soft restart, a full cold cycle. Clears any wedged DHCP client state, stale ARP entries, or zombie stratum sockets that survived a soft reboot. If the LAN comes back and stays up for hours before dropping again, you're hunting an intermittent — note exact uptime before drop and proceed to Step 2 to baseline.

Reboot the router. Pull mains for 60 seconds, then power back. Clears stale ARP cache, kicks the DHCP server through a fresh scope rebuild. Resolves a meaningful percentage of `miner ghost off the LAN` issues that look like miner faults but are router faults. Re-test by pinging the miner continuously for at least 60 minutes after the router comes back up.

Wiggle-test the patch cable at both ends. With the miner running and a continuous ping from a laptop, gently flex the RJ45 boots at the miner end and the switch end. Watch the ping output for drops correlated with flexing. If you can reproduce a drop by flexing — the cable is the fault, swap immediately. Look especially at the cable boot's strain relief at the miner end where vibration loading is highest.

Swap the patch cable end-to-end. Don't troubleshoot a tired cable; replace it with a new `Cat5e` or `Cat6` of appropriate length, freshly out of a sealed bag. The cable is `$5-15 CAD`. Re-run the 60-minute ping baseline. If drops stop, the cable was the fault — done. If they continue, cable is not the fault, proceed.

Swap the switch port. Move the patch cable to a different port on the same switch. Five-second test. Re-run the ping baseline. If drops stop, the port was bad — flag it on the switch (or replace the switch if it's tired) and move on. Cheapest data point in the entire diagnostic.

Pin a static IP outside the DHCP scope. On the D1 dashboard, set a static IP — example: if your DHCP pool is `192.168.1.100-200`, set the miner to `192.168.1.99/24`, gateway `192.168.1.1`, DNS `1.1.1.1` and `8.8.8.8`. Reboot. Re-run the 60-minute ping baseline. This single change fixes a meaningful fraction of D1 LAN-drop tickets — the firmware's DHCP renewal logic is not its strongest feature.

Direct-connect test. Pull the miner off the switch entirely. Plug it directly into a router LAN port — or, if you can, into a laptop with a static IP on the same `/24` subnet. Re-run the ping for 30 minutes. If drops stop, fault is between the switch and the miner: switch backplane, switch uplink to router, or upstream LAN. If drops continue, fault is in the miner controller itself — go to Tier 3.

Disable QoS, parental controls, or traffic shaping on the miner's IP. Some consumer routers throttle long-running TCP sockets — exactly what stratum mining is. Add the miner's IP to a no-shaping exception list, or disable QoS entirely as a test. Re-run ping baseline.

Review the router's DHCP log. Most consumer routers expose this under `Status → DHCP`. Look for the miner's MAC address — distinguish between `never gets a lease` and `gets a lease but loses it after 30 min`. The two patterns require different fixes. Use the data to confirm whether DHCP is the actual fault or whether the miner is dropping the lease itself.

Test stratum reachability from a wired laptop on the same LAN. Run `telnet pool.example.com 3333` (or the pool's actual port) from the laptop. If the laptop can reach the pool but the miner can't, the LAN-to-WAN path is fine and the fault is on the miner's TCP socket layer — points at firmware or PHY hardware.

Roll firmware back one version via `volcminer.com/techsupport`. Manufacturer keeps prior builds available. **Crucial:** keep `keep configuration` checked during the update flow — unchecking it wipes pool/password settings, a documented D1 quirk. Observe for 60 minutes after the new firmware boots. If drops stop, previous firmware had a regression; stay on the working build.

Check the controller's `dmesg` / system log if your firmware exposes one. Look for repeated lines: `eth0: link down`, `eth0: link up`, `phy reset`, `mdio timeout`. Frequency and pattern tells you whether the PHY is being reset by the SoC (suggests software/firmware) or whether the link is bouncing physically (suggests cable or PHY hardware).

Compare against a second D1 on the same LAN. If you have two miners, swap their patch cables, then their switch ports. If the fault follows the miner, it's the controller. If it stays with the cable or port, it's not. The most reliable way to isolate `is it the miner` vs `is it the network` without bench equipment.

Optional: capture packet traffic with a managed switch's port mirror feature. Mirror the miner's port to a laptop running Wireshark. Watch for `TCP RST` from the pool side, `DHCP NAK` from the router, or repeated `ARP request` storms from the miner. Each pattern points at a different root cause and gives you a hard data trail to share with the bench if you ship for repair.

If your firmware version is current and stable on other identical miners, hardware is the only remaining suspect. Stop tweaking software and configuration. Pull the controller cover. Visually inspect the PHY chip area: discolouration, scorched components, lifted solder, missing or cracked decoupling caps near the PHY. Power on briefly and feel the PHY chip surface temperature within 60 s — should be warm, not scorching, not cold. Document what you see, then move to Tier 4.

Stop DIY: you've ruled out cable, switch port, upstream LAN, DHCP, and firmware. The link LED on the miner side flickers without a corresponding switch-side flicker. The PHY chip area runs cold on boot or scorching after 60 s. You're now diagnosing a controller-board-level hardware fault — book a D-Central repair slot. Bench-level rework is needed.

D-Central bench process: continuity-check the PHY chip's pins with a low-current meter, probe the MDC/MDIO bus with a scope to confirm the SoC is talking to the PHY, reflow the PHY if a cracked solder ball is the suspected fault. If reflow doesn't fix it, replace the PHY chip from D-Central's salvaged-parts inventory. If chip-level repair isn't economical, swap the entire controller board from D-Central inventory. Post-repair burn-in: 24 hours of continuous-ping logging on a bench network to catch any intermittent that wouldn't show in a 10-minute test.

Ship safely. Pack the controller separately from the hashboards and PSU if you can — it's the only part with the failure, no need to ship the miner whole. Anti-static bag, double-box, ≥`5 cm` foam on every side. Include a note with your diagnostic data: ping logs, switch-port test results, firmware version, observed link-LED behaviour. The more you give the bench, the less time we spend re-diagnosing — which directly lowers your repair cost.