#1661 snmpd unresponsive after failed proxy of SET variables

agent (1105)

Software version numbers: 5.2.2, 5.3, 5.3.1
Operating systems: Fedora Core 5, Solaris 2.8


To reproduce the problem, consider a master snmpd agent
(at port 1161) that proxies for a subordinate snmpd
agent (at port 2161).
Here are their snmpd.conf files:

# /tmp/snmpd.conf.1161
agentaddress 1161
rwcommunity public
proxy -v 2c -c public localhost:2161 .

# /tmp/snmpd.conf.2161
agentaddress 2161
rwcommunity public

After starting both snmpd processes, note that the
following command, directed at the subordinate snmpd,
that tries to SET two unsupported variables, reports
failure as expected:

$ snmpset -v 2c -c public localhost:2161 \ i 0 i 0
Error in packet.
Reason: notWritable (That object does not support
Failed object: SNMPv2-SMI::enterprises.1.0

However, when directing this request at the master
snmpd, which will proxy for the subordinate snmpd, it
fails in an unexpected way:

$ snmpset -v 2c -c public localhost:1161 \ i 0 i 0
Timeout: No Response from localhost:1161

Apparently, the master snmpd is not responsive to this
request. Although this is bad, what is worse is that
the master snmpd is no longer responsive to any request!:

$ snmpget -v 2c -c public localhost:1161 sysName.0
Timeout: No Response from localhost:1161


After diving into the code with a debugger, it is
apparent that the master snmpd puts itself in a
"netsnmp_processing_set" mode that it never exits.
Requests received while in this mode are queued for
processing after leaving this mode - which never happens.

Note that this is not a problem if we only try to SET
one variable.

There is no problem with the subordinate snmpd. It
correctly responds with an error. The problem is with
the master snmpd.

If the SET was for only one variable,
proxy_got_response will mark the one request as no
longer delegated and the associated session will
(later) be removed from the delegated list and
netsnmp_processing_set will be cleared.

If the SET was for two or more variables,
proxy_got_response will mark only the first request as
no longer delegated. Later, the associated session will
not be removed from the delegated list as there are
requests still marked as delegated.

So, it seems (to me) that there is a problem in
My (heavy-handed?) fix would be to treat all requests
the same as the first but I am not experienced with
this code.


  • ross tyler

    ross tyler - 2006-09-07

    Logged In: YES

    This bug was discovered in an environment where snmpd was
    configured to proxy for snmpdm - the HP OpenView NNM bundled
    snmp agent. snmpd was configured to run on the standard SNMP
    port (161), and proxy for snmpdx (the solaris bundled SNMP
    agent) and snmpdm. HP OpenView NNM, by default, uses the
    standard SNMP port for everything.

    If this is an HP OpenView NNM collection station, a remote
    HP OpenView NNM management station may replicate its
    collected topology. This is done by ovrepld on the remote
    management station and ovtopmd on the collection station
    using SNMP protocols. Periodically, ovrepld will poll
    ovtopmd for its collected topology.

    The ovrepld process will SET multiple MIB variables in
    ovtopmd to define this relationship. If, when it does this,
    ovtopmd is down, then snmpdm will report a failure back to
    snmpd which will enter the mode described above.

  • Wes Hardaker

    Wes Hardaker - 2006-09-14

    Logged In: YES

    Closed by applying the patch in question.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks