This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
BMC Discovery 11.3
A device capture, credential test, or scan fails with "ERROR: SNMP++: SNMP request timeout" or "Device skipped - no SNMP access".
Note that there are two ways to get a device capture (see https://docs.bmc.com/docs/discovery/113/capturing-snmp-devices-788111406.html):
- from the Discovery Access page
- from the Device Info page (which is reached from the Discovery Access page)
In some cases, doing a capture from a Device Info node may result in a blank screen. When clicking the browser "back" button, it returns to the Device Info page and briefly shows a green banner that says "Device skipped (no SNMP access)", which then fades out after a few seconds.
There are many possible reasons for this. The following is a list of possible causes and things to check:
- Make sure a SNMP credential is present and that the IP range includes the address being discovered (a valid credential is needed for device capture)
- Run a credential test. What is the result?
- Increase the timeout in the SNMP credential to 100 seconds and retry.
- What is the SNMP version (v1, v2c, v3) on the credential? Is the device configured to respond on that SNMP version?
- If the device supports SNMP versions other than the one specified in the credential, change the version in the credential and retry.
- For SNMP v1 and v2c, make sure the community string in the SNMP credential is correct. An invalid community string can cause a "Unable to get the deviceInfo: TRANSIENT" error.
- Ask the device administrator:
- if there might be an Access Control List (ACL) or some other configuration on the device that prevents responses to the Discovery appliance.
- if the device is configured to use the default SNMP port (161). Run nmap to confirm the port is open (see below).
- On the Discovery Access page, click on any links for "script failure" or "xx Session Results related" to look for clues.
- In the case of a timeout during a device capture, check the log in /usr/tideway/var/captures for additional clues
- In the case of a timeout during a scan, turn DEBUG logging on for Discovery, run the scan again, and check the tw_svc_discovery.log for clues. Remember to turn DEBUG logging off!
- In one case, the customer made corrections to the IP range and mask on the device, then was able to discover the device.
- From the Discovery command line, run the following commands and check the results:
1. Check connectivity:
2. Check port status. Note: nmap execution was changed in ADDM 10.x and above so that it no longer uses sudo, instead it uses --privileged and gives tideway permission to perform the operation.
/usr/bin/nmap --privileged -sT -sU -p T:22,U:161 [device_ip_address]
The expected result is that port 161 would have a state of "open" or "open|filtered".
3. Do a snmpwalk to the device (see examples below):
/usr/tideway/snmp++/bin/snmpWalk x.x.x.x -v1 -Cpublic
SNMP V2c :
/usr/tideway/snmp++/bin/snmpWalk x.x.x.x -v2c -Cpublic
SNMP V3 :
/usr/tideway/snmp++/bin/snmpWalk x.x.x.x '184.108.40.206.220.127.116.11.3.1' -v3 -snMyLogin -sl2 -authMD5 -uaMyPassword
/usr/tideway/snmp++/bin/snmpWalk x.x.x.x '18.104.22.168.22.214.171.124.3.1' -v3 -snMyLogin -sl3 -authSHA -ua'My$Password' -privDES -up'MyPrivateKey'
The output can also be redirected to a file, for example:
/usr/tideway/snmp++/bin/snmpWalk x.x.x.x -v2c -Cpublic >> snmpwalk.txt
If snmpwalk also fails, please consult the device administrator.
If the problem persists, please contact Customer Support and provide the results to all the questions / checks above.