From owner-freebsd-net@FreeBSD.ORG Sat Mar 25 22:40:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B135716A400 for ; Sat, 25 Mar 2006 22:40:46 +0000 (UTC) (envelope-from czhao@metcomm.net) Received: from mx1-vdb.metcomm.net (mx1-vdb.metcomm.net [198.143.64.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id F195A43D5D for ; Sat, 25 Mar 2006 22:40:44 +0000 (GMT) (envelope-from czhao@metcomm.net) Received: from localhost (localhost [127.0.0.1]) by mx1-vdb.metcomm.net (Postfix) with ESMTP id 8D4C85C22 for ; Sat, 25 Mar 2006 17:40:43 -0500 (EST) Received: from [10.0.0.10] (66-234-40-134.nyc.cable.nyct.net [66.234.40.134]) by mx1-vdb.metcomm.net (Postfix) with ESMTP for ; Sat, 25 Mar 2006 17:40:40 -0500 (EST) Message-ID: <4425C661.8090406@metcomm.net> Date: Sat, 25 Mar 2006 17:38:25 -0500 From: czhao@metcomm.net User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at metcomm.net Subject: Problem in net-snmp 5.2.x. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2006 22:40:46 -0000 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.