Madhu,
How are you supplying the values to net-snmp? Many of these can be
explained by net-snmp's internal representation (e.g., using "uint32" for
non-negative types, so supplying -1 turns into UINT32_MAX inside C, without
any explicit behavior on net-snmp's part. A lot of these limitations are up
to the MIB module implementation to enforce, so the issues that you are
seeing sound mostly like GIGO to me.
Bill
On Mon, Jun 19, 2017 at 4:09 AM, Madhusudhana R <madhusudhan...@in.abb.com>
wrote:
> Hi Coders,
>
>
>
> I have below queries regarding trap types where I found little mismatch
> with *RFC2578* definition and *net-snmp5.7.3* behavior on boundary
> values.
>
> It will be of great help if someone can clarify on this.
>
>
>
> For convenience, below definitions are used.
>
> *INT32_MAX* 2147483647 <(214)%20748-3647>
>
> *NINT32_MAX* -2147483648 <(214)%20748-3648>
>
> *UINT32_MAX* 4294967295
>
>
>
> 1. INTEGER/INTEGER32
>
> Since RFC 2578 does not mention the behavior for integer overflow,
> net-snmp currently sticks to *NINT32_MAX* or *INT32_MAX *for integer
> overflows on both sides. Please clarify what should be the actual behavior?
>
>
>
> 2. GAUGE32
>
> RFC2578 says “The Gauge32 type represents a non-negative integer, which
> may increase or decrease, but shall never exceed a maximum value, nor fall
> below a minimum value. The maximum value cannot be greater than 2^32-1
> (4294967295 decimal), and the minimum value cannot be smaller than 0 “
>
>
>
> But net-snmp wraps around to 2^31 – 1 for any value less than 0. This does
> not conforms to RFC definition. Is this a bug with in net-snmp?
>
>
>
>
>
> 3. UNSIGNED32
>
> RFC2578 says the range lies between 0 to 2^32-1 but there is no
> information on overflows. Currently for overflow net-snmp gives *UINT32_MAX
> *but for input value= -1 it wraps around to *UINT32_MAX*.
>
> What should be the behavior for -1 and integer overflow for this trap type?
>
>
>
> 4. COUNTER
>
> RFC2578 says counter range is 0 to 2^32-1 and should wrap around for
> *UINT32_MAX
> + 1*. But for overflow netsnmp remains at *UINT32_MAX *which is not
> RFC2578 complaint. Looks like a bug. Please clarify.
>
> Also for value =-1, net-snmp gives *UINT32_MAX *which wraps around on
> other direction. Is this correct behavior?
>
>
>
> 5. TIMETICKS
>
> RFC2578 says the range is from 0 to 2^32 which is bit contradictory as it
> violates basic unsigned 32 bit integer range. Currently net-snmp stands
> at *UINT32_MAX *for 2^32 input value. Please clarify on this.
>
>
>
> 6. BITSTRING
>
> This is little bit important query as I am not aware of how it should be
> used.
>
> Please let me know how the BITSTRING should be used along with few example
> for better clarity.
>
>
>
> I am aware that my queries are little bit lengthy but it is my humble
> request if anybody can answer these questions it will be of great help for
> me.
>
>
>
> Thanks in advance.
>
>
>
> Regards,
>
> Madhu
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
