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
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
