[SNMP4J] Fwd: SNMP4J feature request: workaround for Counter64 returned in snmpv1 queries

[Jeff Gehlbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank,

You will have received the below not long ago.  I'm the one who  
suggested Umberto approach you about this issue.  For the record, I  
think this vendor belongs in the SNMP hall of shame for painting  
itself into such a corner -- the agent refuses to speak SNMPv2C, yet  
it includes Counter64 varbinds in SNMPv1 replies.  There are plenty of  
other vendors whose agents exhibit the Counter64-in-V1-reply bug, but  
Mikrotik is the only one I'm aware of that makes it impossible to work  
around the problem by using SNMPv2C.

While we want OpenNMS to support the widest possible range of devices  
(even insanely buggy ones, when possible), it's totally unreasonable  
to ask you to pollute SNMP4J with a hack to work around such a  
needless agent bug.  Hence my suggestion that an extensibility  
facility for the PDU classes similar to the one you provide for the  
SMI would be a good compromise.  I hope you will consider it as a  
possibility.

Best,
- -jeff

Jeff Gehlbach
The OpenNMS Group, Inc.

Begin forwarded message:

> From: "Umberto Nicoletti" <umberto.nicoletti at gmail.com>
> Date: March 3, 2008 8:35:04 AM EST
> To: info at snmp4j.org
> Cc: jeffg at opennms.org
> Subject: SNMP4J feature request: workaround for Counter64 returned  
> in snmpv1 queries
>
> Hello there,
> I'm an opennms 1.3.9 user with an SNMP problem discovering a wireless
> router built on the mikrotik base (http://www.mikrotik.com/). The
> device is in fact assembled and rebranded as a
> http://www.sicetelecom.it/ router.
>
> The problem is that the device in question returns Counter64 values in
> response to snmpv1 queries AND it only supports snmp v1. The details
> of the issue (including packet captures and proof of the erroneous
> implementation) are at:
> http://bugs.opennms.org/show_bug.cgi?id=2306
>
> I promise I will try to get the vendor to be more strict, as he should
> definitely be, in implementing well documented snmp standards, but in
> the meantime I would also be able to poll the devices that are already
> been deployed and that will be deployed shortly at a customer site
> who's using opennms.
>
> What I ask for is that the snmp4j mantainers accept the patch attached
> at the previously mentioned bugzilla issue as a workaround or that
> they implement some kind of equivalent workaround (i.e.: PDU
> extensibility) as suggested in comment
> http://bugs.opennms.org/show_bug.cgi?id=2306#c9.
>
> Thanks in advance,
> Umberto

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkfMDosACgkQB3953+hexDrLfwCfXsrreztGguEnqRrHa1uEglFA
92kAmgP+zbLWmZjPxFDM0tMa0aG4W38g
=aYLX
-----END PGP SIGNATURE-----