[SNMP4J] Please help me

[Frank Fock]

Jacky,

Shortly said, this is a bug in the SNMP4J.jar file in the dist/lib 
directory.
If you build the sources yourself, you won't have the problem below.
You can either recompile the sources using ant or download the newly
packaged beta(2) from http://www.snmp4j.org.

Please find additional comments inline:

Vee wrote:

> Hello
>  
>        I just happened to use SNMP4j and experienced some problem. My 
> code is absolutely simple for the test of trying to get some value 
> from device.
>  
> I firstly set the TransportMapping object due to constructor method of 
> the Snmp class. (but actually I use only SNMP v.1 . I recognize that 
> the Transport mapping is defined in SNMP 2, isn't it?)

No, a transport mapping is SNMP version independent. It can be used
with any version.

>  
>         *TransportMapping transport = new DefaultUdpTransportMapping();
>         Snmp protocol = new Snmp(transport);*
>  
> Hence, I put "transport.listen()" in it (I don't know the point to do 
> this because...well as I said, I think that SNMP v.1 doesn't have 
> transport mapping...if I'm incorrect please suggest) and then set the 
> Target for my device.
>
That's all OK.

>         *transport.listen();*
> *
>         CommunityTarget myTarget = new CommunityTarget();
>         Address deviceAdd;
>         deviceAdd = GenericAddress.parse("udp:10.201.0.110/161");
>
>         myTarget.setAddress(deviceAdd);
>         myTarget.setCommunity(new OctetString("public"));
>         myTarget.setRetries(0);
>         myTarget.setTimeout(5*60);    
>         myTarget.setVersion(SnmpConstants.version1);
> *       
> and then, I'm ready to submit the PDU to device. Note that the OID I 
> want to get is ifInOctets which is 1.3.6.1.2.1.2.2.1.10 according to 
> the MIB-2 RFC1213

If you do a GET request, you will have to append the ifIndex to the above
OID to get a value back. Or simply use a GETNEXT.

>
>        * PDU pdu = new PDUv1();
>         VariableBinding var = new VariableBinding(new 
> OID("1.3.6.1.2.1.2.2.1.10"));
> *

Here use "1.3.6.1.2.1.2.2.1.10.1" instead to get the ifInOctets of 
interface 1.

> *        pdu.add(var);
>         pdu.setType(PDU.GET);
>         pdu = protocol.sendPDU(pdu,myTarget);*
>  
> and the result, it said the null is returned from .sendPDU
> I don't know what I have done wrong. So I try to use log4j and here is 
> the debug messages.
>  
> DEBUG [main] - Initialized Salt to 9c1ccd88a79fbc33.
> DEBUG [main] - Sending message to 10.201.0.110/161 with length 44: 
> 30:2a:02:01:00:04:06:70:75:62:6c:69:63:a1:1d:02:04:08:73:35:b7:02:01:00:02:01:00:30:0f:30:0d:06:09:2b:06:01:02:01:02:02:01:0a:05:00
> DEBUG [main] - New pending request with 
> handleorg.snmp4j.mp.PduHandle at 87335b7 
> <mailto:handleorg.snmp4j.mp.PduHandle at 87335b7>
> DEBUG [Thread-1] - Received message from /10.201.0.110 with length 13: 
> 30:82:00:34:02:01:00:04:06:70:75:62:6c
>
Here is the bug where the incoming message gets truncated.

> ERROR [Thread-1] - java.io.IOException: The encoded length 52 exceeds 
> the number of bytes left in input at position 4
>
> java.io.IOException: The encoded length 52 exceeds the number of bytes 
> left in input at position 4
>         at org.snmp4j.asn1.BER.checkLength(BER.java:805)
>         at org.snmp4j.asn1.BER.decodeLength(BER.java:489)
>         at org.snmp4j.asn1.BER.decodeHeader(BER.java:522)
>         at 
> org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:240)
>         at 
> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:163)
> java.lang.NullPointerException
>  
> It said "the encoded length 52 exceeds the number of bytes left in 
> input at position 4" 
>  

This says that the received message says in its header (byte position 4) 
that it is 52 bytes
long, bute since the message got truncated by a bug in the transport 
mapping, it
is only 13 bytes long and thus cannot be parsed correctly.

> what is this??   Could you give me any suggestion?  Do I need to do 
> any extra work to make it run properly?? (such as addCommandResponder)
>  

No, just recompile the package and everything should work fine.

Best regards,
Frank