ADTRAN NetVanta 3205 agent returns INTEGER for ifPhysAddress

Description

From capsd.log:

2008-09-18 16:01:45,561 ERROR [Capsd Suspect Pool-fiber0] SuspectEventProcessor: Error writing records
java.lang.IllegalArgumentException: cannot convert 1 to a HexString
at org.opennms.netmgt.snmp.snmp4j.Snmp4JValue.toHexString(Snmp4JValue.java:244)
at org.opennms.netmgt.snmp.AbstractSnmpStore.getHexString(AbstractSnmpStore.java:69)
at org.opennms.netmgt.capsd.snmp.IfTableEntry.getPhysAddr(IfTableEntry.java:211)
at org.opennms.netmgt.capsd.SuspectEventProcessor.addIfTableSnmpInterfaces(SuspectEventProcessor.java:939)
at org.opennms.netmgt.capsd.SuspectEventProcessor.addSnmpInterfaces(SuspectEventProcessor.java:581)
at org.opennms.netmgt.capsd.SuspectEventProcessor.addInterfaces(SuspectEventProcessor.java:557)
at org.opennms.netmgt.capsd.SuspectEventProcessor.run(SuspectEventProcessor.java:1463)
at org.opennms.core.concurrent.RunnableConsumerThreadPool$FiberThreadImpl.run(RunnableConsumerThreadPool.java:422)
at java.lang.Thread.run(Thread.java:595)

This does not appear to be a vars-per-pdu kind of issue, as a non-bulk v3 walk with the Net-SNNP tools illustrates the same behavior:

user@nms01:~$ sudo /home/user/.cpan/build/Net-SNMP-5.2.0/examples/snmpwalk.pl -v 3 -u opennms -a md5 -A xxxxxxxxx -x des -X xxxxxxxxx 192.168.1.2 1.3.6.1.2.1.2
1.3.6.1.2.1.2.1.0 = INTEGER: 3
1.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
1.3.6.1.2.1.2.2.1.1.2 = INTEGER: 2
1.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3
1.3.6.1.2.1.2.2.1.2.1 = OCTET STRING: eth 0/1: MAC:MPC860 FEC PHY:ICS1893BF v4.2
1.3.6.1.2.1.2.2.1.2.2 = OCTET STRING: t1 1/1: T1/FT1 Network Interface Module (DS1 Port [T1DSXGA])
1.3.6.1.2.1.2.2.1.2.3 = OCTET STRING: t1 1/2: T1/FT1 Network Interface Module (DS1 Port [T1DSXGA])
1.3.6.1.2.1.2.2.1.3.1 = INTEGER: 6
1.3.6.1.2.1.2.2.1.3.2 = INTEGER: 18
1.3.6.1.2.1.2.2.1.3.3 = INTEGER: 18
1.3.6.1.2.1.2.2.1.4.1 = INTEGER: 1500
1.3.6.1.2.1.2.2.1.4.2 = INTEGER: 0
1.3.6.1.2.1.2.2.1.4.3 = INTEGER: 0
1.3.6.1.2.1.2.2.1.5.1 = Gauge: 100000000
1.3.6.1.2.1.2.2.1.5.2 = Gauge: 1544000
1.3.6.1.2.1.2.2.1.5.3 = Gauge: 1544000
1.3.6.1.2.1.2.2.1.6.1 = INTEGER: 1
1.3.6.1.2.1.2.2.1.6.2 = INTEGER: 2
1.3.6.1.2.1.2.2.1.6.3 = INTEGER: 2

(output truncated, ifPhysAddress is represented in the last three lines)

We should be able to catch the IllegalArgumentException and have capsd behave as if the agent had instead returned a zero-length octet string as RFC1213 states it should do for interfaces that lack a physical address.

Environment

Operating System: All Platform: PC

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Former user September 23, 2008 at 3:12 PM

merged to 1.6 release in revision 10634

Jeff Gehlbach September 20, 2008 at 5:34 AM

Fix committed to 1.6-testing at r10604.

I'd like to get this one into 1.5.94 if possible, targeting accordingly.

Jeff Gehlbach September 20, 2008 at 5:27 AM

I modified a Net-SNMP agent to mimic this behavior by wiring ifPhysAddress to return an integer with the same value as ifType. A walk of the ifTable using the regular Net-SNMP tools against an agent exhibiting this bug looks like this:

IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: vif0.0
IF-MIB::ifDescr.3 = STRING: eth0
IF-MIB::ifType.1 = INTEGER: softwareLoopback(24)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.3 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifMtu.1 = INTEGER: 16436
IF-MIB::ifMtu.2 = INTEGER: 1500
IF-MIB::ifMtu.3 = INTEGER: 1500
IF-MIB::ifSpeed.1 = Gauge32: 10000000
IF-MIB::ifSpeed.2 = Gauge32: 10000000
IF-MIB::ifSpeed.3 = Gauge32: 10000000
IF-MIB::ifPhysAddress.1 = Wrong Type (should be OCTET STRING): INTEGER: 24
IF-MIB::ifPhysAddress.2 = Wrong Type (should be OCTET STRING): INTEGER: 6
IF-MIB::ifPhysAddress.3 = Wrong Type (should be OCTET STRING): INTEGER: 6

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created September 19, 2008 at 10:16 AM
Updated February 3, 2011 at 2:45 PM
Resolved September 23, 2008 at 3:12 PM