Discovery: A device capture, credential test, or scan fails with "ERROR: SNMP++: SNMP request timeout" or "Device skipped - no SNMP access"

Version 9
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    BMC Discovery


    COMPONENT:

    BMC Discovery 11.3


    APPLIES TO:

    BMC Discovery



    QUESTION:

    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.


    ANSWER:

     

    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:

        ping [device_ip_address]

        traceroute [device_ip_address]

    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):

    SNMP v1:  
    /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 '1.3.6.1.2.1.17.4.3.1' -v3 -snMyLogin -sl2 -authMD5 -uaMyPassword
    /usr/tideway/snmp++/bin/snmpWalk x.x.x.x '1.3.6.1.2.1.17.4.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.

    Legacy ID:KA365060

     


    Article Number:

    000025567


    Article Type:

    FAQ/Procedural



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles