When a bulk management tool (BTC Tools, Bitmain’s APMinerTool, WhatsMinerTool, or a firmware’s built-in fleet scanner) reports fewer miners than you actually have racked, the miners are almost never the problem — the scan is. Bulk tools discover miners by broadcasting on the local network and waiting for each unit’s control board to answer. If a reply never reaches your PC, that miner is invisible to the tool even though it’s hashing perfectly. This guide walks the discovery path end to end so you can find exactly where the replies are being dropped.
How bulk scanning actually works
Understanding the mechanism tells you where to look. When you kick off a scan, the tool sends discovery packets (an ARP sweep plus the vendor’s own UDP/HTTP probe) across the IP range you specify. Each miner’s control board answers with its IP, model, and status. The tool lists whatever answers within its timeout window. Three things must all be true for a miner to appear: it must be powered and booted, it must sit on a network segment your PC can reach, and its reply must arrive before the scan times out. Break any one and the count drops.
Tools you’ll need
- The PC running the bulk management software, wired to the same switch as the miners (not on Wi-Fi)
- A managed-switch login or someone who has it, if your fleet uses VLANs
- A known-good Ethernet patch cable for swap-testing
- A ping/ARP utility (built into Windows/Linux) for manual verification
Procedure: walk the discovery path
- Confirm every miner is powered and fully booted. A miner mid-boot or stuck on a hashboard fault won’t answer a scan yet. Give units 2–3 minutes after power-up before trusting the count. If a specific unit never appears across multiple scans, check its front-panel/LED status — a red fault light means it may not have reached a networked state.
- Verify the IP range covers your whole fleet. This is the single most common cause. A range of
192.168.1.1–100will silently skip192.168.1.101and up. If your DHCP pool or static plan spans.1to.254, scan the full range. When miners live on more than one subnet (e.g.192.168.1.xand10.0.0.x), add every segment to the tool — most bulk tools let you queue multiple ranges, and a scan of one subnet cannot cross into another. - Prove your PC can reach a missing miner directly. Take the IP of a unit that didn’t show up (read it off the miner’s LCD, your DHCP lease table, or the switch’s MAC table) and open it in a browser or
pingit. If the web UI loads but the scan missed it, the problem is the tool’s range/timeout, not the network. If it doesn’t load, you have a routing or cabling fault to chase instead. - Isolate the weak network segment. If the shortfall is clustered — one rack or one row missing while the rest report fine — suspect the hardware feeding that segment: a failed or overloaded switch, a bad uplink/trunk cable, or a dying PoE/power injector on that switch. Move the PC’s uplink to the suspect switch and rescan; if the missing units suddenly appear, you’ve localized the fault to the path between the two switches.
- Check for VLAN and subnet isolation. On managed switches, port isolation or separate VLANs will block the broadcast/ARP discovery that scanning depends on, even though the miners have valid IPs. Broadcast discovery does not cross a VLAN boundary or a router. Put the management PC on the same VLAN/subnet as the miners, or run the scan from a machine that already lives on that segment.
- Rule out the host firewall and antivirus. Windows Defender Firewall (and most third-party AV suites) frequently block the raw ARP/UDP discovery traffic or the tool’s listening port. Temporarily allow the bulk tool through the firewall, or test with it briefly disabled on a trusted LAN, then rescan. A count that jumps the moment the firewall is opened confirms the culprit.
- Increase the scan timeout for large fleets. On a big flat network, hundreds of miners answering at once can overwhelm a short timeout — replies arrive after the tool has already moved on. If your tool exposes a scan-timeout or retry setting, raise it and scan a narrower range at a time so every reply lands inside the window.
- Look for duplicate IP addresses. Two miners handed the same static IP (a classic result of imaging units from one config) will collide, and typically only one answers a scan. If a unit intermittently appears and disappears between scans, check your DHCP leases and static assignments for a conflict, then give each unit a unique address.
How to confirm it’s fixed
- Rescan and compare the reported count against your physical inventory — they should match exactly.
- Cross-check with your switch’s MAC-address table or router’s DHCP lease list: the number of miner MACs there should equal the tool’s count.
- Click into a few previously-missing units in the tool and confirm you can read live hashrate and temperature — that proves full two-way management, not just discovery.
Common mistakes
- Scanning over Wi-Fi. A wireless PC often sits on a different subnet than the wired miners, and broadcast discovery won’t cross it. Always scan from a wired connection on the miners’ network.
- Assuming a missing miner is broken. A unit absent from the scan but reachable in a browser is a discovery/network issue, not a hardware fault — don’t pull a hashing miner off the shelf chasing a phantom.
- Setting the range too tight. Re-read the note below: your range’s upper bound must exceed your highest miner IP.
Note: Make sure the IP segment you set includes every relevant address. If you scan 192.168.1.1–100, any miner at .101 or above will not be found. When in doubt, scan the full .1–.254 range of each subnet your fleet uses.
When to escalate
If a miner is reachable by direct IP but shows a red fault or won’t hash, the issue has moved from networking to the unit itself — typically a hashboard, PSU, or control-board fault. Diagnose the specific fault before pulling the machine: look up the model’s error code in our ASIC fault finder, follow the model-specific teardown in our repair manuals, and if a board needs component-level work, start a repair with us. New to the terminology? The mining glossary defines the control-board, hashboard, and firmware terms referenced here.
