Problem in net-snmp 5.2.x.

[czhao at metcomm.net]

Hi, I recently upgraded the net-snmp package on some servers from 5.1.x 
to 5.2.2_1, and found that the "manual discovery" option in JFFNMS would 
not find any CPUs.  I managed to get OpenNMS (marginally) working, and 
it also does not find the CPU on systems running the newer net-snmp package.

Systems running the older net-snmp 5.1_4 package have their cpus 
detected without problems.  Also, note that if a system was previously 
discovered to have cpus and already stored in the database, the cpu 
information continues to be updated.  This indicates that the 
ucdavis.systemStats tree seems to be functioning when queried directly 
(snmpwalk confirms).

I tracked down the manual discovery code in JFF and found (I believe) 
that a difference in the return value of .1.3.6.1.2.1.1 is causing the 
problem.  Doing on snmpwalk on this OID returns many lines, but the 
second line, for 'SNMPv2-MIB::sysObjectID.0' returns a value of 'OID: 
NET-SNMP-MIB::netSnmpAgenOIDs.255' on systems without the problem and a 
value of 'OID: SNMPv2-SMI::dod.0.0.0.0.0.0.0' on system that do have 
this problem.

It seems the monitoring packages are using the return value to determine 
the type of system and which MIB/OID to use to poll for host information 
data.

I have the following questions:
1) Is anyone else seeing this problem or can confirm it's not a problem 
on just my systems?
2) Does anyone know if this was an intentional change?
3) What is the "correct" workaround?  Is there a way to specify the old 
return value in snmpd.conf for example?  I've looked through the 
documentation but I'm not sufficiently familiar with the operation of 
the package or snmp to figure it out.

This problem seems to occur regardless of the FBSD version (tried on 
4.11 and 6.0).

Thanks for your interest.