Antminer – SSH Connection Refused (Network)

Flush your workstation ARP cache. macOS/Linux: `sudo arp -d <miner-ip>` then `ping <miner-ip>` once. Windows: `netsh interface ip delete arpcache` then `ping <miner-ip>`. Clears stale L2 mappings pointing at a device that previously held that IP. One of the most common 'worked yesterday, broken today' causes after a router or DHCP scope reboot. Expected outcome: ping replies with the correct MAC, SSH reattempt succeeds.

Confirm the miner's actual current IP. S19/S21 stock firmware: press the front-panel IP button — miner beeps and displays the IP. S17/S9: use the official Bitmain IP Reporter tool on a Windows laptop on the same LAN, press the IP-report button on the control board, tool pops up the IP. No panel available? Run `nmap -sn 192.168.1.0/24` (or your subnet) and match the MAC in results against the chassis sticker. Do not rely on the IP you wrote down last month.

Power-cycle the miner at the breaker. 30 seconds off, then on. Forces the miner to re-request DHCP and re-register its MAC with the switch. If the switch's MAC table had flipped onto a wrong port (MAC flap), the fresh link-up on boot typically corrects it within 60 seconds. Wait 3 minutes for full boot before retrying SSH. While waiting, re-verify the IP via Step 2 in case DHCP re-assigned.

Disable your workstation VPN and retry. WireGuard (`wg-quick down wg0`), Tailscale (`tailscale down`), corporate IPsec / OpenVPN / NordVPN / ExpressVPN clients — all can push routes that shadow your LAN. Temporarily down the VPN interface, retry SSH. If it works, fix the VPN's `AllowedIPs` / split-tunnel config (see Tier-3 Step 12) before re-enabling. Catches ~15% of network-SSH tickets in 2025-era home-labs.

Try a different workstation on the same LAN. If SSH works from your laptop but not your desktop, the problem is client-local — host firewall, OS route-table staleness, or VPN leftovers from a prior session. Narrows the failure surface from 'LAN is broken' to 'this one machine is misconfigured,' which is a 5-minute fix vs a 5-hour fix.

Direct-attach test. Run a known-good Cat5e / Cat6 cable directly from a laptop to the miner's RJ45 port. Static-IP the laptop to `192.168.1.100/24` (or match the miner's subnet). `ping <miner-ip>`, then SSH. This isolates LAN / switch / VLAN / VPN issues from miner-side issues in under 5 minutes. If direct-attach works and switch-attached doesn't, your LAN is the problem — not the miner. If direct-attach also fails, the miner's network stack or hardware is the issue (escalate to Tier 3/4).

Re-seat and swap the Ethernet cable. Power down, unplug both ends of the patch cable, inspect RJ45 jacks for bent or corroded pins, reconnect firmly. If the link LED on the miner side stays dark or flickers under load, swap to a known-good cable. S19-family RJ45 jacks on rackmount installs are mechanically fragile — strain on the patch cable loosens the jack's solder joint on the control board over time. Strain-relieve with a zip-tie once resolved.

Check switch port LEDs and the switch's MAC table. Link LED should be solid green/amber on a healthy gigabit link. Slow blink = 10 Mbps half-duplex negotiation (bad cable likely). On managed switches (UniFi, Mikrotik, Cisco, Aruba), run `show mac-address-table` and look for the miner's MAC. If the MAC is flapping between two ports, you have a MAC collision — two devices with the same MAC on the network. Isolate by powering down one at a time.

Test from a second workstation on the miner's VLAN directly. Plug a second laptop onto the miner's VLAN (same broadcast domain, no routing between), SSH. If that succeeds, the issue is inter-VLAN routing or a firewall rule between your workstation VLAN and the miner VLAN. If it fails, the problem is at the miner's network stack or hardware — continue to Tier 3.

Audit your router / firewall rules for TCP `22`. Mikrotik: `/ip firewall filter print where dst-port=22`. UniFi: Settings → Firewall → LAN-IN rules. OPNsense / pfSense: Firewall → Rules, check every interface. Cisco / HP / Aruba managed switches: `show access-list` + `show ip interface`. Look for `drop`, `reject`, or `block` rules targeting the miner subnet or port `22`. Edit to allow your workstation subnet → miner subnet on TCP `22`, reload, test. Enable logging on the drop rule to confirm you fixed the right one.

Packet-capture at the miner side. If you can reach the miner over a different protocol (web UI, cgminer API on TCP `4028`, UART console), open a shell and run `tcpdump -ni eth0 tcp port 22`. Initiate SSH from your workstation. You should see the TCP SYN land at the miner. If no SYN arrives, packets never reach the miner — confirm with a switch-side SPAN capture. If SYN arrives and the miner responds but you never see the SYN-ACK back, you have an asymmetric-routing or NAT issue on the workstation side. If SYN arrives and the miner RST's immediately, the daemon is off — see the daemon-side `ERR_SSH` sibling.

Fix WireGuard / Tailscale routing. WireGuard: edit the peer's `AllowedIPs` to exclude the miner subnet — e.g. `AllowedIPs = 10.0.0.0/8, 172.16.0.0/12` and deliberately leave out `192.168.1.0/24` where the miner lives. Tailscale: on the offending node, `tailscale up --exit-node-allow-lan-access=true`, or remove `--advertise-routes=<miner subnet>` from the subnet router config. Reload the VPN, verify your workstation's route table: `ip route` (Linux), `netstat -rn` (macOS), `route print` (Windows). The miner's subnet must have the LAN gateway as its next-hop, not the VPN interface.

Assign the miner a static IP outside the DHCP pool. DHCP lease rotation is a preventable failure mode. Web UI → `Administration` → `Network` → set `Protocol: Static`, pick an IP outside the DHCP scope (e.g. if DHCP serves `.100-.200`, reserve `.10-.99` for infrastructure). Alternatively, use a DHCP reservation bound to the miner's MAC at the router — same effect, managed centrally. Label the miner chassis with the MAC + static IP. For farms >10 miners, maintain a DHCP-reservation spreadsheet.

Put miners on a dedicated VLAN with explicit ACLs. Not optional for any farm with >5 miners, strongly recommended even for 2-miner home setups. Create a 'mining' VLAN, tag it on the trunk port, configure inter-VLAN routing to allow your workstation subnet → mining subnet on TCP `22`, `80`, `4028` only, and deny all other inbound. Allow mining subnet outbound to pool IPs / DNS / NTP only, deny the rest. Protects against compromised miners pivoting into your workstation subnet (the 2019 Bitmain-botnet wave is real) and documents the rules you'll need when you scale.

Rotate the MAC address on cloned or conflicting miners. If two miners ended up with the same MAC (grey-market cloned boards, firmware dev-build residue), rewrite the MAC on DCENT_OS / Braiins OS+ / LuxOS via `ip link set dev eth0 address 02:00:...` in a boot script and persist via `/etc/config/network` on the underlying OpenWrt. On stock Bitmain firmware this is not reliably configurable — flash a custom firmware if you genuinely have a MAC collision. DCENT_OS (https://d-central.tech/dcent-os/) is the Mining Hackers' pick — open-source, scriptable, SSH-enabled by default.

Stop DIY when direct-attach SSH fails, link LED is dark on both sides with known-good cables, and UART console (if you have one) reports `NO-CARRIER` on `eth0`. That's a control-board Ethernet-phy or RJ45-jack hardware failure, not a network config issue — no amount of firewall-rule editing will fix it. Book a D-Central ASIC Repair slot at https://d-central.tech/services/asic-repair/. Ship the control board alone if the hashboards are healthy — cheaper and faster than shipping the whole chassis.

D-Central bench process for network-hardware failures: control-board inspection under magnification, check Ethernet magnetics (pulse transformer) for cracked solder, RJ45 jack for bent-pin or cold-joint damage, phy chip (typically Realtek RTL8211 family) for thermal damage, voltage-regulator domain serving the phy for capacitor or regulator failure. Component-level repair where possible; full control-board swap from salvaged-grade inventory where the phy is dead but the rest of the board is healthy. 24-hour post-repair network burn-in with pool traffic and periodic SSH sessions to verify stability.

Ship safely if going the Repair Service route. Anti-static bag on the control board (do not ship the full miner unless hashboards are being serviced too — expensive and unnecessary), double-box with ≥5 cm of foam on every side. Include a note with: exact model + hardware revision (silkscreen on the control board), firmware at time of failure, detailed network symptoms (direct-attach results, link-LED behaviour, any `tcpdump` or UART captures), and your contact. Clear paperwork cuts diagnostic time and lowers your final invoice. Turnaround 5-10 business days, Canada-wide shipping, US and international welcomed.