[SNMP4J] Problems with Request ID

[PHIL BERGSTRESSER]

Frank,

Whoa. Think about that request. The requestID is defined as a signed
INTEGER32 in SNMP. Shouldn't this be adequate for Java?

Phil

-----Original Message-----
From: snmp4j-bounces at agentpp.org [mailto:snmp4j-bounces at agentpp.org] On
Behalf Of Angel Angelov
Sent: Friday, November 11, 2005 1:44 PM
To: SNMP4J at agentpp.org
Subject: Re: [SNMP4J] Problems with Request ID

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