Difference between revisions of "Template:FAQ:Applications 05"
(5.4 release synchronisation) |
(Clarify handling of unknown communities) |
||
| Line 8: | Line 8: | ||
Assuming that the client application is actually sending the request | Assuming that the client application is actually sending the request | ||
(see the previous entry), there are two main likely causes for the agent not to respond. Either it doesn't receive the request (e.g. it's being blocked by a firewall or packet filtering), or it receives the request, but is unwilling (or unable) to process it. | (see the previous entry), there are two main likely causes for the agent not to respond. Either it doesn't receive the request (e.g. it's being blocked by a firewall or packet filtering), or it receives the request, but is unwilling (or unable) to process it. | ||
| + | Note that if an agent receives an SNMPv1 or SNMPv2c request with an unknown community | ||
| + | string, then it will '''not''' return an error response - the request simply times out. | ||
If the remote system is running the Net-SNMP agent, then the easiest | If the remote system is running the Net-SNMP agent, then the easiest | ||
Revision as of 08:59, 17 August 2007
Assuming that the client application is actually sending the request
(see the previous entry), there are two main likely causes for the agent not to respond. Either it doesn't receive the request (e.g. it's being blocked by a firewall or packet filtering), or it receives the request, but is unwilling (or unable) to process it.
Note that if an agent receives an SNMPv1 or SNMPv2c request with an unknown community
string, then it will not return an error response - the request simply times out.
If the remote system is running the Net-SNMP agent, then the easiest way to check what's going wrong is to shut down the agent, and re-start it using the options:
-f -Le -d
This will display raw dumps of packets seen (or sent) by the agent,
just as the '-d' flag did for the client side in the previous entry.
Restart the agent with these flags, and send the same query as before. If the agent doesn't display anything in response to this request, then it's probably some form of firewall settings, which are preventing the agent from ever seeing the request.
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.
A third possibility is that 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.
The same basic causes could also affect other vendors' SNMP agents. Please consult the relevant documentation for how to investigate and address such problems.
