[SNMP4J] [PATCH] Workaround for Net-SNMP < 5.4.1 64-bit agent bug

[Jeff Gehlbach]

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

Hi!

Replying to my own post, very bad form I know, but I've received no  
feedback on this patch.

Frank, do you think this is something that could be integrated into a  
future release?  In a perfect world we'd just tell everyone to use an  
agent that doesn't exhibit this bug, but the bug is widespread and  
not widely understood -- most users assume that the bug is in OpenNMS  
since they can walk the agent just fine using the Net-SNMP tools.   
This simple change to Snmp4J alleviates a LOT of heartburn.  Having  
it in the official code base means that the OpenNMS project doesn't  
need to maintain a patched version of Snmp4J, and other projects that  
use Snmp4J will reap the benefits as well.

Thanks for your consideration,
- -jeff


On 09Oct , 2007, at 8:59 AM, Jeff Gehlbach wrote:

> Hi!
>
> I work on the OpenNMS project, which has for some time been using  
> SNMP4J as its default protocol implementation.  Thank you for the  
> fabulous work on SNMP4J!
>
> I'm writing to propose a patch that works around a bounds-checking  
> bug in the Net-SNMP project's BER library that causes OpenNMS to  
> fail to discover any 64-bit host running a Net-SNMP snmpd older  
> than version 5.4.1.  The BER bug in question causes IPv4 addresses  
> to be encoded as 64-bit values but marked in the PDU as being four  
> bytes long.  When SNMP4J decodes a RESPONSE PDU containing such a  
> value, it correctly discards the variable in question.  The upshot  
> is that OpenNMS cannot discover the interfaces on a node because it  
> does not get a valid picture of the node's ipAddrTable.
>
> The following patch, against Snmp4J 1.8.2, seems to effect a  
> workaround for this highly annoying and destructive agent bug.  I  
> (and several others) have successfully discovered and managed hosts  
> exhibiting this agent bug by dropping in an SNMP4J JAR built from  
> sources with this patch applied.  The addition of a property to  
> enable this workaround seemed the simplest and least intrusive  
> route, but I'm not married to the idea.  Feedback is earnestly  
> solicited!
>
> Thanks,
> - -jeff
>
>
> diff -ur snmp4j-1.8.2.orig/src/org/snmp4j/smi/IpAddress.java  
> snmp4j-1.8.2/src/org/snmp4j/smi/IpAddress.java
> - --- snmp4j-1.8.2.orig/src/org/snmp4j/smi/IpAddress.java  
> 2007-03-10 21:59:12.000000000 -0500
> +++ snmp4j-1.8.2/src/org/snmp4j/smi/IpAddress.java      2007-08-26  
> 19:07:26.000000000 -0400
> @@ -150,9 +150,17 @@
>                              type.getValue());
>      }
>      if (value.length != 4) {
> - -      throw new IOException("IpAddress encoding error, wrong  
> length: " +
> +         if ( (value.length == 8) && (System.getProperty 
> ("org.snmp4j.smi.bugCompat.netSnmpIpAddress8Bytes").equals 
> ("true")) ) {
> +               byte[] tempValue = { 0,0,0,0 };
> +               for (int i = 0; i < 4; i++) {
> +                 tempValue[i] = value[i];
> +               }
> +               value = tempValue;
> +         } else {
> +        throw new IOException("IpAddress encoding error, wrong  
> length: " +
>                              value.length);
> - -    }
> +      }
> +       }
>      inetAddress = InetAddress.getByAddress(value);
>    }

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

iD8DBQFHKjJuB3953+hexDoRAp27AKCNt83l7pBceZ/Jc/Yy1rN74lG+pgCdES6w
BxNapYq6B/74mLm1BwfLljw=
=Nbhz
-----END PGP SIGNATURE-----