On Sat, Nov 28, 2015 at 9:00 AM, Tim Cox <timmiles...@gmx.ch> wrote:
>
> My agent (which is *not* NET_SNMP) may be obliged to force zero bits onto
> the front of unsigned data
>
> * counter*
>
> * TimeTicks*
>
> * gauge*
>
> I don't think an agent should need to do this, but manager NET-SNMP
> version: 5.4.2.1 is display-editing illogically
>
> Manager appears to understand that these data are unsigned, but
> sign-extends them before displaying them as unsigned
>
> with the result that unsigned 40,000 delivered in two octets *8xxx*
> displays as unsigned 4 billion
>
> It's obvious that signed integers should be transmitted with at least one
> sign bit, but nothing in RFCs suggests that *counter, timeTicks, gauge *are
> signed numbers in positive range, which would require a leading zero bit.
> The expression *positive*, which could be interpreted as meaning signed,
> and the expression *unsigned* are both applied to these data
>
Hi Tim,
This is a common misunderstanding about SNMP and its use of ASN.1. A
counter, for example, is defined as an ASN.1 INTEGER with a range limiting
it to 32 bits:
Counter32 ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
However, since it is encoded as an ASN.1 *INTEGER*, the underlying encoding
follows the INTEGER encoding rules - including the fact that ASN.1 INTEGERs
can be negative. You have to avoid on-the-wire encodings that end up being
negative ASN.1 values, because those are out of range for these unsigned
values.
Now, what should net-snmp do when it receives an out-of-range value? It
has basically three choices:
1. Assume that the entity encoding the value has a bug, and encoded a value
above 0x7fffffff as negative.
2. Assume that the entity encoding the value has a bug, and encoded a value
with a high bit set as negative.
3. Refuse to do anything, report an error in encoding.
It chooses 1. I think there's basically an equally valid argument for doing
any of the 3, but I like #1, because very few people write their own ASN.1
library so there are few libraries out there with bug #2.
Bill
> In any case, why display 32 bits unsigned having prepended 16 1 bits: *FFFF
> 8xxx* ?
>
> I could bend my agent behaviour, but I think this is a bug in NET-SNMP
> version: 5.4.2.1 manager
>
> Not a big one. Please enjoy
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
>
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
