Template:FAQ:Applications 03
Fundamentally, there are two basic reasons why a request may go
unanswered. Either the management application does not like the
request (so never sends it), or the agent does not like the request
(so never responds). The simplest way to distinguish between the
two is to run the command with the command-line option '-d'.
If this doesn't display a hex dump of the raw outgoing packet, then it's the client side which is dropping the request. Hopefully you should also see an error message, to help identify what's wrong.
If this displays one or more outgoing dumps (but nothing coming back), then the request is failing at the agent end. See the next entry for more details.
There are three further possibilities to consider:
One is that the agent may return a response to the original query, but the management application may not like this response, and refuse to display it. This is relatively unusual, and typically indicates a flaw with the remote agent. (I hope you're not contemplating the suggestion that the Net-SNMP command-line tools might contain bugs!)
The typical symptoms of this would be that the '-d' option would
display a sequence of sending and received packet dumps, with the
same contents each time. Ask on the mailing list for advice.
Alternatively, the agent may simply not support the MIB objects being
requested. This is most commonly seen when using the snmpwalk tool
(particularly with SNMPv1).
The symptoms here would be that '-d' would show two pairs of raw
packet dumps - one a GETNEXT request (A1 in the sending packet),
followed by a GET request (A0). Repeating the same request with the
snmpgetnext command-line tool should show the information (if any)
that the agent returned, which was then discarded by snmpwalk<CODE> as
irrelevant.
Note that this is how <CODE>snmpwalk<CODE> was designed to work. It is not an error.
Finally, it may be that the agent is simply taking too long to respond.
The easiest way to test for this is to add the command-line options
"<CODE>-t 60 -r 0", which will send a single request (with no repetitions)
and wait for a minute before giving up. This ought to be long enough
for all but the most-overloaded agent, or inefficient MIB module!
If this turns out to be the cause, then ask on the mailing list for advice on options for improving the performance.
