Host Discovery

LinuxmacOSWindowsFreeBSD

Symptoms: Discovery completes but some known hosts are missing from results.

Most likely causes:

• The host is not responding to ARP — it's on a different subnet, asleep, filtering ARP, or on an overlay network.
• Switch rate limiting (DAI) — the switch is dropping ARP packets before they reach hosts or before responses return.

To tell them apart, test the host with a manual ARP request from the daemon host. If that also fails, the host is unreachable at Layer 2 — see Hosts Not Responding to ARP. If it succeeds but Scanopy misses the host, the issue is likely rate limiting — see Switch Rate Limiting (DAI).

Test with a manual ARP request

Run this on the daemon host, with the missing host's address:

arping -c 3 <missing-ip>

A reply line means the host answered ARP.

Hosts Not Responding to ARP

These issues are independent of Scanopy — the host is genuinely unreachable via Layer 2 ARP from the scanner's network segment. The manual ARP request also fails.

Host is on a different subnet or behind a router

ARP is Layer 2 only. Hosts on other subnets won't see broadcast ARP requests from the scanner's VLAN — routers don't forward ARP broadcasts.

Solution: Run a scanner daemon on each subnet, or add the remote subnet as a target so the daemon's routed-ping fallback can reach it.

Host is asleep or in low-power mode

Laptops, IoT devices, and phones in sleep or Wi-Fi power-save mode may not respond to ARP promptly or at all.

Solution: Increase ARP Retries to give sleeping hosts more chances to wake and respond. Schedule scans during active hours. Accept that sleeping devices will appear intermittently.

Host has static ARP or ARP filtering enabled

Some hardened hosts or embedded devices ignore broadcast ARP or only reply to unicast ARP for known peers.

Solution: Increase ARP Retries (unicast retries may succeed where broadcast failed). If the manual ARP request also fails, the host is filtering ARP.

Virtual machines or containers with restricted networking

VMs in NAT mode or containers on an overlay network are not reachable via Layer 2 ARP on the physical segment.

Solution: Scan from within the virtual network, or switch the VM/container to bridged networking so it appears on the physical segment.

Switch Rate Limiting (DAI)

Understanding ARP Scanning

Scanopy uses broadcast ARP for fast host discovery. For each target IP, we send an ARP "who-has" request and wait for a reply. This is faster and more reliable than TCP/UDP probing because hosts cannot firewall ARP and still communicate on the network.

However, many managed switches implement Dynamic ARP Inspection (DAI) to prevent ARP spoofing attacks. DAI rate-limits ARP packets on untrusted ports to a maximum number of packets per second (pps). When the limit is exceeded, the switch either drops excess packets silently or disables the port entirely.

Known default rate limits:

If your switch has DAI enabled and Scanopy sends ARP faster than the limit allows, excess packets are dropped and those hosts appear offline.

How Retries Work

Retries are targeted — each round narrows to the addresses that haven't answered:

1. Round 1: Send ARP request to all target IPs at the configured rate
2. Wait: Collect responses for 3 seconds
3. Round 2: Send ARP requests only to IPs that didn't respond
4. Repeat: Continue for the configured number of retry rounds
5. Final wait: Extra collection period for late-arriving responses

If rate limiting caused packet loss in round 1, later rounds retry only those hosts, in a smaller burst.

Diagnosis

1. Check if your switch has DAI enabled. Consult your switch documentation for how to view DAI configuration and statistics. Look for rate limit violations or dropped ARP packets.

2. Check for port shutdown. Some switches (notably Cisco) disable the port entirely when the rate limit is exceeded. If your scanner lost network connectivity during a scan, this is likely the cause.

3. Send a manual ARP request. If it finds the host but Scanopy doesn't, rate limiting is likely the cause. If it also fails, the host is unreachable at Layer 2 — see Hosts Not Responding to ARP above.

Solutions

The ARP settings below are per discovery, on its Performance tab (Discover > Scans → edit the discovery → Performance). See Scans for every scan setting and its default.

Option 1: Reduce the ARP scan rate

Lower ARP Scan Rate (arp_rate_pps) to stay within your switch's DAI limit.

Recommended values:

Option 2: Increase retries

If rate limiting causes occasional packet loss, raise ARP Retries (arp_retries) to give hosts additional chances to respond. The default is 2, which makes 3 rounds in total.

Higher retries help when:

• Rate limiting drops some packets but not all
• Hosts are slow to respond (busy or sleeping devices)
• Network has high background traffic

The tradeoff is longer scan time, but since retries only target non-responders, the overhead is usually small.

Option 3: Adjust your switch DAI configuration

If you control the switch, you can increase the rate limit on the scanner's port or mark it as trusted (no rate limit). Consult your switch documentation for the specific commands.

Tuning for Your Network