SNMP

Symptoms: Discovery completes, SNMP port (161) detected on hosts, but no SNMP data (sysName, interfaces, LLDP neighbors) appears.

Check credential assignment

Creating a credential alone doesn't activate SNMP. It must be assigned to the network or to specific hosts.

How to verify: Go to Assets > Networks → select the network → check that an SNMP credential is assigned. Or check the host edit modal's Credentials tab to see host-level assignments.

See the SNMP discovery guide for setup steps, or Troubleshooting credentials for diagnosing file read and loading issues.

Verify the device responds to SNMP

From the daemon host, test SNMP connectivity directly. For SNMPv1/v2c, use the community string:

# Try the default community string
snmpwalk -v2c -c public DEVICE_IP 1.3.6.1.2.1.2.2.1.2

# Try your configured community string
snmpwalk -v2c -c YOUR_COMMUNITY_STRING DEVICE_IP 1.3.6.1.2.1.2.2.1.2

For SNMPv3, test with your USM credentials:

snmpwalk -v3 -l authPriv -u SECURITY_NAME \
  -a SHA -A AUTH_PASSWORD -x AES -X PRIV_PASSWORD \
  DEVICE_IP 1.3.6.1.2.1.2.2.1.2

• If public works but your custom string doesn't → credential mismatch
• If neither works → SNMP is not enabled on the device, or it doesn't accept the version you're testing

Check SNMP version compatibility

Scanopy supports SNMPv1, SNMPv2c, and SNMPv3. SNMPv3 is AuthPriv only — both authentication and privacy are required, MD5 is not supported (use SHA-1 or SHA-256), and AuthNoPriv/NoAuthNoPriv modes won't connect. If a device enforces SNMPv3-only, configure an SNMPv3 credential rather than a community string.

Check daemon logs

For general credential diagnosis (file path errors, PEM issues, assignment summary), see Troubleshooting credentials.

For SNMP-specific log messages, enable debug logging and look for these messages during a scan of the target host:

Interfaces missing or incomplete

Symptoms: A device's ifEntry tab shows fewer interfaces than the device has, or interfaces appear without their neighbor, VLAN, or learned-MAC data.

Cause: The interface table walk was cut short. Scanopy caps a single table walk at 10,000 rows and bounds each query at 30 seconds, so a very large table — or a device that stalls partway through returning one — yields a partial result.

Truncation is reported as a warning on the discovery session itself, so check the run in Discover > Scan > Sessions rather than only the daemon logs.

Interfaces are saved as soon as the interface table is read, before the neighbor and VLAN queries run. So a device that hangs later in collection keeps its interface list but loses the enrichment — bare interfaces with no LLDP/CDP neighbor are the signature of that.

What to check:

• Whether the device responds to a full snmpwalk of the interface table from the daemon host, and how long it takes
• Whether the device is under load or rate-limiting SNMP
• Whether the interface count is genuinely near the 10,000-row cap (stacked chassis and large modular switches can be)

Check host SNMP data

Open the host edit modal to inspect what SNMP has collected:

• SNMP tab — shows sys_descr, sys_name, sys_location, sys_contact, and credential assignment
• ifEntry tab — shows the interface table from the SNMP walk

If both tabs are empty after a scan with credentials assigned, work through the checks above.