Bug 239676 - When using the pass_persist feature, the snmp daemon sends the wrong command to the script.
When using the pass_persist feature, the snmp daemon sends the wrong command ...
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: net-snmp (Show other bugs)
4.4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-10 10:35 EDT by Peter Najdenik
Modified: 2008-01-15 06:39 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-15 06:39:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Najdenik 2007-05-10 10:35:47 EDT
When using the pass_persist feature, the snmp daemon sends the wrong command to
the script. 

Problem occurs after updating to net-snmp-5.1.2-11.EL4.10

Config line in /etc/snmp/snmpd.conf:

      pass_persist .1.3.6.1.4.1.23122 /usr/sbin/bwmonitor

----------

When sending the following command
   snmpgetnext bwtor1osb .1.3.6.1.4.1.23122.1

We get different behaviours of snmpd for different versions:

Below is the debug output of my script (/usr/sbin/bwmonitor) showing what it
gets from snmpd and what it sends back:

With net-snmp-5.1.2-11.EL4.7: (This is the correct behaviour)

7021 <PING
7021 >PONG
7021 <getnext
7021 <.1.3.6.1.4.1.23122.1
7021 >.1.3.6.1.4.1.23122.1.1.2.0
7021 >integer
1

Now the same thing with version net-snmp-5.1.2-11.EL4.10

28705 <PING
28705 >PONG
28705 <get
28705 <.1.3.6.1.4.1.23122.1
28705 >NONE

The snmpd sends the wrong command 'get' instead of 'getnext' to the script.
Comment 1 Jan Safranek 2007-06-04 09:44:37 EDT
I am not able to reproduce the bug in my test environment - my script is called
with 'getnext'.

snmpd.conf:
pass_persist .1.3.6.1.4.1.23122 /usr/bin/nc localhost 3000

On my second terminal I have running "nc -l -p 3000" and typing the protocol
manually.

When I run 'snmpgetnext -v 1 -c public localhost .1.3.6.1.4.1.23122.1', the
snmpd sends 'PING' and 'getnext', as in your net-snmp-5.1.2-11.EL4.7 case.

I am running net-snmp-libs-5.1.2-11.EL4.10, net-snmp-5.1.2-11.EL4.10 and
net-snmp-utils-5.1.2-11.EL4.10 on RHEL-4.5.

Could you please try to run snmpd with '-DALL' parameter (*) and send me the
output, together with complete snmpd.conf?

*) simply run as root: 
service snmpd stop
/usr/sbin/snmpd -f -Lo -DALL >snmpd.log
Comment 2 Peter Najdenik 2007-07-03 08:43:46 EDT
Hi 

Prompted by your request I did some extended tests. The problem only occurs with
my specific configuration. If I remove everything but the line

pass_persist .1.3.6.1.4.1.23122 /usr/sbin/bwmonitor

snmpwalk work's fine.

But with the config below (which worked fine with net-snmp-5.1.2-11.EL4.7)

---------------
proxy -v 2c -c bwnwrwcom localhost:4002 .1.3.6.1.4.1.23122.2 pass_persist
.1.3.6.1.4.1.23122 /usr/sbin/bwmonitor

--------------------

A snmpwalk on .1.3.6.1.4.1.23122
Will produce the following request to /usr/sbin/bwmonitor:

PING
getnext
.1.3.6.1.4.1.23122.2.2.3.0 

--------------------
A snmpwalk on .1.3.6.1.4.1.23122.1
Will produce the following request to /usr/sbin/bwmonitor:PING

PING
get
.1.3.6.1.4.1.23122.1

And both are wrong.
Comment 3 Jan Safranek 2007-07-09 04:41:42 EDT
> ---------------
> proxy -v 2c -c bwnwrwcom localhost:4002 .1.3.6.1.4.1.23122.2 pass_persist
> .1.3.6.1.4.1.23122 /usr/sbin/bwmonitor
> 
> --------------------

This line does not make any sense - it's rejected by snmpd config parser. Do you
mean two lines?
    proxy -v 2c -c bwnwrwcom localhost:4002 .1.3.6.1.4.1.23122.2
    pass_persist .1.3.6.1.4.1.23122 /usr/sbin/bwmonitor

Is the intention of these options to ask for 23122.2 the snmpd on 4002 and
/usr/sbin/bwmonitor for the rest of 23122 tree or do you want something else?

In either way, I need to have full snmpd.conf and also snmpd.conf of the snmpd
running on port 4002 to guess what's wrong.
Comment 4 Jan Safranek 2008-01-15 06:39:44 EST
Closing due to reporter inactivity. Feel free to reopen the bug if you are able
to reproduce it and provide the required information.

Note You need to log in before you can comment on or make changes to this bug.