[SNMP4J] Wrong SNMP Enterprise parsed from trap by SNMP4j

[Frank Fock]

Hi Soumya,

Cool, you discovered a bug that is there in SNMP++ since 1988 (more than 
twenty years).
And I did the same mistake in SNMP4J again.
The two subidentifiers X and Y are encoded together as (X*40)+Y where X 
is 0,1, or 2.
For X = 2, Y can be greater than 39. Here is the error in SNMP4J and 
SNMP++. Both
assumed that Y will be always < 40 and that X may be 3 or greater - 
which is of course
wrong.

Both libraries will be fixed very soon with new releases.

Best regards,
Frank


Am 23.01.2014 13:17, schrieb Chatterjee, Soumya Subhra:
> Hi Frank
>
> Here is the hex dump of the trap.
>
> Trap data: 30:81:E1:02:01:00:04:06:70:75:62:6C:69:63:A4:81:D3:06:04:91:6D:7A:27:
> 40:04:7F:00:00:01:02:01:01:02:01:00:43:01:00:30:81:BB:30:1C:06:05:91:6D:7A:27:01
> :04:13:32:30:31:34:2D:30:31:2D:31:35:54:31:30:3A:34:30:3A:33:34:30:12:06:05:91:6
> D:7A:27:02:04:09:57:53:44:31:32:32:37:35:39:30:0F:06:05:91:6D:7A:27:03:04:06:6C:
> 30:32:31:34:30:30:15:06:05:91:6D:7A:27:04:04:0C:44:65:66:61:75:6C:74:47:72:6F:75
> :70:30:14:06:05:91:6D:7A:27:05:04:0B:44:65:76:69:73:41:75:74:6F:2D:31:30:1B:06:0
> 5:91:6D:7A:27:06:04:12:44:65:66:61:75:6C:74:54:72:61:6E:73:61:63:74:69:6F:6E:30:
> 2C:06:05:91:6D:7A:27:07:04:23:54:69:6D:65:6F:75:74:5F:6F:63:63:75:72:72:65:64:5F
> :77:61:69:74:69:6E:67:5F:66:6F:72:5F:6F:62:6A:65:63:74
>
> If you want, I can also provide the Wireshark capture file for the trap.
>
> Soumya Subhra Chatterjee
> CA Technologies
> Associate Software Engineer
> Tel:  +914066877206
> SoumyaSubhra.Chatterjee at ca.com
>
>                             
>  Please consider the environment before printing this e-mail.
>
> -----Original Message-----
> From: snmp4j-bounces at agentpp.org [mailto:snmp4j-bounces at agentpp.org] On Behalf Of Frank Fock
> Sent: 23 January 2014 5:27 AM
> To: snmp4j at agentpp.org
> Subject: Re: [SNMP4J] Wrong SNMP Enterprise parsed from trap by SNMP4j
>
> Hi Soumya,
>
> You can send the hexdump of the trap PDU to support at snmp4j.org.
> There is no known issue. Some devices/agents implement a wrong length encoding of BER elements, but its not clear what could have caused that issue from the facts your provided.
>
> Best regards,
> Frank
>
> Am 22.01.2014 10:20, schrieb Chatterjee, Soumya Subhra:
>> Hi all/Frank
>>
>> Recently I came across traps (v1) by Appsmon application. Capturing
>> the packet using Wireshark and examining its properties gives an
>> Enterprise OID of 2.2205.122.39 but when SNMP4j parses the trap the
>> same comes out as 57.5.122.39
>>
>> Why are the values coming out to be different? Is there any known issue about it?
>>
>> If you want to take a look at it, I can provide code snippets, wireshark capture of the trap, and screenshots, if you can give a location/email id where I can provide that.
>>
>> Soumya Subhra Chatterjee
>> CA Technologies
>> Associate Software Engineer
>> Tel:  +914066877206
>> SoumyaSubhra.Chatterjee at ca.com
>>
>> _______________________________________________
>> SNMP4J mailing list
>> SNMP4J at agentpp.org
>> https://s16675406.onlinehome-server.info/mailman/listinfo/snmp4j
> --
> ---
> AGENT++
> Maximilian-Kolbe-Str. 10
> 73257 Koengen, Germany
> https://agentpp.com
> Phone: +49 7024 8688230
> Fax:   +49 7024 8688231
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> https://s16675406.onlinehome-server.info/mailman/listinfo/snmp4j

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231