Skip to content

We're upgrading our operations to serve you better. Orders ship as usual from Laval, QC. Questions? Contact us

Bitcoin accepted at checkout  |  Ships from Laval, QC, Canada  |  Expert support since 2016

NET_ERR Info

ASIC Miner – Frequent Pool Disconnections

Frequent pool disconnections -- the miner authenticates successfully on every attempt, then loses the stratum TCP session mid-flight and has to re-handshake. Effective hashrate drops 3-15% to repeated reconnects and stale shares.

Informational — Monitor and address as needed

Affected Models: All ASIC miners -- Antminer S9, S17, S19, S19 Pro, S19j, S19j Pro, S19 XP, S19k Pro, S21; Whatsminer M30S, M50, M60; Avalon; Innosilicon; Bitaxe Supra/Ultra/Hex/Gamma/GT; NerdAxe; NerdQAxe; NerdMiner; NerdNOS

Symptoms

  • Pool dashboard shows `Alive: Yes` most of the time but the 'last share' timestamp bounces between <1 min and 4-6 min ago on a healthy-looking rig
  • Miner log shows repeated `socket disconnected from <pool>:<port>` or `lost connection to pool` lines, 1-20 times per hour
  • `mining.authorize` succeeds on every reconnect -- this is not an auth failure
  • Hashrate graph looks sawtoothed: climbs for 2-5 minutes, drops to zero for 5-30 seconds, climbs again
  • Effective (pool-side) hashrate is 3-15% below the miner's self-reported hashrate, consistently
  • Stale-share rate climbing above 1% on the pool-side dashboard
  • `ping <pool-host>` from the same LAN shows >100 ms average or erratic spikes above 300 ms
  • `mtr <pool-host>` shows packet loss on a specific hop -- often the ISP edge or peering router
  • Disconnects cluster at specific times of day (6-10 PM evenings, or when HVAC kicks on)
  • Multiple miners on the same LAN disconnect simultaneously -- points to router / switch / ISP, not the miner
  • Miner UI shows Pool 1 disconnected -> Pool 2 active -> Pool 1 active cycling every few minutes
  • Happens on `stratum+ssl://:443` but not on plain `stratum+tcp://:3333`, or vice-versa
  • Started after a router firmware update, a new AI-Protection feature turning on, or a VPN client installing on the LAN
  • DCENT_OS / Braiins OS+ / LuxOS pool status chip flickers between green and amber, never going solid red long enough to auto-failover

Step-by-Step Fix

1

Hard power-cycle at the breaker -- 30 seconds off, back on. Clears any wedged socket state on the miner and any stale DHCP reservation on the router. Watch the log tail for 10 minutes after reboot before doing anything else. Same rule we apply everywhere: cost zero, rules out the single most common transient failure, and sometimes ends the whole ticket before more invasive steps are needed.

2

Move the miner from WiFi to wired Ethernet if at all possible. Every Antminer, Whatsminer, Avalon, and Innosilicon ships with an RJ45 port for a reason. A stable WiFi setup means a dedicated 2.4 GHz SSID, a router within 3-5 m line-of-sight, and no mesh hop -- anything less is a running hashrate tax. Bitaxe / Nerd family are ESP32 WiFi-only by design and cannot be wired; everything else should be CAT6 to a switch.

3

Override router DNS from 'auto / ISP' to 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google). Log into router admin, change LAN DNS under WAN or DHCP settings, save, reboot the miner. ISP resolvers -- particularly on Canadian carriers -- routinely serve stale stratum hostname answers with long TTLs, causing the miner to reach dead backends. Cloudflare and Google DNS refresh aggressively and resolve consistently. One of the highest-ROI changes in this guide.

4

Lengthen the DHCP lease to 24 hours (86400 seconds) and assign a static reservation for the miner's MAC address. Default-short leases (30 / 60 minutes) trigger mid-session renewals that break stock Bitmain socket handling, presenting as a disconnect event exactly every 30 / 60 / 120 minutes on the dot. A long lease plus static reservation stops the pattern and gives you a predictable IP for remote access.

5

Disable router 'AI Protection' / 'Threat Prevention' / 'Web Filter' / deep packet inspection for the miner's VLAN. ASUS AiProtection, Netgear Armor, Eero Secure, and the Trend Micro module baked into many ISP combo boxes have been observed injecting RST packets into long-lived stratum sockets. Turn the feature off for the miner's network or exempt the miner's MAC. Your mining rig does not need AI-powered web filtering.

6

Re-seat and strain-relieve every Ethernet cable. Power off at the breaker. Unclip the RJ45 from the control board, inspect gold contacts for oxidation or tarnish (wipe with IPA if present), reconnect firmly until it clicks. Zip-tie or tape the Ethernet cable to the chassis with ~10 cm of strain relief -- this prevents fan vibration from working the jack loose over weeks. S19-family jacks are notorious for cracked solder joints under sustained vibration; strain relief before replacement buys you months.

7

Swap the Ethernet cable with a fresh known-good CAT6. Cheap CAT5e and old CAT6 from a drawer drop packets under sustained load more than most people expect. Use a <5 m run of new CAT6 directly from miner to switch (no couplers, no wall plates) as a diagnostic baseline. Once stable, you can re-introduce longer runs and in-wall cabling and confirm they don't regress the session.

8

Pin the miner's network config: static IP matching the router reservation, DNS explicitly set to 1.1.1.1 and 8.8.8.8 in the miner's own network panel. DCENT_OS, Braiins OS+, LuxOS, Vnish, and stock Bitmain on recent builds all support this. Bypasses DHCP and ISP DNS entirely -- the two most common external failure modes -- and makes the miner's network behaviour reproducible so you can actually diagnose.

9

Capture a disconnect with tcpdump from a Linux / macOS / WSL box on the same LAN: `sudo tcpdump -i <iface> -w pool.pcap host <pool-host>`. Let it run through at least two disconnect cycles. Open pool.pcap in Wireshark, filter on `tcp.flags.reset == 1` or `tcp.flags.fin == 1`. Who sent the reset first -- miner, pool, or a packet with a suspicious TTL (router injecting)? One capture collapses a week of guessing into five minutes of evidence.

10

Configure pool-2 and pool-3 as fallbacks. Pool-1 = your regional low-latency primary. Pool-2 = public-pool.io or solo.ckpool.org (solo-lottery fallback, good for resilience and hashrate decentralization). Pool-3 = Ocean or another regional option. Stock Bitmain, DCENT_OS, and Braiins OS+ all handle multi-pool failover natively. A short disconnect on pool-1 then becomes a 30-second failover blip instead of a multi-minute hashrate hole.

11

Tune TCP keepalive at the kernel. SSH into the miner (firmware-dependent), check `sysctl net.ipv4.tcp_keepalive_time`. Default is often 7200 seconds (2 hours) -- too long for stratum. Set to 60 seconds via `sysctl -w net.ipv4.tcp_keepalive_time=60` and persist in /etc/sysctl.conf. The kernel then sends TCP keepalive probes every minute on idle sockets, detecting dead paths faster and keeping middle-boxes from timing out the session.

12

Flash DCENT_OS on Antminer hardware. DCENT_OS is D-Central's own open-source Antminer firmware, built by Mining Hackers for Mining Hackers, maintained in public on GitHub. Modern stratum handling with proper keepalive, per-pool fast failover, and the log surfaces real disconnect reasons (RST, FIN, JSON-RPC error code, stratum close frame) instead of stock Bitmain's useless 'socket closed' line. Stratum V2 client-side support, per-chip HW% as a bonus. Alternatives: Braiins OS+, LuxOS, Vnish. Not for Whatsminer/Avalon/Innosilicon/Bitaxe -- those run their own firmware paths.

13

VLAN-isolate the miner fleet. Dedicated VLAN with a simple firewall rule: permit outbound TCP/3333, TCP/4334, TCP/443, UDP/123 (NTP), UDP/53 (DNS to 1.1.1.1). Deny everything else. No AI-protection, no QoS, no deep-packet inspection. A cheap managed switch (MikroTik, TP-Link Omada, UniFi) plus a separate router port dedicated to the mining VLAN collapses five categories of residual disconnect causes into one clean network path.

14

Replace a cracked Ethernet jack on an S19-class control board. If the wiggle-test from step 6 induced a link drop, the RJ45 has cracked solder joints from repeated fan-vibration cantilever load. Hot-air rework job: protect surroundings with Kapton, heat the jack to ~280 C top-side while supporting the board, lift with tweezers, clean pads with solder wick + IPA, seat fresh jack, reflow. If you don't have the station, this is a D-Central bench repair (~20 minutes).

15

Inspect PSU for load-induced rail sag. If the miner is power-cycling subtly during disconnects (hashrate bounces to 50% for a few seconds, rather than dropping to zero cleanly), the PSU may be momentarily dropping 12 V under peak load, which resets the SoC Ethernet block without a full reboot. Multimeter on DC, probe 12 V output under full load -- expect >=13.8 V sustained on an APW9 / APW12. Lower = swap PSU with a known-good unit.

16

Thermal-image the control board during a disconnect event. A FLIR ONE Pro or entry IR camera pointed at the control board will show a hot-spot if the Ethernet PHY or SoC is running above spec. Thermal-induced disconnects cluster with ambient temperature -- they hit on hot afternoons and vanish at 2 AM. Re-paste the SoC, reseat the heatsink, and if the PHY is a separate chip (some S19 revisions), re-paste it too.

17

Stop DIY and book a D-Central repair slot. If you've eliminated physical (cable/jack), DNS, router filters, DHCP, latency, firmware, VLAN isolation, cracked jack, PSU sag, and thermal -- the miner still drops sockets -- that's control-board silicon territory. Dying Ethernet PHY, SoC with intermittent MAC-layer faults, or eMMC holding a corrupted network-stack driver that reflash won't clear. Ship to D-Central. We bench-test on programmable load + isolated pool backend; if the fault follows the board, it's board-level, and if it clears on our bench we'll tell you it was your LAN.

18

Ship safely for repair. Anti-static bag the control board (or the whole miner). Double-box with >=5 cm foam on every side. Include a written note: exact disconnect cadence you measured (every 2 min? every 30 min on the dot?), pools tried, firmware version(s) tested, what you already ruled out, and screenshots of your mtr output and tcpdump summary if you captured one. Diagnostic time is billable -- a good note cuts the repair quote materially. Turnaround 5-10 business days; Canada-wide shipping; US and international welcomed.

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.