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.
Discovery graph toolbar	A blue Bandwidth from TCP statistics badge: bandwidth is measured, on a Windows host without Npcap. See the blue badge.
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.

Blue badge: Bandwidth from TCP statistics

A Windows host without Npcap measures bandwidth from the TCP statistics Windows keeps for each connection. The figures are real, and traffic thresholds work. The badge is there because this mode has restrictions:

protocols are inferred from port and process name only, with no detection from the payload;
a connection shorter than one collection cycle is not measured;
figures are a few percent lower than with packet capture, because only payload bytes are counted;
the agent service must run as LocalSystem or an Administrator account.

Npcap is used whenever it is installed. To remove the badge and the first three restrictions, install the Npcap runtime and restart the agent service. Details: Windows without Npcap.

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 — since 4.2.0 this reason alone no longer zeroes the bandwidth: the agent falls back to TCP statistics and the badge is blue. When the badge is amber and the reason ends with TCP statistics need Administrator/LocalSystem, run the agent service as LocalSystem or an administrator account, or install the Npcap runtime (the SDK is not needed).
Linux — since 4.2.0 libpcap is built into the agent, so this reason should not appear. If it does, the host runs an older agent: upgrade it.

The agent does not start: “libpcap.so.0.8: cannot open shared object file”

Only agents older than 4.2.0 show this: they link libpcap dynamically, and the host has no library under the name they look for.

Debian / Ubuntu: apt install libpcap0.8
RHEL / CentOS / Fedora: dnf install libpcap, then create the name the old binary looks for:

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

Upgrading the agent to 4.2.0 or later removes the need for both; the package and the link can stay, they are no longer used.

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.