On Wed, Feb 04, 2015 at 12:03:36PM +0530, Ashwini Pagade wrote: > Hi MF, > > While testing further in detail I found below behaviour in netsnmp: > > When I send trap below for the integer value = 2^31 i.e 2147483648 for the > first time: > snmptrap -c public -v 2c vl-pun-sms-dv01 '' 1.3.6.1.4.1.20006.1.0.5 > 1.3.6.1.4.1.12345.1 > i 2147483648 > > I see below in snmp logs: > > Received 93 bytes from UDP: [10.129.157.150]:40991->[10.129.55.4] > 0000: 30 5B 02 01 01 04 06 70 75 62 6C 69 63 A7 4E 02 0[.....public.N. > 0016: 04 1B 5D D3 52 02 01 00 02 01 00 30 40 30 10 06 ..].R......0@0.. > 0032: 08 2B 06 01 02 01 01 03 00 43 04 28 93 DC 04 30 .+.......C.(...0 > 0048: 19 06 0A 2B 06 01 06 03 01 01 04 01 00 06 0B 2B ...+...........+ > 0064: 06 01 04 01 81 9C 26 01 00 05 30 11 06 08 2B 06 ......&...0...+. > 0080: 01 04 01 E0 39 01 02 05 00 80 00 00 00 ....9........ > ... > > trace: snmp_pdu_parse(): ../../snmplib/snmp_api.c, 5236: > dumph_recv: error index > dumpx_recv: 02 01 00 > dumpv_recv: Integer: 0 (0x00) > > here first time it gives the integer value as 0.
No, it says the error index is 0, that is expected an can be seen in the blob above - it is the 3 bytes at position 24-27 while the value you sent in is at position 87-93. > Next time when I send the same trap I get below: > > Received 93 bytes from UDP: [10.129.157.150]:38601->[10.129.55.4] > 0000: 30 5B 02 01 01 04 06 70 75 62 6C 69 63 A7 4E 02 0[.....public.N. > 0016: 04 06 86 87 26 02 01 00 02 01 00 30 40 30 10 06 ....&......0@0.. > 0032: 08 2B 06 01 02 01 01 03 00 43 04 28 94 43 E9 30 .+.......C.(.C.0 > 0048: 19 06 0A 2B 06 01 06 03 01 01 04 01 00 06 0B 2B ...+...........+ > 0064: 06 01 04 01 81 9C 26 01 00 05 30 11 06 08 2B 06 ......&...0...+. > 0080: 01 04 01 E0 39 01 02 05 00 80 00 00 00 ....9........ Note that this blob differs from the last one only in bytes 17-20 and 44-47, these are expected to differ as they are the request id and the timestamp. > dumph_recv: VarBind > trace: snmp_parse_var_op(): ../../snmplib/snmp.c, 166: > dumph_recv: Name > dumpx_recv: 06 08 2B 06 01 02 01 01 03 00 > dumpv_recv: ObjID: SNMPv2-MIB::sysUpTime.0 > trace: snmp_pdu_parse(): ../../snmplib/snmp_api.c, 5293: > dumph_recv: Value > dumpx_recv: 43 04 28 94 43 E9 > dumpv_recv: UInteger: 680805353 (0x289443E9) This is actually a varbind, so that is more expected, but this is the first varbind at position 29-46, and according to the specification this is a timestamp expressed in centiseconds that are provided by snmptrap since you didn't supply one. > > all above are wrong values. Also in case of integer it fails for negative > values as below: > > snmptrap -c public -v 2c vl-pun-sms-dv01 '' 1.3.6.1.4.1.20006.1.0.5 > 1.3.6.1.4.1.12345.1 > i -12345 > > trace: snmp_parse_var_op(): ../../snmplib/snmp.c, 166: > dumph_recv: Name > dumpx_recv: 06 08 2B 06 01 04 01 E0 39 01 > dumpv_recv: ObjID: SNMPv2-SMI::enterprises.12345.1 > > trace: snmp_pdu_parse(): ../../snmplib/snmp_api.c, 5293: > dumph_recv: Value > dumpx_recv: 02 02 CF C7 > dumpv_recv: Integer: -12345 (0xFFFFCFC7) > > I think in snmpapi.c its not converting it properly for negative values and > on my adapter I get below 4294954951 value for -12345 I have to admit that I have a hard time seeing how -12345 in resulting in -12345 out could be discerned as a problem. I also think your adapter is broken - the most significant bit of the value is set and that tells that this is a negative value. This is also the reason that 0x80000000 is encoded as 02 05 00 80 00 00 00, note the additional 00 before 80 that is there to tell that this value is positive. > Whats wrong in snmpapi.c ? Nothing from what I have seen here, but I think you should read up on the relevant RFCs, in particular rfc 1905, and it would be good if you could find a reference on the encoding rules as well. /MF ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
