Hi Jens,
First of all, we seem to agree that this SNMP4J behavior is not a bug.
Instead, the device that sends IPv6 addresses as IpAddress syntax
is buggy.
How should SNMP4J "ignore" such a bug? Return a Null value?
How would you ever know, that the agent should be fixed?
If you want to be able to process such non-standard IpAddress encodings,
you can simply register your IpAddress implementation for the syntax
64 (IpAddress).
There are three steps to do (without changing any SNMP4J code):
1. Implement your IpAddress class which parses IPv6 BER encoded IpAddress
values.
2. Call SNMP4JSettings.setExtensibilityEnabled(true) before loading any
SNMP4J
class.
3. Set the system property "org.snmp4j.smisyntaxes" to the properties file
that replaces the standard IpAddress class by your own implementation.
Use the org\snmp4j\smi\smisyntaxes.properties file as template for your
file.
That's all.
Best regards,
Frank
Am 24.10.2013 14:49, schrieb Jens Bannmann:
Hi,
in our project, we use SNMP4J for communicating with printers - among other
functions, we use TreeUtils.walk() to "scan" the whole MIB tree.
Recently, using SNMP4J 2.1.0, we ran into problems with a printer (Kyocera
3050ci) that returns IPv6 addresses (16 bytes) for several OIDs. As far as
I understood the SMI spec, it only allows 4-byte addresses and thus does
not support IPv6 at all - which means that SNMP4J does not have to handle
such cases. However, it also does not simply ignore it - the tree walking
stops and logs the following exception on stderr:
java.io.IOException: IpAddress encoding error, wrong length: 16
at org.snmp4j.smi.IpAddress.decodeBER(IpAddress.java:166)
at
org.snmp4j.smi.AbstractVariable.createFromBER(AbstractVariable.java:172)
at org.snmp4j.smi.VariableBinding.decodeBER(VariableBinding.java:167)
at org.snmp4j.PDUv1.decodeBER(PDUv1.java:186)
at org.snmp4j.mp.MPv1.prepareDataElements(MPv1.java:191)
at
org.snmp4j.MessageDispatcherImpl.dispatchMessage(MessageDispatcherImpl.java:272)
at
org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:368)
at
org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:328)
at
org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:76)
at
org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:378)
at java.lang.Thread.run(Unknown Source)
We therefore never get the full subtree. To solve this problem, we forked
the SNMP4J library and changed the code so that tree walking continues.
Note that the relevant code is unchanged in version 2.2.2.
However, we would very much like to drop that fork and return to a regular
release.
Note: Microsoft's command-line tool "snmputil" simply lists these entries
as "Invalid", but continues walking the tree.
Best regards,
Jens Bannmann
--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax: +49 7024 8688231
_______________________________________________
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j
