Skip to content

Discovery finds nothing

A scan runs to completion but reports "0 devices found" — or the subnet list stays empty. Discovery runs entirely on the collector, not on the Vesana server itself — most causes sit on the collector VM or in the network between it and the target devices.

1. Is a collector even running, and is it online?

Without at least one collector in the target network there's nothing to scan — the scan button is then deliberately disabled. Check the collector count in the header on the Discovery overview, and on the collector VM:

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

Details: Collector.

2. Is the right subnet even in the list?

Discovery only scans subnets the collector knows about — derived from its network interfaces, its routing table, via SNMP from the gateway, or entered manually. If the target network isn't in the subnet list at all:

  • Click "Refresh subnet list" — not a scan, it only pulls the collector's current interfaces/routes/SNMP walk results again (runs on its own only once, when a collector first reports in — otherwise on click or via the schedule checkbox "Refresh subnets first")
  • Still missing afterward: enter it manually (subnet list → "Add subnet manually")
  • Check whether the subnet is accidentally marked as excluded — a /16 exclude also blocks all /24 subnets underneath it

Details: Discovery → Networks.

3. Manual nmap test on the collector VM

The fastest way to separate discovery problems from the actual collector code — directly on the collector VM:

# Ping scan (no port scan):
sudo nmap -sn 192.168.1.0/24

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

  • Firewall/segmentation: does a firewall between the collector VM and the target subnet block ICMP or the scanned ports? Discovery needs at least ICMP reachability for the initial ping sweep.
  • VLAN/routing: is the collector VM in the same VLAN as the target devices, or does traffic need to be routed — and is that routing actually set up?
  • VPN/tunnel: is the collector VM behind a VPN that only allows certain subnets through?

If the manual nmap scan finds devices without trouble, but Vesana still shows nothing, it's more likely the scan profile, exclusions, or the ghost filter logic (see below).

4. Scan profile too restrictive?

The scan profile determines how many ports are checked and how aggressively the scan runs:

Profile Ports Note
Stealth 4 (22, 80, 443, 3389) only finds devices with these ports open
Normal (default) 8 good compromise
Aggressive 24 broadest detection, but more network load and higher IDS footprint

A device that only responds on a rarely checked port (e.g. pure SNMP without the standard ports) might not show up as a "device with identity" at all with Stealth/Normal, even if it's perfectly reachable via ICMP. Fix: switch to a broader profile, or specifically use the Aggressive option for that one subnet.

Details: Discovery → Scan profiles.

5. Missing SNMP community

Without a matching SNMP community, a device that could actually deliver a lot of detail stays listed as "unknown device (responds to ping)" — it's still found, just not identified. If "found nothing" really means "identified nothing": add the SNMP community early (Discovery → Settings → SNMP communities), then "refresh subnet list" or trigger a new scan — a newly added community automatically triggers a subnet refresh.

6. Ghost filter too aggressive? (rare)

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

7. Scan stuck "waiting"

If the scan history shows an amber wait reason instead of a result:

  • "Waiting for collector update" — the scan is deliberately held back until the collector has updated to the version intended for the scan (prevents an auto-update from killing the running scan process). Continues automatically once the update is done.
  • "Collector offline" — the scan is waiting to be picked up once the collector is back online.

Not a bug, just a safeguard — wait it out or check collector status (point 1).

Checklist

  1. Collector online? (journalctl)
  2. Target subnet in the subnet list, not excluded?
  3. Manual nmap -sn from the collector VM successful?
  4. Scan profile broad enough for the target devices?
  5. SNMP community configured, if identification (not just visibility) is desired?
  6. Scan history shows a wait reason instead of an error?

Next