How to fix “net err!” on Bitmain Antminer L3+ ASICs

On an Antminer L3+, net err! is raised by the control board, not by the hashboards. The miner cannot get a usable network path — no link, no address, or no route to the pool — so it reports a network error while its four BM1485 Scrypt chains sit enumerated, healthy and useless. At nameplate (384 MHz, 504 MH/s) an L3+ pulls ~800 W — roughly 19 kWh/day of heat for zero accepted shares — and unlike a dead hashboard it usually costs a cable, a switch port, or a jack to fix.

What the error actually reports

• No link at all. If the Ethernet PHY does not come up, the miner never gets a link and the web UI is unreachable: link LED dark, no DHCP lease, no ARP reply on the subnet. That is copper, switch port, RJ45 jack, or a dead PHY — in that order of likelihood.
• Link, but no usable layer 3. The link LED is lit and the miner still cannot reach the pool: no lease, an address on the wrong subnet, a gateway that is not on the wire, a pool hostname that will not resolve, or the stratum port blocked outbound. cgminer never opens a socket and the status page reports a network fault.

Neither case touches the BM1485s — chip enumeration runs over the chain UART, independently of Ethernet. A network error plus zero hashrate is two independent faults, and the hashrate one is the expensive one.

Likely causes, ranked

1. Physical link. Bad patch cable, a switch port gone half-duplex, or a run past the 100 m 100BASE-TX limit. This is most of them.
2. No DHCP lease. Exhausted scope, a VLAN with no relay, or a MAC-filtered port: the L3+ comes up with no address and declares a network fault.
3. Wrong static configuration. An address outside the subnet, a gateway that is not actually on that segment, or a duplicate IP shared with another miner — two boxes fighting over one address flap in and out all day.
4. DNS, or a blocked stratum port. The pool hostname will not resolve, or the firewall drops the miner’s outbound TCP to the pool’s stratum port, so cgminer never opens a socket. Point the miner at a resolver it can actually reach, or configure the pool by IP, and confirm the port is permitted outbound from the mining VLAN.
5. A recovery SD card left in the slot. A flash or recovery card left in an L3+ can leave the miner booting or storing its configuration from the card rather than from onboard flash. Pull the card after any SD-based recovery, power-cycle, and re-enter the network settings.
6. Dead Ethernet PHY or RJ45 magnetics. Surges and ground loops on long farm runs kill magnetics — this is the one that ends in a soldering iron. A salvaged control board can also leave two units answering to one MAC: DHCP issues one lease, both flap.

Diagnose before you desolder anything

1. Look at the RJ45 LEDs on the control board. Link LED dark with a known-good cable in a known-good port → PHY or jack. Link LED lit → the copper is fine and the fault is layer 3 or above.
2. Swap in a certified cable and a different switch port before anything below. Two minutes of work rules out the most common cause on the list.
3. Find the miner without the web UI. Press the IP-report button; the L3+ beeps and broadcasts its address for the Bitmain IP Reporter tool to catch. That beacon is a broadcast and does not cross a router or VLAN boundary, so run the tool on the same L2 segment as the miner (how to get your ASIC’s IP address).
4. Confirm the lease, then the ARP reply. Look the miner’s MAC up in the DHCP server’s client table. From a laptop on the miner’s subnet, ping the address and check that the MAC appears in your ARP table. No lease and no ARP reply means the box is not on the network at all — go back to step 1. A live ARP reply with no answer on TCP 80 or the cgminer API on TCP 4028 points at the control board.
5. Prove the path to the pool from the miner’s own subnet. Resolve the pool hostname and open a TCP connection to its stratum port from a laptop on that segment. If DNS or the port fails there, it will fail from the miner. Walk the gateway and DNS settings, then pin the unit to a static IP inside the subnet but outside the DHCP pool.

Electrical checks

Safety: the low-voltage DC on an L3+ hashboard or busbar is not a shock hazard. The PSU is. An APW3++ or APW7 holds several hundred volts on its PFC bulk capacitors after you unplug it — mains-side work happens unplugged, discharged, lid on.

1. Measure the 12 V rail at the PSU output, under load, miner running. APW3/APW3++ and APW7 regulate 11.6–13.0 V DC. Sag below ~11.6 V browns out the control board and drops it off the network intermittently.
2. Mind the derate. An APW3++ makes 1600 W at 220 V but only 1200 W at 110 V; an APW7, 1800 W and 1000 W. Against an ~800 W L3+, a 120 V circuit with a tired receptacle has little margin — measure at the receptacle, under load.
3. Certify the drop cable with a cable tester (pairs 1/2 and 3/6 for 100BASE-TX), not a continuity beep — a pair that opens as the fans vibrate the rack is a classic farm fault. Verify chassis ground while you are there.

Board-level repair

• Inspect and reflow the jack first. The RJ45 on the L3+ control board is a through-hole part levered on every cable pull; cracked barrel joints show at 10×. Preheat the board to 120–150 °C, reflow the pins, and only then replace it — with a desoldering gun, not braid.
• Good jack, good cable, still no link? The PHY is gone. Replace the control board; it is a commodity part and costs less than the bench time to rework a PHY. The swap changes the MAC — update DHCP reservations and fleet inventory or you will chase a phantom offline miner for a week.
• Board boots but the network configuration will not persist? Reflash the control board from an official Bitmain L3+ SD recovery image written to a card with the vendor’s flashing tool, then remove the card and power-cycle. Re-enter the IP and pool settings and confirm they survive a reboot.

Verify the fix

• Link LED lit and steady; the miner holds its lease (or its static address), answers ARP and ping from its own subnet, and stays up with no reboot in the log.
• Pool shows Alive on the Miner Status page, accepted shares incrementing, and the cgminer API on TCP 4028 answering your poller.
• Hashrate settles near the 504 MH/s nameplate at ~800 W. If it does not, the network was never your only problem — go work low hashrate or a faulty hashboard on the L3+.
• Zero reconnect events over 24 h — intermittent link faults hide behind a five-minute test.

Common mistakes

• Reflashing firmware to fix broken copper. Confirm link before you touch flash.
• Blaming the pool before you have proven the path. Resolve the hostname and open the stratum port from a laptop on the miner’s subnet first — if that fails, the pool is fine and your firewall is not.
• Reading it as dead hashboards. The BM1485 chains never see Ethernet.
• Re-testing with the cable that came off the failed unit. It is the prime suspect and you just re-hired it.

Related

• ASIC Fault Finder — match a symptom to a fault path.
• “crc check error” on the L3+ — the chain-side sibling fault.
• Start a repair — our bench works L3+ control boards.