[SNMP4J] Problems with Request ID

[Angel Angelov]

Hi Frank,
thanks for the source code patch.
I applied it and tested it. It fixes the problem by response PDUs with 
request ID > 2^31.

Will you put this source code modification in to the next SNMP4J release?

What do you think to change the type of requestID from Integer32 to 
UnsignedInteger32?
In this way you can avoid other similar problems...

And one suggestion:
It will be useful to put the release version in:
 - package name like SNMP4J-1.6a.jar
 - in jar manifest file like "SNMP4J-Version: 1.6a
 - log line with the version
One or more of this items will help the developers to control better the 
library release they use.

Thanks for the great library and for the great support.

Regards,
Angel



Frank Fock wrote:

> Hi Angel,
>
> Please try to replace row 383-391 of MessageDispatcherImpl by
>
>      // if request ID is == 0 then create one here, otherwise use the 
> request
>      // ID because it may be a resent request.
>      PduHandle pduHandle;
>      if ((pdu.getRequestID().getValue() == 0) &&
>          (pdu.getType() != PDU.RESPONSE)) {
>        pduHandle = createPduHandle();
>      }
>      else {
>        pduHandle = new PduHandle(pdu.getRequestID().getValue());
>      }
>
> This will fix the problem, I suppose.
>
> Best regards,
> Frank
>
> Angel Angelov wrote:
>
>> Hi Frank,
>> I upgraded snmp4j to v1.6a, but I still get problems with request IDs 
>> > 2^31.
>>
>> Here is a packet I receive:
>> 2005-11-10 13:25:01,215 [DefaultUDPTransportMapping_0.0.0.0/1162] 
>> DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Received 
>> message from /172.25.2.20/40975 with length 63: 
>> 30:3d:02:01:00:04:06:70:75:62:6c:69:63:a0:30:02:04:8d:ef:89:54:02:01:00:02:01:00:30:22:30:0f:06:0b:2b:06:01:04:01:86:8d:1f:64:01:01:05:00:30:0f:06:0b:2b:06:01:04:01:86:8d:1f:64:01:02:05:00 
>>
>>
>> The request ID is set to -1913681580 in to the PDU object
>> When I snoop the UDP packets on my network interface I see that the 
>> request ID have value 0x8DEF8954
>>
>> I crate response PDU using the same request ID -1913681580.
>> This is the response packet:
>> 2005-11-10 13:25:01,218 [DefaultUDPTransportMapping_0.0.0.0/1162] 
>> DEBUG org.snmp4j.transport.DefaultUdpTransportMapping - Sending 
>> message to 172.25.2.20/40975 with length 71: 
>> 30:45:02:01:00:04:06:70:75:62:6c:69:63:a2:38:02:04:4f:76:6d:0a:02:01:00:02:01:00:30:2a:30:13:06:0b:2b:06:01:04:01:86:8d:1f:64:01:01:42:04:03:2b:00:00:30:13:06:0b:2b:06:01:04:01:86:8d:1f:64:01:02:42:04:02:a0:54:20 
>>
>> When I snoop the UDP packets again I see that the request ID of the 
>> response PDU have value 0x4F766D0A
>>
>> Because the IDs are different, the response is not ignored from the 
>> agent.
>>
>> The GET request is generated from Cricket 
>> (http://cricket.sourceforge.net)
>>
>> Frank, can you reproduce the problem with the packet data I send to you?
>>
>> Regards,
>> Angel
>>
>>
>>             _______________________________________________
>> SNMP4J mailing list
>> SNMP4J at agentpp.org
>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>
>>
>>  
>>
>
>