Discussion:
snmptrap unsigned type not working as expected
(too old to reply)
Ashwini Pagade
2015-01-29 18:02:50 UTC
Permalink
Hi,

I am using snmpV3 adapter and passing V2 traps to it by using commands as
below. It looks like the range for type *u* (i.e. unsigned) is upto (2^31)
- 1 (i.e. 2147483647). I was expecting it to be (2^32) - 1 (i.e.
4294967295).

snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5
1.3.6.1.4.1.12345.1 u 2147483647

Above command generates following log:
trace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 04 7F FF FF FF
dumpv_recv: UInteger: 2147483647 (0x7FFFFFFF)


snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5
1.3.6.1.4.1.12345.1 u 2147483648

Above command generates following log:
trace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 05 00 80 00 00 00
dumpv_recv: UInteger: -2147483648 (0x80000000)

Refer to:
http://www.net-snmp.org/docs/man/snmptrap.html

I am using net-snmp v5.5.

Is this the correct behavior or am I missing something?

Thanks.
Bill Fenner
2015-01-29 21:21:09 UTC
Permalink
I think that looks like a bug in dumpv_recv. Note that the hex value is
correct.

Bill
Post by Ashwini Pagade
Hi,
I am using snmpV3 adapter and passing V2 traps to it by using commands as
below. It looks like the range for type *u* (i.e. unsigned) is upto
(2^31) - 1 (i.e. 2147483647). I was expecting it to be (2^32) - 1 (i.e.
4294967295).
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5
1.3.6.1.4.1.12345.1 u 2147483647
dumph_recv: Value
dumpx_recv: 42 04 7F FF FF FF
dumpv_recv: UInteger: 2147483647 (0x7FFFFFFF)
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5
1.3.6.1.4.1.12345.1 u 2147483648
dumph_recv: Value
dumpx_recv: 42 05 00 80 00 00 00
dumpv_recv: UInteger: -2147483648 (0x80000000)
http://www.net-snmp.org/docs/man/snmptrap.html
I am using net-snmp v5.5.
Is this the correct behavior or am I missing something?
Thanks.
------------------------------------------------------------------------------
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-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Ashwini Pagade
2015-02-01 10:40:20 UTC
Permalink
Hi Bill,

Thank you for your response.

I think it is not just the dump/log error and incorrect value is propagated
further down the line. I have an snmpV3 adapter which receives the value.
This adapter too gets the incorrect value.

I think below line in function asn_parse_unsigned_int() in file asn1.c is
printing the incorrect value:
DEBUGMSG(("dumpv_recv", " UInteger:\t%ld (0x%.2lX)\n", value, value));

However I am not sure how this could be fixed. Data type of 'value' looks
correct which is u_long.

Any idea?

Thanks.
Post by Bill Fenner
I think that looks like a bug in dumpv_recv. Note that the hex value is
correct.
Bill
Post by Ashwini Pagade
Hi,
I am using snmpV3 adapter and passing V2 traps to it by using commands as
below. It looks like the range for type *u* (i.e. unsigned) is upto
(2^31) - 1 (i.e. 2147483647). I was expecting it to be (2^32) - 1 (i.e.
4294967295).
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5
1.3.6.1.4.1.12345.1 u 2147483647
dumph_recv: Value
dumpx_recv: 42 04 7F FF FF FF
dumpv_recv: UInteger: 2147483647 (0x7FFFFFFF)
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5
1.3.6.1.4.1.12345.1 u 2147483648
dumph_recv: Value
dumpx_recv: 42 05 00 80 00 00 00
dumpv_recv: UInteger: -2147483648 (0x80000000)
http://www.net-snmp.org/docs/man/snmptrap.html
I am using net-snmp v5.5.
Is this the correct behavior or am I missing something?
Thanks.
------------------------------------------------------------------------------
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-users mailing list
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Bill Fenner
2015-02-02 15:12:52 UTC
Permalink
Post by Ashwini Pagade
Hi Bill,
Thank you for your response.
I think it is not just the dump/log error and incorrect value is
propagated further down the line. I have an snmpV3 adapter which receives
the value. This adapter too gets the incorrect value.
Did you consider the possibility that a similar bug exists in the "snmpV3
adapter"?

Bill
Ashwini Pagade
2015-02-03 07:34:44 UTC
Permalink
Hi Bill,

I found below line is priting the wroung value.
Post by Ashwini Pagade
DEBUGMSG(("dumpv_recv", " UInteger:\t%ld (0x%.2lX)\n", value, value));
Changing %ld to %lu in above line worked for me.

I am also considering SNMPV3 adapter code which might be doing the wrong
conversion.

Thank you..!!

Ashwini
Post by Ashwini Pagade
Post by Ashwini Pagade
Hi Bill,
Thank you for your response.
I think it is not just the dump/log error and incorrect value is
propagated further down the line. I have an snmpV3 adapter which receives
the value. This adapter too gets the incorrect value.
Did you consider the possibility that a similar bug exists in the "snmpV3
adapter"?
Bill
Loading...