📄 snmp-faq-1.1.ascii
字号:
Received packet...in snmpIoCommunityValidate: 7b9ef8pkt comm: public - 6comm: public - 6ipRouteEntryNext >>> 11ipRouteEntryInfoGet >>> lastmatch 11ipRouteEntryInfoGet >>> lastmatch 12ipRouteEntryInfoGet >>> lastmatch 13 Received packet...in snmpIoCommunityValidate: 7b9ef8pkt comm: public - 6comm: public - 6ipRouteEntryNext >>> 1ipRouteEntryNext >>> 2ipRouteEntryInfoGet >>> lastmatch 2ipRouteEntryInfoGet >>> lastmatch 3ipRouteEntryInfoGet >>> lastmatch 4ipRouteEntryInfoGet >>> lastmatch 5ipRouteEntryInfoGet >>> lastmatch 6ipRouteEntryInfoGet >>> lastmatch 7ipRouteEntryInfoGet >>> lastmatch 8ipRouteEntryInfoGet >>> lastmatch 9ipRouteEntryInfoGet >>> lastmatch 10ipRouteEntryInfoGet >>> lastmatch 11 Received packet...in snmpIoCommunityValidate: 7b9ef8pkt comm: public\050 - 6 comm: public - 6ipRouteEntryNext >>> 11ipRouteEntryNext >>> 12ipRouteEntryInfoGet >>> lastmatch 12ipRouteEntryInfoGet >>> lastmatch 13 ->RESOLUTION:1) ipAdEntBcastAddr is INTEGER type not IpAddress type. From MIB-II RFC - IpAddrEntry ::= SEQUENCE { ipAdEntAddr IpAddress, ipAdEntIfIndex INTEGER, ipAdEntNetMask IpAddress, ipAdEntBcastAddr INTEGER, ipAdEntReasmMaxSizecase LEAF_ipAdEntBcastAddr: getproc_got_ip_address (pktp, vbp, htonl (pIpAddrEntry->ipAdEntBcastAddr)); INTEGER (0..65535) } In snmpIp.c - the method implemnetation for ipAddrEntryInfoGet() is incorrect - case LEAF_ipAdEntBcastAddr: getproc_got_ip_address (pktp, vbp, htonl (pIpAddrEntry->ipAdEntBcastAddr)); It should be integer, but NOT ip_address. In file snmpIp.c change the lines to be as follows case LEAF_ipAdEntBcastAddr: getproc_got_int32 (pktp, vbp, pIpAddrEntry->ipAdEntBcastAddr);2) Looping for var binds should be called using vbp->vb_ml.ml_last_match not lastmatch. The code in snmpIp.c is incorrect in the subroutine ipAddrEntryNext(). it reads: ipAddrEntryInfoGet (lastmatch, pktp, vbp, &ipAddrEntry); it should be: ipAddrEntryInfoGet (vbp->vb_ml.ml_last_match, pktp, vbp, &ipAddrEntry); Similarly code in ipAddrEntryGet() is incorrect - ipAddrEntryInfoGet (lastmatch, pktp, vbp, &ipAddrEntry) correction : change "lastmatch" to vbp->vb_ml.ml_last_match . SPR / PATCH: 9033KEYWORDS: query getnext var bind --------------------------------------------------------------------------24. TITLE: SNMP MIB compiler fails on UInteger32 in rfc1447 mib definition. SCOPE DISCOVERED ON HOST: All ------------------- ------------------- ARCHITECTURE: All ------------------- ------------------- BSP: All ------------------- -------------------PRODUCT / REVISION: SNMPv1/v2c 1.0 ------------------- -------------------DESCRIPTION OF PROBLEM:Problem using the mibcompiler for a ASN.1 type (UInteger32) which is defined in RFC1442 but has not been included in the mibcompiler.% mibcomp -check rfc1447.mibWind River Systems WindNet MIB compiler , version 1.0.Copyright (c) 1989-1996, Wind River Systems Inc.rfc1447.mib:6: SNMPv2-SMI doesn't define UInteger32RFC 1442 defines SMI for SNMPv2 and it contains the definition for UInteger32: -- an unsigned 32-bit quantity UInteger32 ::= [APPLICATION 7] IMPLICIT INTEGER (0..4294967295) RESOLUTION: RFC1442 is obsolete, and it has been replaced by RFC1902. TheUInteger32 has been removed and Unsigned32 type has been added. This isreflected in the SNMP MIB compiler that is based on Emissary 6.0Checking the SNMP header files in the /target/h/snmp/ dir will show thatUInteger32 has been removed. Use Unsigned32 instead of UInteger32. SPR / PATCH:KEYWORDS: mib compiler RFC 1573 1442 interfaces ASN1--------------------------------------------------------------------------25. TITLE: SNMP MIB compiler complains about BITS in the MIB definition. SCOPE DISCOVERED ON HOST: All ------------------- ------------------- ARCHITECTURE: All ------------------- ------------------- BSP: All ------------------- -------------------PRODUCT / REVISION: SNMPv1/v2c 1.0 ------------------- -------------------DESCRIPTION OF PROBLEM:The following MIB definition fails with the SNMPv1/v2c mib compiler withthe error : expected a string got BITSUnsigned32 and BITS are both in rfc1902, which replaces rfc1442 ...,and rfc1902 is supported by the smpv1/v2c 1.0 mib compiler.The mibcompiler does not complain about Unsigned32.SOME-IF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, BITS FROM SNMPv2-SMI enterprisesFROM RFC1155-SMI DisplayStringFROM RFC1213-MIB ;... sysProcessorNo OBJECT-TYPE SYNTAX BITS {master(0), slave1(1)} MAX-ACCESS read-write STATUS current DESCRIPTION " processor number" ...END RESOLUTION:The MIB defition compiles the BITS construct without error if the BITS is removed from the IMPORTS statement.SPR / PATCH: 9565KEYWORDS: bits mibcomp snmpv1 snmpv2 snmpv2c snmp--------------------------------------------------------------------------26. TITLE: m2Init does not initialze the maxRouteTableSize value correctly. SCOPE DISCOVERED ON HOST: All ------------------- ------------------- ARCHITECTURE: All ------------------- ------------------- BSP: All ------------------- -------------------PRODUCT / REVISION: SNMP v1/v2c 1.0 Tornado 1.0.1 ------------------- -------------------DESCRIPTION OF PROBLEM:One of the functions in the m2lib - m2IpRouteTblentryGet()corrupts the memory. The following m2Init() call was used :m2Init(0,0,0,0,0,0,10);Although the routeTable size is set to 10, after this call the routeTable grows beyond 10. Repeated SNMP-get calls, and a few seconds to a few minutes later task dies with a bus error.RESOLUTION:When initializing the routing table structure using m2IpInit, youhave to first release the resources with m2IpDelete. Once you release the resources call m2IpInit with a value of "10" for the routetable size, it should work the way you expect it to.If you call m2IpInit without calling m2IpDelete, itdoes not initialize the m2RouteTableSize to 10, and the default value of 40 is still being used. Shown below are two outputs from snmp walk for ipRouteDest. The first one was done without calling m2Delete() so the value of maxRouteTableSize in m2Init() which was set to 1 did not take affect. In the second case m2Delete() was called before m2Init() and hence only one route has been retrieved by the SNMP manager which is the expected result.> snmpwalk ipRouteDestipRouteDest.127.0.0.1 IP Address: 127.0.0.1ipRouteDest.147.11.41.0 IP Address: 147.11.41.0ipRouteDest.147.11.41.10 IP Address: 147.11.41.10ipRouteDest.147.11.41.11 IP Address: 147.11.41.11ipRouteDest.147.11.41.12 IP Address: 147.11.41.12ipRouteDest.147.11.41.13 IP Address: 147.11.41.13ipRouteDest.147.11.41.14 IP Address: 147.11.41.14ipRouteDest.147.11.41.15 IP Address: 147.11.41.15ipRouteDest.147.11.41.16 IP Address: 147.11.41.16ipRouteDest.147.11.41.17 IP Address: 147.11.41.17ipRouteDest.147.11.41.18 IP Address: 147.11.41.18ipRouteDest.147.11.41.19 IP Address: 147.11.41.19No more in subtree> snmpwalk ipRouteDestipRouteDest.127.0.0.1 IP Address: 127.0.0.1No more in subtreeSPR / PATCH:KEYWORDS: m2Lib MIB m2IpInit m2IpLib m2IpGroupInfoGet Ip routing table --------------------------------------------------------------------------27. TITLE: How to set the priority of the tSnmpd task at vxWorks boot time. SCOPE DISCOVERED ON HOST: All ------------------- ------------------- ARCHITECTURE: All ------------------- ------------------- BSP: All ------------------- -------------------PRODUCT / REVISION: SNMP v1/v2c 1.0 Tornado 1.0.1 ------------------- -------------------DESCRIPTION OF PROBLEM: How do I change the default priority of the WindNet SNMP agent task "tSnmpd" during the network initialization sothat when vxWorks boots up the tSnmpd task is set to the new priority. RESOLUTION:The network subsystem initialization is done from usrNetwork.cusrSnmpdInit() initializes the SNMP agent and the MIB-2 libraries.snmpdInit(snmpMibModules, traceLevel,0, 0) routine is called fromusrSnmpdInit() to initialize the SNMP agent:STATUS snmpdInit ( MIB_MODULE * pModules, /* MIB modules */ int traceLevel, /* trace level */ int prio, /* agent task priority */ int stackSize /* agent task stack size */ )The third parameter <prio> is set to 0 which has the default value - 150.This default task priority can be modified in usrNetwork.c to another value. After modifying usrNetwork.c, rebuild vxWorks. Parameter <stackSize> specifies the stack size of the task and is set to 0 which has the default value of 0x7000.SPR / PATCH:KEYWORDS: startup initialize SNMP SNMPv1 SNMPv2c --------------------------------------------------------------------------28. TITLE: How are the driver counters used for MIB2 interfaces ? SCOPE DISCOVERED ON HOST: All ------------------- ------------------- ARCHITECTURE: All ------------------- ------------------- BSP: All ------------------- -------------------PRODUCT / REVISION: SNMP v1/v2c 1.0 Tornado 1.0.1 ------------------- -------------------DESCRIPTION OF PROBLEM:Why ifInOctets and ifOutOctets is 4294967295 and does not change. % get ifOutOctets.1ifOutOctets.1 Counter: 4294967295% get ifInOctets.1 ifInOctets.1 Counter: 4294967295RESOLUTION: m2IfTblEntryGet() maps the MIB-II interface index to the system's internal interface index.The driver IOCTL structure is initialized, and the interface table is read if there is a change is configuration.The MIB-II interface entry variables below can only be tracked by thehardware driver. Drivers that support these variables respond to theIOCTL successfuly. If these variables are not supported by the driverdefault values are used:/* defaults */ pIfReqEntry->ifInOctets = -1; pIfReqEntry->ifInNUcastPkts = 0; pIfReqEntry->ifInDiscards = 0; pIfReqEntry->ifInUnknownProtos = 0; pIfReqEntry->ifOutOctets = -1; pIfReqEntry->ifOutNUcastPkts = 0; pIfReqEntry->ifOutDiscards = 0;SPR / PATCH: 3452, SNMP v1/v2c Release NotesKEYWORDS: M2_NETDRVARS MIB-II interface group network driver--------------------------------------------------------------------------29. TITLE: Why the SET request from a SNMP manager does not get a r⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -