Template:FAQ:Applications 05

From Net-SNMP Wiki
Revision as of 08:56, 28 May 2009 by Dts12 (Talk | contribs) (Latest FAQ revision - preparing for 5.5 release)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Assuming that the tests outlined in the previous entry indicate that the problem lies with the agent not responding, the obvious question is "why not".

Again, there are two basic possibilities - either the agent never sees the request, or it receives it but is unwilling (or unable) to process it. If the remote system is running the Net-SNMP agent, then the easiest way to distinguish between these two cases is to shut down the agent, and re-start it manually using the options

             -f -Le -d

Then send the same query as before. This should display raw dumps of packets seen (or sent) by the agent, just as with the client side in the previous entry.


If the agent does not display anything, then it is simply not receiving the requests. This may be because they are being blocked by network or local firewall settings (iptables -L), or the agent may not be listening on the expected interfaces (netstat -a).

This is most commonly encountered when running queries from a remote host, particularly if the same request succeeds when run on the same system as the agent itself.


If the agent displays a dump of the incoming request, but nothing going out, then the most likely cause is access control settings. See the relevant entries in the AGENT section for details. Note that if the agent receives an SNMPv1 or SNMPv2c request with a unknown community string, then it will not return an error response - the request is simply discarded.

Another possibility is that the request may be rejected by settings in /etc/hosts.{allow,deny}. Again, '-d' will display an incoming packet dump but no corresponding outgoing response. However in this situation, the agent should also log a message that the request is being refused.


Running the agent with '-d' can also help identify situations where the agent is responding to the request, but only after a long delay. This would be indicated by a series of incoming packet dumps (showing various retries from the client side), followed by several outgoing dumps - possibly long after the client tool has given up in disgust.
See the entry The agent worked for a while, then stopped responding. Why? later in this section.