BugZero updated this defect 58 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
3/22/2024
Smart Assurance - SMARTS
No affected releases provided.
No fixed releases provided.
Smarts IP discovery error on Window Hosts 26-Oct-2009 12:33:43 PM+287ms Pacific Daylight Time] t@2664 Discovery #8SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First OID: .1.3.6.1.4.1.232.6.2.9.3.1.3[26-Oct-2009 12:33:43 PM+303ms Pacific Daylight Time] t@2664 Discovery #8SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First OID: .1.3.6.1.4.1.232.6.2.6.7.1.2[26-Oct-2009 12:33:43 PM+319ms Pacific Daylight Time] t@2664 Discovery #8SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First OID: .1.3.6.1.4.1.232.6.2.6.8.1.2[26-Oct-2009 12:33:43 PM+319ms Pacific Daylight Time] t@2664 Discovery #8SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First OID: .1.3.6.1.4.1.2021.4.3[26-Oct-2009 12:33:43 PM+319ms Pacific Daylight Time] t@2664 Discovery #8SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First OID: .1.3.6.1.4.1.2021.4.5 SNMPv2 agent is looping on Smarts IP discovery of SystemEdge host The following "Agent loops" discovery error for OID .1.3.6.1.4.1.674.10892.1.400.20.1.7 appears in Smarts discovery progress window and in Smarts IP server log: [16-Sep-2009 15:36:09+246ms SAST] t@56 Discovery #1SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.204.20.70, First OID: .1.3.6.1.4.1.674.10892.1.400.20.1.5[16-Sep-2009 15:36:09+251ms SAST] t@56 Discovery #1SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.204.20.70, First OID: .1.3.6.1.4.1.674.10892.1.400.20.1.7 Response from a GET_BULK of the OID .1.3.6.1.4.1.674.10892.1.400.20.1.7 returns a NoSuchName / NoSuchInstance exception in packet trace from a Smarts IP discovery of the device
The SNMPv2 bulk request of OID .1.3.6.1.4.1.674.10892.1.400.20.1.7 returns a noSuchInstance error and returns the same polled OID in response. This is incorrect according to RFC definitions, so the SNMPAgent implementation for SNMPV2c version is incorrect for these devices.According to latest the RFC 3416 (http://tools.ietf.org/html/rfc3416), for Bulk/getNext requests of an OID (out of MIB tree range, no lexicographic successor), an SNMP Agent should give an EndofMibview value and no error for error status. The following explanation of this behavior is found in RFC 3416 and RFC 1905:" (2) If the requested variable bindings name does not lexicographically precede the name of any variableaccessible by this request, i.e., there is no lexicographic successor, then the corresponding variable binding producedin the Response-PDU has its value field set to "endOfMibView", and its name field set to the variable bindings name in the request."
This is an SNMPv2 agent issue that must be addressed with the agent vendor to resolve. To work around this issue, you can discover the device through SNMPv1.