Bandwidth is always zero

A Sentinel Agent whose bandwidth values are all 0, whose traffic thresholds never fire, and whose protocols are all Unidentified is almost always missing its packet-capture runtime — not looking at an idle host.

Is it idle, or is it not measured?

A bandwidth of 0 looks identical in both cases, so the agent reports a capture status with every collection and the Web UI shows it. Look for these before assuming a quiet network:

Where	What you see
Discovery graph toolbar	An amber No packet capture badge. Hover it — the tooltip repeats the reason the agent itself reported.
Proto filter dropdown	A line at the top explaining that protocols are inferred from port and process name only.
Edge tooltip on the map	“not measured — no packet capture” in place of a bandwidth figure, and no sparkline.
Process report	A warning icon on the Traffic In and Traffic Out threshold pills and their two chart panels.

If none of these appear and the values are still 0, capture is working and the links really are idle — a genuine 0.000 kbits/s is a measurement and is displayed as such.

On a merged map (level 2) the badge reads “No packet capture on at least one agent”. The map merges several agents and only claims trustworthy traffic when every contributing agent could capture, so one driverless host marks the whole view. Open each host’s own map to find which one.

What still works without capture

Only bandwidth is lost. The agent stays up, the service keeps running, and nothing else degrades:

Kept — the full connection inventory: local and remote IP and port, PID, process name, direction, interface. The topology map is complete.
Kept — CPU, memory, disk, filesystem, process metrics, and the per-interface netBytesRate / netTxDrops, which come from OS counters rather than from packets.
Kept — protocol labels, but inferred from port number and process name alone. This is why the Unidentified bucket grows: ephemeral ports carry no well-known-port hint and there is no payload to inspect.
Lost — every kbits/s value. Per-process Traffic In / Traffic Out stay at 0, map link usage stays at 0, and traffic thresholds can never fire.

Reading the reason

The badge tooltip carries the agent’s own reason. Each one points at a different fix.

“couldn’t load wpcap.dll” / device enumeration failed

No pcap runtime is installed.

Windows — install the Npcap runtime. The SDK is not needed.
Linux — install libpcap0.8 (Debian/Ubuntu) or libpcap (RHEL).

On RHEL the shipped binary looks for libpcap.so.0.8 while the distribution provides libpcap.so.1:


ln -s /usr/lib64/libpcap.so.1 /usr/lib64/libpcap.so.0.8

OpenLive failed / permission denied

The runtime is present but the agent may not open it.

Linux — grant the capability to the agent binary itself, then restart the service:


setcap cap_net_raw+ep /opt/mugnsoft/discovery_agent

Windows — recent Npcap installers default to Restrict driver access to Administrators only. Either run the service as LocalSystem / an administrator account, or reinstall Npcap with that option cleared.

The capability is granted on the agent binary, not on a helper process — packet capture runs inside the agent. Replacing the binary during an upgrade clears the capability, so re-apply setcap after every update.

No usable capture interface

The runtime loaded and permissions are fine, but every interface was filtered out — typically a container or a host whose only interfaces are docker/veth devices, which are skipped.

If the traffic you want is host-local IPC, enable loopback capture instead:


{
  "discoCaptureLoopbackEnabled": "true"
}

Expect bandwidth figures to rise once it is on, since host-local traffic starts being counted. This flag is Linux-only today.

Checking from the logs

The agent logs the capture state on change only — a warning when capture becomes unavailable, an informational line when it recovers — so a permanently driverless host logs once rather than every cycle. Search the agent log for capture:


grep -i "capture" /opt/mugnsoft/discovery_agent/log/*.log

Because it only logs on change, an absence of recent lines is not proof that capture works. The Web UI badge reflects the last collection and is the reliable check.

Protocols are all “Unidentified”

This is the expected consequence of the above, not a separate fault. With no captured payload, a connection is labelled only if its port is well known. Client-side connections on ephemeral ports — browsers, IPC, most outbound traffic — have no such hint and land in Unidentified.

Two settings shape this:

discoProtocolDetectionEnabled (default "true") — deep inspection of packet payloads. If you set it to "false" deliberately, expect the same Unidentified growth even on a host that captures normally.
discoCaptureLoopbackEnabled (default "false") — host-local IPC is invisible until this is on.

Both are re-read at the start of every collection cycle, so a change applies on the next run without restarting the agent.