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

[Frank Fock]

Jeff,

At the moment, the only way for you to provide a workaround
for the brain damaged agent is implementing your own
message processing model (e.g. MPv1WithCounter64) that
uses a modified PDUv1 (e.g. PDUv1WithCounter64).

I agree that such a workaround is more complex than
it should be. I will introduce a factory for the
PDU used by a MessageProcessingModel to facilitate
changes to the used PDU class.

Best regards,
Frank

Jeff Gehlbach wrote:
> -----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-----
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j

-- 
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com