Skip to content

Discovery finds nothing

A scan completes but reports "0 devices found" — or the network list stays empty. Scanning is done by a collector or by the Active Collector on the Vesana server, each from its own network — so most causes live on that machine or in the network between it and the target devices.

1. Is a collector there, and is it online?

Without a reachable collector in the target network there's nothing to scan. If none is online, the Discovery overview says so explicitly — "Find devices (scan)" and "Find networks automatically" only work once at least one is reachable. On a collector VM:

journalctl -u vesana-collector --since '5 minutes ago'

Details: Collector.

2. Is the right network even in the list?

Discovery only scans networks the collector knows — from its network interfaces, its routing table, its ARP cache, via SNMP from the gateway and from monitored SNMP devices, or entered manually. If the target network isn't in the list at all:

  • Click "Find networks automatically" — not a device scan; the collector looks again at which networks it knows. On its own this only runs once on a collector's first contact and, if "Refresh subnets first" is ticked on the schedule, before a scheduled scan — otherwise on click.
  • If the network is still missing: "Add network" (enter it manually, e.g. for networks behind a VPN).
  • Check whether the network is accidentally excluded — a /16 exclude also blocks every /24 inside it.

Details: Discovery → Networks.

3. Manual reachability test on the collector machine

The fastest way to separate network problems from Vesana — talk directly from the collector machine to a device in the target network that you know is running:

# Does the device answer ping?
ping -c 3 192.168.1.10
# Is a known port open (here 443)?
timeout 3 bash -c '</dev/tcp/192.168.1.10/443' && echo open
# Same network: is the device in the ARP table?
ip neigh show 192.168.1.10

If the manual test also finds nothing, the problem is in the network between collector and target devices — not in Vesana:

  • Firewall/segmentation: does a firewall between collector and target network block ICMP and the scanned ports? In its own network the scanner also finds devices via ARP; in routed networks it needs ICMP or an open port.
  • VLAN/routing: is the collector in the same VLAN as the target devices, or does traffic need routing — and is that routing actually set up?
  • VPN/tunnel: is the collector behind a VPN that only lets certain networks through?

If the manual test reaches the devices fine but Vesana still shows nothing, the cause is more likely the scan profile, excludes or the ghost filter (see below).

4. Scan profile too restrictive?

The scan profile determines which ports are checked and how fast the scan runs:

Profile Ports Rate
Stealth 4 (22, 80, 443, 3389) 50 packets/s
Normal 11 200 packets/s
Aggressive 27 1000 packets/s — must be confirmed explicitly when starting

A device that only answers on a rarely checked port may not show up as a "device with identity" under Stealth/Normal, even though it's reachable. Fix: switch to a broader profile. Stealth scans take noticeably longer in dense networks because the 50 packets/s are actually kept.

Details: Discovery → Scan profiles.

5. Missing SNMP community

Without a matching SNMP community, a device that could deliver lots of detail stays as "Unknown device (responds to ping)" — it is found, just not identified. The gateway's routing table is then also missing as a source for other networks. If "found nothing" actually means "identified nothing": add an SNMP community (Discovery → Settings → SNMP communities), then run "Find networks automatically" or a new scan by hand — a newly added community does not trigger anything on its own.

6. Ghost filter too aggressive? (rare)

Discovery automatically filters out known network artifacts — but only provable ones (a proxy-ARP MAC address answering for more than three addresses, or blanket RST replies to everything). A device that only answers ping and exposes nothing else deliberately stays visible — the filter is conservative. If a specific device you know is still completely missing from the results, the ghost filter is rarely the cause in practice — point 3 or 4 above is more likely.

7. Scan stuck "waiting" or failed

If the scan history shows a waiting reason instead of a result:

  • "Waiting for collector update" — the scan is held back until the collector has updated to the intended version (prevents an auto-update from killing the running scan). Since v1.903.0 only if the collector really gets the update, and for at most 30 minutes — after that the scan goes out anyway.
  • "Collector offline" — the scan waits for the collector to pick it up once it's back online.

A scan has 15 minutes in total; if that runs out before the follow-up probing of the devices is done, the collector reports the scan as failed instead of delivering an incomplete result. In large networks, split into smaller ranges or choose a faster profile.

Checklist

  1. Collector online? (journalctl)
  2. Target network in the list, not excluded?
  3. Manual ping / port test from the collector machine successful?
  4. Scan profile broad enough for the target devices?
  5. SNMP community set, if identification (not just visibility) is wanted?
  6. Scan history shows a waiting reason rather than an error?

Next